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

Thomas Zander kplato@kde.org
Thu, 16 Aug 2001 22:56:38 +0200


--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi, sorry for the delay...


On Sat, Aug 11, 2001 at 08:36:04PM +0100, John D Lamb wrote:
> I've had a look at Thomas Zander's code. I don't actually follow all the
> concepts; so I've had a first stab at writing the code to handle
> PERT/CPM. I've used a substantially simplified and slightly modified
> version of kptnode because it made it easier to test the code robustly.
> At the moment, it will compile with
> g++ kptnode.cc

Hmm? Doing a rm *.o and an make install takes a whopping 30 seconds=20
here, is it so slow for you?

Well anyway, it does not compile for me, so I was stuck reading code.
(the error: undefined reference to `cout' tells all ;)

> I've used STL a lot because it is very efficient and gives reasonably
> compact source and object code. I don't know how easy it is to
> substitute the STL list with a QList. In any case I think there's a
> couple of good arguments for writing a core library that doesn't use Qt
> (even though I suggested durations as the Qt class). First, we'll need a
> lot of algorithms that are already available efficiently in STL. Second,
> the library could be used outside this project. Third, it may be easier
> to test (debug) the code as a library seperate from the GUI. The obvious
> argument against is that we'd have to write conversion functions for an
> interface to the Qt part - I can't think of a good way to counter that.
> :-)

Have you used QT? The reason I use it is because it solves all sorts of
problems the STL has, not the least being unicode.
If liking is the problem, use a stripped-down version of QT, its only
400Kb

The reason I like QT is because I am a lazy programmer, and I use the
huge library of stuff from QT, its not because I have to use it or=20
something.

> The code itself raised some issues for me. First, a lot of the core
> functions like getDuration need PERT/CPM to have been done before they
> can return a sensible value.=20

Whats the problem there? (getting back to that later)

> Second, I haven't yet understood how kplato
> will deal with activities that have already finished in a project.

A node has a starttime and an endtime.=20
If not started, starttime is 0, if not ended endtime is 0

> 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 node,
right?

> Please let me know if you can do anything with this or see improvements.
> Clearly, we need more data-hiding.

 :-)


If I read your code well, the only thing PERT does is put all tasks=20
head to tail and then count the duration of the task.
It naturally accounts for things like dependencies, risk,=20
availability of resources etc.



What I think we should do is the following
- only leaf nodes can have an actual duration (the rest only ask the childr=
en
  how long they take to complete)
- A leaf node can simply return the duration it has set as expectedDuration.
- A leaf node can simply return the duration it has set as randomDuration.
- A leaf node has resources and associated risks as well as start-end-time
  dependencies which define the distribution which has to be used in=20
  parent nodes to calculate the duration.
- a non-leaf node has to return an expectedDuration based on PERT.

but also:
- a leaf node either has a start time set (which can be 0) or has a start=
=20
  dependency on another node. The last one can be calculated by asking
  the dependent parent its end time and using the lag of the kptRelation.
  This means that a non-leaf node can _not_ have a start dependency, right?
- for a leaf node: end time =3D start time + duration ;)
- a non-leaf node can tell its start time by asking all children their=20
  start times and returning the smallest one.

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=20
  (starttime + duration) and taking the largest end time (last one)
  end time - start time gives expected duration.


As you see I made so many points it gets boring. This is not by excident bu=
t=20
by design, this is also the design in kptnode, and almost each of the poste=
d=20
points above is one method call.
Therefor the above has to be implemented to do the PERT calculation correct=
ly.
I am willing to do that, but first I would like to hear opinions if the abo=
ve
is correct.


ps. resource allocation is still missing from the above..

Thanx John, it was a really good learning program, just not for prime time=
=20
usage ;)

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

--2fHTh5uZTiUOsy+g
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

iD8DBQE7fDOGCojCW6H2z/QRAk+BAKDbiCP/L4M3dFccGDP8pBhJfiRqjACfZGfT
FZaTWzmJSpD1a4EyT387vZg=
=k713
-----END PGP SIGNATURE-----

--2fHTh5uZTiUOsy+g--