[kplato] Functional Breakdown

[John D Lamb]

I'm not sure what this bit about columns means yet (though I think I
could make a good guess), but I think I follow the rest now.
I suppose a project might be broken down something like the following
example

                Project( root node )
                       |
         +-------------+----------------+
         |             |                |
      Task A        SubProject B      Task C
                       |
               +-------+---------+
               |       |         |
             Task P  Task Q    Task R

Hence WBS tree. Two things occur to me.

1. Project, subproject and tasks all have a lot in common; so might be
derived from an abstract base class (say) Activity with functions for
duration, start time, etc.:

                   Activity
                       |
                +------+------+
                |             |
              Task          Project


Then a project would simply contain Activities which might be tasks or
(sub)projects, but which for most purposes could be treated the same.
It would be useful to be able to manipulate this so that a suitable
group of Activities could be grouped
as a subproject by user or expanded.
I too think this sort of structure could make the code more efficient.
There should be no difficulty applying PERT to this structure.
Surely, it would make a project easier to represent.

2. This sort of structure might make assignment of resources (e.g.
assignment of people to perform tasks) easier, though resource balancing
might require temporary expansion to a project of leafs (or tasks or
end-nodes). That should be OK as long as it's not made visble to user
how implementation works.


The risk assesment stuff looks as if it could easily be put into the
task or calculated for a subproject.

JDL

Jim Sabatke wrote:

> Regarding code:  I think that each column, or sometimes groups of
> columns, should have its own class to keep calculations independent and
> relevent to the column(s).  We might be talking code just a bit early,
> but I certainly agree with your analysis.