Implementing ECSS Software Engineering Standards at ESOC

Implementing ECSS Software Engineering Standards at ESOC
Issue 2.1 (25 Nov 02) Implementing ECSS Software Engineering Standards at ESOC A course on using the Ground Segment Software Engineering and Management Guide (GS SEMG) John Barcroft Issue 2.1 (25 Nov 02)

Issue 2.1 (25 Nov 02) Implementing ECSS Software Engineering Standards at ESOC Course Contents PART 1 OVERVIEW – PSS-05, ECSS and GS SEMG PART 2 SOFTWARE ENGINEERING PART 3 MANAGEMENT and PRODUCT ASSURANCE PART 4 CONTRACTS and TAILORING

Overview Session – Contents
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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 Duration = 1½ hours approx. Cover: overall timings practical arrangements: toilets, coffee, breaks, lunch participants’ list to be filled in for HR training records materials: copies of SEMG and tailoring template, slide handout, evaluation form, blank paper style: interactive – ask questions, contribute own experience; plus some exercises in the later sessions may find bugs in SEMG and TT – will be recorded introductions presenter – name and background each participant – name, company/ESA, department, function, knowledge of PSS-05 and ECSS

Issue 2.1 (25 Nov 02) 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

ECSS Architecture Levels
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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”) Level 0 explains how committees are organised, the lifecycle and approval processes for standards, etc. Level 1 – domains are Management, Product Assurance, Engineering, as we’ll see Explain significance of “shall” (cf. “should” and “may”)

ECSS Standards Architecture
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) ECSS Standards Architecture

Issue 2.1 (25 Nov 02) 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

ECSS Level-3 Software standards
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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”) Some level 3 documents do contain normative material, but this is not the case with E-40/Q-80

ECSS-E-40 (SW Engineering) and ECSS-Q-80 (SW PA)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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 Don’t use .com, which takes you to a Web site for East Coast Security Services Inc. in the US!

Issue 2.1 (25 Nov 02) Basis of ECSS-E-40 ECSS-E-40 is derived from ISO/IEC 12207 ISO/IEC 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 for space projects

Process-based Standards
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Process-based Standards ISO 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 A process is a set of activities and related resources that transform an input into an output. A process model is not a step-by-step procedural description like a recipe. Rather, it is a set of elastic building blocks that can be put together in different ways. The relationships between the processes are defined for a particular case, within general constraints. (Mention the ‘float limits’ for processes – e.g. design can’t start until you have your system requirements.) C S1

Issue 2.1 (25 Nov 02) 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 Criteria to be applied (e.g. risk, cost, size) – more on this later Pick what’s appropriate Modified or new rare because ECSS quite comprehensive

ECSS-E-40 and ISO 12207 Processes
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) ECSS-E-40 and ISO Processes ECSS-E-40 and ECSS-Q-80 are based on ISO 12207 5. PRIMARY LIFE CYCLE PROCESSES 6. SUPPORTING LIFE 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 Q-80 E-40 E-40/Q-80, M- M- series 6.5 Validation 6.6 Joint Review 5.5 Maintenance 6.7 Audit 6.8 Problem Resolution 5.1 and 5.2 especially M-00 6.1 is M-50 6.2 is M-40 7. ORGANIZATIONAL LIFE CYCLE PROCESSES 7.1 Management 7.3 Infrastructure 7.2 Improvement 7.4 Training

Issue 2.1 (25 Nov 02) 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” This Standard also applies to the development of non-deliverable software which affects the quality of the deliverable product. Other classes of software products not covered are:management information systems (e.g. finance, planning), technical information systems (e.g. CAD/CAM, analysis packages) and supporting software products for documentation systems, database systems, spread-sheets. These usually result from the procurement or adaptation of existing commercial products, and are not part of the space system

Customer-Supplier Relationships
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Customer-Supplier Relationships Reviews are the main interaction points between the customer and supplier The fundamental principle of this Standard is the customer-- supplier relationship, assumed for all software developments. The organizational aspects of this are defined in ECSS--M—20 (Project Organisation). The customer is, in the general case, the procurer of two strongly associated products: the hardware and the software for a system, subsystem, set, equipment or assembly (see ECSS--E--00). The concept of the customer-supplier relationship is applied recursively, i.e. the customer can himself be a supplier to a higher level in the space system as shown in Figure 1. Supplier not necessarily external. ‘Business agreement’ – which is sometimes a contract

E-40 Processes and Activities
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) E-40 Processes and Activities

Issue 2.1 (25 Nov 02) 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 Software Maintenance 5.8 Software Operations Engineering 5.7 ORR QR AR Validation and Acceptance 5.6 qualified accepted Design Engineering 5.5 CDR defined PDR SWRR Requirements Engineering 5.4 specified SRR System Engineering 5.2 functional State: There are six major reviews that mark progress in the software life cycle. These reviews are: System Requirement Review (SRR), which marks approval of the requirements baseline Software Requirements Review (SWRR), which marks the customer’s agreement that all requirements with respect to the RB are captured in the software requirements specification Preliminary Design Review (PDR), which marks approval of the technical specification and the software architectural design Critical Design Review (CDR), which marks approval of the detailed design, source code and the results of testing Qualification Review (QR), which marks approval of the software against the technical specification Acceptance Review (AR), which marks acceptance of the software against the intended operational environment These reviews have been selected as the minimum necessary for a workable contractual relationship. They are normally conducted at the completion of a key activity. They must be present in all projects and must include the customer. In long projects, additional milestones should be added to measure the progress of deliverables. Note: SEMG mentions only specified and defined states.

ECSS-E-40 Overview - Standard Customer-Supplier Relationship
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) ECSS-E-40 Overview - Standard Customer-Supplier Relationship 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 Design Engineering PDR SRR CDR QR AR System Engineering Validation and Acceptance SWRR Requirements Software Maintenance Software Operations Engineering ORR More than one supplier and more than one contract may be involved. A ‘typical’ project might have a FUP (fixed unit price) contract for developing the software requirements specification and interface control document – i.e. up to SWRR a FFP (firm and fixed price) contract for design engineering and validation against the TS – i.e. up to QR a FUP contract for support to the start of operations contracts for first and second line maintenance. Customer Supplier N.B. Analogue of FFP PSS-05 Development based on URD

