ESAHomeSpace EngineeringSystems
   
About us
Software Engineering and Standardisation
Software life cycle
Software building blocks
Software standardisation
Archive
Services
Useful linksContact us
FOR SECURITY REASONS, ALL LINKS TO THE ftp.estec.esa.int SERVER ARE DISABLED. YOU MAY REQUEST RELATED DOCUMENTS TO bssc@esa.int
 
 
 
 
 
printer friendly page
BSSC Workshop
 
The ESA Board for Software Standardisation and Control (BSSC) organised a Workshop at ESTEC on 10-11 February 2005 on the subject of experience with the usage of ECSS (European Cooperation for Space Standardisation) software standards and coding standards for space projects. Proceedings are available from the right menu.
 
 
Introduction
 
ECSS software standards, in particular ECSS-E-40 (Software Engineering) and ECSS-Q-80 (Software Product Assurance), have been in use since 1999 and 1996 respectively and were recently reissued in improved “B” versions. They are or will be complemented by the following level 3 standards:
  • ECSS-E-40-01 “Space Segment Software”
  • ECSS-E-40-03 “Ground Segment Software”
  • ECSS-E-40-04 “Software Life-cycle”
  • ECSS-E-40-05 “Software Verificatio, Validation and Testing”
  • ECSS-E-40-06 “Software development for reuse”
  • ECSS-Q-80-01 “Guidelines for the Reuse of Pre-developed Software”
  • ECSS-Q-80-02 “Guidelines on Software Process Assessment and Improvement”
  • ECSS-Q-80-03 “Guidelines for Software Dependability and Safety Methods and Techniques”
  • ECSS-Q-80-04 “Guidelines for Software Metrication Programme Definition and Implementation”.

It is a characteristic of these standards that they are comprehensive standards that require tailoring when applied to specific projects. Consistent tailoring taking into account project characteristics and programmatic constraints represents a significant challenge. The prime objective of the Workshop was to exchange experience in the use of the standards and, in particular, their tailoring from both the customer and supplier perspectives.

Over the years BSSC has produced coding standards for different languages e.g. ADA, C++, and is currently producing new standards for Java and XML. In addition non-ESA coding standards are available. ECSS standards do not address directly the coding standards, but require that coding standards are defined and agreed, at various levels of the software development, between the supplier and the customer.
 
 
Summary of addressed topics
 

  • Software as part of a system
  • Application of software standards
  • Quality of software standards
  • The ECSS Level 3 documents
  • The challenge of tailoring the software standards
  • Software and system certification
  • Software process capability evaluation and improvement
  • Coding standards and Automation of the life cycle

 
 
Conclusion
 
  • there is no software crisis but a system crisis. The ECSS-E40 “system engineering process related to software” must be given particular care, it is essential to the future software development.


  • a proper (non waterfall) life cycle in line with the system integration philosophy may help to cope with schedule issues. See E40-04 for adapting the reviews.


  • stop reducing the engineering/PA effort to cope with budget. Risk is now too high and mission outage will cost more.


  • standards are flexible on purpose. A given project must make it more precise through a tailoring (coming from its own initiative) and can fix the details in a proper software development plan.


  • the fundamentals of the software standards are good, their application will be now easier with the publication of E40 Part 2B (the DRDs)


  • tailoring is essential. However a proliferation of tailored version must be avoided.
    • Define families of software application for generic tailoring based on the use of same processes, same activities, same documents, same contractual aspects [and not "small" or "earth observation"].
    • Have tailoring done by experts in the field.


  • perform process capability assesment, compare your profiles with the one proposed by Esa, prepare process improvement plans


  • think about Ada2005 and (real-time) Java for manually developped code. Keep C for autocode. Systematize modelling and automation of the life cycle.

 
 
Last update: 22 August 2006
 


BSSC Workhop proceedings (zip)
 
 
 
   Copyright 2000 - 2017 © European Space Agency. All rights reserved.