UCL Department of Space and Climate Physics


Software Project Management and Quality Assurance

Software Development at MSSL is based upon: 

Coupled Development

Closely coupled software-hardware development

  • Documented requirements, ICDs, design and test specifications
  • Configuration control including NCRs and ECRs
  • Coordinated phased development, scheduled & prioritised, progress monitoring, testing

Comprehensive Testing

  • MSSL software is in full operation in space after our extensive tests on the ground


  • 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

Skilled and Experienced Staff

  • Essential for successful development









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:

SoftwareDifferences w.r.t. Hardware
Software models oriented more to functionality progressionHardware models more oriented to higher quality build
Intermediate deliveriesNot just at major EM/FM phases
Extensive use of software simulatorsHardware not available, or access restricted during development
Archive all releasesNot just EM and FM software deliveries retained
Backup codeHardware analogy is spare model
Provide security against code hackingNot a hardware issue
Post launch development (problem fixing and enhancements possible)Hardware development has to stop at launch

When 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 and 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)

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 and 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.)