Issue 2.1 (25 Nov 02) ECSS-E-40 Overview - Alternative Customer-Supplier Relationship (GS SEMG) 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 Design Engineering PDR SRR CDR QR AR System Engineering Validation and Acceptance SWRR Requirements Software Maintenance Software Operations Engineering ORR Starting the contract based on the software requirements specification has the implication that validation testing is done against the TS. Customer Supplier N.B. Analogue of FFP PSS-05 Development based on SRD

Issue 2.1 (25 Nov 02) 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

Issue 2.1 (25 Nov 02) Waterfall Model

Issue 2.1 (25 Nov 02) Evolutionary Model

ECSS-E-40 Overview: Document Outputs
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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 The RB will contain the customer requirements. The customer requirements are a critical item for the whole software project because they define the basis upon which the software is accepted. Interface Requirements Document (IRD) specifies the requirements for external interfaces for the overall system and the interfaces between the constituent parts of the system. IRD shown in brackets because it is conceptually part of the RB. Technical specification (TS), as well as defining what the product must do, is also the reference against which both the design and the product will be verified. Although ‘how’ aspects may have to be addressed, they should be eliminated from the TS, except for those aspects that constrain the software. Examples of constraints that may be placed on the development include the use of COTS, existing infrastructure and schedule. Interface Control Document (ICD) is supplier’s response to IRD ICD shown in brackets because it is part of the TS. Design Definition File (DDF): all elements of the software design are documented including the source code. The Design Justification File (DJF) is generated and reviewed at all stages of the development and review process. It contains the documents that describe the trade-offs, design choice justifications, test procedures, test results, evaluations and any other documentation called for to justify the design of the product. The DJF is the primary input for the Qualification and Acceptance Reviews and acts as supporting input to other reviews. Note: IRD is part of RB. Similarly ICD is part of TS. (E-40 note says: Space segment software is in general integrated with highly specialised processors and electrical equipment. The IRD and ICD therefore have a special importance and are controlled separately to ensure consistent design throughout the hardware and software life cycle.) SWRR files are same set as SRR. ORR is actually a system-level review. Software OP is finalised for AR; normally drafted by CDR RB (IRD) Customer DJF TS (ICD) DDF DJF DDF DJF DDF DJF MF DDF DJF DJF OP

Software documentation
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software documentation RB Requirements Baseline TS Technical Specification Customer’s requirements Supplier Specification Interface Requirements Interface Control Document ... ... ... ... DDF Design Definition File DJF Design Justification File Justification of design trade-offs Mention (Contribution to) Management File (MGT; software development plan …) Operations Plan/Operational Documentation (OP) Maintenance File (MF) Product Assurance File (PAF) Design of all components Software code Verification and Validation Plans Release information Milestone reports, test results ... ... N.B. Expected contents at each review specified in Annex A of ECSS-E-40

Issue 2.1 (25 Nov 02) Special requirements Man-machine interfaces Software reuse More on these later. They are different because they affect more than just an individual process.

ECSS-E-40 to PSS-05 Relationship – 1 of 2
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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

ECSS-E-40 to PSS-05 Relationship – 2 of 2
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) ECSS-E-40 to PSS-05 Relationship – 2 of 2 PA FA SR/R UR AD DD TR OM UR/R AD/R DD/R SR Design Engineering PDR SRR CDR QR AR System Engineering Validation and Acceptance SWRR Requirements Software Maintenance Software Operations Engineering PSS-05 phases: UR = user requirements definition SR = software requirements definition AD = architectural design DD = detailed design and production TR = transfer OM = operations and maintenance /R = review milestone for specified phase PA = provisional acceptance FA = final acceptance Note that FA is assumed to take place early in the OM phase.

Issue 2.1 (25 Nov 02) Q-80 organisation Top box deals with management and organisation. Bottom left with process assurance Bottom right with product QA Purpose is to provide adequate assurance that the software product and processes conform with requirements and plans By measuring and controlling quality of product, indirectly, using metrics of processes, directly by ensuring that documented and verified processes are used By ensuring that a system of process improvement is used. Direct checking of product is covered in E-40.

ECSS-E-40/PSS-05 Features Comparison
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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 Tailoring versus mandatory and recommended practices Integration within the system life-cycle (reviews) versus software only projects Process outputs “files” versus documents with strict tables of contents E-40 addresses space system product tree: PSS-05 is a general software standard

Issue 2.1 (25 Nov 02) 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

Transition from PSS-05 to ECSS SW Standards
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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).

Issue 2.1 (25 Nov 02) 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

Issue 2.1 (25 Nov 02) 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 Note that Appendix C in A and B has an informative document lifecycle table

SEMG Part A: Software Engineering
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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.

ECSS-E-40 and ECSS-E-70 Relationship?
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) ECSS-E-40 and ECSS-E-70 Relationship? ECSS-E-70 ACTIVITIES Identify Characteristics, Constraints, Concepts. Assess feasibility. (G/S) perspective GSRR GSPDR GSTVVRR GSCDR Define requirements on G/S& G/S Baseline Complete G/S design to element level & start implementation Procure G/S facilities & elements Integrate, Verify & Validate G/S systems (includes preliminary validation of mission data Train people & Validate full G/S (i.e. includes people and mission data REVIEWS GSTVVR OVRR A B C D ORR Validation and Acceptance Design Engineering Requirements Engineering E-40 Processes SW Requirements Analysis Architectural Design E-70 phases: 0/A = feasibility studies and conceptual design B = preliminary design C = design D = production (1 production/procurement; 2 technical validation; 3 operational validation) E = in-orbit operations F = mission termination The phases and milestones that constitute the software development life cycle are not to be identified with the Ground Segment / Mission Life Cycle phases (or the Space Segment Life Cycle phases for that matter). Software development life cycle is individually defined for each development. The synchronisation of reviews with higher level reviews is project-dependent. DO NOT CONFUSE e.g. GSPDR with s/w PDR. THIS MESSAGE IS DELIVERED IN SEMG, BUT DIAGRAM COULD BE TAKEN TO IMPLY A MAPPING. System Engineering SRR SWRR PDR CDR QR AR E-40 Reviews

SEMG Part B : Management
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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

SEMG Part B : Management
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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)

Issue 2.1 (25 Nov 02) 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

Afterthought: PSS-05 and the GS SEMG
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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 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!

Transition to ECSS Software Standards at ESOC
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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 ECSS terminology (e.g. SRS, RB)

Tailoring Template (draft)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) 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 No PSS-05 lite as such. Filter for invoking a tailored SEMG Have a look!

