[kplato] projects, subprojects and tasks

[j.d.lamb at btinternet.com]

I've been a bit busy reccently, but am catching up on all of this.

>  from:    Heiko Evermann <Heiko.Evermann at gmx.de>
>  date:    Thu, 08 May 2003 13:40:46
>  to:      kplato at kde.org
>  subject: Re: [kplato] projects, subprojects and tasks
> 
> Hi Thomas, hi everyone,
> 
> 
> After some more analysis, this is what I found:
> 
> Concerning Milestones:
> MrProject does not seem to have them: 
> http://www.mrproject.org/user-guide.php does not tell us about them.
> MS project has a very simple way of defining milestones: if a task has a 
> duration of 0, then it is a milestone. There do not seem to be further 
> restrictions. It can be predecessor or successor to other tasks, of 
> course. It can even have subtasks. I tried it out. If you have a task A 
> with two subtasks B and C and note 0 duration for B and C, then A has a 
> duration of 0, too, and all three get displayed as a milestone. That 
> means they are displayed as a diamond and the date is displayed.
> 
> So my proposal is to drop the class KPMilestone and just to handle tasks 
> with zero duration differently in the display. I think this makes things 
> easier.

Tasks with zero duration can already be handled: indeed they are strictly necessary for CPM.

I wouldn't personally use milestones, but they don't get in the way of any other code and may later be useful for resource handling. I think that if someone wants them, they should can have them, otherwise they can ignore them.

> 
> Concerning subtasks:
> I am more and more convinced that it would be better  not to use 
> KPTProject for Tasks having subtasks, as this makes the object handling 
> lot more complicated.

I think that was my idea though I might be mistaken and I don't take my ideas personally: about 90% of them just don't work.

I think KPTProject for tasks with subtasks does work. Whether the UI presents the project this way is another matter. But it has a number of advantages in terms of programming. For any task we need sometime to can work out its duration. A simple task and a task with subtasks work out durations in a different way. Arranging tasks and subtasks like this lets us use recursion for calculations.

There are some other advantages and disadvantages. It is a little harder, but not impossible, to disassemble a subproject. On the other hand, it makes it easier to copy whole subprojects from one project to another.

Note that the project/subproject need not be the same thing as work breakdown structure. I recall having a discussion with Thomas about this in which I concluded he was right about how things should be structured.

> 
> Concerning KPTProject:
> At first I thought it might be completely unneccessary. But something 
> else is neccessary: I think we ought to have a model for the program, 
> following MVC. kdeedu/kstars, for example, hase a model called 
> KStarsData, where all application data is collected. Of this we have one 
> instance. If we have something like this in kplato, we could even have 
> an empty project. Just try this: Run kplato, state that you want to 
> start with an empty document. kplato then asks you about project data, 
> which is a bit surprising as you stated that you wanted to start with an 
> empty document. Cancel that dialog, and you get an almost empty view, in 
> pert as in gantt, it just looks a little bit funny. So it would be good 
> to have a model for the whole program to work on. This model should be 
> able to hold an empty list of tasks to get an empty display in the 
> beginning. So far so good. But this model must support adding and 
> deleting tasks, so in the end it must be able to do what KPTNode already 
> knows to do. Apart from that it should hold other things like author 
> information etc. So my conclusion is that the main model best is 
> modelled as a subclass of node.

That looks interesting.

> 
> Summary:
> * base class KPTNode
> * class KPTTask : KPTNode for tasks and subtasks
> * class KPTProject : KPTNode for the main model. This does not get 
> displayed in the gantt/pert views. For its properties (we might invent 
> many) we will have a menu entry: "edit project properties" and a fitting 
> dialog.
> 
> Some things in the views etc. will have to be changed and some code will 
> have to be moved, but not that much. After that, implementing further 
> edit capabilities like indent/unindent should be easy.
> 
> Comments?
> 

One of the criticisms of M$ project is that it is very restrictive about what the project Gannt chart looks like. I'd quite like to see the possibility of having either/both of the following, though the UI designers might say I'm asking for too much:

1. A Gantt chart that lets you specify days/hours as holidays/non-working times. I think MRProject already does some of this. I's certainly like to be able to turn individual days off or specify the start/finish times.

2. The possibility to display the Gantt chart without a calendar and with variable scale (e.g. display in days or hours or weeks of
total time, ignoring weekends, etc.) This would be useful for me: the only things I really need project planning for, I tend to specify (say), total of 137 hours and a task length for each task. Actually fitting it all to a calendar would be too much, but I could accept a fictitious start date provided I could display everything in hours and specify how many were left.



JDL