Software Development at MSSL is based upon:

The software development environment for space scientific instruments at MSSL is unlike many 'classical' environments in quite major aspects. The software developments are not for simple implementation on an already existing system, or even on a computing system that is yet to be specified and purchased. The developments are for a scientific instrument which in itself has to be completely developed over the same time period. This leads to a software development environment closely coupled to the corresponding instrument hardware development. Significant difference between software and hardware development are outlined as follows:

Also, as the requirements are generally not fully known at the outset, a 'classic' approach of complete design, followed by coding, cannot be followed. An overall flexible design, in which functionality can be implemented as it becomes known, is required. There is also little room for iteration due to time and resource constraints. In consequence, MSSL has evolved software project management & Software Quality Assurance (SQA) processes over many years which are closely allied to the corresponding hardware development processes. Also, in addition, they are usually modified to adhere to quality standards set by the particular space agencies. The software management and SQA processes as a result have significant commonality with ESA ECSS and ISO9001 SQA standards. At MSSL it is recognised that Software Quality Assurance is the responsibility of everyone. It is the responsibility of the first person who detects a problem to ensure that it is dealt with appropriately. A brief summary of the resulting processes designed to ensure quality software, include:

Software Project Management

• Phased development (Design Study, Breadboard, Engineering Model, Flight Model)
• Project Planning (Schedule production, milestones, resources)
• Progress Monitoring (Consortium meetings, project meetings, software meetings)

MSSL Minimal Software Engineering Process document outlines a minimal process to follow when developing software at MSSL. It should be followed if no other, higher standards are applicable.

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.

Build Code

• consistent with documented design
• stick to the scope of requirements but try to be flexible to ease future modifications.
• plenty of comments to aid maintenance! (but also this is part of detailed design)

Test

• numerical accuracy
• robustness of code (stress tests)
• functionality
• against Requirements to demonstrate completeness

      Test plan + results required as hard-copy
      Completeness should be agreed by initiator

User guide / OM guide (if required)

• Can re-use parts of design doc to explain functionality and support maintenance
• 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 manager
      If early drafts are to be released this must be made very clear - and agreed by (TBD depending on the project)

Software Development

• Documented Requirements
• Coding Standard
• Development (Design, coding, debugging)
• Verification (At unit, instrument & spacecraft levels)

Configuration Control

• NCRs (Formal 'Non-Conformance Reporting' procedures)
• ECRs (Formal 'Engineering Change Request' procedures)
• CIDL (Configuration Item Data List. This is produced to specify the exact versions of the software for testing and delivery.)
• Archiving (Configuration controlled software is archived for future reference.)
• STD (A 'Software Transfer Document' for the associated software delivery is produced. This specifies the CIDL, current functionality supported or omitted, and any outstanding NCR's and ECRs, and complete build instructions for the delivered software.)