Software Engineering Session – Contents
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software Engineering Session – Contents Recap Overview of E-40 / SEMG software engineering processes Duration = 1½ hours approx.

Issue 2.1 (25 Nov 02) 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 Note that Appendix C in A and B has an informative document lifecycle table, which also appears in Part C.

Issue 2.1 (25 Nov 02) Scope Space system Ground segment Launch service segment Space segment Ground segment subsystem Software product Equipment Software component Software unit e.g. Operations Control System (OCS) might contain following products: control system kernel mission planning system file transfer system data distribution system Scope = software engineering of ground systems or products within them. Not concerned with ground operations organisations, but of course their needs have a profound effect on the software. ground operations organisation + group of subsystems (facility) = ground segment entity

Mapping of SEMG Part A to E-40
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Mapping of SEMG Part A to E-40 E-40 SEMG A KEY 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 Software verification and validation (supporting) processes 5.9 9 Software maintenance 5.8 6.2 Space segment software Ground segment software 6.3 10 Software reuse 6.4 11 Man-machine interfaces 6.5 Critical software 6.6 General requirements = 5.n Special requirements = 6.n Refers reader to Q-80

Processes, activities and tasks
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Processes, activities and tasks Note: ECSS-E-40 uses only ‘shall’ SEMG uses PSS-05 approach Process Outputs Inputs Activity ‘shall’ mandatory Task ‘should’ recommended ‘may’ optional

Software Engineering Processes and Activities
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software Engineering Processes and Activities

System engineering for software
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) System engineering for software PDR SWRR Requirements Engineering Design CDR QR AR Validation and Acceptance SRR System Engineering 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 IRD DJF System engineering is an important concept. It sees hardware and software as elements of the space product tree. Software does not necessarily have a human user. Ariane5-01 failed because of inadequate tracing of sub-system to system and vice versa. System partitioning allocates requirements to hardware, software and human operations (and ensures that all are covered and traceable) System-level requirements for V&V System-level integration: [observability – perhaps best avoided because no one really understands it], interface, customer’s inputs, supplier support (incl. outputs) to software integration into the system Outputs: RB, IRD (interface requirements – mandatory if software is to be integrated with customer’s hardware or software products – part of IRD), DJF (contains here traceability to system partitioning, results of SRR milestone review) 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

Issue 2.1 (25 Nov 02) Software management Planning Selection of the software life cycle model Technical budget and margin management SDP (Software Development Plan) Plans covered in Part B – Development, CM, V&V, Maintenance, QA on process and product Technical Budget and Margin Management deals with the areas of computer resources (e.g. CPU load, maximum memory requirement) and performance requirements. More critical for on-board systems where resource requirements are fixed constraints. Supplier manages margins and presents status at each milestone.

Issue 2.1 (25 Nov 02) Life cycle models Evolutionary Waterfall A life cycle model defines a project into a sequence of phases, which relate the processes to a time base. A life cycle model defines the processes, activities and tasks that occur within each phase and the relationships between each of them. A number of life cycle models exist, but they all share the software development processes The Standard Waterfall Model is essentially a once-through, do-each-activity-once approach. The key characteristic of the waterfall model is that the processes defined by this guide are organised in a sequential manner. A phase can start prior to the completion of a previous phase but it must be recognised that this carries an associated risk. Errors or omissions may become visible at a later stage, requiring rework with an associated cost and schedule impact. The waterfall model allows for a limited amount of iteration between phases, to allow for the correction of defects. This approach is characterised by the planned development of multiple releases. All processes of the life cycle are executed to produce a release (this can include System Engineering depending upon whether all system engineering requirements are knowable at the start). Each release incorporates the experience of earlier releases. The evolutionary approach may be used because, for example: Some customer experience is required to refine and complete the requirements Some parts of the implementation may depend on the availability of future technology Some new customer requirements are anticipated but not yet known Some new customer requirements may be significantly more difficult to meet than others and it is decided not to allow them to delay a usable delivery In an evolutionary development, the supplier should recognise the customer's priorities and produce the parts of the software that are both important to the customer and possible to develop with the minimal technical problems or delays. The disadvantage of the evolutionary approach is that if the requirements are very incomplete at the beginning, the initial software structure may not bear the weight of later evolution. Expensive redesign may be necessary or, even worse, temporary solutions may become embedded in the system and distort its evolution. Customers may become impatient with teething troubles of each new release. In each development cycle, it is important to aim for a complete statement of requirements to reduce risk and to develop an adaptable design to ensure later modifiability. In an evolutionary development, all requirements do not need to be fully implemented in each development cycle but the architectural design should take account of all known requirements. The Dynamic Systems Development Method (DSDM) is a more formal method for undertaking evolutionary development, which allows a management framework for undertaking the development. The incremental delivery life cycle model starts with a given set of requirements and performs the development in a sequence of builds. The first build incorporates a part of the requirements, the next build adds more requirements and so on until the complete product is built. At each build, the necessary processes, activities and tasks are performed e.g. software requirements engineering may be performed once, while the design engineering process is performed during each build. In this approach, as each build is developed, the activities and tasks in the development process are employed in parallel with the operations and maintenance processes.

