OPS Forum ECSS software standards 20.01.2006

1,169 views

Published on

This forum will address the importance of software engineering standards and provide an overview of current status and future developments. It will highlight issues associated with tailoring standards for specific projects, particularly the work done by the Board for Software Standardisation and Control (BSSC) on tailoring ECSS standards for ground segments.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,169
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  •  
  • This Standard covers all aspects of space software engineering including requirements definition, design, production, verification and validation, transfer, operations and maintenance.   It defines the scope of the space software engineering processes and its interfaces with management and product assurance, which are addressed in the Management (-M) and Product assurance (-Q) branches of the ECSSSystem, and explains how they apply in the software engineering processes.   This Standard reflects the specific methods used in space system developments, and the requirements for the software engineering processes in this context. Together with the requirements found in the other branches of the ECSS Standards, this Standard provides a coherent and complete framework for software engineering in a space project.   This Standard is intended to help the customers to formulate their requirements and suppliers to prepare their responses and to implement the work. This Standard is not intended to replace textbook material on computer science or technology, and such material is avoided in this Standard. The readers and users of this Standard are assumed to possess general knowledge of computer science.   The scope of this Standard is the software developed as part of a space project, i.e. “Space system product software”. This Standard also applies to the development of non-deliverable software that affects the quality of the deliverable product. It is not intended to cover software developments beyond the scope of the ECSS System of Standards. An example is the development of commercial software packages, where software is developed for a (large) volume market and not just for a single customer, and the main requirement analysis consists of market analysis, combined with a marketing strategy.
  • This Standard covers all aspects of space software engineering including requirements definition, design, production, verification and validation, transfer, operations and maintenance.   It defines the scope of the space software engineering processes and its interfaces with management and product assurance, which are addressed in the Management (-M) and Product assurance (-Q) branches of the ECSSSystem, and explains how they apply in the software engineering processes.   This Standard reflects the specific methods used in space system developments, and the requirements for the software engineering processes in this context. Together with the requirements found in the other branches of the ECSS Standards, this Standard provides a coherent and complete framework for software engineering in a space project.   This Standard is intended to help the customers to formulate their requirements and suppliers to prepare their responses and to implement the work. This Standard is not intended to replace textbook material on computer science or technology, and such material is avoided in this Standard. The readers and users of this Standard are assumed to possess general knowledge of computer science.   The scope of this Standard is the software developed as part of a space project, i.e. “Space system product software”. This Standard also applies to the development of non-deliverable software that affects the quality of the deliverable product. It is not intended to cover software developments beyond the scope of the ECSS System of Standards. An example is the development of commercial software packages, where software is developed for a (large) volume market and not just for a single customer, and the main requirement analysis consists of market analysis, combined with a marketing strategy.
  • 1984: PSS-05 (1) 1991: PSS-05 (2) 1994: ECSS established 1997 – 1999: ESOC QMS prepared, based on PSS-05-0 1999: ECSS-E-40A first issue 2002: First ECSS tailoring: The Ground Segment Software Engineering and Management Guide (SEMG). Tailoring of all ECSS standards that could bear on software engineering (E-, M- and Q-). 2002: ESOC QMS updated based on SEMG. Applied in new contracts and work orders (e.g. OPS-G MCS and Simulator frame contracts) 2003: ECSS-E-40B 2005: A step forward – the SETG: Tailoring of ECSS for Ground Segments
  • OPS Forum ECSS software standards 20.01.2006

    1. 1. Three Years of ECSS Software Standards An Appraisal and Outlook OPS-G Forum 20th January 2006 D. Ponz & M. Spada
    2. 2. Outline <ul><li>Why Software Engineering </li></ul><ul><li>The Standardisation Process </li></ul><ul><li>ECSS Software Standards applicable to ESA Software </li></ul><ul><li>Key issues in application of the ECSS Standards </li></ul><ul><li>Tailoring of ECSS Standards for Ground Segments </li></ul><ul><ul><li>First step: SEMG </li></ul></ul><ul><ul><li>Second step: SETG </li></ul></ul><ul><li>Next Steps </li></ul><ul><li>Conclusions </li></ul>
    3. 3. What is Software Engineering? <ul><li>Software engineering is about systematic development, evaluation and maintenance of software </li></ul><ul><li>Surveys have shown that the average corporation pays 3 to 7% of its annual revenues for hardware and software for corporate data processing and another 2 to 5% for maintenance: that’s 5-10% of the economy in the developed world </li></ul><ul><li>Another measure: software project failures cost the US economy about 60 B$ annually – double this for the whole world* </li></ul><ul><li>Information technology is mission critical for many businesses - rely on the efficiency and integrity of their IT systems for their business needs </li></ul><ul><li>Means that software engineering is vital </li></ul><ul><li>  </li></ul><ul><li>* Source 2002 study by America's National Institute of Standards (NIST), quoted in Economist of Nov 25 2004 </li></ul>
    4. 4. Software Engineering Standards <ul><li>Many people have to develop or maintain software or manage the related processes </li></ul><ul><ul><li>It follows that software engineering standards are used by many people </li></ul></ul><ul><ul><li>The standards must therefore be readily understandable to a wide community </li></ul></ul><ul><li>This is not the case for many other engineering standards: </li></ul><ul><ul><li>e.g. we all use TCP/IP many times on a daily basis, most of us without any special knowledge of TCP/IP, but implementing TCP/IP packages and tuning TCP/IP communications systems is very specialised activity </li></ul></ul>
    5. 5. The Standardisation Process <ul><li>Standardisation organisations like the European Cooperation for Space Standardisation (ECSS) and the Consultative Committee for Space Data Systems (CCSDS) exist to produce and maintain standards </li></ul><ul><li>They have established structures/procedures for reviewing and approving standards </li></ul><ul><ul><li>WGs, Independent peer review, committee hierarchy etc. </li></ul></ul><ul><li>In addition, some technical standards can be verified by prototyping, bread-boarding or an initial implementation before release of the standard </li></ul><ul><ul><li>E.g. CCSDS SLE standards </li></ul></ul><ul><li>But not possible for a software engineering standard </li></ul>
    6. 6. Standardisation Process - Software Engineering Standards <ul><li>Not practical to “test “a software engineering standard before release because </li></ul><ul><ul><li>Would involve a significant implementation project – would take too long, would not easily find volunteer projects </li></ul></ul><ul><li>A software engineering standard reflects best practices as understood by the writers of the standards </li></ul><ul><ul><li>Incorporates the authors’ development cultures </li></ul></ul><ul><li>Users of the standard are in effect verifying it! </li></ul><ul><li>Users’ development cultures may differ from those of authors </li></ul><ul><ul><li>It can result in interpretation problems </li></ul></ul><ul><li>Tailoring complicates it further: </li></ul><ul><ul><li>Users may exercise the processes in ways which were not thought about by the authors or only subset of the processes </li></ul></ul>
    7. 7. Standards Applicable to ESA Software <ul><li>ECSS-E-40B Space Engineering – Software </li></ul><ul><li>E-40 Part1B: Principles and Requirements (Nov. 2003) </li></ul><ul><ul><li>Covers all aspects of space software engineering </li></ul></ul><ul><ul><ul><li>Complete life cycle </li></ul></ul></ul><ul><ul><li>Is defined in terms of </li></ul></ul><ul><ul><ul><li>Engineering processes,which may be broken down into activities and tasks </li></ul></ul></ul><ul><ul><ul><li>Process interfaces with management and product assurance </li></ul></ul></ul><ul><ul><ul><li>Inputs and outputs to processes </li></ul></ul></ul><ul><li>E-40 Part2B: Document Requirements Definitions (DRDs) (Mar. 2005) </li></ul><ul><ul><li>Defines the contents of documents in line with expected outputs of processes/actrivities defined in E-40 Part1 </li></ul></ul>
    8. 8. Standards Applicable to ESA Software (Cont.) <ul><li>ECSS-E-40B is or will be complemented by the following level 3 (technical domain specific) standards: </li></ul>
    9. 9. Standards Applicable to ESA Software (Cont.) <ul><li>ECSS-Q80-B: Space Product Assurance – Software (Oct. 2003) </li></ul><ul><ul><li>Covers </li></ul></ul><ul><ul><ul><li>SW product assurance programme implementation: organisation, responsibilities, etc. for SW PA </li></ul></ul></ul><ul><ul><ul><li>SW process assurance: lifecycle and requirements applicable to different phases </li></ul></ul></ul><ul><ul><ul><li>SW product quality assurance: metrification, product quality requirements, etc. </li></ul></ul></ul><ul><li>Management Standards – not software specific </li></ul><ul><ul><li>M-00B Policy and Principles (August 2003) </li></ul></ul><ul><ul><li>M-10B Project Breakdown Structures (June 2003) </li></ul></ul><ul><ul><li>M-20B Project Organisation (June 2003) </li></ul></ul><ul><ul><li>M-30A Project Phasing and Planning (April 1996) </li></ul></ul><ul><ul><li>M-40A Configuration Management (April 1996) </li></ul></ul><ul><ul><li>M-50A Information/Document Management (April 1996) </li></ul></ul><ul><ul><li>M-60A Cost and Schedule Management (April 1996) </li></ul></ul><ul><ul><li>M-00-03A Risk Management (April 2000) </li></ul></ul>
    10. 10. Application of Standards <ul><li>Solution : Use prescriptive standards but allow tailoring </li></ul><ul><li>ECSS Approach: Tailoring of the standards to Programme/Project needs </li></ul><ul><li>Tailoring influencing factors </li></ul><ul><ul><li>Programme/Project characteristics e.g. </li></ul></ul><ul><ul><ul><li>Programmatic and financial constraints </li></ul></ul></ul><ul><ul><ul><li>Technical parameters </li></ul></ul></ul><ul><ul><ul><li>Scope and type of procurement </li></ul></ul></ul>
    11. 11. The Challenge of Tailoring a Software Engineering Standard <ul><li>Requires detailed understanding of the whole standard, </li></ul><ul><ul><li>Average software developer or project manager does not have this </li></ul></ul><ul><li>Standard is open to interpretation - ambiguous </li></ul><ul><li>Almost no guiding literature available – also for ISO 12207, the “parent” standard of E-40 </li></ul><ul><li>Limited advice in ECSS literature, e.g. a short annex to ECSS-E-40B </li></ul>
    12. 12. Tailoring Options <ul><ul><li>Use a tailoring tool </li></ul></ul><ul><ul><ul><li>Questionnaire based </li></ul></ul></ul><ul><ul><ul><li>The answers are used to define a table with </li></ul></ul></ul><ul><ul><ul><ul><li>Retained requirements </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Output documents required </li></ul></ul></ul></ul><ul><ul><ul><li>TEC-SWE have developed a useful tailoring tool for E-40 </li></ul></ul></ul><ul><ul><li>Organizational tailoring </li></ul></ul><ul><ul><ul><li>Suited for an organisation with similar projects </li></ul></ul></ul><ul><ul><ul><li>The same tailoring could be used for all </li></ul></ul></ul><ul><ul><li>No tailoring at all! </li></ul></ul><ul><ul><ul><li>Let the contractor do it </li></ul></ul></ul><ul><ul><ul><li>In conflict with ESA Policy (IPOL(2004)6) – customer should do it </li></ul></ul></ul><ul><ul><ul><li>Only works where there is no competition – otherwise “playing field not level” </li></ul></ul></ul>
    13. 13. Particular problems of tailoring E-40 <ul><li>E-40 is defined in terms of </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Inputs and outputs to processes </li></ul></ul><ul><ul><li>Processes may be broken down into activities with their own inputs and outputs </li></ul></ul><ul><li>Problem: </li></ul><ul><ul><li>Have to map outputs into a set of supplier deliverable documents </li></ul></ul><ul><ul><li>Outputs must be aggregated into manageable set of deliverables </li></ul></ul><ul><ul><li>If not done can get large number of deliverables </li></ul></ul><ul><ul><ul><li>Not practicable, very costly, difficult configuration management </li></ul></ul></ul><ul><ul><ul><li>Problem for both customer and supplier </li></ul></ul></ul><ul><ul><li>The E-40 DRDs were not available for a long time </li></ul></ul>
    14. 14. The “ Many Standards” Issue for Software <ul><li>Problem: </li></ul><ul><ul><li>ECSS-E-40 addresses the technical processes needed to define, design, build and maintain software </li></ul></ul><ul><ul><li>Producing and maintaining software also involves the disciplines of management and product assurance </li></ul></ul><ul><ul><li>In the ECSS scheme need to use standards from the </li></ul></ul><ul><ul><ul><li>PA branch (ECSS-Q series) </li></ul></ul></ul><ul><ul><ul><li>Management branch (the ECSS-M series) </li></ul></ul></ul><ul><li>Solutions possible: </li></ul><ul><ul><li>Use E-40 only or E-40 and Q-80 </li></ul></ul><ul><ul><ul><li>E-40 and Q-80 contain basic management elements </li></ul></ul></ul><ul><ul><li>Combine all relevant ECSS standards into a single volume (ESOC and Galileo approach) </li></ul></ul>
    15. 15. <ul><li>Stated with BSSC ESA Ground Segment Software Engineering and Management Guide – SEMG , BSSC(2002)4 </li></ul><ul><ul><li>adopted by ESOC in 2002 </li></ul></ul><ul><ul><li>became applicable to new projects, e.g. GOCE and Herschel/Planck, TMTCS Backend System </li></ul></ul><ul><li>Structured in three Parts: </li></ul><ul><ul><li>Part A : Software Engineering </li></ul></ul><ul><ul><ul><li>Software lifecycle processes in accordance with the E-40 Standard </li></ul></ul></ul><ul><ul><li>Part B : Software PA & Project Management </li></ul></ul><ul><ul><ul><li>Software project management, configuration and documentation management and software product assurance in accordance with ECSS Q-80 and M-series Standards </li></ul></ul></ul><ul><ul><li>Part C : Document Templates </li></ul></ul>First ECSS Software Engineering Standards Tailoring: the SEMG
    16. 16. Experience with the SEMG <ul><li>ECSS-E-40 and ECSS-Q-80 are consistent </li></ul><ul><ul><li>E.g. Tailoring of Q-80 flows naturally from that of E-40 </li></ul></ul><ul><li>ECSS-M standards are </li></ul><ul><ul><li>Focused more on overall space project management </li></ul></ul><ul><ul><li>Not adapted for software engineering </li></ul></ul><ul><ul><li>Stylistically inconsistent with E-40 and Q-80 </li></ul></ul><ul><li>Following a period of usage of the SEMG, the following needs arose </li></ul><ul><ul><li>To align the SEMG with the latest versions of the ECSS Standards </li></ul></ul><ul><ul><li>To provide traceability to the ECSS applicable standards </li></ul></ul><ul><ul><li>To retrofit the users experience with the usage of SEMG </li></ul></ul><ul><ul><li>To address some specific problems with the first tailoring e.g.: far too many (over 50) deliverables </li></ul></ul><ul><ul><ul><li>Due to lack of clarity on mapping of deliverables to process outputs, especially in ECSS-E-40 </li></ul></ul></ul><ul><ul><li>Tailoring not critical enough (did not go far enough) </li></ul></ul>
    17. 17. <ul><li>Tailoring of ECSS Software Standards for Ground Segments in ESA – SETG , BSSC 2005(1) </li></ul><ul><li>BSSC established a support contract with Fraunhofer Institute for Experimental Software Engineering (IESE) in July 2004 </li></ul><ul><ul><li>IESE has experience in the software standards domain </li></ul></ul><ul><ul><li>IESE is an experimental institute which brings together a solid theoretical background with a down-to-earth mindset </li></ul></ul><ul><li>Main process steps </li></ul><ul><ul><li>Interview of main stakeholders: feedback on SEMG, proposals for improvement </li></ul></ul><ul><ul><li>Review of latest ECSS standard versions against SEMG </li></ul></ul><ul><ul><li>Review by BSSC and interviewees </li></ul></ul><ul><ul><li>New tailoring started in June 2004 </li></ul></ul><ul><ul><li>SETG published in June 2005 </li></ul></ul>A step forward – The SETG
    18. 18. <ul><li>The process descriptions must be streamlined and made more structured, with clear identification of the activities to be performed </li></ul><ul><li>Explicit identification of process outputs is required </li></ul><ul><li>The review/update cycle for outputs/documents should be made more explicit </li></ul><ul><li>Explicit identification of reviews inputs and outputs should be provided </li></ul><ul><li>The processes outputs should be mapped to documents as far as possible </li></ul><ul><li>The number of documents to be produced (about 50 in SEMG) was excessive </li></ul><ul><ul><li>to be reduced as far as possible by elimination of redundancies and aggregation of outputs </li></ul></ul><ul><li>No traceability to ECSS requirements. Tailoring is not transparent </li></ul>Feedback on SEMG
    19. 19. <ul><li>Traceability to ECSS requirements has been provided </li></ul><ul><li>The processes and the terminology have been aligned with the latest relevant ECSS standards version </li></ul><ul><li>T he processes have been consolidated in line with ESA Ground Segment practice </li></ul><ul><li>T he processes outputs have been detailed and associated with documents and reviews as far as necessary </li></ul><ul><li>Reviews inputs and outputs have been detailed </li></ul><ul><li>Traceability of outputs vs. documents has been provided </li></ul><ul><li>The number of mandated documents has been considerably reduced ( from 50 to 16 !) and the document life-cycles have been made explicit </li></ul>Main changes in the SETG
    20. 20. <ul><li>The SETG has four parts: </li></ul><ul><li>Part A: Software Engineering </li></ul><ul><ul><ul><li>Software lifecycle processes in accordance with the E-40 Standard </li></ul></ul></ul><ul><li>Part B: Product Assurance and Management </li></ul><ul><ul><ul><li>Software project management, configuration and document management and software product assurance in accordance with ECSS Q-80 and M-series Standards </li></ul></ul></ul><ul><li>Part C: Document Templates </li></ul><ul><ul><ul><li>Packaging of processes outputs </li></ul></ul></ul><ul><li>Part D: Traceability Against ECSS Standards </li></ul><ul><ul><ul><li>Traceability Matrix with respect to ECSS Standards Requirements </li></ul></ul></ul><ul><ul><ul><li>Outputs vs. Documents </li></ul></ul></ul>The SETG
    21. 21. The SETG Structure Development Maintenance Verification Validation Project management Configuration management Document management Product assurance Process assurance Primary life cycle processes Support life cycle processes Part B Part A
    22. 22. ECSS processes and the SETG SETG
    23. 23. ECSS processes and the SETG (Cont.) ESTEC Ground Segment Manager/ Final User ESOC engineering OPS Industry Customer that performs the System requirement engineering Customer that performs the System requirement engineering Customer that makes only System/ Software requirement engineering Supplier that does only development Supplier that does only development software spec - CDR system software spec – A R 1 system software spec – AR 2 Customer that delegates the system requirement engineering to its Supplier Supplier that does everything Supplier that does everything Supplier that does the rest Supplier that does the rest E40 applicable SETG as a valid tailoring of E40 SETG as OPS/ industry sw std
    24. 24. <ul><ul><li>Unchanged 529 </li></ul></ul><ul><ul><li>Tailored 20 </li></ul></ul><ul><ul><li>Tailored out 78 </li></ul></ul>Tailoring Statistics 85% 3% 12% unchanged Tailored Tailored out
    25. 25. <ul><li>Table indicates when documents are produced/updated/reviewed </li></ul>Documents Life-cycle
    26. 26. <ul><li>The SETG is a tailoring of ECSS Standards for ESA Ground Segment Software </li></ul><ul><ul><li>It is a more user-friendly version of the BSSC SEMG, aligned with the latest versions of the ECSS Standards </li></ul></ul><ul><ul><li>The traceability to the ECSS Standards is fully documented [SETG-Part-D] </li></ul></ul><ul><li>The SETG is intended to be used as the applicable tailoring for ESOC software development and maintenance contracts </li></ul><ul><li>ESRIN is considering adopting the SETG for their Ground Segment Software </li></ul><ul><li>The SETG is available </li></ul><ul><ul><li>On the BSSC Web Site </li></ul></ul><ul><ul><li>http://www. estec . esa . int / wmwww /EME/ Bssc / stds . htm </li></ul></ul><ul><ul><li>On the BSSC LN Database </li></ul></ul>Summary
    27. 27. <ul><li>Review OPS-QMS procedures to align them with SETG </li></ul><ul><ul><li>WG established in Q4 2005 </li></ul></ul><ul><ul><li>WG reviewed 39 procedures </li></ul></ul><ul><ul><li>DCRs raised on 19 documents </li></ul></ul><ul><ul><li>Work has been completed </li></ul></ul><ul><li>Tailoring required for small projects and studies </li></ul><ul><ul><li>Can be based on tailoring of ECSS-E-40 only </li></ul></ul><ul><ul><li>Approach will be to keep this tailoring consistent with the SETG </li></ul></ul><ul><ul><li>Will be a BSSC activity for 2006 </li></ul></ul>Next Steps
    28. 28. Conclusions <ul><li>Improvement of ECSS software standards needed </li></ul><ul><ul><li>These standards are not easy to use </li></ul></ul><ul><ul><ul><li>Not “ readily understandable” and unambiguous, inconsistent in some cases </li></ul></ul></ul><ul><li>Tailoring of ECSS software engineering standards is a significant challenge </li></ul><ul><ul><li>E-40 and Q-80 give all options, but not what actually required in given project </li></ul></ul><ul><ul><li>Solutions have been identified, but there is still some way to go </li></ul></ul><ul><ul><li>Proliferation of tailorings must be avoided </li></ul></ul><ul><ul><ul><li>Define families of software applications </li></ul></ul></ul><ul><ul><ul><li>Have tailoring done by experts </li></ul></ul></ul><ul><ul><ul><li>Promising work done by </li></ul></ul></ul><ul><ul><ul><ul><li>TEC-SWE : Tailoring tool </li></ul></ul></ul></ul><ul><ul><ul><ul><li>http://www.estec.esa.nl/wmwww/EME/index.htm </li></ul></ul></ul></ul><ul><ul><ul><ul><li>BSSC : Tailoring of ECSS Software Engineering Standards for Ground Segments </li></ul></ul></ul></ul>
    29. 29. Conclusions (Cont.) <ul><li>Software engineering combines the E, Q and M disciplines. The ECSS standards separation into E, Q and M documents is not helpful for software </li></ul><ul><ul><ul><li>Promising work done by BSSC </li></ul></ul></ul><ul><ul><ul><ul><li>Integrated tailoring of software engineering related ECSS standards </li></ul></ul></ul></ul><ul><li>Reviews of standards should not be for “elite” </li></ul><ul><ul><li>People with experience in the field should be included as far as possible </li></ul></ul><ul><ul><li>Reviews should be means to expose the standards to the people who will use them </li></ul></ul><ul><ul><ul><li>Feedback </li></ul></ul></ul><ul><ul><ul><li>Awareness </li></ul></ul></ul><ul><ul><ul><li>Commitment </li></ul></ul></ul>

    ×