Dutch Space has implemented a full set of software engineering and associated processes.
Traditionally these were oriented along ESA PSS-05 and Mil-Std-498, however since several years the basis for all projects has moved towards ECSS-E-40 and ECSS-Q-80.
Software Engineering processes Quick Reference Card (available as 
Acrobat PDF document)
The software engineering processes are integrated with the system engineering processes, for all (large, complex) projects containing software. The system engineering methods and techniques are applied on the system level first, and integrate with "CUS" and "ENG" processes according to SPiCE for Space (S4S).
All software engineering processes are defined in the "Software Engineering Applicable Technology (SWEAT)", and on the Dutch Space intranet. They are supported with document templates, methods and tools, internal audits, process reviews, etc.
The Software Engineering Process Group (SEPG) is customdian for the processes; a Software Engineering Tool Group (SETG) is custodian for methods and tools used in the projects.
The processes have been modelled according to the figure below, in order to achieve and maintain consistency. An important element is Lessons Learnt, used to systematically grab and disseminate experience from other projects.
As a part of the continuous software engineering process improvement programme, Dutch Space was assessed for a suitable selection of key areas in S4S for a level 2 in early 2004; this level was reached. It is planned to obtain a full level 3 in 2006.
Dutch Space is also an active contributor to ECSS-E-10 and E-40/Q-80 working groups.
S4S key areas "CUS.1.x" and "CUS.2.x", regarding supplier control, are tasks for the "Procurement Manager (PrM)", who is overall responsible for all supplier aspects; the PrM reports directly to the project manager. This combines engineering and programmatic tasks.
On the engineering matters, the PrM is a full member of the system engineering team, responsible for the translation of the system requirements and design into a coherent subcontract definition, and consequently for handling all impact vice versa the supplier. He uses appropriate system engineering and software engineering methods for this purpose.
The S4S key areas "ENG.x.y", regarding (software) engineering, are the responsibility of the software (system) engineer.
In order to support the requirements management process throughout the development lifetime of a project, several methods and tools were used in the course of the last 20+ years. The internal process has evolved together with the tool usage, to keep up with the increasing complexity of today's projects . For larger projects, the commercial DOORS toolset is used, including DOORSNet which allows concurrent engineering over the internet using a single requirements management repository. A full lifecycle template for documentation and traces has been designed for easy application in new projects. The Herschel-Planck ACMS project uses this approach effectively, with co-operating parties in Spain and England.
DocExpress is used to handle DOORS to MSWord interfaces, for reporting purposes.
Depending on the type and needs of the various projects, several methods and tools are used for requirements analysis and software design.
Methods used are: UML, Hatley-Pirbhay, Yourdon, Ward-Mellor, (HRT-)HOOD.
Tools used are: EnterpriseArchitect, SystemArchitect, Rational Rose, HOODNice, Concerto-HOOD.
Software construction and integration is performed on various platforms and operating systems, depending on the needs of the projects. Most used programming languages are C, C++ and Ada, but occasionally also Java and Fortran are used. Platforms are PC, SGI, Sparc (including ERC32), (embedded) PowerPC, inter alia. Commonly used operating systems are Unix, Irix, (RedHat) linux, Solaris, …
For specific purposes, especially for simulation environments, Matlab/Simulink is used. For design of human-computer interfaces, mostly QT-toolkit is applied.
Coding for C and C++ is performed according to the BSSC C and C++ coding standards, with slight in-house modifications.
In the area of V&V and testing, several tools are used to support testing and perform static and dynamic analysis of code. These are also used to check on the coding standards application. Tools used are: Cantata, AdaTEST, QAC, Purify.
Configuration management of software baselines is performed default through the Concurrent Versioning System (CVS). A special server is dedicated to host the different configurations of developed software and related test and simulation environments, and to check-out versions for development and modification. The CVS repositories are maintained by the software configuration manager.
Changes in the requirements baselines (hence verification) will be maintained in the DOORS requirements management system.
Default all encountered problems are logged in the central Software Problem Report (SPR) database. The software review board (SWRB), comprising at least of the (software) system engineer, Product Assurance manager, Assembly, Integration and Test manager reviews the SPRs on a regular basis, and defines appropriate actions. The SPR tool provides information on the status of the SPR, hence how and when problems are solved, by whom, and to what CVS baseline.
All documentation and code are internally reviewed, according to pre-defined procedures.
Joint reviews are prepared by means of a dedicated review plan, which is inline with ECSS-M-30-01A.
Safety and dependability (RAMS) aspects are handled by the RAMS engineer. Dutch Space has vast experience in performing dependability and safety analysis and design of both hardware and software, including software for manned space application.
This includes HA, HAZOP, FTA, (S)FMECA, HSIA, CCSA.
All formal documentation, e.g. in the scope of reviews and data packages, is handled by the Central Document Office (CDO).