Issue 2.1 (25 Nov 02) Group Activity SCENARIO Incremental delivery model 3 phases with increasing functionality TASKS Map the processes and reviews onto the development life cycle (consider which processes and reviews to iterate)

Software requirements engineering process
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PDR SWRR Requirements Engineering Design CDR QR AR Validation and Acceptance SRR System Engineering Software requirements engineering process Software requirements analysis roughly equivalent to PSS-05 SR phase milestone is SWRR (GS SEMG option) Software architectural design roughly equivalent to PSS-05 AD phase Software verification and validation [planning] milestone is PDR S/w reqts: functional and performance requirements; quality requirements; security; human factors (ergonomics); data definition and database requirements + external interface requirements Architectural design: top-level architecture and components, interfaces (external and between components), integration plan, verification and traceability Software verification and validation: planning for V&V, based on customer’s reqts (RB) and ECSS V&V processes. Note that verification and validation are covered in E-40, i.e. are considered mainstream engineering activities. TS contains response to RB (software requirement specification) ICD (normally part of TS) contains response to IRD. Would normally contain external interface specifications and preliminary (top-level) internal and external interface designs At the end of this process, the DJF will include the top-level design trade-offs, the requirement traceability and top-level architecture traceability matrices and the PDR milestone report. The DJF also contains the planning aspects for verification and validation. TS ICD DDF DJF

Software design engineering process
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software design engineering process PDR SWRR Requirements Engineering Design CDR QR AR Validation and Acceptance SRR System Engineering Design of software items Coding and testing Integration Validation testing against the technical specification (equivalent of PSS-05 System Testing ST) milestone is CDR cf. PSS-05 DD Phase Detailed design of software components and units; detailed design of interfaces (external and between components and units) – needs to enable coding without further design; needs to makes sure requirements are allocated down the tree; user manual; test reqts and plan (+update to integration test plan); verification and traceability Coding and testing: unit coding and testing (test procedures and test data); user manual update; integration test plan update; verification and traceability Integration: integrate and test units, components into item (i.e. product) OUTPUTS DDF ‘sections’: components design (source code normally included here); software user manual DJF: software unit test plan, software integration plan, software validation against TS (tests, test cases and procedures for validation testing) Updated ICD in TS, with more details on the interfaces DDF DJF + updates to ICD

Software validation and acceptance process
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PDR SWRR Requirements Engineering Design CDR QR AR Validation and Acceptance SRR System Engineering Software validation and acceptance process Validation testing against RB subset-1 milestone is QR carried out in supplier’s environment (no exact PSS-05 equivalent) Delivery and installation Validation testing against RB subset-2 (or TS) carried out at customer’s site on development platform Validation testing against RB milestone is AR carried out in operational environment (like PSS-05 AT) DDF DJF AT = acceptance tests PSS-05 has provisional acceptance (PA) in TR phase and final acceptance (FA) in OM phase. Both take place in the operational environment DDF: software installation plan; source code, build code and executable code (need to be able to re-generate) DJF: preliminary acceptance test spec and results, QR report; operational acceptance test spec and results; observation reports; compliance matrix (acceptance tests to RB); AR report N.B Middle two activities are like PSS-05 TR Phase

Validation testing – summary of the four stages
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Validation testing – summary of the four stages Green = Design Engineering Yellow/Orange = Validation and Acceptance

Software operations engineering process
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software operations engineering process Operational planning (i.e. plans, procedures, standards for the following …) Operational testing System operation User support and anomaly handling (cf. PSS-05 first-line maintenance) OP Main output is operational plans.

Software maintenance process
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software maintenance process Problem and modification analysis Modification implementation Maintenance review/acceptance Software migration (cf. PSS-05 “adaptive” maintenance) Software retirement MF Updates to MF are: problem analysis report; software release note Maintenance Plan; Software Migration Plan and Migration Justification. Development processes can be used. Like the PSS-05 OM phase, but E-40 places more emphasis on migration and retirement separates first-line maintenance into software operations

Issue 2.1 (25 Nov 02) Software Re-use Developing software for intended re-use Customer requirements Supplier requirements Re-using software from other projects Use of third party COTS RB TS SDP DJF Don’t forget re-use of public domain and open source software. Subject to be treated in its own right in next session. This slide just to mention this topic (which is under Special Requirements in E-40). This process is not stand-alone: affects development processes, especially system engineering and software requirements engineering. RB: re-use requirements; software acquisition process for COTS TS: spec to achieve required re-use SDP: software acquisition approach and justification of selected COTS where appropriate DJF: justification of methods and tools; justification of any COTS selected; evaluation of re-use potential when existing software is considered for re-use; software user manual aspects relating to possible re-use

Man-Machine Interfaces
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Man-Machine Interfaces Determine prototyping requirements Determine MMI standards Supplier consideration of MMI aspects RB TS DJF Also in E-40 under Special Requirements. As with Software Re-use, this process is not stand-alone, but rather affects development: system engineering and software requirements engineering in particular. RB: MMI requirements and requirements for use of prototypes TS: specification of MMI requirements DJF: results of prototype evaluation

Management and Product Assurance Session – Contents
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Management and Product Assurance Session – Contents Overview of Part B Project Management Configuration Management Product Assurance Software Reuse and Purchasing of COTS Software Product and Process Metrics Process Improvement Feedback on SEMG and tailoring template Duration = 1:45 approx.

Mapping of SEMG Part B to Q-80
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Mapping of SEMG Part B to Q-80 M- series SEMG B KEY Q-80 2 Software Project Management 3 Configuration Management 4 Software Product Assurance Q-80 4.2 Product Assurance Management 5 Software Product Assurance Process Implementation 4.3 Product Assurance 7 Software Product Quality Assurance 4.4 Process Assurance 6 Software Process Assurance 4.5 Software Product Assurance Plan 4.6 Product Assurance and the Software Lifecycle

Software Project Management
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software Project Management The Software Development Plan Project Management Tasks Project Management and the Software Lifecycle

The Software Development Plan
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) The Software Development Plan Customer specifies project management requirements Supplier responds with Software Development Plan, including project organisation project phasing and planning project work breakdown structures cost and schedule management.

