[kplato] Re: kplato
John Lamb
J.D.Lamb at btinternet.com
Wed Mar 3 21:19:38 CET 2004
Dag Andersen wrote:
>>By subtask, do you mean a collection of tasks (almost like a
>>miniproject?) That can be handled by PERT/CPM modification so that
>>the collection has a defined duration gotten by calculation.
>
> No, I meant the oposit. A subtask is one of the tasks in a
> collection :) A task that have subtasks (children) is a summary task
> (also sometimes called a container).
> A summary task does not have resources, duration etc, it just sums up
> its subtasks. So the summary task starts when the first subtask
> starts and finishes when the last subtask finishes.
> One thing a summary task can have is relations. Linking a task to a
> summary task should have the same effect as linking the task to all
> the summary tasks subtasks. (puhh)
OK. Not implemented in pert/cpm. But could easily be implemented.
>>I really meant a little more. The functions to add and remove
>>nodes, etc., could be separated. Maybe that's not so practical.
>
> Yes, I had a feeling it was more to it.
> Well, from the code a can see that there are a number of functions
> involved.
> These are defined in KPTNode:
> - initialize_arcs
> - set_up_arcs
> - set_unvisited_values
> - set_pert_values
> They all mine data from the node and recursivly from its children, so
> to separate these from KPTNode, I'd say you need a "copy" of the
> project node structure for them to operate on.
>
> These are defined in KPTProject:
> - pert_cpm
> - forward_pass
> - backward_pass
> These gets duration from each node and writes back
> erliestStart/latestFinish.
>
> So one way to do this is to give you a "copy" of the nodes (doesn't
> *need* to be a full copy, only the info you need) then you calculate,
> store the results in the "copy" and returns it. It is then used to
> update the nodes.
> What do we gain? We can make PERT/CPM independent of KPlato, of
> cource. Other than that, I don't know.
That was probably the main gain for me. If pert/cpm is independent it is
easier to test robustly.
> OTOH, there might be other ways to do this, and if you rewrite, who
> knows?
Maybe an interface class. I'd need to look more at this.
>>eventually pert/cpm might call any duration function so probably
>>ought to be called with a pointer to member function argument whose
>>default argument was expected duration. This would allow standard
>>pert/cmp and also monte-carlo type stuff.
>
> Or called with an enum specifying what "type" of duration to get, so
> that PERT/CPM calls node->duration(type) instead of
> node->expectedDuration() as now?
>
That is probably better. It's a little more flexible and certainly more
readable.
>>IIRC that's right. The problem is I don't recall and I don't see
>>what the rest of the code does with this information. pert/cpm is
>>not yet suggesting when a task should start - just when it could
>>start.
>
> Yes, atm I use earliestStart/latestFinish together with duration and
> ASAP/ALAP to place the node within the timespan. I think ASAP/ALAP is
> not a problem, they don't really affect the PERT/CPM calculations (at
> least not before resources are considdered?.) The other constraints
> will do, though:
OK, very useful to know.
> Start Not Earlier Than, Must Start On etc means that pert_cpm must
> place these node on specific times and it may not be possible in
> which case erros must be signaled.
a modified pert/cpm can handle these.
>>Good idea. I can write the function. It will be easier if you can
>>say what you want it to return. If it's called before a new
>>dependency is added all it must do is check the dependency and
>>return true/false. If you want something more robust (maybe someone
>>introduces several bad dependencies) then it could return a list of
>>possible dependencies where at least one had to be removed.
>
> I was thinking: when a dependency is defined it is checked for
> validity and rejected if it's not ok. There are atm 2 ways to define
> a dependency:
> - In a dialog
> - Loading from xml file
> So I think this should be checked there and then, and we can forget
> about it elsewhere.
>
It was the XML-style that concerned me more. Actually, it could probably
be handled at load time because dependencies would be added one by one.
>>OK. But PERT/CPM will also have to tell whether the project is
>>feasible. This is necessary eventually anyway. If there are no
>>resources but a task needs some then it can't be done. What sort of
>>information would be useful to the user? Maybe a list of tasks with
>>unsatisfied constraints.
>
> I was thinking of error information stored in each node/resource, then
> the ui can decide how to present it.
>
That is a good idea. The pert/cpm code still would not have to
communicate directly to the interface.
--
JDL
Non enim propter gloriam, diuicias aut honores pugnamus set propter
libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
More information about the kplato
mailing list