* Added configuration option for enabling this menu tab
* Montecarlo method calculates a range of enddates and its corresponding
likelihood. For each task of an order, there are three possible
durations (pessimistic, normal and optimistic). Each duration is
associated with a likelihood value. A montecarlo calculation, generates
for each task a random value and takes the duration of the task
associated to this random value, summing each value for each task, the
resuling value is the hypothetical enddate of that order. This operation
is executed n times. The higher the value, the more accurate the
results, although there is a threshold limit.
FEA: ItEr63OTS06MonteCarlo
Now the mode is changed after hiding the previous tab, so the previous
tab is not repainted and the new tab is showed with the correct mode.
FEA: ItEr63S03BugFixing
Adds a new type of allocating function.
This function allocates hours into resources following a Sigmoid
function.
Known bugs:
* The calendar of a resource (Specific) or the calendar of a Task
(Generic) is not being respected. For instance, the algorithm allocates
hours on bank holidays.
* By default, the algorithm only considers periods of time of 1 hour. If
the calculation estimates an allocation of 0.25 hours for one day, the
result if truncated to 0 hours. This usually happens at the beginning
and at the end of task. Solving the problem at the beginning is easy,
just need to skip allocations with 0 hours assigned, shifting to another
day. But this is not a totally satisfactory solution as it leaves gaps
by the end of the task. To solve this, one solution could be to increase
the period of time by one day at the end, till there won't be 0 hours
allocated on the last day.
FEA: ItEr62OTS04FuncionCurvaS
The combobox for selecting type of assigment function (advance
allocation) is created every time the user changes the zoom
leve
FEA: ItEr62OTS04FuncionCurvaS
The problem lied in that the end date of the task group was being
updated keeping the length when the start changed. Since the children
of the group were not modified when adding the milestone the end date
was not recalculated and the wrong value persisted.
Calculating the end date keeping the length in task groups is
incorrect since their end date doesn't depend on the previous length,
but in the incoming dependencies. Several refactorings and
simplifications applied thanks to this insight.
FEA: ItEr62S05BugFixing
Fixed bug, changing the checking if the element is a Task
by an checking if the element is ITaskLeafConstraint,
what permit to move and to update too the milestones.
FEA : ItEr62S05BugFixing
When the start was inside a day and the hours to allocate just
completed the day, the end date should be moved to the next day but it
was returning the same day.
FEA: ItEr62S05BugFixing
By default, if they are not specified, the start and end are taken
from the task. This allows to calculate resources per day correctly
when doing backwards scheduling. The external behavior is the same for
resource allocations' start date. For the end date now instead of
returning the date of the last day assignment, the date set at the
reset method would be returned.
FEA: ItEr62OTS04PlanificacionHaciaAtras
Otherwise in subsequent updates on a allocation with a consolidated
part the resources per day could be different than the specified in
the last modification.
FEA: ItEr62OTS04PlanificacionHaciaAtras