Software Project Management
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Software Project Management Organising the Project Tailoring Management Interface Roles, Responsibilities and Authority Risk Management Technical Management Cost Management Schedule Management Reporting Project Progress business agreement by customer in RFP, response by supplier customer access for audit, inspection customer and supplier project managers, organisation risk management policy and risk register; product assurance involvement methods and tools and enforcing use; organising assurance, CM, V&V costs by WBS and category, payment milestones, CCNs timings, resource allocation, ‘exception’ reporting regular reports and progress meetings (per requirements or contract)

Project Management and the Software Lifecycle
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Project Management and the Software Lifecycle ‘Each planning document exists in outline from the start of the project. It is updated prior to the start of each phase to provide increasing levels of detail, so that each phase is fully planned prior to its commencement’ SEMG B spells out what this means for each life cycle process PDR SWRR Requirements Engineering Design CDR QR AR Validation and Acceptance SRR System Engineering

Configuration Management
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Configuration Management Configuration Management Processes The Configuration Management Plan Configuration Management and the Life Cycle

Configuration Management Processes
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Configuration Management Processes Configuration Identification Choosing Configuration Items Configuration Item Content Configuration Item Storage and Distribution Baselines Forming and Maintaining Baselines Media Configuration Change Control Configuration identification: configuration items (CIs), unique identifiers, version (issue, revision) Choosing configuration items: configuration management or configuration management plus change control – items for each category are listed Configuration Item Content: agreed defined formats and structures Configuration Item Storage and Distribution: access, security, accuracy reqts. on CM system. Also information flows Baseline: set of Cis, reviewed and agreed as basis for future development. Releases: major, minor and patch. Forming and Maintaining Baselines: software configuration file with list of CIs at each milestone and release; configuration status reports (in progress reports) Media: software name, version and ref. to config. file Configuration change control: authorisation and approvals; promotion of a CI through unit, integration, system and acceptance tests – higher levels of authority

Configuration Management Plan
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Configuration Management Plan Defines organisation, methods, means and procedures to manage the configuration Exists for each phase, but appropriately scoped Defines document approval/agreement procedures related document management activities process for receipt, assessment, authorisation and distribution of documents.

Configuration Management and the Life Cycle
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Configuration Management and the Life Cycle

Product Assurance (1 of 2)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Product Assurance (1 of 2) This completes Part A in relation to quality, specifying when product assurance is performed (and often repeating A) Purpose of software PA: provide adequate assurance that the software product and processes conform to their specified requirements and adhere to the established plans, by measuring and controlling quality of product, indirectly, using metrics process, directly, by ensuring that documented and verified processes are used a system of process improvement is employed Direct control of product quality is software validation and acceptance (Part A)

Product Assurance (2 of 2)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Product Assurance (2 of 2) Product Assurance Manager (engineer also mentioned) Product Assurance Plan, maintained throughout project Larger, more risky projects need a product assurance function

Issue 2.1 (25 Nov 02) Overview of Contents PROCESS ASSURANCE Process Improvement Sub-Supplier Control Purchasing COTS Software Re-use of Software Tools, Techniques and Methods and Supporting Environment Hardware Environment for Operational System Process Metrics Verification and Validation Software Problem Reporting Non-Conformance Reporting Assurance of the Configuration Management Process PRODUCT ASSURANCE Product Quality Objectives and Metrics Procedures and Standards Software Dependability and Safety SOFTWARE PRODUCT ASSURANCE PLAN Quick overview of what is covered. Will then examine selected subjects which are perhaps more interesting or new wrt PSS-05 Product Assurance deals with the assurance of the product by Defining product quality objectives and metrication Defining product standards and procedures Ensuring product dependability and safety. Process Assurance Software Product Assurance Plan shall specify or reference: Quality objectives (measurable whenever possible) The software development life cycle, (including milestones and the input and output criteria for each phase) Verification and validation activities (including definition, schedules, resources and approval authorities) Responsibilities for quality activities such as reviews and tests configuration management and change control, non conformance control and corrective action Methods, tools and rules to be used The procedures for determining the criticality category of software processes and items. PA plan lists plans and production schedule. PA assures that each plan is finalised for the phase to which it applies maintained up-to-date reviewed against contractual requirements PA and the software life cycle highlights PA involvement in ensuring compliance, traceability, verification and validation in each life cycle process. PRODUCT ASSURANCE AND THE SOFTWARE LIFE CYCLE

Re-use process (from Part A)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Re-use process (from Part A) Re-use of existing software (also COTS, public domain, open source) should give cost and time savings improved quality (already tested) Software developed for re-use may involve additional costs Topics addressed: Developing software for intended re-use Customer requirements Supplier requirements Re-using software from other projects Use of third party COTS Problems mentioned by previous attendees: pain from wrong re-use of software; re-use problems with KOS and shared kernel; complications when ESA owns the software. Developing software intended for re-use Identify requirements from customer domain that may be used in future projects Normally at customer’s request Supplier must ensure requirements are addressed in each key development process Supplier may request customer to identify requirements for which future re-use might be possible Customer requirements Customer identifies re-use constraints (e.g. architecture constraints due to target platforms, operating systems) Supplier should seek to identify generic aspects of application domain Supplier requirements procedures, methods and tools to ensure that re-use requirements are addressed PDR and CDR review of implementation document CM and design document requirements for re-use items (Part B suggests CM normally independent for software developed for re-use: longer lifetime, transfer to next project) Will look more closely at the last two …

