1 / 110

Implementing ECSS Software Engineering Standards at ESOC

Implementing ECSS Software Engineering Standards at ESOC. A course on using the Ground Segment Software Engineering and Management Guide (GS SEMG) John Barcroft. PART 1. PART 2. PART 3. PART 4. Implementing ECSS Software Engineering Standards at ESOC. Course Contents.

fox
Download Presentation

Implementing ECSS Software Engineering Standards at ESOC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing ECSS Software Engineering Standards at ESOC A course on using the Ground Segment Software Engineering and Management Guide (GS SEMG) John Barcroft

  2. PART 1 PART 2 PART 3 PART 4 Implementing ECSS Software Engineering Standards at ESOC Course Contents OVERVIEW – PSS-05, ECSS and GS SEMG SOFTWARE ENGINEERING MANAGEMENT and PRODUCT ASSURANCE CONTRACTSand TAILORING

  3. Overview Session – Contents Introductions Introduction to ECSS Overview of ECSS-E-40 • process-based standards • customer/supplier relationships • lifecycles • documentation ECSS-E-40 and PSS-05-0 Applying ECSS software standards to ground segment software – GS SEMG

  4. ESA Standards Policy • In June 1994, ESA (Council resolution ESA/C/CXIII/Res 1) • adopted the new standards being prepared by the European Cooperation for Space Standardisation (ECSS) • decided to phase out the ESA PSS standards

  5. ECSS Architecture Levels • Level 0 (ECSS-P-00 Standardization Policy) • policy and objectives of the ECSS system and its architecture • principles for document creation, validation and maintenance • Level 1 documents • policy and principles in the specific domain • global view of the requirements • outline of interfaces between the elements (and the documents) at Level 2 • Level 2 documents • requirements and functions (“what to do” and expected output) for all aspects in the individual domain • Level 3 documents • methods, procedures and tools to achieve the requirements of Level 2 documents (“how to do”)

  6. ECSS Standards Architecture

  7. ECSS Standards relevant to Ground Segment Software • Engineering Standards: Systems Engineering: ECSS-E-10 Ground Segment Engineering: ECSS-E-70 Software Engineering: ECSS-E-40 • Software Product Assurance: ECSS-Q-80 • Software Project Management: • Policy and Principles: ECSS-M-00 • Project Breakdown Structures: ECSS-M-10 • Project Organisation: ECSS-M-20 • Phasing and Planning:ECSS-M-30 • Configuration Management: ECSS-M-40 • Information/Documentation Management: ECSS-M-50

  8. ECSS Level-3 Software standards • ECSS-E-40 is a “level 2” standard • In preparation: level 3 standards: • ECSS-E-40-1 Space Segment Software • ECSS-E-40-3 Ground Segment Software • ECSS-E-40-4 Software Lifecycles • Level 3 standards contain no new requirements • provide guidance (not “normative”)

  9. ECSS-E-40 (SW Engineering) and ECSS-Q-80 (SW PA) • Q. Who wrote them? • A. ECSS Working Groups with participation of ESA, CNES and Industry • A single WG has been responsible for both documents • N.B. they are produced by ECSS and are not ESA or BSSC documents! • Q. Where do I find ECSS documents? • A. At http://www.ecss.nl

  10. Basis of ECSS-E-40 • ECSS-E-40 is derived from ISO/IEC 12207 • ISO/IEC 12207 is the leading international software engineering standard • issued in 1995 • Information Technology – Software Life Cycle Processes • intended for use in contractual situations • ECSS-E-40 is a tailoring of ISO 12207 for space projects

  11. Process-based Standards • ISO 12207 and ECSS-E-40 are based on • processes • requirements on those processes (component activities and their expected outputs) • They are in effect “standards for making standards” • meta-standards, templates for standards • Process approach comes from vogue for business process re-engineering of the 1990’s • Process model can always be projected into a set of phased activities S1 is a supporting process for a repetitive activity like review, which can be “called” by a primary process. A Primary Processes B C S1

  12. Tailoring Tailoring is a process by which individual requirements or specifications, Standards and related documents are evaluated and made applicable to a specific project, by selection and in some exceptional cases, modification of existing or addition of new requirements ECSS-E-40B

  13. E-40 Q-80 E-40/Q-80, M- M- series ECSS-E-40 and ISO 12207 Processes ECSS-E-40 and ECSS-Q-80 are based on ISO 12207 5. PRIMARYLIFE CYCLE PROCESSES 6. SUPPORTINGLIFE CYCLE PROCESSES ISO 12207 Processes: 5.1 Acquisition 6.1 Documentation 6.2 Configuration Management 5.2 Supply 6.3 Quality Assurance 5.3 Development 5.4 Operation 6.4 Verification 6.5 Validation 6.6 Joint Review 5.5 Maintenance 6.7 Audit 6.8 Problem Resolution 7. ORGANIZATIONAL LIFE CYCLE PROCESSES 7.1 Management 7.3 Infrastructure 7.4 Training 7.2 Improvement

  14. ECSS-E-40/Q-80 Scope Concerns the “Product software”, i.e. software that is part of a space system product tree and developed as part of a space project. Applicable to all the elements of a space system: the space segment, the launch service segment and the ground segment. N.B. By comparison, PSS-05 applied to “all deliverable software implemented for ESA in house or by industry”

  15. Customer-Supplier Relationships Reviews are the main interaction points between the customer and supplier

  16. E-40 Processes and Activities

  17. Software Maintenance 5.8 Software Operations Engineering 5.7 Validation and Acceptance 5.6 Design Engineering 5.5 Requirements Engineering 5.4 System Engineering 5.2 SRR SWRR PDR CDR QR AR ORR State: functional specified defined qualified accepted ECSS-E-40 Overview Legend: SRR System Requirements Review SWRR Software Requirements Review (GS SEMG option) PDR Preliminary Design Review CDR Critical Design Review QR Qualification Review AR Acceptance Review ORR Operational Readiness Review

  18. Legend: SRR System Requirements Review SWRR Software Requirements Review (GS SEMG option) PDR Preliminary Design Review CDR Critical Design Review QR Qualification Review AR Acceptance Review ORR Operational Readiness Review Software Maintenance Software Operations Engineering Validation and Acceptance Design Engineering Requirements Engineering System Engineering SRR SWRR PDR CDR QR AR ORR Customer Customer Supplier ECSS-E-40 Overview - Standard Customer-Supplier Relationship N.B. Analogue of FFP PSS-05 Development based on URD

  19. Legend: SRR System Requirements Review SWRR Software Requirements Review (GS SEMG option) PDR Preliminary Design Review CDR Critical Design Review QR Qualification Review AR Acceptance Review ORR Operational Readiness Review Software Maintenance Software Operations Engineering Validation and Acceptance Design Engineering Requirements Engineering System Engineering SRR SWRR PDR CDR QR AR ORR Customer Customer Supplier ECSS-E-40 Overview - Alternative Customer-Supplier Relationship (GS SEMG) N.B. Analogue of FFP PSS-05 Development based on SRD

  20. Software Lifecycles • The lifecycle defines the sequencing and dependency of the processes • As with PSS-05, choice of the lifecycle is a management activity • the supplier must document the choice in the Software Development Plan • E-40 does not impose any lifecycle - it only requires that one is defined

  21. Waterfall Model

  22. Evolutionary Model

  23. ECSS-E-40 Overview: Document Outputs Requirements Baseline (RB) Interface Requirements Document (IRD) Technical Specification (TS) Interface Control Document (ICD) Design Definition File (DDF) Design Justification File (DJF) Maintenance File (MF) Operations Plan (OP) Software Maintenance Software Operations Engineering Validation and Acceptance Design Engineering Requirements Engineering System Engineering SRR SWRR PDR CDR QR AR ORR RB (IRD) Customer DJF TS (ICD) DDF DJF DDF DJF DDF DJF MF DDF DJF DJF OP

  24. Software documentation RB Requirements Baseline TS Technical Specification Customer’s requirements Supplier Specification Interface Control Document Interface Requirements ... ... ... ... DJF Design Justification File DDF Design Definition File Justification of design trade-offs Design of all components Verification and Validation Plans Software code Milestone reports, test results Release information ... ... N.B. Expected contents at each review specified in Annex A of ECSS-E-40

  25. Special requirements • Man-machine interfaces • Software reuse

  26. ECSS-E-40 to PSS-05 Relationship – 1 of 2 • Detailed analysis: “PSS-05-0 and ECSS-E-40 Comparison”, BSSC(98)2 • Main conclusion : • PSS-05 mandatory practices cover many (~70%) of the ECSS-E-40 requirements, • identification of ECSS-E-40 requirements not covered by PSS-05-0 practices

  27. UR SR AD DD TR OM UR/R SR/R AD/R PA FA DD/R Software Maintenance Software Operations Engineering Validation and Acceptance Design Engineering Requirements Engineering System Engineering SRR SWRR PDR CDR QR AR ECSS-E-40 to PSS-05 Relationship – 2 of 2

  28. Q-80 organisation

  29. ECSS-E-40/PSS-05 Features Comparison Processes versus practices E-40 is based on ISO 12207 cf. PSS-05 is based on IEEE SW standards Customer/supplier relationship E-40 is to be used with other M and Q standards cf. PSS-05 is a “one-stop” shop Integration within the system life-cycle (reviews) versus software only projects Tailoring versus mandatory and recommended practices Process outputs “files” versus documents with strict tables of contents E-40 addresses space system product tree: PSS-05 is a general software standard

  30. ECSS-E-40 and PSS-05 • Could you use PSS-05 as a response to ECSS-E-40? • In principle yes • But not recommended because : • different terminology for reviews, outputs, etc • PSS-05 does not completely cover ECSS-E-40

  31. Transition from PSS-05 to ECSS SW Standards • Difficulties: • transition from a practice-based standard to a process-based standard • many standards (E40, Q-80, ECSS-M-) instead of one (PSS-05).

  32. ESA Ground Segment Software Engineering and Management Guide (ESA GS SEMG) • Solves problems by • providing ECSS compliance in the form of a set of practices • covering all relevant ECSS standards in a single document

  33. ESA Ground Segment Software Engineering and Management Guide(ESA GS SEMG) • SEMG is based on “B” versions of E-40 and Q-80 • improved versions undergoing public review • SEMG has three volumes • Part A: Software Engineering covering ECSS-E-40 • Part B: Management covering ECSS-Q-80 and ECSS-M- series • Part C: Document Templates

  34. SEMG Part A: Software Engineering • Drafted by an ESOC WG: • Members: Y Doat, G di Girolamo, G Gienger, A Head, M Jones, E Perdrix and S Valera • Technical Author from Anite (Richard Jack, then John Brinkworth and John Barcroft) • Is in line with ECSS-E-40-3 “Space Engineering - Ground Segment Software” • ECSS guide to tailoring E-40 for ground segments • Introduces another review (between SRR and PDR) to line up with PSS-05 practice.

  35. A C B D Integrate, Verify & Validate G/S systems (includes preliminary validation of mission data Identify Characteristics, Constraints, Concepts. Assess feasibility. (G/S) perspective Train people & Validate full G/S (i.e. includes people and mission data Complete G/S design to element level & start implementation ECSS-E-70 ACTIVITIES Define requirements on G/S& G/S Baseline Procure G/S facilities & elements GSTVVR GSRR GSPDR GSCDR ECSS-E-70 REVIEWS ORR GSTVVRR OVRR ECSS-E-40 and ECSS-E-70 Relationship? Validation and Acceptance Design Engineering Requirements Engineering SW Requirements Analysis E-40 Processes Architectural Design System Engineering QR AR CDR SWRR PDR SRR E-40 Reviews

  36. SEMG Part B : Management Problems of using the ECSS-M standards • requirements drawn from many ECSS source documents • inconsistent terminology • requirements must be filtered out that do not apply to software and/or ground segment (spacecraft prime management aspects, spacecraft model philosophy…) • not complete for software

  37. SEMG Part B : Management SEMG solves the problems by • using consistent terminology and style in line with ECSS-E-40/Q-80 • removing inapplicable material • where needed, providing missing software-specific material (mainly from PSS-05)

  38. Status of GS SEMG • Final revision by BSSC completed in March • Officially published and now applicable • Companion tailoring template available in draft • Applicability: primarily intended for use in ground segment software development in D/TOS at ESOC

  39. Afterthought: PSS-05 and the GS SEMG • PSS-05-0 Issue 2 appeared in 1991 • The revision cycle for such standards is ca. 5-6 years • PSS-05-0 is overdue for revision! • Revision ruled out by the change in ESA policy (no new PSS) • If it had been revised, it would probably have been brought in line with ISO12207 • The result may well have had similarities to the GS SEMG!

  40. Transition to ECSS Software Standards at ESOC • Approach described in BSSC(2000)2, July 2000 “Transition to ECSS Software Standards” • ECSS-E-40 and ECSS-Q-80 are applicable for the software activities of ESA projects • Not required to apply ECSS-E-40 retroactively to projects already using ESA PSS-05-0 • SEMG is implementation of ECSS software standards • ESOC QMS changes identified (minimal), mainly • references to PSS-05 • use of ECSS terminology

  41. Tailoring Template (draft) • Lists inputs and outputs by process • Gives • tailoring condition (i.e. the circumstances in which the tailoring can be done) • tailoring possibility (i.e. the details of the tailoring actions that can be applied) • Can be used as a form to record a specific set of tailoring actions and the reasons for them

  42. PART 1 PART 2 PART 3 PART 4 Implementing ECSS Software Engineering Standards at ESOC Course Contents OVERVIEW – PSS-05, ECSS and GS SEMG SOFTWARE ENGINEERING MANAGEMENT and PRODUCT ASSURANCE CONTRACTSandTAILORING

  43. Software Engineering Session – Contents Recap Overview of E-40 / SEMG software engineering processes

  44. Recap • SEMG • Part A: Software Engineering covering ECSS-E-40 • Part B: Management covering ECSS-Q-80 and ECSS-M- series • Part C: Document Templates • Tailoring Template (draft) • Inputs and outputs for each process • Tailoring condition • Tailoring possibility

  45. Launch service segment Ground segment Space segment Ground segment subsystem Equipment Software product Software component Software unit Scope Space system ground operations organisation + group of subsystems (facility) = ground segment entity

  46. KEY SEMG A E-40 5.9 Software verification and validation(supporting) processes 6.3 6.6 Critical software Ground segment software Mapping of SEMG Part A to E-40 3 System engineering for software 5.2 4 Software management 5.3 Handled in-line in SEMG A 5 Software requirements engineering 5.4 Not applicable 6 Software design engineering 5.5 7 Software validation and acceptance 5.6 Refers reader to E-40-3 8 Software operations engineering 5.7 9 Software maintenance 5.8 6.2 Space segment software 10 Software reuse 6.4 11 Man-machine interfaces 6.5 General requirements = 5.n Special requirements = 6.n Refers reader to Q-80

  47. Inputs Process Outputs Activity ‘shall’ mandatory Task ‘should’ recommended ‘may’ optional Processes, activities and tasks Note: ECSS-E-40 uses only ‘shall’ SEMG uses PSS-05 approach

  48. Software Engineering Processes and Activities

  49. Validation and Acceptance Design Engineering Requirements Engineering System Engineering SRR SWRR PDR CDR QR AR IRD IRD System engineering for software Done by Customer • System requirements analysis • System partitioning • System-level requirements for software verification and validation • System-level requirements for software integration milestone is SRR RB DJF Note: ECSS-E-40 sees each software element in relation to the system e.g. to the next higher level, not just a “stand-alone” user requirements statement

  50. SDP (Software Development Plan) Software management • Planning • Selection of the software life cycle model • Technical budget and margin management

More Related