UCL Logo

Software Project Management & Quality Assurance

Software Development at MSSL is based upon:

Closely coupled software-hardware development
Skilled & experienced staff
Comprehensive testing
· Evolved over 40 years of space instrument development
· Tuned to size and type of developments. (Simultaneous software and hardware development, non-contractual relationships, evolving requirements, small local team)
· Significant commonality with ECSS / ISO9001
· Documented requirements, ICDs, design and test specifications
· Configuration control including NCRs and ECRs
· Coordinated phased development, scheduled & prioritised, progress monitoring, testing
· Essential for successful development
· MSSL softwares are in full operation in space after our extensive tests on the ground

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:

Software models oriented more to functionality progression Hardware models more oriented to higher quality build
Intermediate deliveries Not just at major EM/FM phases
Extensive use of software simulators Hardware not available, or access restricted during development
Archive all releases Not just EM and FM software deliveries retained
Backup code Hardware analogy is spare model
Provide security against code hacking Not a hardware issue
Post launch development (problem fixing and enhancements possible) Hardware development has to stop at launch

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)


  • 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

Software is developed within the above project phases, with each functional element being added generally as a layer across an overall design base. A significant time is required to establish a suitable design base, and the required simulators (in the absence of real hardware) for testing in the early stages of a project. The general philosophy is 'develop a little' and 'test a little' to detect problems early.
  • Documented Requirements
  • Coding Standard
  • Development (Design, coding, debugging)
  • Verification (At unit, instrument & spacecraft levels)

Configuration Control

Configuration control is to ensure that only authorised changes are made to software, and is usually implemented when the software is submitted for formal integration and testing, prior to a delivery. The following procedures are then followed for configuration controlled software :-
  • 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.)

Mullard Space Science Laboratory - Holmbury St. Mary - Dorking - Surrey - RH5 6NT Telephone: +44 (0)1483 204100 - Copyright © 1999-2008 UCL

Search by Google