[kplato] Functional Breakdown

[Jim Sabatke]

You are pretty close.  The only thing I would change is the meaning of a 
"subproject."  I would call your "subproject B" as "task B," and "task 
B" has "subtasks".  A subtask is just a task that has a task as a parent 
node.

I would define a "subproject" as a WBS tree that can be opened in KPlato 
by itself, and where the root node would be a subtask in the "main" WBS.

Using your diagramming, which I think is a really clear way to explain this:

                                Project (WBS Task 1)
                                                 |
                +-------------+--------------+
                |                              |                         
        |
            Task 1.1                 Task 1.2                   Task 1.3 
(Task 1.3 is a sub-project)
                                                 |                       
          |
                            +--------+-------+              
+------------+---------------+
                            |                   |                |       
       |                            |                                   |
                       Task 1.2.1  Task 1.2.2  Task 1.2.3 Task 1.3.1   
 Task 1.3.2                   Task 1.3.3

I think that implementing subprojects might be a bit overwhelming for 
early versions of KPlato. 

I agree with the analysis that a task class should be created to 
encapsulate the calculations.  The class should be based on a "general 
tree" type of classs.

John D Lamb wrote:

>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.
>>
>_______________________________________________
>kplato mailing list
>kplato@master.kde.org
>http://master.kde.org/mailman/listinfo/kplato
>
>

-- 
Jim Sabatke
SuSE 7.1 Linux
Kernel - 2.4.0
http://www.execpc.com/~jsabatke

"People tell me that I'm fading fast, that I can't last the whole night through" Janis Ian