Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site gargoyle.UChicago.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!ihnp1!ihnp4!gargoyle!stuart
From: stuart@gargoyle.UChicago.UUCP (Stuart A. Kurtz)
Newsgroups: net.micro.mac
Subject: Resource Exclusion in MacProject?
Message-ID: <442@gargoyle.UChicago.UUCP>
Date: Sun, 28-Apr-85 21:52:33 EDT
Article-I.D.: gargoyle.442
Posted: Sun Apr 28 21:52:33 1985
Date-Received: Mon, 29-Apr-85 04:42:55 EDT
Organization: Dept. of Comp. Sci., The University of Chicago
Lines: 40

A (serious) criticism of MacProject:

MacProject is not capable of preventing assignment of a resource to
multiple projects concurrently.  This is surprising, particularly as
MacProject recognizes two different reimbursal strategies: so called
multiple and single.  Single reimbursal resources bill only for time
spent on the job, independent of how many jobs are being performed
concurrently; while multiple reimbursal resources bill for each task
independently.  The clear intent is that multiple reimbursal
scheduling is intended for pooled resources, e.g., trucks, engineers
(generic), secretarial help.  For these resources, additional
capacity can be achieved (at additional cost) by hiring more of
whatever resource is required.  Single reimbursal is clearly intended
for dealing with specific individuals.  This is all well and good,
but MacProject will happily assign the same individual to two or more
tasks simultaneously, and thereby realize an apparent cost reduction!
This is unreasonable.  Even more unreasonable, such "overuse" is not
automatically reported, one needs to examine the full resource
allocation window (normally invisible) to see that such a difficulty
exists.

Now of course, one can obtain single use (a.k.a. "mutual exclusion")
in such cases by adding precedence constraints, but this seems
completely out of spirit with the program: first, it requires the
user to sequentially overspecify the problem; and second (far worse),
if one does this, it is then the users responsibility to remove such
constraints to obtain full generality if situations change.

If this program did indeed permit mutual exclusion (can anyone thing
of a reasonable single-use resource for which one does not want
mutual exclusion?) it would admit many more applications.  Some
possibilities: designing a course, arranging the order of
presentation of a logical argument (e.g., a mathematical paper), or
even more reliable and flexible handling of the tasks for which
MacProject is ostensibly designed.

Stu

<sak>     ::= stuart | kurtz
<address> ::= ihnp4!gargoyle!<sak> | <sak>@uchicago.csnet