[kplato] Summary of Data Discussion

[Chris Clarke]

On Tuesday 19 June 2001 11:46, Thomas Zander wrote:

Thomas,

Thanks for the comments.  It looks like we're making a lot of progress here.

[Task definition]

> I think you forgot Task Type in your task here..

D'OH!  That's what I get for only having three coffees yesterday.

It's now in the list.

> > Constraint: Duration my only be entered if {Task} is empty
> >
> > 4.1.3. Task Type
> >
> > Task Type ::=
> >   ConstraintType ::= [Start On Date | Finish By Date |  Work Between
> > Dates | Milestone | Percent of Project] +
> >   Constraint ::= [Entered Date | Calculate]
> >
> > (Jim: this was what I got out of your email.  Were all 5 items supposed
> > to be a task type?  I'm not sure how the last two fit in)
>
> Well, it seems logical to have them here.
> But from a data-modeling POV those are not tasks, those are points in time
> (where a task would always be a length of time). So they can not take
> resources, they have no relationships or subtasks.
> Therefor, again from a data-modeling POV, the "Milestone" and "Percent of
> Project" types should be something like 'CheckMarks'.

Both of these things I see as objects in the PERT chart, with relationships 
to other tasks.  For instance I might define Milestone1 as a block on the 
chart that depends on the completion of tasks A, C, and E (i.e. when A, C, 
and E complete we declare Milestone 1 achieved).  There may also be tasks 
that contractually I cannot begin until Milestone 1 is achieved.

Given that from the programming point of view I now see Milestone as a 
seperate object that derives from the same base class as a task, because they 
do share a lot.  Something like:

Item ::=
  ID +
  Name +
  {Relationship}

Task ::=
  (inherits) Item +
  Task Type +
  Duration +
  Status +
  {Task} +
  {Resource}

Milestone ::=
  (inherits) Item +
  Milestone specific data (e.g. payment!)

Based on Jim's comments it seems that we should also be putting Resource into 
this tree, inheriting from Task.

[Snip duration]

> > 4.1.6. Relationship
> >
> > Relationship ::=
> >   Preceding Node +
> >   Type ::= [ Finish-Start | Finish-Finish | Start-Start ] +
> >   Lag
>
> Lag is an implied value, ask the relation (the preceding node)
> for its lag, it should now this.
> It does not belong in the data-model (ehh, format ;).

Another one for the glossary :-)

I think you're talking about what I call float, which is the amount of time 
the end date of a task can drift before it affects the schedule.

My meaning for lag is the additional time required between two tasks.  For 
example, Task B is expected to complete 3 days after Task A completes.  The 
relationship for B would look like:

Preceding Node=A
Type=Finish-Finish
Lag=3 days

A real world example of this type of relationship occurs in testing. 
Developing the software and developing the test are two tasks that can work 
in parallel (and at the system test level there is no relationship between 
their start dates -- I've seen tests developed 2 years before the coding was 
to start).  A couple of days after the module is complete I will conduct the 
regression test and sign off, so my task will complete 3 days after the 
coding.

Cheers,
Chris.
-- 
Chris Clarke
security@cfourconsulting.com
http://cfourconsulting.com