This document outlines a minimal process
to follow when developing software at
MSSL. It should be followed if no other, higher standards are
Requirements are essential to defining the scope of a job.
- to clarify understanding between the initiator and the programmer
- clarify and agree how much effort and elapsed time are needed for the job (c.f. project schedule)
- what items are to be delivered (what are the outputs)
The minimum requirements
documentation is a numbered list.
Design must be written down before coding starts.
- demonstrates the understanding of the requirements by the programmer
- should include a picture showing how the s/w will work.
- this does not need to be formal,
rather the requirement is
clarity for the initiator's understanding. More important to
show the logic of the s/w than the physical implementation.
- this forces the initiator to think about the completeness of what
they have asked for. Hence will expose gaps in thinking.
- identify required inputs or starting conditions
- allows a break-down of the job into sub-tasks which presents a way
of monitoring progress
- the physical design of code in diagram and words will support
operations and maintenance of the code.
- The Design document must be read and agreed by initiator.
- consistent with documented design
- stick to the scope of requirements but try to be flexible to ease
- plenty of comments to aid maintenance! (but also this is part of
- numerical accuracy
- robustness of code (stress tests)
- against Requirements to demonstrate completeness
+ results required as hard-copy
be agreed by initiator
User guide / OM guide (if required)
- Can re-use parts of design doc to explain functionality and support
- Can re-use test material as a tutorial
For all external deliveries we need a :-
Documentation and s/w release process:
must be approved by project manager
PA Process: Minimum standards must be maintained even by project
If early drafts are to be
released this must be made very clear - and agreed by
(TBD depending on the project)