Purchasing COTS software
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Purchasing COTS software Customer identifies acquisition process for COTS/OTS/MOTS Selection criteria (ref. to Part A) financial stability supplier track record with customer support and maintenance access to documentation and source code (esp. for critical software) licensing and IPR suitability for intended use Component list in DJF for customer approval description, ordering criteria, inspection criteria, maintenance and upgrade arrangements, back-up if unavailable, licensing COTS product subject to configuration control Receiving inspection by supplier: report detailing any problems Use of third party COTS products customer specifies COTS and acquisition requirements in RB supplier documents acquisition process in SDP and implements it supplier should consider use of COTS that meet project requirements requirements may need to be adjusted (to fit COTS) – discussion with customer needed investigation of COTS packages and selection reasons recorded in DJF Selection factors for special attention: financial stability supplier track record with customer support and maintenance access to documentation and source code (esp. for critical software) licensing and IPR suitability for intended use. Selection criteria – public domain and open source subject to similar criteria, but supplier maintenance may be non-existent and there may be some licensing issues that are difficult to handle.

Issue 2.1 (25 Nov 02) Re-use (Part B) – 1 of 2 Supplier finalises investigations on re-use of existing software check validity of re-using tools and methods identify necessary adaptation check level of validation check documentation status check quality status (NCRs, waivers) supplier certification re all relevant tests on relevant platform Document in software re-use records (DJF) Same standards for re-used as for bespoke (‘purchased non-COTS’) Re-use of software from other projects if customer requires, supplier shall consider; if not, supplier should consider possible benefits supplier documents spec of intended re-use requirements in TS (evaluation results in DJF) Part B considerations

Issue 2.1 (25 Nov 02) Re-use (Part B) – 2 of 2 If levels of product assurance fall short, supplier may analyse software life cycle data generate documentation by reverse engineering use product service history configuration management and change control information effectiveness of problem reporting records stability and maturity (from change control records) relevance of product service history to new environment (e.g. problems confined to areas not used) error rates and maintenance records impact of modifications If remaining doubts on fitness for purpose, additional verification may be agreed Customer approves re-use based on software re-use records (DJF)

Issue 2.1 (25 Nov 02) Metrics General quality model (e.g property, metric, evaluation method) collect, store, analyse, report, act Product metrics size (design, code) complexity (design, code) … Process metrics actual duration of phases/tasks compared to plan effort used in phases/tasks compared to the plan number of SPRs generated during verification (i.e. review or audit) number of SPRs generated during integration and validation testing and use. SPR counts (process metrics) – SEMG B makes it mandatory to report them to the customer Notes on Function Point Analysis: FPA is a sizing measure of clear business significance. First made public by Allan Albrecht of IBM in 1979, the FPA technique quantifies the functions contained within software in terms which are meaningful to the software users. The measure relates directly to the business requirements which the software is intended to address. It can therefore be readily applied across a wide range of development environments and throughout the life of a development project, from early requirements definition to full operational use. Other business measures, such as the productivity of the development process and the cost per unit to support the software, can also be readily derived. The function point measure itself is derived in a number of stages. Using a standardized set of basic criteria, each of the business functions is a numeric index according to it's type and complexity. These indices are totalled to give an initial measure of size which is then normalized by incorporating a number of factors relating to the software as a whole. The end result is a single number called the Function Point index which measures the size and complexity of the software product. In summary, the function point technique provides an objective, comparative measure which assists in the evaluation, planning, management and control of software production.

Issue 2.1 (25 Nov 02) Group Activity SCENARIO The list of possible product metrics is to be extended TASKS What properties might you want to evaluate? What metrics would you collect for them? How would you derive them? Product metrics Size (design, code) Complexity (design, code) Fault density (the number of SPRs per 1000 lines of code ) Failure intensity (the percentage of Critical SPRs compared to all SPRs) Test coverage (percentage lines of code covered in tests) Number of observation or anomaly reports Number of SPRs.

Process Improvement (1 of 2)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Process Improvement (1 of 2) ‘Collect, store, analyse, report, act’ on process and product metrics Identify weaknesses by analysing metrics collected Identify improvements to address the weaknesses Implement those improvements Variation on the Deming cycle: Plan – Do – Check – Act

Process Improvement (2 of 2)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Process Improvement (2 of 2) Management responsibility Resource management Measurement, analysis and improvement Product realization Customers (and other interested parties Parties) Requirements Satisfaction Continual improvement of the quality management system ISO9001:2000 ISO9001:2000 stresses process improvement CMM – origins US DoD – Software Engineering Institute – 5 levels, of which top one ‘Level 5 Optimizing’ is defined as ‘Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies’ SPICE – Software Process Improvement and Capability dEtermination – ISO/IEC series – developed almost entirely by and Web – draws on CMM, Trillium (Canadian), Bootstrap (which ESA used to use) and others NB SPiCE or SPICE – seen both in use CMM SPICE for SPACE (S4S)

Contracts and Tailoring Session – Contents
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Contracts and Tailoring Session – Contents Software procurement and the QMS Statements of Work Software Metrics (revisited) Tailoring Recap Feedback on SEMG and tailoring template Duration = 1½ hours approx.

Issue 2.1 (25 Nov 02) What the ESOC QMS says

Issue 2.1 (25 Nov 02) PR-7110 … specifies how the existing ECSS software engineering standards will be applied within ESOC. … addresses in particular […]: responsibilities associated with software procurement and development activities associated with the software lifecycle tailoring criteria to be applied as function of software project criticality, size and lifetime

Issue 2.1 (25 Nov 02) PR-7110 … is applicable to all software developed for ESOC and incorporated in or used by ESOC products and services … is not applicable to software developed to support feasibility studies and calculations, administrative tools software available as commercial of the shelf (COTS). Any deviations from this and associated procedures, or any additional requirements, to be specified in SOW and reflected in SDP You might get a question on procedure for procuring COTS. There is material in the SEMG on this, which will have been covered. I don’t think there’s a direct QMS procedure. Check with A Mantineo (ESOC Quality Manager).

PR-7110 – applicable documents
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR-7110 – applicable documents Software Engineering and Management Guide Part A Software Engineering Software Engineering and Management Guide Part B Management QMS PROCEDURES AND WORK INSTRUCTIONS ON CONTRACTS AND PROCUREMENT PR-6200-TOS Anomaly and Problem Identification,Reporting and Resolution WI-2102-TOS Software Tools and Methods in Software Validation PR-7410-TOS Project Control and Management PR-5100-TOS Configuration Management PR-7300-TOS Critical Supplier Evaluation and Control PR-7100-TOS Control of Procurement via Contracts PR-0400-TOS Risk Management PR-1500-TOS Management of Operations Training Activities PR-7200-TOS Procurement Using Purchase Orders WI-7500-TOS Service Level Agreements, Format and Management PR-5300-TOS Document Production and Change Software Engineering and Management Guide Part C Document Templates The Tailoring Template

