Re: Resources

Hi John,
did you get anywhere with this?
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?

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

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?
>
> 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.
Does this mean that when user defines that a task needs 2 C++ 
programmers and 1 Python programmer the "team" is automagically 
created?
>
> 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
Do you mean to replace
        KPTDuration m_availableFrom;
        KPTDuration m_availableUntil;
        QPtrList<KPTDuration> m_workingHours;
with this new data structure?
>
> 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)
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)?
>
> 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)
KPTTask only seems to be prepared for automated appointment now.
>
> + + +
>
> 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?
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.

-- 
Mvh,
Dag Andersen