Is a part of the Prototype Requirement (issue 57601) until stated otherwise

Basically, we could summarize this as having an initial plan, or as someone else
has coined it, a base line for the project, and, its actual outcome, aka runtime
state, which is basically a deviation to the base line.

While most of this is evaluation of the actual state of the project in
comparison to the planned state of a project, some of the information must also
directly be available in the visualizing part of the software.

And, while we're at it, not always the planned time required for a certain task
to complete, incl. also buffer time, is sufficient to get the task actually done.

We should also allow the software/data model, to provide for prolonging of tasks
due to, for example, their overall complexity and unforeseen
circumstances/uprising problems.

So we actually have to deal with three situations:

1 tasks complete just in time and is according to plan
2 tasks complete way below the planned time effort
3 tasks require more time due to uprising problems and other reasons for delay

While 1 and 2 can simply be implemented using an additional field, 3 would
require some more thought as to how the situation is dealt with.

This might actually also include sub tasking a given task, adding more solution
providing tasks that will fix the situation at hand. An example task would be
for example:

Rollout LDAP on the latest your-favorite-linux-distribution-here release version
and apply the company's ldap schema to it and also replicate the existing
database to the newly installed ldap server. Scheduled time: 4h.

It then shows that ldap cannot be installed from out of the box, so that the
time schedule can be met, in fact, it may even show that ldap actually cannot be
installed on such a system due to packaging/installation routine errors etc.

This would require that the whole task is to be set into question on whether it
can be solved in a given time frame.

Since the baseline of the project plan is being locked, according to someone's
proposal, the effective project plan needs to be changed, so that additional
tasks might come up, provably as sub tasks of the original one, for example
Setup Additional Test System, time: 4h
Test Deployment, time: 4h

and so on.

For the actual implementation I would therefore presume that we

- use the project's initial plan, or baseline as the basis for the runtime
- and that we will use the actual outcome of the runtime project, as data gets
entered into the system for "real-time" comparison with the initial plan, or
baseline

So that we might actually have two sets of data, one for the initial plan, and,
second, for the running project.

In the (object oriented) data model we will thus have to provide for 

a) project "plantime" data, and,
b) project "runtime" data

 

Reset assignee on issues not touched by assignee in more than 1000 days.

obsolete