PR-7110 – roles and responsibilities (1 of 3)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR-7110 – roles and responsibilities (1 of 3) Quality Manager designates (with GS Manager) the PA Representative reviews procurement contract Technical Officer writes statement of work (SOW) and contract technical specification (CTS) monitors contract at technical level approves software development, configuration, validation and verification plans reviews software product assurance plan interfaces with initiator(s), end-users, ESA-internal support units, and Supplier Software Project Manager monitors SW Quality Control activities and Problem Trend Analyses

Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR-7110 – roles and responsibilities (2 of 3) Product Assurance Representative reviews tailoring as specified in SOW and reflected in the Software Project Management Plan for compliance with this procedure approves the Software Product Assurance Plan authorises formal release of software for operational [validation and] use following AR.

Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR-7110 – roles and responsibilities (3 of 3) Software Review Board (SRB) control authority for approving changes from QR onwards (QR, AR, problems reports and change requests during operation and maintenance) comprises Technical Officer Software PA Rep. counterparts on supplier’s side user representatives. Configuration Control Board (CCB) control authority for authorising changes [proposed/]approved by the SRB during hand-over to the end user and during execution of operation and maintenance processes (role and responsibility covered by Configuration Management procedure).

Issue 2.1 (25 Nov 02) PR Procurement Software Maintenance Service Level Agreement (SLA) Contract Statement of Work (SOW) plus or has as appendices Software Development Contractual Technical Specification (CTS) which contains or refers to Supplier and customer responsibilities wrt Customer Furnished Items (CFIs) defined The table of contents of the SOW shall include the following items: · Introduction including purpose and scope of work, related documents · Work to be done · Schedule, Milestones and Deliveries · Constraints (platforms, environment, work location (on-site/off-site ESOC), SW re-use, etc..) · Customer furnished items · Risk Management · Reporting · Acceptance testing · Software Engineering Aspects including tailoring of standards · Quality and Safety Assurance Requirements The SLA shall define the services to be provided by the contractor. This includes: · The definition of the systems to be maintained · The definition and management of the different types of maintenance (i.e. corrective, adaptive, user support, administrative tasks) · The split of work between the different types of maintenance · Configuration management · Training of maintenance team · Security (use of passwords and privileges) If SOW addresses a subset of the lifecycle, CTS refers to outputs of prior process Requirements List e.g. SSD from RB

PR7110 – SoW Table of Contents
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR7110 – SoW Table of Contents Introduction including purpose and scope of work, related documents Work to be done Schedule, Milestones and Deliveries Constraints (platforms, environment, work location (on-site/off-site ESOC), SW re-use, etc..) Customer furnished items Risk Management Reporting Acceptance testing Software Engineering Aspects including tailoring of standards Quality and Safety Assurance Requirements There is also work going on in the QMS Improvement Group on a generic SoW.

Issue 2.1 (25 Nov 02) Statements of Work ‘Classic’ approach: SWRR as start of development FUP to do requirements analysis under responsibility of TO alternatively, TO may write the requirements FFP to do rest of development FUP to support operations validation (including SVTs, simulations programme) and LEOP At ESOC 1st and 2nd line maintenance are typically combined in one contract covers software operations engineering and software maintenance

PR7110 – Life cycle and requirements
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR7110 – Life cycle and requirements Life cycle model specified in SOW and confirmed in supplier’s SDP Always starts with system requirements, defined in SSD and IRD if applicable If part of larger system, software project management agree with overall project management (typically the GSM) responsibilities for system requirements definition incorporation of requirements into higher-level document (e.g. Flight Dynamics Requirement Compilation) Agreement documented in Mission Implementation Plan (MIP)

Issue 2.1 (25 Nov 02) PR7110 – Development Procedure outlines the processes Software requirements analysis resulting in the software requirements specification and ending with the Software Requirements Review (SWRR) Top level architectural design documented in the Design Definition File (DDF) and the Design Justification File (DJF) and reviewed at the Preliminary Design Review (PDR) Software design engineering, also documented in the Design Definition File (DDF) and the Design Justification File (DJF), which includes the detailed design and production of code, reviewed at the Critical Design Review (CDR) Software validation and acceptance: this includes validation testing against a subset of the SSD at the suppliers premises (Factory Acceptance Testing – FAT), qualification review (QR), delivery, installation and validation against the SSD in the operation environment. It concludes with the Acceptance Review (AR) Typical ESOC approach is preliminary Site Acceptance Test (similar to PSS-05 Provisional Acceptance ), followed by check out period (typically 2 months, specified in SoW) followed by (final) Site Acceptance Test … and invokes GS SEMG Parts 1, 2 and 3

PR7110 – Operations and maintenance
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR7110 – Operations and maintenance Procedure outlines the processes Software Operations Engineering normally starts after the acceptance review and ends with the software retirement Software Maintenance normally begins after the acceptance review … and invokes GS SEMG Parts 1, 2 and 3

PR7110 – Tailoring criteria (in this order)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR7110 – Tailoring criteria (in this order) Functional criticality Level 1 = Safety critical: Risk to human life and Equipment or loss of mission Level 2 = Mission critical: Risk of degraded mission Level 3 = Performance critical: Performance related parameters such as time of response, numerical accuracy, etc. Non critical = none of the above Project size Very small (one independent program, one main function, < 6 man-months or team <= 2 for <= 1 year or <= 2000 lines of source excluding comments) Small (< 2 man-years or team <= 5 people for <= 1 year or <= 10,000 lines of source code excluding comments) Normal (not belonging to above categories) Operational lifetime Short (< 1 year and no re-use) Long (> 1 year or re-use)

