Re: Resources

Dag Andersen wrote:
> Hi John,
> did you get anywhere with this?

Sadly, not very far. I did check far enough into the existing code to 
convince myself that it should still work.

I'd like to do something more. Maybe modify the existing code so that it 
can calculate some start and finish times when there are resources. To 
do this it would help a lot to separate out the code that does actual 
PERT/CPM calculations. It is much easier to write this if we know 
precisely what may be modified by the calculations. Also, its eaier from 
my point of view. I'm only really good at programming algorithms.

The only information a basic PERT/CPM algorithm needs are:
1. A start time for the project.
2. A duration for each node.
3. The list of dependent (dependChildNodes).
Therefore the algorithm doesn't need to be rerun unless one of these is 
changed.

The algorithm calculates (i.e. The only things it modifies are).
1. Earliest start for node.
2. Latest start for node.
3. Earliest finish for node.
4. Latest finish for node.
It also does (if I recall correctly) a sanity check: it won't try to 
calculate if, for example, task C follows B, which follows A, which 
follows C.

Everything else can be hidden or protected from the calculations. I'd 
actually like to get rid of some of the things I put in like dummy start 
and end nodes, which only make things a bit simpler for the algorithm.

If this had a separate interface from the stuff that handles the work 
breakdown structure, who is responsible for the task, loading, saving, 
dialog handling, etc., it would be easier to write algorithm code that 
could be compiled and linked separately.

Resources are a bit harder (actually NP-hard) and an algorithm (or 
heuristic since it won't guarantee to find the 'optimal' solution) would 
need some of the resource information.

> It seems I will have a little time I can use on kplato the next weeks, 
> so...
> 
> On Søndag den 25. maj 2003 17:38, John Lamb wrote:
> 
>>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
> 
> I don't quite see where you are going, so let me try to map it to 
> kplato classes:
> C++ programmers: KPTResourceGroup
> 	Alice:	KPTResource
> 	Bob:		KPTResource	Note
> Python programmers: KPTResourceGroup
> 	Bob:		KPTResource	Note
> 	Charlie:	KPTResource
> 
> programmers:	New super resource group, or note?

Resource group

> 
> programming team: Is this also a new type of resource group, or could 
> it be constructed when user assigns resources to a task.

It could be constructed when user assigns resources. There are some 
cases where you might want a combined resource. For example, you might 
want to specify a task could be done with resources A and B or with 
resources C and D. I guess that is unusual and it might be better to 
leave it at resource and resource group.

If we want an algorithm that takes resources into account it needs to 
know (but not change) a list of Resources/ResourceGroups for each task. 
It would also create (or revise) a list of specific resources assigned 
to the task when it did the PERT/CPM calculations.

> Note:
> I have also thougt that one resource could be member of two or more 
> resource groups. Could this be solved by linking KPTResource to 
> KPTResourceGroup and thus avoid defining supergroups?

I don't know what you mean by 'linking' but I think you're right. I was 
probably getting carried away by the idea of recursive programming on a 
class hierarchy.

>>+ + +
>>
>>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
> 
> Do you mean to replace
>         KPTDuration m_availableFrom;
>         KPTDuration m_availableUntil;
>         QPtrList<KPTDuration> m_workingHours;
> with this new data structure?

Probably better to put on the list of things that could be done 
eventually. I guess it would be better to start with code that handles 
resources more simply.

>>+ + +
>>
>>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)
> 
> Isn't this the result of user specifying that a task needs a number of 
> resources from one or more resource type(s) and/or requestin use of 
> specific resource(s)?
> 

If we don't use combined resources, yes.



-- 
JDL

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