[kplato] Summary of Data Discussion

[Anders Johansson]

Exactly how are you defining resource. My definition would be a person 
working in the project. I think resource is an independent class like

resource {
	functionInProject string // i.e. developer, sub-project manager or something
	linkIntoKDEPIM pimId	//linking the resources of the project with the rest of 
KDE's resources for groupware functionality
}

I'm currently reading up on the structure of KDE, but it's a moving target, 
so the current info is sometimes a bit hard to find. Especially pim seems to 
be undergoing a radical reinvention right now.


On Tuesday 19 June 2001 22:27, Chris Clarke wrote:
> 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.