[kplato] Functional Breakdown

[John D Lamb]

Looks good. I have a couple of queries and a suggestion.

Is task ID specific to a project? or could tasks be available to more
than one project. I had imagined that a project would contain an STL
vector of pointers to Tasks. Each task probably ought to have
a) a name (class Qstring )
b) an id ( unsigned long ) (but owned by project or by task?) to allow
names to be blank or duplicated.
c) rest of list in 2.
d) private data for calculations.

My suggestion is that 5. could be covered by a generic "Distribution"
class that could return values such
as
Time duration();
Time optimisticDuration();
Time pessimisticDuration();
Time minimumDuration();
Time randomDuration();
where Time is either QTime or some sensible duration measure (possibly
typedef unsigned long representing seconds).
The simplest Distribution would be a "Fixed" distribution, where all
functions returned the same value.
More complicated distributions could return more than one fixed value or
could be true distributions such as the Beta, uniform or triangular.
randomDuration() could be used for Monte Carlo estimates.  
I envisage Distribution as having an STL vector of parameters.
Initially, kplato could implement only the Fixed distribution - anything
else that was needed could be derived later from the base class, which
would effectively be a Java-style interface.

I didn't fully follow the logic of the low and high risk. I'm sure it
makes sense, but I can't yet see how.

Also, what do you mean by WBS terminal nodes - again, probably me not
guessing the obvious.

Jim Sabatke wrote:

> 2.    Assign Task Duration Type to tasks.  Example Task Types:
>            Start On Date (Earliest Start)
>            Finish By Date (Latest Finish)
>            Work Between Dates (Earliest Start - Latest Finish)
>            Milestone
>            Percent of Project - Usefull for tasks like management hours
> which are a function of the duration of the entire project.
> 
> The Task Type can be taken from context.  Manually entered dates could
> be considered constraints.  Where dates are not manually entered, the
> program would be free to assign start/finish dates.
> 
> ** Important Note ** As a general rule, manually entered data should
> take precedence over calculated data.  The program should not change
> manually entered data.  One of the most annoying things about M$ Project
> is that entered data are often changed.
> 
> 3.    Assign an unchanging Task ID to each task.  The Task ID would be
> assigned in sequence starting with 1.  The Task ID for a task would not
> change if the task order is changed in any way.  This is especially
> useful for external programs that might be expecting task IDs related to
> certain tasks.
> 
> 4.    Assign task dependencies - a list of Task IDs that must be
> completed before the current task begins.
> 
> 5.    Allow task durations to be calculated from the following columns:
> 
>         "Optimistic Hours"    "Pessimistic Hours"  "Expected Hours"
> "Risk"    "Duration"
> 
>         The "Duration" would be calculated like:
> 
>         "Risk" = Low        Duration = (OH + 4EH +PH) / 6
>         "Risk" = High      Duration = (OH + 4EH + 2PH) / 7
>         "Risk" = None      OH = EH = PH = "Duration"
> 
>         If Duration is entered, then OH, PH, EH all will be set to
> "Duration" and "Risk = None"
> 
> 6.    Durations should only be enterable for WBS terminal nodes.