[kplato] Resources

[Dag Andersen]

On Lørdag den 18. oktober 2003 13:33, John Lamb wrote:
> 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. 
I'm having a look at coding a little bit of this to get a feel for it. 
It will be *very* basic, though, and only include something like 
this:
- Project resourcedialog to define available resources. (actually 
filling in functionallity to existing dialog) Done and committed.
- New resourcedialog for tasks, to be able to define the amount and 
type of resources a task needs.
- Very simple algorithm to allocate resources during PERT/CPM 
calculations.

I hope to have something committed in a few days but the code is 
starting to look a bit messy, so we'll see...

>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.
Well, now each resource is owned by one resource group, I thought it 
could be fruitfull to have resources that could be member of more 
than one group, to take care of ie persons which have different 
skills (C++/python programming, for instance). But this will not give 
us combined resource teams, though.
>
> >>+ + +
> >>
> >>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.

-- 
Mvh,
Dag Andersen