[Lecture Notes by Prof Yuen and possibly others 2000-2001]

Project Management
------------------

A large software development project contains many parts, and the
interest of CS/SE specialists concerns how to ensure that each
programming team does its part effectively and the parts fit together
successfully, using tools and systems that define requirements clearly,
break the problem into parts correctly, including the interactions
between parts, and provide for a uniform style and good documentation
so that each team understands what others are doing and the resulting
code can be maintained well by other people in the future.

There is however another important set of techniques which are quite
different in nature from CS, that of project management. The different
parts of a project require early cost estimates, depending on the amount 
of work and the skills/tools needed. Such estimates are not only needed
for overall project costing which management uses to decide whether to
undertake a project or how much money to ask for in budget allocation
or competitive tendering, but also to allocate personnel to each part
to do the development and testing: not just who does what, but also
when. The last question has to take into consideration not just when
somebody is free, but which parts are needed earlier and which parts
later depending on how the parts work together. Also, the question of
how to carry out tests of the parts individually and working tegether
has to be considered from the start, since this determines when a 
part has to be completed in order to take part in integration tests
with other parts.

Consider a package containing modules A to F. A, B and C will work,
separately, then module D will combine their results before sending
these to modules E and F which are again independent. Two programmers
are available. A is larger than B so the second programmer also gets
C, and the first programmer, after finishing A, starts on D while C
is still being developed. Since D is not yet finished when C is done,
programmer 2 starts E, which is larger than F; when D is done, work on
E stops while both programmers work together to test the integration
of A-D; when that is successful, 2 continues with E and 1 starts on F;
after both are available, testing D with E and F takes place, and 
then the whole system is tested.

Now this is only a simple example, but the project management is not
all that simple already; we have not, for example, considered whether
programmer 1 has the expertise to do A, D and F and programmer 2 B, C
and E, nor how the schedule will be affected if one of them encounters
unexpected problems somewhere along the line and the timing is thrown
off course; if there is only one computer for both programmers, or if 
some modules require a particular machine while others can be developed
on different platforms, or whether the computer that will run the
final product is available at the time they want to test module
integration (testing individual parts is usually more flexible in
requirements). There are various constraint satisfaction and optimal
scheduling/resource allocation problems to solve, which themselves
require computer packages. 

Yet another issue project planners has to consider is the reporting and
monitoring system with which project leaders will keep track of how
things are doing and whether actual events are departing significantly
from plan as to require rescheduling and budget modifications. The decision
whether to add more programmers to a behind schedule part is a tricky one
too, since new people cost the existing team time in training and plan
modifications, and may make progress even slower. Just as the productivity
difference between skilful and not so skilful programmers is high, the
quality of project management makes a great deal of difference in 
software development productivity.