 |
Department of Engineering |
 |
|
Computer Project Management
Or see the newer, expanded version
[Staffing]
[Requirements]
[Time Estimates]
[Procedural Issues]
[Working Alone]
[Bug detection]
[Slippage]
[The End]
[References]
[Jargon]
Computer Project Management
In a university environment, Computer Projects
- may be written as a one-off yet end up being used for years
- are unlikely to depend on many commercial libraries/programs
- may only ever be used inhouse
- may well result in freeware
- may well be written by one person
- may have cutting edge technology
- may not have much of a GUI
This document attempts to adapt some standard Project Management procedures
to this situation (viewed mostly from the programmer's perspective).
Contributions and suggestions welcomed! A "slides" version is available.
If you're going to manage a project it's worth holding out for the best staff.
Good programmers are at least 10 times more
productive than bad (Survival Guide p.102) so staff
will often give a busy programmer a job rather than temporarily employ a student. There's not always much choice though.
If you can employ several people your team might well comprise: Project Manager, Product Manager, Architect,
User-interface designer, End-user liaison, Developer, QA/Testers, Toolsmith,
Build Coordinator, Risk Officer, End-user documentation specialist (Survival Guide p.105).
These don't always get on with each other. If they're all one person, beware!
It's likely that programmers will be seconded from other work. Sometimes
this results in the programmer doing 2 jobs at once. Even if the project
succeeds there may be failures elsewhere as a consequence. You need to decide
how much of this task-balancing is your responsibility.
Sometimes in business the managers want to introduce a new computing system so that they can radically change working practises - the program becomes the means to fulfill a non-computing end. The "success" of the system will depend on the quality of staff training and the nature of input the staff had into the design process.
In the academic world the true purpose of the program is usually clearer, but even so, as soon as the program needs to be used by someone other than the programmer, misunderstandings can arise.
- Requirements Document - should be used as part of the contract. Extracting
requirements from users might not be an easy task but if you don't do
it, you can guarantee (and deserve to get!) massive requirements creep
and completely unrealistic estimates of timescale and cost. Performance does
matter (some recent projects have produced sluggish results) but isn't
always easy to specify.
- Prototypes - Useful for extracting requirements. What should you do with them once development begins? It
may be best to throw them away (or at least say you have), otherwise you may
have to keep updating it in step with the real product's changed specification
to attract new customers
- Stakeholders - These should be identified early on. It's they who
ought to approve the specification and be consulted on any subsequent changes.
- Baseline - a set of minimal requirements. This needs to be established
and agreed upon as early as possible. Items which don't make it into the
baseline can be marked as desirable, highly desirable, etc.
- Milestones and Deliverables - these may be all that your supervisor
cares about, so time their release for maximum effect!
- Aftercare - whenever possible make it clear that once the project's
over it belongs to the people you did the project for, and that they will
look after
it on a day-to-day basis. It's up to them to ensure that the requirements
include details on how to make this easy enough. WebApps in particular
are likely to involve open-ended maintenance of content.
Hard. Many procedural decisions aim to improve the accuracy of these
estimates. As usual, decomposing the task helps - if phase 1 takes 20% longer
than estimated, and other phases are similar in nature to phase 1, then you
have an early warning of a 20% over-run for the
whole project. If
tasks are small then they're more likely to be comparable to other tasks,
making future estimation easier.
- Beware: typically, 80% of the time is spent on unplanned rework (Survival Guide p.219)
- The industry average for code production is 8-20 lines of correct code per day - independent of the language.
Re-estimate schedules periodically.
Modularisation and Plugs-in
Splitting the task into de-coupled sections has many benefits. Recently,
Plug-in architectures have become popular. As well as allowing
others to extend the program, there are development advantages too
- development teams can work independently
- some decisions about what features to offer can be defered
Model
- Waterfall - Non-overlapping phases. OK if detailed analysis can be successfully completed
prior to coding. This might well be possible for a stable project definition and development environment. A variant is the Sashimi lifecycle with some overlap (local eddies)
- Spiral - revisits all phases of development. Useful with new technologies -
minimises the costs of rethinks - but can be hard to manage.
- Reuse-orientated - Relies on a large base of reusable software. Development may consist in adapting existing code, combining the components
using corba, javabeans, etc.
- Staged delivery - each milestone is a working release. Useful with new technologies (Survival Guide p.56). Some recent
UK central government failures have been blamed on their "big bang" implementation.
- Controlled iteration - Go onto the next stage if (say) 80% is done. Appropriate for strongly Object-Orientated tasks where progress
is incremental
Note that in an Object-Orientated situation, things might not develop as outsiders (or older programmers) might
expect - if data-structures are hidden away inside objects, detailed
decisions about data-structures may be defered. Top-down design is
complicated by the fact that there may be no "top".
Monitoring Progress
Some monitoring is needed, both for your own benefit and to keep others happy. If none is done, the unproductive time and 'admin'
overhead
increase rather than decrease as the project progresses.
For small groups, the cost of computing metrics is 3-8% initially dropping
to 1% (Pressman, p.100).
Records are also a
way to cover yourself if things go wrong.
- Use Binary Milestones - tasks are either Done or Not Done.
The problem with tasks that are 90% done, is that the other 10% can end up taking a long time.
- A WWW page helps with communications - eg a project diary. If you keep it up to date people
might not pester you for progress reports
- Keep a "Top 10 Risks List" and make it generally visible - it will help convince people that you have their
concerns at heart. Update it fortnightly on a Friday afternoon. Column headings might include "Position", "Last position", "Weeks in chart", "Description" and "Progress". The major risks may be more to do with "management" than programming. Pressman (p.149) reports the 5 top project risk
factors as: lack of formal top-management support; lack of end-user interest;
lack of understanding of requirements; lack of end-user involvement in
requirements definition; unrealistic end-user expectations.
Note than some statistics (e.g. lines of code produced per day) might be more
useful as propaganda than as progress indicators. Of course, that doesn't stop
them being useful to you. Especially if you're using O-O techniques you can
bamboozle
the boss with impressive complexity metrics (members per class,
depth of inheritance tree, number of children, number of operations
overridden, percent of public and protected, etc).
Chain of Control
Unless you're careful you may find yourself being softened up by individuals
from opposing power bases. Even if there's an agreed chain of control, sabbaticals and pressure of work lead to line-managers being nominal. If you can't work under a single boss arrange
meetings whenever feature creep arises (or get those who want
the changes to organise the meetings)
Coping with change
Standards
Though in principle one should adopt official standards, in practise there
are many "official standards" to choose from, and the newest may not be
well supported. People who want the project to fail may insist on an
impractical standard.
Companies may have standard ways of formatting code (see for example
A C Style Guide - a 38 page DVI file). Even if you're working alone it may be useful to have
a convention for compound names (compound_interest or
CompoundInterest?) and a way of determining from an array's name
whether the 1st element used is at offset 0 or 1.
Some common standards include
- UML - Universal Modelling Language
- BPEL - Business Process Execution Language
- SysML - Systems Modelling Language
Software
Several sites (e.g. www.project-management-software.org) offer project management software. Perhaps
the best known is
Microsoft Project.
Open Development
An alternative approach is that taken by Linux, with a more decentralised
model of software development that might be able to accelerate development -
"Given enough eyeballs, all bugs are shallow". Instead of "users" and
"developers", everyone is a potential "co-developer"
For much of the time you're likely to be working alone and unsupervised.
Supervisors often underestimate the psychological issues involved.
Be aware of your strengths and weaknesses.
-
It's unlikely that one person will be strong in all phases of development.
Phases of Discovery, Invention, Implementation and Documentation take turns
at peaking, though (depending on the choice of life-cycle model) you can
try to keep different kinds of work available so that there's always something
to match your mood.
- You may have no-one to bounce ideas off, or no-one to inspect your code.
You might find some-one prepared to respond to e-mail. Newsgroups can be
useful.
- Be aware of your favourite 'displacement mechanisms'. Try to make
them something useful (documentation) rather than cosmetic. A common
diversion is to over-develop tools and utilities
- To cheer yourself up make a list of easy things that you can tick off.
- Think of a good name for the project (this document's really entitled "COMputer PROject Management In Student Environments" - Compromise)
- Beware of Burnout. A regular employer might look after you because
they want to hold onto you for a future project. If you're a contract worker
however, your longevity isn't high on the contracter's priorities - you'll
need to pace yourself.
The programming task may only be part of your job - you may still be studying for a Ph.D. One way to reduce the risk of the programming task taking over
is to be strict about when/where you do the work - e.g. only in the mornings
and never from home.
Testers get credits nowadays on computer projects.
- industry average
experience suggests that there are 15-50 errors per 1000 lines of
delivered code. (Survival Guide - p.610).
Some expensive bugs have been documented.
- You can try daily build/smoketest, each programmer using a private version of main source. (Survival Guide p.206)
- Use "defect seeding". Put 10 deliberate errors into your code or
documentation and get someone to check it. If they find 20 errors
but only 5 of them are your deliberate ones then you might hypothesise
that since they only found half of the deliberate errors they only found
half of the other errors, so there are 30 unintentional errors. Some
checkers find this a fun way to work. Don't forget to remove
seeded bugs!
- Supply the test suite with the program (Mozilla)
- Code walkthrough - get someone to listen as you describe the code
- Involve the customer in testing
- Web applications may present difficulties because of the number of
components that may be involved. If there's a problem (in particular
performance-related) the cause could be: the network; the database,
the web server
(with modules for PHP support), the web proxy-server or the browser itself
(which comes in various varieties each with different plug-ins, java
interpreters and so on). Black-box testing alone won't be enough.
- Beware of typos in error messages - they're commonly missed
"Of the most expensive software projects, about half will
eventually be canceled for being out of control. Many more are
canceled in subtle ways" (Survival Guide p. vii).
Once things start slipping it's hard to get them back on schedule - the
situation tends to get worse rather than better. This may be because
of the nature of the project or choice of procedures. Problems include
- Gold-plate (the opposite of Boiler-plate) - A developer gets carried
away with details
- Feature-creep - clients etc. keep requesting more features
- Mythical man-month - Adding staff can slow a project down rather than
speed it up: 9 women can't deliver a baby in a month
Delaying the release may be the only sensible option - "People forget how
fast you did a job - but they always remember how well you did it" -
Howard Newton.
Oh no it isn't!
- Maintenance (65% new requirements, 18% because of new OS, 17% bug
fixes) - Software Engineering, page 606.
- Bug reporting - Once you accept that your delivered test will have bugs
you may wish to encourage people to report them. You could have a built-in
reporting facility, or you could pay bug reporters (as done with TeX code,
and Stroustrup's book). This might make them happy (rather than angry) to find bugs.
- Intellectual Property Rights
- Post-mortem of project - metrics are especially useful when those of
different projects can be compared, so saving old metrics can help
characterize, evaluate, predict and improve future projects
- Cambridge University's Contract Research Staff page has some useful links.
- CAPSA and its implementation (Report to the Audit Committee and the Board of Scrutiny,
University of Cambridge)
- Anti-Patterns in Project management, Brown, McCormick, Thomas, Wiley, 2000
- Code Complete, Steve McConnell, Microsoft Press, 1993
- Software Project Survival Guide, Steve McConnell, Microsoft
Survival Guide
- Refactoring, Martin Fowler et al, Addison-Wesley, 1999
- The Mythical Man Month, Brooks, F.P.,
Addison-Wesley, Anniversary edition 1995 (2001 reprint)
- Software Engineering: a Practitioner's Approach (European Adaptation), Pressman, R.S., McGraw-Hill, 2000
- Software Engineering (6th edition), I.Sommerville, Addison-Wesley, 2001
- ISO standards exist to assess the quality of the software development process (ISO 9001) and its products (ISO 9126).
- Project Management (from the ImpEE project)
- Alpha release - the first release, often kept
in-house. Then comes
the pre-production Beta release which users might profitably try unaided
- Blackbox testing - testing without knowledge of the insides of the program
- Boiler-plate - standard code
- Cleanroom software development - being extra careful
- Corncob - a troublemaker
- COTS - Commercial-off-the-shelf (not always stable - Java)
- Design by Committee - producing a product that pleases no-one. Sucessful products typically have a small design team.
- Defect Testing - looking for differences between behaviour and specification
- Firedrills - artificially created sudden deadlines
- Fuzzing - black box testing with fault injection and stress testing
- Gold Disk - final release disk
- Golden Hammer - a mythical tool that solves all problems
- Gold-plate - extra, unnecessary features
- Greybox testing - testing with some knowledge of the insides of the program (the language it was written in, for example,
or how its components interact).
- Integration testing - testing a combination of units that have already passed unit tests
- Legacy System - an old piece of software that may be impossible to modify
- Metrics - measurable code characteristics.
- Not Invented Here Syndrome - used to be popular in Cambridge. Now replaced by 'Design by Committee'
- Oracle - something that predicts the result of a test so that results needn't be manually checked
- Regression Testing - The selective retesting of a software system that has been modified to ensure that any bugs have been fixed and that no other previously-working functions have failed as a result of the changes.
- Reinventing the Wheel - writing code that's already been written. Sometimes done to keep people busy, like whitewashing stones
- Silver Bullet - a methodology or tool that solves all problems
- Smoketest - a recompile to see if a program "smokes" (crashes)
- Spaghetti Code - messy code with GOTOs
- Stovepipe - a standalone (usually legacy) program
- Tiger Team - a small team to perform a single task quickly (1 or 2 people, a day/week of work)
- Unit testing - testing the individual components
- Validation - are we building the right product?
- Verification - are we building the product right?
- Whitebox testing - testing with knowledge of the insides of the program.
|
|
