The specification supplied to you is vague and incomplete. It needs to be considerably expanded to fill in missing detail. It has been deliberately left incomplete to allow you the flexibility of varying the size and complexity of the programs you undertake to suit your abilities and speed of working. For the final user systems you may not finalise the specification until quite late in the term, bearing in mind that the deadlines are immovable and you want to achieve as much as possible in the time available.

This approach is not appropriate for those parts of the system upon which lots of other things depend; in particular, the interfaces between different modules. This is the area in which the team will need to interact most closely, and it is important that these basic parts of the system are specified clearly and precisely on paper before major programming work starts. Later changes to this specification should be permitted only if essential for the overall good of the project.

You need to decide on a complete specification for the classes and their methods at a fairly early stage. Nevertheless, if you forget something, and need to add it at a late stage, it is sometimes possible to make minor changes to the specification without causing too much extra work for everyone. It is much better to try to get it right from the start, however.

Once a specification is agreed it should be recorded as such in the team diary, and the specification itself should be labelled with the date and name of the responsible author. If subsequent changes are needed or if ambiguities come to light and need to be resolved, the date and author of the amendment should be added to the amended document. One person should always be responsible for keeping the latest version of the specifications and seeing that the rest of the team is kept up-to-date when changes occur. That person could be the team leader or some other member of the team, but both he and the rest of the team must be quite clear about who has this responsibility. The specification itself is best kept on the computer as a text document, unless it contains complicated diagrams which you may prefer to draw on paper. The machine readable document should always contain the author's name and date of the original, and a list of author's name and date for every time the document was amended.

Although the specification supplied to you is rather vague, it doesn't give you infinite freedom. Where requirements are stated they must be followed. If you really feel that you need to change some stated requirement (rather than just fill in the detail), you must obtain permission from the lecturer in charge. Such permission will not be given lightly.

Care should be taken to make adequate allowance in your design for program testing needs. This means that the test routines should be included in the design (test routines need designing just as carefully as the rest of the program and should be designed at the same time, not as an afterthought). Some particular points to note are:

1. Extra routines are often needed for testing - these should be designed just like any other routine.
2. Extra facilities may be needed in some routines for diagnostic purposes. These should be designed in from the start and may often be retained permanently with a global debug flag used to activate them.

Considerable judgement is required to decide what diagnostics are worthwhile on a permanent basis, and what form they should take. This is an important part of the design effort and should be given the attention it deserves. The extra initial effort often pays off handsomely in the later stages of the work, particularly when you need to make minor changes to code that has been working for some time (late changes like this are very common and can negate the value of all the earlier painstaking testing that you did)!

Each program module (i.e. one or more related procedures) should be the responsibility of one person to code and test. It is asking for trouble to try to test simultaneously several modules from different authors. Instead, each author should write his own test programs and dummy routines (called stubs) in place of other parts of the system that are not yet available.

Program design is best top-down (if you are experienced enough to do it), but program development is often more efficiently done bottom-up. In other words, start by implementing those routines that call no others (except standard library routines). When these have been fully tested, they will help in the testing of the next level of routines (i.e. those that call only the routines which have already been written). This bottom-up style of implementation reduces the number of stubs that have to be written.

Strict bottom-up development is often not possible if several people are trying to simultaneously develop different parts of the system. Generally the routines of one person will call those of another, so strict bottom-up development requires the first person not to start work until the routines he needs have been completed, which is often not acceptable.

Instead, an approach that can help to keep everyone occupied from an early stage is to develop initially much simpler temporary versions of the basic routines that are called from many parts of the overall system. If this is done, the specifications of the temporary routines should be as close as possible to the final versions so that the changeover is as smooth as possible. Often it is possible to make the specifications identical but implement the temporary versions using much simpler but less efficient algorithms.

In addition to the normal machine testing, all very important routines (particularly those accessing shared data or with other real-time features) should be tested by walkthroughs (see below) as this is a useful way of increasing reliability.

When the author of a basic module has completely tested it to his satisfaction, he should sign it off as completed in the team diary and it then becomes available for general use by other members of the team. If bugs are found subsequently, a note should be made in the team diary (under the signature of the finder) and details passed to the author of the routine who should correct the bug and again record the fact in the team diary (after the corrected routine has been retested to his satisfaction).

It is easy to underestimate the time and difficulty involved in putting together a number of routines, even if each has been ‘thoroughly’ tested. Even with good diagnostics it can often be time-consuming trying to track down a bug in a large program. If the diagnostics are poor (or have already been removed because the routines are ‘working’), it can easily become a nightmare.

Real-time programs are notoriously prone to bugs that appear after testing is apparently complete. Be warned! Design conservatively and retain basic checks and diagnostics in the final system.

A walkthrough is a widely used team inspection procedure that can be used to check anything from program code to user documentation. The work to be inspected must be in written form and each member of the team must be able to see a copy. Typically the author of the work leads the team through it by reading it aloud line by line and, in the case of technically detailed work such as program code, by explaining what each step is doing and why. Often, the very act of having to explain his work to an audience leads the author to see errors that he had previously missed. Also, other members of the team can interrupt and ask questions at any time. The aim is to uncover as many defects as possible. This includes not only programming errors, but comments on technique, style, non-conformity to standards or other conventions, and any other deficiencies or questionable points in the work.

An alternative style of walkthrough is for the author (or someone else) to provide test data and lead the team through a manual simulation of the system (a ``dry run''), with intermediate results kept on paper or blackboard. The purpose of any walkthrough is to encourage discussion and searching questions. Most errors are discovered by questioning the author's decisions at various stages, rather than by getting wrong results from the test data (which could be done a lot more easily by simply running the test data through the computer)!

Walkthroughs are a valuable way to uncover deficiencies in all stages of program development from initial specification to final documentation. They are best conducted very systematically with a chairman or moderator appointed to ensure smooth progress. He should halt discussion that gets too far from the point and referee arguments (a simple vote can resolve matters of opinion, matters of fact must be resolved by gathering sufficient evidence). In all cases, however, the author of the work remains responsible for it. Other participants may point out deficiencies or other issues and make suggestions, but any changes to the work are made by the author afterwards, not during the walkthrough. The purpose of the walkthrough is to find bugs and make suggestions for improvements: it should have no power to take decisions on the spot. It is essential that the author make careful notes of the suggestions made.

Walkthroughs are a relatively simple and informal way of inspecting software, with a view to improving its quality. Further reading on more sophisticated methods of software inspection, as used today in the software industry, can be found in T.Gilb & D.Graham, Software Inspection, (Addison-Wesley, 1993) QA76.75.Q35

Adequate documentation during all stages of program development is infinitely more important in a team project than for one person working on his own. In particular, all matters affecting more than one member of the team must be written down so that there is no room for later argument on what was decided. This includes decisions as to who does what, work schedules, specifications and designs.

Use the document preparation facilities on the computers to prepare and keep this documentation. Give some thought on how best to organise this. With several people accessing the same files, you need to devise protocols to reduce the risk of important files being deleted through misunderstanding. It is best to have one person solely responsible for the master copy and allow other people to make copies of the master but not to change it themselves.