Re: kplato

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.