[kplato] Some code for KPTProject::getDuration()

[Thomas Zander]

--Bu8it7iiRSEf40bY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 19, 2001 at 07:03:52PM +0100, John D Lamb wrote:

> > > Second, I haven't yet understood how kplato
> > > will deal with activities that have already finished in a project.
> >=20
> > A node has a starttime and an endtime.
> > If not started, starttime is 0, if not ended endtime is 0
>=20
> I think there is rather more to it than that. Consider nodes A, B, C, D
> with time dependencies A before B and C and B and C before D and fixed
> durations 5, 10, 5 and 5 days respectively. The relative start times
> would be (A) 0, (B) 5, (C) 5, (D) 15 assuming all nodes start as early
> as possible (more later). My question is if (say) Activity A started on
> November 1 and today is November 3, how do we represent start times? At
> very least we need to know the current date and which nodes have
> started/completed.

My comment was from a data structure POV, if the user signals task A has=20
ended, we update the data structure to reflect that, in this case by
setting the endtime to that specific data.

The PERT analytical will then tell us that B will start at the same time as
A ended (we know that exact time) and allow C to start at that time
as well.

The user can then tell KPlato to start, which will set the starttime of node
C to that exact time, again changing the of the PERT.

Will that do?

> > > Third, functions like getDuration will have to call the basic PERT/CPM
> > > routines many times if we want a Monte Carlo simulation for the likely
> > > outcome of a project.
> >=20
> > But a PERT/CPM duration call will always return the same for a leave no=
de,
> > right?
>=20
> getDuration() won't return the same value each time if we use random
> numbers, even for leaf nodes. Maybe this is a problem that could be
> deferred till later. If we use subprojects then there is an efficiency
> issue. PERT/CPM on the project needs the duration (as a constant value)
> of each node at least twice; it's not efficient to use a function call
> for this for subprojects. One solution is to store the fixed values as
> hidden data in the node.

I was thinking that getDuration will always return the same value and=20
getRandom duration will provide a random function to add/subtract from
that value.
So to store the duration seems logical, but this will probably prove=20
more difficult then that, lets wait with this issue a bit.

> > If I read your code well, the only thing PERT does is put all tasks
> > head to tail and then count the duration of the task.
> > It naturally accounts for things like dependencies, risk,
> > availability of resources etc.
>=20
> I'm not sure that this isn't an oversimplification. The PERT/CPM code
> (implicitly) finds a critical path.
I work with sales people often, my job is to tell it simple ;)
I do think we understand each other though.

<snip>
 =20
> > but also:
> > - a leaf node either has a start time set (which can be 0) or has a sta=
rt
> >   dependency on another node. The last one can be calculated by asking
> >   the dependent parent its end time and using the lag of the kptRelatio=
n.
> >   This means that a non-leaf node can _not_ have a start dependency, ri=
ght?
>=20
> Probably these should be earliest start and latest finish. In the
> example above, Node C had duration 5 but earliest start 5 and latest
> finish 15. It could start any time between 5 and 10 days. The choice
> might depend on availability of resources. PERT/CPM gives the earliest
> start and latest finish, but also the total float and free float

My point was that to be able to get an end time, you need a start time. The
end time is used in PERT again, so you are probably right that this has to=
=20
be earliest start and latest finish. Though then they do not fit in the=20
method names we made in the current design anymore.


> If a non-leaf node represents a subproject, it ought to have start
> dependencies just like the leaf nodes in the project.

Hmm, then we have to override that calculation stuff in the kptproject clas=
s,
oh wait; we had to do that anyway ;))


> > - for a leaf node: end time =3D start time + duration ;)
>=20
> earliest end =3D earliest start + duration. The actual time chosen to
> start an activity need not be the earliest possible time.

Right.

> > - a non-leaf node can tell its start time by asking all children their
> >   start times and returning the smallest one.
>=20
> True, but there is a more efficient implementation if the non-leaf is a
> subproject (I don't know if it could be anything else) because PERT/CPM
> applied to a project would effectively have to calculate an earliest
> start for the subproject just to calculate everything else.

But that is true for all nodes, if you want to know how to plan your=20
resources, you need to know the times they are needed. Hence a start time.
But lets wait a little with resources as well..

> > for non-leaf nodes the expectedDuration is calculated as:
> > - taking the startime of this leaf (as defined a number of points back)
> >   taking all the children nodes and asking them their end time
> >   (starttime + duration) and taking the largest end time (last one)
> >   end time - start time gives expected duration.
>=20
> Again true, but probably not the most efficient way.
>=20
> There is another subtle issue with expected durations if the duration is
> not fixed: the expected duration of the project is in general greater
> than the sum of the expected durations of the critical path nodes. As an
> example, if the duration of the node C is not fixed at 5 days but
> exponentially distributed with mean 5 days, then the expected duration
> of the project would become nearly 21 days.

Thats wierd..
=20
> Where do you want to go next?

Give me a day to think this over ;)
(Thinking about a recursive algoritm that fills a data-set by asking releva=
nt
nodes for their info, updating the data-set when more info becomes availabl=
e)

--=20
Thomas Zander                                            zander@earthling.n=
et
The only thing worse than failure is the fear of trying something new

--Bu8it7iiRSEf40bY
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7gVRkCojCW6H2z/QRAgJ1AKDZrPpOaSxZgqZhiwYMPykyA31EjwCfV/sp
XxJo1sxlrzl0zzpTNX3JW64=
=T4KM
-----END PGP SIGNATURE-----

--Bu8it7iiRSEf40bY--