[kplato] Resources

[John Lamb]

I've had some thoughts on how to use resources within the PERT 
calculations. These are only half-formed and would need development 
before I could implement them in code.

As a motivating example consider the following resources available over 
five days.

Alice:   C++ programmer available Monday-Friday
Bob:     C++/Python programmer available Monday, Wednesday and Friday
Charlie: Python programmer available any 2.5 days.

We can imagine various combinations of these forming actual resources 
(or resource groups)

C++ programmers:     contains Alice and Bob   (OR)
Python programmers:  contains Bob and Charlie (OR)
programmers:         contains C++ OR Python programmers
programming team:    contains ONE C++ programmer AND TWO Python
                      programmer

This suggests to me three types of resource:

1. Atoms (like KPTResource)
    contain name of resource, availability and appointment.
2. Pooled (OR) resources (like KPTResourceGroup)
    contains a list of resources and quantities: actual resource
    used will be, for example, 1 x Alice OR 1 x Bob
3. Combined (AND) resources
    contains a list of resources and quantities: actual resource
    used will be, for example, 1 x Python programmer AND 2 x java
    programmers

This is relatively easy to handle from a user's point of view though 
there may be some advantage in hiding some of the detail. For example, 
each task might be given a combined resource without a user having to 
construct it explicitly.

The reason for suggesting it, however, is that it may be advantageous 
from an algorithmic point of view. Mathematically, resources would be 
structured as a finite atomic Boolean lattice (only a little more 
complex than the tree used for work breakdown structure). This would 
allow us to find very fast the Atoms that make up the resource. So, for 
example, in assigning a programming team for Wednesday, we could very 
quickly find that there was precisely one unit of resource available 
without having to know explicitly that it was either (Alice AND Bob) OR 
(Bob and Charlie). We could even do a PERT schedule and leave the user 
the option of choosing which Atom to use where.

There are various common functions, which suggest to me a class 
hierarchy for resources. If we want to know whether a resource is 
available for Wednesday (a period of time), the calculation is different 
depending on whether you ask the question of an Atom, a combined 
resource or a pooled resource, but the function takes the same 
parameters (a start time and duration) and returns the same answer (true 
or false). It should even be possible to assign any particular type of 
resource to a time slot (another base class function) without specifying 
which particular Atom to use. This defers the assignment of Atoms to 
after the PERT schedule is generated.

+ + +

At the moment KPTResource contains time slots (appointments) structured 
as KPTAppointments much like a histogram (in the sense used by the GNU 
Scientific Library*). Essentially a histogram comprises a start time and 
set of pairs (duration: amount). I'd also add a total availability to 
allow for flexible resources. So, for example, if a day has eight hours, 
we'd have

Alice:   Monday, (40.0, 1.0), 40
Bob:     Monday, (8.0, 1.0), (8.0, 0.0), (8.0, 1.0), (8.0, 0.0)
                  (8.0, 1.0), 24
Charlie: Monday, (40.0, 1.0), 20

There are a couple of differences in the structure of KPTAppointment. 
There's probably no good reason to change them because they contain the 
same information available in essentially the same time. It might be 
useful to add to them (e.g. to change amount of resource available in a 
time slot or to allow for a total amount of resource available over the 
project).

+ + +

I think it would be valuable for an Atom to have availability (and hence 
any resource can calcuate availability) but resources separately have 
appointment (or assignment) to a task. I think at the moment 
KPTAppointment has a task assigned (could be null?)).

Essentially I envisage three levels of task<->resource information

1. (a) Resource availability (appointments not assigned to a task)
    (b) Resource suitability (A task specifies a (combined) resource)

2. Resource appointment. As part of PERT/CPM algorithm, resources are
    assigned to tasks so that total resource usage matches limits
    (possibly moving start times for task to achieve results)

3. Atom appointment. Either automated or user-specified appointment of
    individual resources to tasks (step 2 may leave a choice)

+ + +

Another thought:

It's possible to display Resource availability/usage/appointment in a 
Gannt chart. What does this suggest about sensible structures for 
storing the availability/usage/appointment information.

+ + +

Questions:

How should working hours be used (see KPTResource.h)?
How would you specify cost/availability/preference for extra resources?
Maybe put a cost on resources with a default of zero.
What is needed for compatibility with KDEPIM?
What have I misunderstood?


+ + +

Comments:

Please. I'd like to try coding this (simple private test in Python then 
in C++ on the real code).

JDL

+ + +

*I'm not actually proposing that we use the GNU Scientific Library for 
histograms: it's written in C rather than C++, doesn't have all the 
features we'd need and uses doubles where we'd want to use KPTDuration. 
A C++ class would be easy to write. On the other hand, I would suggest 
using the GNU Scientific Library for implementing anything more than the 
simplest RISK/PERT calculations (e.g. Monte Carlo estimates) because it 
has some excellent random variate generators.

-- 
JDL

Non enim propter gloriam, diuicias aut honores pugnamus set propter
libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.