PR7110 – Tailoring of V&V activities
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR7110 – Tailoring of V&V activities Functional criticality Verification and validation activities Level 1 – Safety critical As SEMG, but independent team producing independent verification and validation plans and reports, plus specific Q80 dependability and safety requirements if relevant Level 2 – Mission critical As SEMG, but independent team producing independent verification and validation plans and reports Level 3 – Performance critical As SEMG Non-critical Apply only size and lifetime criteria This might raise some questions. Typically ESOC software has parts which are mission critical: In the MCS area, independent validation is carried out by TO, but this is becoming impractical for complex systems with only one TO, so consideration is being given to providing an independent contract test team – has implications for frame contracts, independent test team should not be from within the frame contracts for MCS development For simulators, independent test contractor approach has been applied for some years Flight dynamics have an organisational unit for independent testing Safety critical – risk to human life Mission Critical – risk of degraded mission

PR7110 – Tailoring: size and operational lifetime
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR7110 – Tailoring: size and operational lifetime Size / operational lifetime Documentation (size affects management plans, lifetime affects life cycle documentation) Normal As SEMG Small As defined in Tailoring Template for a small project Very small with long lifetime As defined in Tailoring Template for such a project Very small with short lifetime as specified in Tailoring Template: the system requirements process and the software engineering process may be combined into one process. The procedure does not give much detail here, but refers instead to the Tailoring Template. The latter gives a number of possible tailoring possibilities for a small project, but does not give specific guidance in relation to the categories here. We will look at it shortly.

PR7110 – Tailoring: documentation
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) PR7110 – Tailoring: documentation The estimated criticality level, size and lifetime of each software sub-system The resulting tailoring measures The list of documents derived from tailoring are recorded in the SOW and reflected in the SDP You may get questions about 1st bullet: For most ESOC SOWs all the subsystems have the same lifetime (same as mission) If not, subsystems are usually tendered separately (e.g. the mission planning system of Rosetta is developed after launch) Currently most people are not providing estimates of criticality level and size in their SoWs/SDPs. Criticality levels for parts of MCS are being studied as a spin-off of the SCOS-2000 certification activity. Use of tailoring template with SoW? – Watch out for differences between contractual deliverables list and applied tailoring of SEMG.

Issue 2.1 (25 Nov 02) PR7110 – Also covers Further ‘Development’ topics Management and Management Plans Reviews Acceptance and Release Software Verification and Validation Problem Reporting Configuration Management and Control Tools and Methodologies Software Metrics Supplier Audits … and these sections refer to SEMG and other procedures and standards

Issue 2.1 (25 Nov 02) PR7110 – Software Metrics Metrics to be defined in SOW and reflected in Software Product Assurance Plan (SPAP) Software Project Manager or maintenance leader must collect and periodically analyse, for each process: Number of statements of source code, broken down to sub-system level, distinguishing between executable and comment statements For object-oriented systems, number of classes and optionally other statistics (e.g. number of methods) SPR statistics, including SPR history (trend). SPR statistics are typically reported monthly in the monthly progress report (also with graph) Additional metrics may be requested (and, again, defined in SOW and reflected in SPAP)

Issue 2.1 (25 Nov 02) Tailoring in SEMG E-40 says: select and exceptionally modify or add requirements SEMG elaborates: The tailoring process is the deletion of non-applicable processes, activities and tasks. The addition of unique or special processes, activities or tasks is permitted, as specified in the contract. Tailoring may also involve the deletion of outputs or the limitation of applicability to certain parts of the system. The existing requirements may be refined or specified. Some criteria to consider: overall space project risk project/equipment/product characteristics – criticality, longevity, size, operational or non-operational status, real-time constraints, level of definition of the requirements cost. IPR may influence what is delivered (and need for escrow, etc.)

Tailoring (ex Part B) – typology (1 of 2)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Tailoring (ex Part B) – typology (1 of 2) 2. Is the normal ESOC case 3. Might apply for specific subsystems, e.g. off-line data delivery 4. Examples are from experimental or small satellite projects, like the TEAMSAT Young Engineers Satellite, which launched on ARIANE 502 in 1997 , and used a minimum cost control system based on SCOS-II. Project category definitions

Tailoring (ex Part B) – typology (2 of 2)
Implementing ECSS Software Engineering Standards at ESOC Issue 2.1 (25 Nov 02) Tailoring (ex Part B) – typology (2 of 2) Classification of ground segment components Simulators are normally treated like on-line operational SW at ESOC.

Issue 2.1 (25 Nov 02) Group Activity SCENARIO You are in charge of a small, non-critical, project for software with a short operational lifetime and need to decide what documentation is required TASKS Review the tailoring conditions critically and comment on them Decide what tailoring you would apply to the project in question. (Fill in the template with the appropriate conditions and actions)

Issue 2.1 (25 Nov 02) Related guideline … The TO checklist is quite new in the QMS However it has not been aligned with SEMG/ECSS-E-40 : still based on PSS-05 Claims to apply to all TOs but very biased towards MCS software TO tasks Extremely detailed. Requires further work to make it really useful for all TOs

Issue 2.1 (25 Nov 02) 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 Contractual (PR7110) Statement of Work Contract Technical Specification Requirements List SEMG Tailoring Template Inputs and outputs for each process Tailoring condition Tailoring possibility Note that Appendix C in A and B has an informative document lifecycle table

Issue 2.1 (25 Nov 02) Feedback Suggestions for improvement to SEMG and Tailoring Template to BSSC: Mike Jones and/or Uffe Mortensen AR end-of-project assessment of lessons learned: make contractual and feed into improvement of SEMG? Please don’t forget: Course evaluation form THANK YOU

Implementing ECSS Software Engineering Standards at ESOC

Similar presentations

Presentation on theme: "Implementing ECSS Software Engineering Standards at ESOC"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Implementing ECSS Software Engineering Standards at ESOC

Similar presentations

Presentation on theme: "Implementing ECSS Software Engineering Standards at ESOC"— Presentation transcript:

Similar presentations

About project

Feedback