Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA

Transcription

1 BSSC 2005(1) Issue 1.0 June 2005 Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA Part A: Software Engineering Prepared by: ESA Board for Software Standardisation and Control (BSSC) european space agency / agence spatiale européenne 8-10, rue Mario-Nikis, PARIS CEDEX, France

2 II BSSC 2005(1) Issue 1.0 June 2005 PART A SOFTWARE ENGINEERING DOCUMENT STATUS SHEET DOCUMENT STATUS SHEET 1. DOCUMENT TITLE: Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA 2. ISSUE 3. REVISION 4. DATE 5. REASON FOR CHANGE 1 0 June 2005 Update of BSSC (2002)1-3 to align it with latest ECSS standards versions Approved, June 2005 Board for Software Standardisation and Control M. Spada, BSSC co-chair J. L. Terraillon, BSSC co-chair Copyright 2005 by European Space Agency

3 BSSC 2005(1) Issue 1.0 June 2005 PART A SOFTWARE ENGINEERING III TABLE OF CONTENTS 1 Introduction Overview Major Changes from BSSC (2002) Structure of this Part Software Life Cycle Processes for Ground Segment Introduction Space Project Engineering Ground Segment Systems Levels of Decomposition Software Requirements for Ground Systems Processes, Activities, and Phases The Software Life Cycle Processes Software Requirements Engineering Software Architecture and Interface Design Design and Implementation Engineering Process Software Delivery and Acceptance Software Verification and Validation Software Maintenance Ground Segment System Engineering Software Management Processes for Ground Segment Management Processes Overview Software Life Cycle Models Selection of the Software Life Cycle Model Software Requirements Engineering Process Software Requirements Analysis Determine Software Requirements Determine Interface Requirements Determine Security Requirements Determine Safety Requirements Determine Reusability Requirements Define Procedures, Methods, Tools for Developing Reusable Software Determine Requirements for Reusing Software MMI Requirements and Mock-Up[optional] Software Requirements Review (SWRR) Software Architecture and Interface Design Process Construction of the Architectural Model Definition of the Interfaces Reusing Software from Other Projects Verification and Validation Planning Determine Verification & Validation Effort by Criticality Identify Verification & Validation Tasks Independent Verification & Validation Organisation Selection Integration Planning Preliminary Design Review (PDR) Software Design and Implementation Engineering Process Design of Software Items Component Design... 34

4 IV BSSC 2005(1) Issue 1.0 June 2005 PART A SOFTWARE ENGINEERING Interface Design Update Integration Test Plan Development of Software User Manual Coding and Testing Develop and Document Software Units Unit Testing Integration Planning Integration Validation by the Supplier Critical Design Review (CDR) Software Delivery and Acceptance Process Provisional Software Delivery and Installation Provisional Software Acceptance Provisional Software Acceptance Review (AR1) Final Software Delivery and Installation [optional] Final Software Acceptance Final Software Acceptance Review (AR2) Software Maintenance Process Maintenance Planning System Operation User Support Problem and Modification Analysis Modification Implementation Maintenance Review Software Migration [optional] Software Retirement [optional] Appendix A Glossary Definitions Operational Software Non-operational Software Abbreviated Terms Appendix B References... 58

5 BSSC 2005(1) Issue 1.0 June 2005 PART A SOFTWARE ENGINEERING V PREFACE The Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA comprises four parts: A, B, C, and D. This part, Part A, describes the software engineering activities for space system ground segments, and is designed to be applied in all ground segment software engineering projects undertaken by the European Space Agency (ESA). ESA applies the European Co-operation for Space Standardisation (ECSS) E-40 Space Engineering: Software standard for all space projects. This part of the document covers the tailoring of the ECSS-E-40 requirements for ESA ground segment software projects. This volume is an update of the BSSC document ESA Ground Segment Software Engineering and Management Guide, BSSC (2002)1-3 Issue 1.0, March It has been produced by the Fraunhofer Institute for Experimental Software Engineering (IESE) under the lead of the BSSC. Valuable input was provided by Yves Doat, Alessandro Donati, Frank Dreger, Alessandro Ercolani, Eduardo Gomez, Mario Merri, Serge Moulin, David Verrier, Willy Wittwer, all from ESA/ESOC. The volume was reviewed and revised by the BSSC members. Requests for clarifications, change proposals or any other comment concerning this volume should be addressed to: BSSC/ESOC Secretariat BSSC/ESTEC Secretariat Attention: Mrs M Spada Attention: Mr J L Terraillon ESOC ESTEC Robert Bosch Strasse 5 Postbus Darmstadt NL-2200 AG Noordwijk Germany The Netherlands [email protected] [email protected]

6

7 BSSC 2005(1) Issue 1.0 June INTRODUCTION 1 INTRODUCTION 1.1 This volume covers all aspects of software development and maintenance, including requirements definition, design, implementation, verification and validation, transfer, and maintenance. This volume is a unified and complete description of how to implement the requirements of ECSS-E- 40 [Ref. 10], ECSS-Q-80 [Ref. 9], and the ECSS-M standards [Ref. 2-8, 16, 17] as they concern ESA ground segment software. It constitutes a tailoring for ESA Ground Segment projects of the requirements of ECSS-E-40, Software [Ref. 10], ECSS-Q-80, Software Product Assurance [Ref. 9], and the relevant M Series standards: M-00-03A [Ref. 17], M-10B [Ref. 3], M-20B [Ref. 4], M-30A [Ref. 5], M-40A [Ref. 6], M-50A [Ref. 7], M-60A [Ref. 8], according to the goal of the tailoring process as specified in ECSS E-40 [Ref. 10]: The goal of the tailoring is to select, modify or add adequately requirements in order to reach the optimized ratio quality and the actual project peculiarities. Guidelines for tailoring are provided in Annex C of [Ref. 10]. Managers, software engineers, and product assurance specialists applying this volume are thus conformant with the above-mentioned ECSS standards, to the extent defined by the tailoring performed. Part A of this volume also covers some of the concepts of ECSS E-70, Ground Systems and Operations [Ref. 11], and of ECSS E-40-03, Space Engineering Ground Segment Software [Ref. 15]. 1.2 Overview Part A provides an overview of the software life cycle processes in accordance with the E-40 standard [Ref. 10], and its application in the life cycle of software for ESA ground systems. It also gives advice on applying this volume to a particular project. Part B of the volume covers the processes for software project management, configuration and documentation management, and software product assurance. The majority of these practices are defined in the ECSS Management [Ref. 2 to 8, 16, 17] and ECSS Product Assurance [Ref. 9] series of documents, rather than the ECSS E-40 standard. Figure 1.1 provides an overview of the issues covered in parts A and B of this volume. Part C provides proposed templates for documents packaging the software life cycle process outputs. Part D provides traceability matrices to the applicable ECSS standards, traceability of outputs vs. documents, and the documents' life cycle.

8 2 BSSC 2005(1) Issue 1.0 June 2005 INTRODUCTION Primary life cycle processes Supporting life cycle processes Verification Validation Part A Part B Project Management Development Maintenance Configuration Management Documentation Management Product Assurance Process Assurance Figure 1.1: Overview of Parts A and B 1.3 Major Changes from BSSC (2002)1-3 This volume incorporates the following major changes from BSSC (2002)1-3: The processes and the terminology have been aligned with the latest relevant ECSS standards version. The system engineering and software requirements engineering processes have been merged into the software requirements engineering process. The operations and maintenance processes have been merged into the maintenance process. The process descriptions have been streamlined. The process outputs have been detailed and associated with documents and reviews. Review inputs and outputs have been detailed. The document templates have been reviewed to package all process outputs into a set of documents that is manageable both from a technical and a cost point of view. Traceability has been provided against the applicable ECSS standards. Traceability of outputs vs. documents has been provided. 1.4 Structure of this Part This part is structured into chapters reflecting the major software life cycle processes. Each chapter is structured into (sub-)sections, each subsection representing an activity of the process. The processes and activities are mandatory unless stated otherwise. In case of optional processes or activities, their title is followed by the keyword [optional], and an explanation is given under which circumstances the process shall be executed or not. Each subsection is structured as follows. First, the purpose of the activity is stated in one sentence. Then the activity itself is described. Following this description is a list of outputs expected from the activity, including information on which document each output goes to, and a reference to the related review(s), where applicable. Each entry in this list follows the following convention:

9 BSSC 2005(1) Issue 1.0 June INTRODUCTION Documents being updated during this activity: <list of documents that are updated during the activity> added/updated (by document): <document title>: Section XXX: Output title Review(s) In case no document is mandated for the respective output, it is listed under without mandated document. Example: Documents being updated during this activity: Interface Control Document, Software Budget Report Document, Software Design Document added/updated (by document): Interface Control Document: Section 3.1: Definition of information to be exchanged through component interfaces - PDR Software Budget Report Document: Section 3.1: Schedulability analysis or design feasibility verification with models or simulation - PDR Section 3.3: Technical budgets - PDR, CDR Software Design Document: Section 4: Software architectural design - PDR The sections describing reviews have an additional input section stating the document(s) to be submitted for the review. Following the structure of the output sections, a specification of the parts of the document subject to review is also provided, to help concentrate on the document changes. Example: Documents subject to this review: Software Product Assurance Report Document, Software Problem Report Document, Software Release Document, Software User Manual Document, Software Validation Test Document, Software Validation Plan Document Elements of above documents subject to review: Software Product Assurance Report Document: Section 3: [1202] Agreed assessment or audit report Section 3.1: [1085] Software process assessment records: strengths and weaknesses... NOTE This volume states that certain outputs are to be collected in review reports (Software Requirements Review Report, Preliminary Design Review Report, Critical Design Review Report, Provisional Acceptance Review Report, Final Acceptance Review Report). However, there is no specific format mandated for these reports, so there are no specific templates in Part C. There are two appendices to this part: Appendix A provides a glossary of terms. Appendix B provides the reference documentation.

10 4 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT 2 SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT 2.1 Introduction This chapter contains a brief description of the scope of ground systems and explains the concept of decomposing the ground segment into its lower level components. This seeks to establish the relationship of the software development with the overall ground segment development. Furthermore, the chapter introduces the concept of applying processes to develop ground segment software. 2.2 Space Project Engineering The purpose of a space project is to deliver to a customer a system that includes one or more elements intended for operation in space [Ref. 12]. The engineering process, one of five main domains within space projects, is responsible for the definition of the system, verification that the customer's technical requirements are achieved, and compliance with the applicable project constraints. A space system is composed of three principal elements: Space segment Launch service segment Ground segment A specific space system consists of a set of interdependent elements put together to achieve a given objective. The physical form may include any combination of hardware, software and personnel. NOTE This volume concentrates on the development and maintenance of software for ground segments only. 2.3 Ground Segment Systems A brief summary of the scope of the ground segment is presented. A more detailed description of the scope of the engineering activities for the ground segment may be found in ECSS E-00 [Ref. 12] and ECSS E-70 [Ref. 11]. Within a Space System, Mission Operations comprise that subset of mission engineering activities required to operate the space segment. These activities are broadly flight operations, ground operations, and logistics engineering. Mission Operations implements the mission in accordance with the stated, implied or re-defined mission objectives in terms of providing plans and services, conducting experiments, producing, providing, and distributing mission products. In this context the domain of ECSS-E-70 [Ref. 11] covers the Ground Segment, i.e., the ground facilities and personnel involved in the preparation and/or execution of Mission Operations for unmanned missions. In addition, it also considers those aspects of the space segment system of relevance to mission operations. The ground segment can be seen as being composed of two main components: Ground Operations Organisations, comprising the human resources performing the various operational tasks and preparing the mission operations data (e.g., procedures, documentation, mission parameters, mission description data, etc.) Ground Segments, consisting of the major ground infrastructure elements that are used to support the preparation activities leading up to mission operations, the conduct of operations themselves, and all post-operational activities. The scope of this volume is the development of software for the Ground Segment. The Ground Segment consists of a number of subsystems [Ref. 12]. A subsystem consists of a set of interdependent components constituted to achieve a given objective by performing a specified function. A subsystem does not provide sufficient functionality to satisfy the customer's needs. A Ground Segment normally consists of, but is not restricted to, the following main subsystems:

11 BSSC 2005(1) Issue 1.0 June SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT The Mission Control System (MCS). This is the system responsible for control of the mission after launch. Simulators, including simulators for training and testing. The Ground Station System (GSTS). This includes the antenna, receivers, ground converter, communications software, etc. The Ground Communications Sub-net (GCS). This is the communications network linking the ground stations and control centres used in any given mission. On-Board Software Validation Facility (SVF) and Software Development Environment (SDE), used for developing, testing and maintenance of on-board software. The MCS may contain: Operations Control System (OCS), Payload Control System (PCS), Mission Exploitation System (MES), e.g., PDS. In addition, Electrical Ground Support Equipment (EGSE) will be needed for the check-out of spacecraft or payloads before launch [Ref. 11]. Those systems may be grouped together to constitute facilities. There is a direct correspondence between ground systems and space operations organisations. The combination of an operations organisation and its corresponding supporting facility constitutes a Ground Segment Entity. Classical examples of entities are Control Centres, from which the elements of an operations organisation control an element of the mission using the related facilities. Each such entity may contain a number of software products in the sense of ECSS-E-40 [Ref. 10]. For example, an Operations Control System could contain the following software products: control system kernel, mission planning system, file transfer system, data distribution system. This volume is concerned with the software engineering of the Ground systems or the software products contained therein. It is not concerned with the ground operations organisations, but it is clear that their needs will have a profound effect on the software products. Although they are ground segment elements, the EGSE and the SVF are usually procured along with the space segment. Their development processes are rather closely coupled to the space segment development phases, rather than being coupled to the ground segment ones discussed in section 2.8 of this part. In general, development of the ground segment elements will be delayed compared to that of the space segment elements. This is because of the design dependencies: for example, the training simulator design cannot be completed until the design of the spacecraft elements it is simulating is known sufficiently well. Since the ground segment is used for operating the space segment, the main constraint on its development is that of readiness for operations. This normally means that the ground segment will be available for operations some time before launch. However, in some cases the development software engineering processes may continue after launch, e.g., for a deep space mission for which the mission operations take place at the end of a long cruise phase (~years), it may be decided to develop mission operations software after launch. 2.4 Levels of Decomposition Each of the ground segment subsystems is composed of a number of lower-level components. The component is referred to as an equipment when it consists of a hardware element (which may include embedded software) and called a software product when it comprises software only. A ground segment subsystem may consist of any number of pieces of equipment and software products. The ground segment may be implemented as a single procurement, but usually several separate procurements are used for the separate software products or pieces of equipment of which it is composed. The levels of decomposition are fully defined in ECSS-E-00 [Ref. 12]. They are summarised in Table 2.1, in terms of the software engineering terminology used in E-40 [Ref. 10]. This volume describes the processes required to develop a software product. In doing so, it covers some activities relating to the integration of the software product into the ground segment or overall space system.

12 6 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT The level of integration required will be dependent on the project requirements. A particular project may require the development of a single software product or it may involve the development of a number of software products and pieces of equipment. Particular care shall be taken to ensure that the boundary of the software product is clear and that the requirements for integration into the wider system are addressed. Level of Decomposition Software product Software Component Software Unit Definition A set of computer programs, procedures, documentation and their associated data. Part of a software system Note 1: Software component is used as a general term. Note 2: Components can be assembled and decomposed to form new components. In the production activities, components are implemented as modules, tasks or programs, any of which can be configuration items. This usage of the term is more general than in ANSI/IEEE parlance, which defines a component as a basic part of a system or program ; in this volume, components are not always basic, as they can be decomposed. A separately compilable piece of source code. Note: In this volume, no distinction is made between a software unit and a database; both are covered by the same requirements. Table 2.1 Levels of Decomposition 2.5 Software Requirements for Ground Systems ECSS-E-70, Ground Systems and Operations [Ref. 11] standard, provides a number of specific requirements for software products for ground systems. Software products often constitute critical elements of the ground segment in terms of cost, schedule and technical risk. A particular aspect for consideration [Ref. 11] is to maximise reuse of functionality across missions, since in most cases only a small part of the total system needs to be modified to accommodate the mission-specific characteristics. The following general requirements, listed in Table 2.2, shall be considered to ensure cost-effective design, implementation, and maintenance of ground software, based on the requirements of ECSS-E- 70 [Ref. 11]. This volume provides additional information on how these general requirements are addressed within the ECSS-E-40 [Ref.10]. Requirement Meaning Configurability Primarily to be modular and parameter-driven to accommodate evolution and enable reuse across missions. Modularity allows the replacement of parts with different components. Vendor independence Scalability Portability With respect to computer platform and vendor To facilitate expansion of the hardware & software configuration of the system without major re-design To reduce the cost of migrating the system to a new computer platform and operating system in order to cope with the obsolescence of hardware and software (e.g., in case of long duration missions or long-lived infrastructure software)

13 BSSC 2005(1) Issue 1.0 June SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT Requirement Openness Meaning Refers to the capability to interface with other (new) systems or to add functionality without major re-design. Re-usability To permit re-usability across missions, i.e., mission customisation should not involve massive modifications Standards Whenever possible, widely used (often de-facto) standards should be utilised. COTS products Whenever cost-effective and technically suitable, commercial off-the-shelf (COTS) should be used. Open Source Software The advantage of Open Source software products is that the source is available, can be changed or adapted and removed depending on the product release policy (e.g., as concerns platform migration) of COTS vendors. Table 2.2 ECSS-E-70 Requirements for Ground Systems Software It should be noted that the ground system operation may include the following aspects of software development related to the space segment: On-board software management On-board software maintenance. The software development processes defined in this volume also cover the engineering of On-board Software Management software. On-board software maintenance, to maintain the space segment onboard software, shall be performed in accordance with the requirements of space segment software. 2.6 Processes, Activities, and Phases A process is a set of interrelated activities that transform inputs into outputs [Ref. 1]. This volume describes those processes that transform initial customer requirements into a software product. Processes may be divided into a set of activities. There may be up to two refinement levels; however, refinement will not go as far as describing which steps to take in which order. This is part of the actual development process chosen and should either be left to the supplier's discretion, or specified in a separate, project-specific document. A phase is a management construct. Usually, a project is broken down into phases to facilitate progress tracking and determine milestones. In each phase, a number of activities are executed, until a milestone formally states the end of the phase. The activities follow defined processes. This means that each process is executed in at least one phase, and that each phase comprises at least one process. Note that one process can also be executed several times, in different phases. For example, for a project following the evolutionary life cycle model, there will be more than one development phase, including processes, e.g., requirements, and architectural engineering, design, and implementation engineering. 2.7 The Software Life Cycle Processes The processes for developing ground segment software are: Software Requirements Engineering, Software Architecture and Interface Design, Software Design and Implementation Engineering, Software Delivery and Acceptance, Software Maintenance. These processes cover the life cycle of a ground segment software product from the initial customer requirements to implementation, installation, and acceptance of the software product. During all of these processes, software verification and validation processes and reuse processes are being executed. Additional supporting processes are management processes. Figure 2.1 gives an overview over E-40 and this volume's processes and reviews.

14 8 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT System engineering processes related to software Requirements and architecture engineering Design and implementation engineering Delivery and acceptance Validation Verification Management Maintenance SWRR PDR CDR QR AR PDR CDR AR1 AR2 Operation E-40 This volume Requirements engineering Architecture and interface design Design and Implementation Delivery and acceptance Maintenance Validation Verification Management Figure 2.1: E-40 vs. this volume processes and reviews Software Requirements Engineering This process is concerned with the establishment of the requirements of the software product, along with the elaboration of the interface requirements. Each of the software products identified in the System Engineering process will undergo Software Requirements Engineering. The requirements for each of the software products are normally described in a Software Requirements Specification Document and one or more Interface Control Documents. These constitute the Technical Specification, which contains a precise and coherent definition of functional and performance requirements and the specification for interaction with external systems, which may be other software products or other systems. All significant trade-offs, feasibility analyses, make/buy decisions and supporting technical assessments are documented in the Technical Specification Software Architecture and Interface Design This process includes preparing the architectural design of the software product, i.e., the top-level structure and the software components meeting the software requirements, and documenting it in the Software Design Document. The process will also identify the top-level design for the external interfaces (i.e., these to other software or systems) and internal interfaces (i.e., between the software components of the software product). These are described in the Interface Control Document(s) Design and Implementation Engineering Process Software Design Engineering includes the detailed design of the software product. This process produces the design for each element in the software product tree. All elements of the software design are documented in the Software Design Document. The documentation produced shall also include a description of the rationale for design decisions and of the analysis and test approach to show that the design meets the requirements. For large software developments, in which the software has been partitioned into smaller subsystems, the software design engineering process will also include the integration of the individual subsystems into the complete software system.

15 BSSC 2005(1) Issue 1.0 June SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT The implementation process describes the development of software code. This usually leads to units that are then gradually integrated into larger components, until finally, the complete system emerges, which can be delivered. The process is also concerned with the unit, integration, and system testing activities for each software product. Coding and Integration are the responsibility of the supplier Software Delivery and Acceptance The software transfer and acceptance process comprises the delivery and installation of the software and the acceptance by the customer. Customer and supplier are equally involved in this process Software Verification and Validation Verification [Ref. 1] determines whether the outputs of an activity fulfill the requirements or conditions imposed on them. Validation determines whether the requirements, and the final as-built software product, fulfill their specific intended use. In other words: Verification is the process to ensure that I am doing things right (inputs versus outputs at each process/phase/activity); Validation is the process to ensure that I am doing the right things, i.e., the software is fulfilling its requirements and therefore its intended use. Generally, there are many methods that can be used for verification and validation. In this context, a typical verification method will be a review, and a typical validation method will be testing. Nevertheless, testing may also be used for verification, as reviews can be used for validation. The Software Verification and Validation processes run concurrently with the software engineering processes, and the related activities are included in the descriptions of the different processes. At the end of the coding and integration process, however, specific verification and validation activities are undertaken. These activities, described in the software delivery and acceptance process, include the transfer of the software to the customer and the subsequent acceptance of the software by the customer Software Maintenance This process is concerned with the controlled modifications to code and associated documentation due to a problem or due to the need for improvement or adaptation. The process ends with the retirement of the software product. 2.8 Ground Segment System Engineering ECSS-E-70 [Ref. 11], ground segment engineering, is partitioned into phases A to F that include the activities described below. The ground segment life cycle phases are not necessarily concurrent with those of the space segment, although there is extensive interaction between the two. Furthermore, other project life cycle models may be used for the development of individual system elements this section focuses particularly on the implications for elements containing software. A brief overview of the Ground Segment life cycle phases activities is given below: Feasibility Studies and Conceptual Design (Phase 0/A) Preliminary Design (Phase B) Design (Phase C) Production (Phase D) 1. Production/procurement 2. Technical verification and validation 3. Operational validation In-orbit Operations (Phase E) Mission Termination (Phase F) For further information on these phases and their relationship to the engineering processes, please refer to ECSS E-70 [Ref. 11] and ECSS E [Ref. 15]. In the Ground Segment context, most of the activities in the E-40 [Ref. 10] System Engineering Process are performed at Ground Segment level, including Ground Segment partitioning and specification of internal and external interface requirements. Since this volume covers those processes directly related to the software development and maintenance at Ground Segment

16 10 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE LIFE CYCLE PROCESSES FOR GROUND SEGMENT software subsystem level, e.g., Mission Control System, Simulator, only those E-40 [Ref. 10] system engineering requirements directly relevant to a software subsystem, e.g., observability requirements, have been retained and integrated into the Software Requirements Engineering Process. A System Specification Document (SSD) is not required to be produced for a software subsystem. The software engineering starts with the Software Requirements Engineering Process. The outputs of this process constitute the baseline for the software development.

17 BSSC 2005(1) Issue 1.0 June SOFTWARE MANAGEMENT PROCESSES FOR GROUND SEGMENT 3 SOFTWARE MANAGEMENT PROCESSES FOR GROUND SEGMENT The practices for addressing management and product assurance are covered in Part B. The majority of the requirements for the management of software projects are covered by the ECSS M series, and Part B provides a mapping of these requirements for the effective management of ground segment software development. This chapter gives an introduction to the management activities described in Part B and introduces possible software life cycle models. Furthermore, it gives advice on the selection of an appropriate model. 3.1 Management Processes Overview Software engineering activities shall be systematically planned and carried out. Plans shall be developed to cover the following activities: Development (in the Software Development Plan) Configuration and Document Management (in the Software Configuration Management Plan) Verification (in the Software Verification Plan) Validation (in the Software Validation Plan) Maintenance (in the Software Maintenance Plan) Product Assurance (in the Software Product Assurance Plan). Supporting the engineering processes, there are a number of management and assurance activities: Project management. This covers aspects such as project organisation, risk, cost, and schedule management, and project phasing and the software life cycle. Part B section 2 provides details on these activities. Configuration and Information/Documentation Management. This covers aspects such as the identification of a configuration and the subsequent control of it. Part B section 3 provides details on these activities. Software product assurance. This covers aspects such as the organisation of product assurance activities, process improvement, sub-supplier selection and control, COTS procurement, risk management, software process assurance, and software product quality assurance. Part B section 4 provides details on these activities. 3.2 Software Life Cycle Models This section describes three different life cycle models: The standard waterfall model The incremental delivery model The evolutionary development model. Other models may also be suitable. Standard Waterfall Model 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 volume are organised in a sequential manner. Completion of a phase is achieved by means of a review of the deliverable outputs and their approval for use in the next phase. 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.

18 12 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE MANAGEMENT PROCESSES FOR GROUND SEGMENT Requirements Engineering Architecture and Interface Design Design and Implementation Delivery and Acceptance Maintenance Verification & Validation SWRR PDR CDR AR1 AR2 Figure 3.1: The waterfall model Incremental Delivery Model 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 maintenance processes. Requirements Engineering Architecture and Interface Design Increment 1 Increment 2 Design and Implementation Delivery and Acceptance Architecture and Interface Design Design and Implementation Increment n Delivery and Acceptance Maintenance Verification & Validation SWRR PDR 1 CDR 1 AR1 1 AR2 1 PDR 2 CDR 2 AR1 2 AR2 2 Figure 3.2: The incremental delivery model Evolutionary Development Model This approach is characterised by the planned development of multiple releases. All processes of the life cycle are executed to produce a release. 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,

19 BSSC 2005(1) Issue 1.0 June SOFTWARE MANAGEMENT PROCESSES FOR GROUND SEGMENT 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 shall recognise the customer's priorities and first produce those parts of the software that are important to the customer and can be developed with 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 the 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 shall take into account all known requirements. NOTE The Dynamic Systems Development Method (DSDM) is a more formal method for undertaking evolutionary development, which allows a management framework for undertaking the development. DEV 1 Maint 1 DEV 2 Maint 2 DEV 3 Maint 3 Figure 3.3. The evolutionary development model The DEV box is equivalent to the waterfall model in Figure 3.1. The MAINT box represents a maintenance phase, using a specific release. 3.3 Selection of the Software Life Cycle Model The purpose of this activity is to select an appropriate life cycle model for software development. The organisation of the primary processes on a time base is known as a life cycle model. 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 among them. A number of life cycle models exist, but they all share the same basic software development processes.

20 14 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE MANAGEMENT PROCESSES FOR GROUND SEGMENT The software engineering processes must occur, whatever the size, application, hardware, operating system or programming language used. Each of these factors, however, influences the development approach and the style and content of the deliverable items. The life cycle model chosen is specific to the requirements of the project, but it must address the software processes identified in this volume. Normally the deliverables of each process must be reviewed and approved before proceeding to the next process, although this depends on the life cycle model chosen for the project. In any case, the life cycle model shall define the input and output for each phase and its associated milestones, including required documents. There are five major reviews that mark progress in the software life cycle: Software Requirements Review (SWRR), which marks the customer s agreement that all requirements 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, the source code, and the results of testing. Provisional Acceptance Review (AR1), which marks the validation of the software by the customer at his premises in an Integration Environment representative of the target Operational Environment. Final Acceptance Review (AR2), which marks the validation (checkout) of the software by the customer in the target environment, e.g., integration environment for Infrastructure software, and operational environment for mission-specific software. 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 can be added to measure the progress of deliverables. It should be noted that these review points are applicable to a single product. When a system or subsystem development includes a number of software products, each product will undergo the above reviews. There are also likely to be similar reviews that address the integration of the individual products. The supplier shall define the lower-level software engineering methods and tools to be applied during the development. All software development shall adopt the process model in this volume, but lowerlevel methods and tools, e.g., coding standards, shall be chosen to suit the development approach. These standards shall be approved by the customer as being fit for the application under development. The development life cycle model chosen for the project and the associated reviews shall be documented by the supplier in the Software Development Plan. The definition of the life cycle shall be associated with choices of techniques used during the development and maintenance processes, with the risks inherent to the project. Documents being produced/updated during this activity: Software Development Plan added/updated (by document): Software Development Plan: Section 5.3: Identification of project risks - PDR Section 6.1: Software development life cycle definition - PDR Section 6.2: Definition of software development and maintenance techniques - PDR

21 BSSC 2005(1) Issue 1.0 June SOFTWARE REQUIREMENTS ENGINEERING PROCESS 4 SOFTWARE REQUIREMENTS ENGINEERING PROCESS The purpose of this process is to establish the Technical Specification. The Software Requirements Engineering process is concerned with the problem analysis and the toplevel solution for the software products defined during the Ground Segment system engineering process. Each software subsystem may be a single software product or may contain a number of software products. This chapter defines the process for generating the software requirements for a software product. For a particular project, there may be a number of instances of this process, corresponding to the partitioning from the system engineering process. Requirements engineering specifies software functions and performance and establishes design constraints. It takes as input the Interface Requirements Document produced at Ground Segment Level. A System Specification Document is not produced, all requirements are documented in the Software Requirements Specification. The primary output of the Software Requirements Engineering process is the Technical Specification, consisting of the Software Requirements Specification and the Interface Control Documents. In addition to defining what the product must do, it 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 Technical Specification, 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. The definition of the software requirements includes the customer, software developers, hardware engineers, and operations personnel. They all have a different concept of the end product. These concepts must be analysed and then synthesised into a complete and consistent statement of requirements on which everyone can agree. Software requirements may require the construction of prototypes to clarify or verify them. Requirements that cannot be justified by modelling, or whose correctness cannot be demonstrated in a formal way, may need to be prototyped. Man-machine interface requirements often require this kind of exploratory prototyping. The outputs are detailed in the following subsections. 4.1 Software Requirements Analysis The purpose of this activity is to produce a set of software requirements that are as complete, consistent, and correct as possible. Software requirements shall be established and and described rigorously. Requirements must be described in text to ensure that they are testable. It is preferable, where possible, to supplement the textual requirements using non-textual means, such as diagrams. The requirements should be organised in the following general categories: Characteristics of software products Interface issues Security issues Safety issues. Each software requirement must be uniquely identified. Each requirement shall include the attributes listed in Table 4.1 below.

22 16 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE REQUIREMENTS ENGINEERING PROCESS Attribute Identifier Each software requirement shall include an identifier, to facilitate tracing through subsequent processes. Need Essential software requirements shall be marked as such. Essential software requirements are non-negotiable; others may be less vitally important and subject to negotiation. Priority For incremental delivery, each software requirement shall include a measure of priority so that the developer can decide the production schedule. Stability Some requirements may be known to be stable over the expected life cycle of the software; others may be more dependent on feedback from the design engineering process or may be subject to change during the software life cycle. Such unstable requirements shall be flagged. Type Identify the type of requirement, as specified in Table 4.2. Verification method Source The method of verification for each requirement shall be given, using the guidance in this document. References that trace software requirements back to the Requirements Baseline shall accompany each software requirement. Table 4.1 Requirement identification attributes In addition to the attributes of requirements, as described in Table 4.1, the following aspects shall be considered when identifying the requirements of a software product: Consistency of Software Requirements: A set of requirements is consistent if, and only if, no individual requirement conflicts with another requirement. Duplication of Software Requirements: Duplication of software requirements should be avoided, although some duplication may be necessary to make the Technical Specification understandable. The supplier shall construct a logical model of the functional requirements of the software product. A logical model is a representation of the technical specification, independent of the implementation, written with a formalized language and it can be possibly executable. Formal methods can be used to prove properties of the logical model itself and therefore of the technical specification. The logical model shall include a behavioural view. Documents being produced/updated during this activity: Software Requirements Specification added/updated (by document): Software Requirements Specification: Section 4.7: Software requirements logical model - SWRR Section 4.7: Behavioural view in software requirements logical model - SWRR Determine Software Requirements The purpose of this activity is to determine and describe a number of requirements of the software product. The following requirements shall be determined and documented in the Software Requirements Specification: Functional requirements Performance specifications, including hardware characteristics Requirements concerning the environment the software is supposed to be developed and operated in

23 BSSC 2005(1) Issue 1.0 June SOFTWARE REQUIREMENTS ENGINEERING PROCESS Data definitions and database requirements Technical budget and operations requirements Observability requirements (the customer shall trade off the software visibility with the risk of activating undesirable code) Requirements applicable to the selected delivery medium and any software configuration applicable to the software item Portability requirements Requirements concerning the maintainability of the software Software configuration and delivery requirements Requirements subject to acceptance testing and associated verification methods. Any development constraints imposed by the customer on the supplier, e.g., concerning design or implementation of the software, shall be specified in the Software Requirements Specification. Documents being produced/updated during this activity: Software Requirements Specification added/updated (by document): Software Requirements Specification: Section 4.4: Environmental conditions under which the software item executes - SWRR Section 5.1: Functional specifications - SWRR Section 5.2: Performance specifications, including hardware characteristics - SWRR Section 5.4: Software operations requirements - SWRR Section 5.5: Requirements for technical budgets - SWRR Section 5.6: Development constraints - SWRR Section 5.8: Portability requirements - SWRR Section 5.10: Software product quality requirements - SWRR Section 5.11: Maintainability requirements - SWRR Section 5.13: Software configuration and delivery requirements - SWRR Section 5.15: Data definition and database requirements - SWRR Section 5.19: Software observability requirements - SWRR Section 6.2: Requirements subject to acceptance testing and associated verification methods. - SWRR Determine Interface Requirements The purpose of this activity is to specify interfaces to all elements with which the system or component must interact, as well as appropriate interface management procedures. Specify hardware, software, or database elements with which the system, or system component, must interact or communicate. Interface requirements should be classified into software, hardware, or communications interfaces. Software interfaces could include operating systems, software environments, file formats, database management systems, and other software applications. Hardware interface requirements may specify the hardware configuration. Communications interface requirements constrain the nature of the interface to other hardware and software. They may demand the use of a particular network protocol. External interface requirements shall be described or referenced in Interface Requirements Documents. An overview shall be given in the Software Requirements Specification. Interface management requirements shall be defined and documented in the Software Requirements Specification, and appropriate procedures in accordance with the configuration management process described in Part B section 3.2, to guarantee the consistency of the system interfaces. At the stage of the software requirements definition, it might not be possible to produce a detailed specification for some interfaces whose definition depends on the design of the software. For these cases only, it is acceptable that the related Interface Control Documents are produced during the Architecture and Interface Design process and submitted for review as new documents at PDR.

24 18 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE REQUIREMENTS ENGINEERING PROCESS Documents being produced/updated during this activity: Interface Control Document, Software Requirements Specification added/updated (by document): Interface Control Document: Section 5: External interfaces in the Interface Control Documents - SWRR Software Requirements Specification: Section 5.3: Interface requirements overview Section 5.18: Interface management requirements Determine Security Requirements The purpose of this activity is to specify requirements for securing the system against threats to confidentiality, integrity, and availability. Any requirements for securing the system against threats to confidentiality, integrity, and availability shall be specified. These shall describe the level and frequency, if applicable, of access allowed to authorised users of the software product. The level of physical protection of the computer facilities may be stated. Documents being produced/updated during this activity: Software Requirements Specification added/updated (by document): Software Requirements Specification: Section 5.7: Security requirements, including those related to factors that can compromise sensitive information - SWRR Determine Safety Requirements The purpose of this activity is to specify requirements reducing the possibility of damage that can follow from software failure. Any requirements to reduce the possibility of damage that can follow from software failure shall be specified. The safety requirements for the system components will have been identified from the system level analysis. Software shall be considered safety-critical if the information it presents can lead to injury to people, affect the mission, or damage property. The safety requirements for software, which specify what would happen when failures of a critical piece of software actually do occur, will normally be identified at Ground Segment level. In deriving the software requirements, it must be ensured that these actions are traceable throughout the software and that appropriate verification and validation is undertaken. Documents being produced/updated during this activity: Software Requirements Specification added/updated (by document): Software Requirements Specification: Section 5.12: Safety requirements - SWRR

25 BSSC 2005(1) Issue 1.0 June SOFTWARE REQUIREMENTS ENGINEERING PROCESS Determine Reusability Requirements The purpose of this activity is to identify specific reusability requirements for the software. This activity is concerned with the identification of software requirements for reuse of the software in future applications. The supplier must ensure that these requirements are addressed in each of the key development processes. Any special reuse constraints that apply to the development shall be specified and documented, to enable future reuse of the software All documentation concerning reusability shall be as modular as possible, to facility actual reuse. The implementation of the reuse requirements shall be formally evaluated at the PDR and CDR milestones. The supplier shall seek ways of identifying generic aspects of an application domain whenever possible, even if not explicitly specified in the requirements. The use of techniques addressing these aspects is recommended. Documents being produced/updated during this activity: Software Requirements Specification added/updated (by document): Software Requirements Specification: Section 5.17: Reusability requirements - SWRR Define Procedures, Methods, Tools for Developing Reusable Software The purpose of this activity is to ensure that the supplier defines proper procedures, methods, and tools to support the development of reusable software. The supplier shall define procedures, methods, and tools to support the development of reusable software. This includes configuration management and reuse items documentation, along with any specific design documentation. These procedures, methods, and tools must be applied during the software development processes to ensure that all reuse requirements are adequately addressed. Documents being produced/updated during this activity: Software Design Document added/updated (by document): Software Design Document: Section 8.2: Methods and tools for software for intended reuse including justification - PDR Determine Requirements for Reusing Software The purpose of this activity is to describe the circumstances under which software, e.g., third party COTS products, can or shall be reused. Requirements for reusing pre-developed software, e.g., commercial off-the-shelf software (COTS), and appropriate acquisition requirements shall be specified by the customer. The supplier shall implement the software acquisition process and document the process in the Software Development Plan. Where an appropriate COTS product can be shown to meet project requirements, the supplier shall consider its use. This is in addition to any requirements placed by the customer. The requirements of the software product may need some revision to suit a chosen COTS product. These changes need to be discussed and agreed upon with the customer. The supplier shall record the evaluations of all

26 20 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE REQUIREMENTS ENGINEERING PROCESS investigated COTS products in the Software Development Plan, along with the reasons for selection of a particular COTS. The software procurement process for COTS has to pay special attention to the following topics: Economic soundness of the supplier Past experiences with this supplier The supplier s capability to provide support and maintenance as well as the cost of this maintenance Access to good quality documentation and source code (this is essential for critical software) Licensing and intellectual property rights. Consistency with product assurance and verification and validation requirements is particularly relevant. Suitability of the product for its intended use. Part B section provides some guidance regarding product assurance requirements for the purchase of software products. Part B section provides further guidance on COTS software procurement. The previous paragraphs also apply to Off-the-Shelf Software (OTS) and Modified Offthe-Shelf Software (MOTS). Public domain and open source software can be treated in a similar manner bearing in mind that: supplier maintenance may be non-existent, the intellectual property issues may be difficult to handle. The GNU General Public License (GPL), for example, requires any product incorporating open source code to be put under the same license (note that this license does not apply to all GNU products). Documents being produced/updated during this activity: Software Development Plan, Software Requirements Specification added/updated (by document): Software Development Plan: Section 5.7: Software procurement process implementation - PDR Software Requirements Specification: Section 5.17: Requirements for reusing software - SWRR Section 5.17: Requirements for reused software acquisition process - SWRR MMI Requirements and Mock-Up[optional] The purpose of this activity is to consolidate and evaluate MMI specifications by building and evaluating prototypes. Prototypes are a common engineering practice to test customer reaction and design ideas. A software prototype implements selected aspects of proposed software so that testing can be performed. The prototyping approach is very useful for assessing elements of the user interface. Building a prototype for the MMI (man-machine interfaces) aspects, which is also known as a mockup, allows assessment of the suitability and appropriateness of the MMI solution. An MMI prototype is normally built quickly and easily. Such prototype development may relax the quality, reliability, maintainability or safety requirements that are used in producing the final software product. MMI prototype software is, therefore, normally 'pre-operational' and is not normally part of the delivered system. There may be cases, however, when the MMI prototype will be upgraded to become part of the software product. In these cases, the prototype shall be subjected to quality, reliability, maintainability or safety procedures like the rest of the software product. For software with interfaces to human operators, the customer shall, based on the complexity and requirements of the MMI, determine if a software mock-up of the MMI is requested to support the requirements and architecture engineering process. If this is the case, the customer shall determine if

27 BSSC 2005(1) Issue 1.0 June SOFTWARE REQUIREMENTS ENGINEERING PROCESS general MMI standards shall be applicable to the software project and include these requirements in the Software Requirements Specification. Where specified, software prototypes shall be developed in support of the Requirements Engineering process. The aim of the prototype is to ensure that MMI specifications are consolidated and evaluated with respect to human factors and use. The prototype shall ensure that: there is proper consideration of human factors, the MMI aspects reach an acceptable level of definition, the technical performance of the MMI is verified. The MMI for the software product shall be defined in the Software Requirements Specification. The supplier shall ensure that end-users, or their representatives, participate in the MMI prototype evaluation. The results of the evaluation of the prototype shall be documented. This activity is optional. It shall be performed in the case MMI prototyping requirements are included in the Software Requirements Specification. Documents being produced/updated during this activity: Software Requirements Specification added/updated (by document): Software Requirements Specification: Section 5.14: MMI specifications for software, including those related to manual operations, human equipment interactions, constraints on personnel, and areas requiring concentrated human attention that are sensitive to human errors and training - SWRR Section 5.16: MMI software prototype requirements - SWRR Section 5.16: MMI general requirements - SWRR without mandated format: Report on evaluation of MMI specifications using a software prototype - SWRR 4.2 Software Requirements Review (SWRR) The purpose of this activity is to ensure that all quality criteria have been addressed properly in the software requirements, to review the outputs of the requirements engineering processes, and to establish a baseline for the software architectural design. The outputs of the software requirements engineering process shall be formally reviewed. This shall be a technical joint review including the customer and the supplier. Other specialists may be part of the review. The principal aim of the SWRR is to agree with the customer that all the necessary requirements are captured in the Software Requirements Specification within the Technical Specification. In particular, the following criteria shall be considered: Software requirements are traceable to system partitioning and system requirements. Software requirements are externally and internally consistent (not implying formal proof consistency). Software requirements are verifiable. The software requirements related to safety, security, and criticality are correct as shown by suitably rigorous methods. All quality criteria have been properly addressed. The phrase To Be Defined (TBD) indicates incompleteness. The nature of the life cycle model chosen for the development will impact on the completeness of the requirements. For example, the waterfall model assumes that the requirements are complete before moving on to the next process, so there must be no TBDs in the Technical Specification. Other life cycle models may be chosen when extraction of the requirements is more difficult and, in this case, TBDs may be perfectly acceptable. Subsequent activities in the project would be targeted towards completion of the TBDs.

28 22 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE REQUIREMENTS ENGINEERING PROCESS The successful completion of the review establishes a baseline for the architectural design of the software. After the start of the software architectural design process, modifications to the software requirements can increase costs significantly. The software architectural design process shall not be started if there are still doubts, major open points or uncertainties in the software requirements. The requirements shall be evaluated for verifiability. This means that it must be possible to: check that the requirement is incorporated in the design, verify that the software will implement the requirement, test that the software does implement the requirement. The inputs listed below are the relevant inputs for this review as stated in the producing activities descriptions in parts A and B. Inputs Documents subject to this review: Interface Control Document, Software Requirements Specification Elements of above documents subject to review: Interface Control Document: Section 5: External interfaces in the Interface Control Documents Software Requirements Specification: Section 4.4: Environmental conditions under which the software item executes Section 4.7: Software requirements logical model Section 4.7: Behavioural view in software requirements logical model Section 5.1: Functional specifications Section 5.2: Performance specifications, including hardware characteristics Section 5.4: Software operations requirements Section 5.5: Requirements for technical budgets Section 5.6: Development constraints Section 5.7: Overall security, safety and reliability requirements of the software to be produced Section 5.7: Security requirements, including those related to factors that can compromise sensitive information Section 5.8: Portability requirements Section 5.9: Software quality requirements Section 5.10: Software product quality requirements Section 5.11: Maintainability requirements Section 5.12: Safety requirements Section 5.13: Software configuration and delivery requirements Section 5.14: MMI specifications for software, including those related to manual operations, human equipment interactions, constraints on personnel, and areas requiring concentrated human attention that are sensitive to human errors and training Section 5.15: Data definition and database requirements Section 5.16: MMI software prototype requirements Section 5.16: MMI general requirements Section 5.17: Reusability requirements Section 5.17: Requirements for reusing software Section 5.17: Requirements for reused software acquisition process Section 5.19: Software observability requirements Section 6.1: Verification of quality requirements Section 6.2: Requirements subject to acceptance testing and associated verification methods. Inputs without mandated format: Report on evaluation of MMI specifications using a software prototype

29 BSSC 2005(1) Issue 1.0 June SOFTWARE REQUIREMENTS ENGINEERING PROCESS Documents being produced/updated during this activity: Software Requirements Review Report (no mandated format) added/updated (by document): Software Requirements Review Report (no mandated format): Requirements verification report - PDR Software requirements verification evaluation

30 24 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS 5 SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS The purpose of this process is to develop a design of the system components and interfaces sufficiently detailed to enable individuals or small groups to work independently in the Detailed Design Engineering process. The architectural design shall document each component and its relationship with other components. During the architectural design process, the interface between development and maintenance (e.g., documents to be produced, tools to be kept for maintenance) shall be identified and documented in the Software Development Plan. The method used for the architectural design, documentation standards for design and code, naming conventions for files, modules,... shall be described in the Software Design Document, as well as applicable programming standards. Documents being produced/updated during this activity: Software Design Document added/updated (by document): Software Design Document: Section 5.1: Architectural design method - PDR Section 5.3: Documentation standards - PDR Section 5.4: Naming conventions - PDR Section 5.5: Programming standards - PDR 5.1 Construction of the Architectural Model The purpose of this activity is to construct an architectural model that describes the design of the software. The definition of the architectural design is the responsibility of the software engineers. Other kinds of engineers may be consulted during the process and representatives of the users and operations personnel shall be involved in its review. This activity is concerned with development and evaluation of the architectural design of the software and its subsequent documentation. The generation of the top-level design generally involves the following topics: Transformation of the requirements into an architecture, including components, their internal and external interfaces, and their relationships Identification of validation requirements Preliminary Design Review (PDR). A recognised method for software design shall be adopted and applied consistently in this activity. The supplier shall construct an architectural model that describes the design of the software, using implementation technology. The architectural model shall be derived from the software requirements described in the Technical Specification. In transforming the software requirements into an architectural model, design decisions are made in which requirements are allocated to software components, and their inputs and outputs are defined. Design decisions shall also satisfy nonfunctional requirements, design quality criteria, and implementation technology considerations. Design decisions shall be recorded in the Software Design Document. The description of the architectural model shall, as a minimum, cover:

31 BSSC 2005(1) Issue 1.0 June SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS Hierarchy Dependency Interfaces Operational usage for the software components, and document the process, data, and control aspects of the product. Modelling is an iterative process. Each part of the model needs to be specified and re-specified until a coherent description of each component is achieved. The architectural model shall describe, according to the chosen design method, the following items: The static architecture (e.g., programs, packages, classes, modules, etc.) The dynamic architecture (active objects, such as threads, tasks and processes), using description techniques based on automata and scenarios or techniques used for the behavioural view of the logical model The mapping between the static and the dynamic behaviour The software behaviour. In case of real-time software, the dynamic architecture design shall be described using an analysable computational model. Schedulability analyses or scheduling simulations shall be performed as necessary, to prove that the design is feasible. As support to the verification of the software requirements and architectural design (feasibility of the design), the supplier shall perform an estimation of the technical budgets, including the following items: Memory size for static code size, static data size and stack size CPU utilization These shall be documented in the Software Budget Report. There shall be distinct layers within the architecture, with each component occupying a specified layer. Components in a given layer shall provide services to the components in the layer above and use the services of the layer immediately below. Component definition shall continue until: all software requirements have been allocated to components components may be re-used or are small enough to be designed, coded and unit tested. The level of architecture detail will show which requirements are to be met by each component, but not necessarily how to meet them: this will only be known when the design engineering process is undertaken. The interfaces between components will be restricted to a definition of the information to exchange, not how to exchange it. The latter shall be documented in the relevant Interface Control Documents. For each component, the following information shall be defined as a minimum: Inputs Functions or operations to be performed. Layering assists the control of complexity by the use of 'information hiding'. By treating the lower layers essentially as 'black boxes', the information necessary to the internal workings of the lower layers can remain hidden. There is no unique design for any software system. Studies of the different options may be necessary. A number of criteria, which will depend on the actual application, will be needed to choose the best option. Only the selected approach shall be documented in the Software Design Document. Trade-off criteria, reasons for the chosen solution, etc. shall be documented, but no specific format is mandated. The architectural design shall be documented in the Software Design Document. Although textual descriptions can be used, ideally, the model shall be represented by diagrams. The architectural model will show, at each layer of the architecture, the interactions between the components. s of the design shall be included where possible, using an appropriate technique. The diagramming technique used shall be documented and referenced. A traceability matrix of the software requirements in the Technical Specification with the defined architecture shall be included in the Software Design Document.

32 26 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS Documents being produced/updated during this activity: Interface Control Document, Software Budget Report, Software Design Document added/updated (by document): Interface Control Document: Section 5: Definition of information to be exchanged through component interfaces - PDR Software Budget Report: Section 5.1: Schedulability analysis or design feasibility verification with models or simulation - PDR Section 5.3: Technical budgets - PDR, CDR Software Design Document: Section 6: Software architectural design - PDR Section 6.1: Software static architecture - PDR Section 6.1: Software dynamic architecture - PDR Section 6.1: Computational model - PDR Section 6.2: Hierarchy, dependency and interfaces of software components - PDR Section 6.2: Process, data and control aspects of software components - PDR Section 6.4: Software architectural design trade-offs - PDR Section 6.4: Trade-off criteria, reasons for the chosen solution, etc. - PDR Section 9.2: Software requirements to architectural design traceability - PDR 5.2 Definition of the Interfaces The purpose of this activity is to define all interfaces external to the software product as well as the interfaces between the components in the architecture. The interfaces external to the software product and the interfaces between the components in the architecture shall be defined. The internal interfaces shall be documented in the Software Design Document, while the external interfaces shall be documented in related Interface Control Documents. The interfaces are normally specified as data structures. The definition of each interface shall include the: service provided by the interface, description of each element (e.g., name, type, dimension) in the interface, range of possible values of each element, initial values of each element. It should be noted that some of the external interfaces might have been already specified during the Software Requirements Engineering process and submitted for review at SWRR. For these interfaces, Interface Control Documents shall be updated, if required, and submitted for review at PDR. For the still undefined external interfaces, new Interface Control Documents shall be produced. Documents being produced/updated during this activity: Interface Control Document, Software Design Document added/updated (by document): Interface Control Document: Section 5: Preliminary external interfaces design (new or updated from TS) - PDR Software Design Document: Section 6.3: Preliminary internal interfaces design - PDR

33 BSSC 2005(1) Issue 1.0 June SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS 5.3 Reusing Software from Other Projects The purpose of this activity is to ensure that the supplier considers reusing software from other projects. The supplier shall consider the reuse of previously developed software, including commercial off-theshelf software, if required by the customer. In the case where the customer has placed no specific requirements for reuse, the supplier shall also consider the possible benefits to be obtained through the reuse of previously developed software. The analysis of the potential reusability of existing software components shall be performed through: identification of the reuse components, a quality evaluation of these components, following Part B section For details of the reuse activity, please refer to Part B section Documents being produced/updated during this activity: Software Design Document added/updated (by document): Software Design Document: Section 5.6: Specification of reuse of predeveloped software - PDR Section 5.6: Justification of reuse - PDR 5.4 Verification and Validation Planning Determine Verification & Validation Effort by Criticality The purpose of this activity is to ensure that the verification and validation effort is determined and risk, dependability, and safety analyses are performed. The effort required for verification and validation and the degree of organisational independence needed shall be determined as a function of the criticality of the software product. Applicability of Part B section (risk management) and Part B section (independent software verification and validation) shall be checked. Risk, dependability, and safety analyses (see Part B section 2.2.3) shall be performed if any of the following aspects are traceable to the software product: Potential of an undetected error in the software requirement to cause death or personal injury, mission failure or financial or catastrophic equipment loss or damage The maturity of and risks associated with the software technology to be used Availability of funds and resources in the project for verification and validation. The evaluation of the criticality of the software product shall be documented in the Software Verification Plan. The Software Development Plan shall be updated with verification and validation effort. Documents being produced/updated during this activity: Software Development Plan, Software Verification Plan added/updated (by document): Software Development Plan: Section 6.5: Verification and validation effort (update to SDP) - PDR Software Verification Plan: Section 4: Organisational independence and effort identification - PDR

34 28 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS Section 4: Identification of risks - PDR Section 4: Criticality and resources identification - PDR Identify Verification & Validation Tasks The purpose of this activity is to ensure that V&V tasks are identified and documented. The verification and validation tasks suitable for the software product shall be identified, given the assessment of the criticality of the software product. A number of possible verification and validation tasks may be used on a project, for example, document reviews, inspections, and testing. Target life cycle activities and software products needing verification shall be determined based upon the scope, magnitude, complexity, and criticality analysis mentioned above. The verification activities for each component that are appropriate for the reliability and safety requirements shall be defined. For example: Design documentation must be internally reviewed. Reused design components must be inspected. The methods and tools chosen and the validation testing facilities shall be documented in the Software Verification Plan and the Software Validation Plan, respectively. Control procedures for forwarding verification/validation reports to the customer and other involved organisations need to be established and documented in the above plans as well. The validation approach, features to be tested/not to be tested, etc. shall be documented in the Software Validation Testing Document. For each test case, appropriate test procedures shall be documented in the Software Validation Testing Document. Documents being produced/updated during this activity: Software Validation Test Document, Software Validation Plan, Software Verification Plan added/updated (by document): Software Validation Test Document: Section 5: Validation approach - AR1, AR2 Section 6.4: Validation test procedures - AR1, AR2 Software Validation Plan: Section 5: Validation tasks - AR1, AR2 Section 6: Validation process identification - PDR Section 6: Validation methods and tools - PDR Section 7: Validation testing facilities - AR1, AR2 Section 8: Control procedures for validation process - AR1, AR2 Software Verification Plan: Section 6: Verification process identification - PDR Section 6: Software products identification - PDR Section 6: Verification methods and tools - PDR Section 6: Verification organisation and activities - PDR Independent Verification & Validation Organisation Selection The purpose of this activity is to ensure that the software is analysed with regard to the need for independent verification and/or validation, and that an appropriate organisation is selected, if required. The need for independent verification and/or validation shall be established as a function of the criticality of the software. If required, a qualified organisation shall be selected to perform the required

35 BSSC 2005(1) Issue 1.0 June SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS processes. This organisation shall have the independence and authority needed to perform the verification/validation activities. (See also Part B section and Part B section for this.) The organisational requirements shall be specified in the Software Verification/Validation Plan. Documents being produced/updated during this activity: Software Validation Plan, Software Verification Plan added/updated (by document): Software Validation Plan: Section 4: Independent validation organisation selection - PDR Section 4: Requirements for independent validation and related organisational structure - PDR Software Verification Plan: Section 4: Independent verification organisation selection - PDR Section 4: Requirements for independent verification and related organisational structure - PDR 5.5 Integration Planning The purpose of this activity is to develop preliminary test requirements and plan for software integration. The developer shall develop preliminary test requirements and plan for software integration. Integration is the task of building a software product by combining its components into a working system. The integration task must be planned to ensure that components are integrated in a useful sequence. Integration testing shall verify that the major components interface correctly. The approach to integration planning shall be to ensure that a minimum amount of time is spent on testing, while ensuring that the software product is adequately tested. As support to the verification of the software requirements and architectural design, the supplier shall verify the software behaviour using the behavioural view of the logical model produced during the requirements analysis. The software integration plan shall define the scope, approach, resources, and scheduling for the integration task. Documents being produced/updated during this activity: Software Integration Test Plan added/updated (by document): Software Integration Test Plan: Preliminary software integration test plan - PDR without mandated format: Software behaviour verification - PDR, CDR 5.6 Preliminary Design Review (PDR) The purpose of this activity is to verify with the customer that all his needs are captured in the software architectural design. The outputs of the Architecture and Interface Design Process shall be formally reviewed during the Preliminary Design Review (PDR). This shall be a technical review and shall include the customer. The principal aim of the PDR is to review the software architectural design and to evaluate the reuse potential of the software. In particular, feasibility of software design and feasibility of maintenance shall be reviewed. An evaluation of the reuse potential of the software shall be performed. The successful completion of the review establishes a baseline for the development of a software item.

36 30 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS The exact nature of the evaluation will depend on the project requirements, but consideration shall be given to the following aspects: Traceability of the software requirements in the Software Requirements Specification to the software architectural design External consistency (interfaces with external systems) Internal consistency (interfaces between components) Feasibility of software design Feasibility of software maintenance Completeness, adequacy, and consistency of documentation. After the start of the design engineering process, modifications to the architectural design can increase costs significantly. The design engineering process shall not be started if there are still doubts, major open points, or uncertainties in the architectural design. The results of the verification activities shall be evaluated and documented in the PDR Report, together with recommendations on how to solve the issues. The PDR is the responsibility of the supplier. Inputs Documents subject to this review: Interface Control Document, Software Budget Report, Software Configuration Management Plan, Software Design Document, Software Development Plan, Software Integration Test Plan, Software Product Assurance Plan, Software Product Assurance Report, Software Validation Test Document, Software Validation Plan, Software Verification Plan, Software Requirements Review Report (no mandated format) Elements of above documents subject to review: Interface Control Document: Section 5: Preliminary external interfaces design (new or updated from TS) Section 5: Definition of information to be exchanged through component interfaces Software Budget Report: Section 5.1: Schedulability analysis or design feasibility verification with models or simulation Section 5.2: Scheduling simulation status (update during component design) Section 5.3: Technical budgets Software Configuration Management Plan: Section 5: Coherent product and documents identification system Section 6.3: Procedure for approving the configuration baseline Section 6.3: Procedure for changing the configuration baseline Section 6.3: Internal procedure for change impact assessment Software Design Document: Measures for handling critical software Technical specification for components developed for reuse Section 5.1: Architectural design method Section 5.3: Documentation standards Section 5.4: Naming conventions Section 5.5: Programming standards Section 5.6: Specification of reuse of predeveloped software Section 5.6: Justification of reuse Section 6: Software architectural design Section 6.1: Software static architecture Section 6.1: Software dynamic architecture Section 6.1: Computational model Section 6.2: Hierarchy, dependency and interfaces of software components Section 6.2: Process, data and control aspects of software components Section 6.2: Software component list Section 6.3: Preliminary internal interfaces design Section 6.4: Software architectural design trade-offs Section 6.4: Justification of design choices

37 BSSC 2005(1) Issue 1.0 June SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS Section 6.4: Trade-off criteria, reasons for the chosen solution, etc. Section 8: Justification of selection of reused software Section 8.1: Evaluation report of proposed components for reuse Section 8.2: Methods and tools for software for intended reuse including justification Section 9.2: Software requirements to architectural design traceability Software Development Plan: Project organisation documentation Project management information Section 5.2: Geographical distribution table Section 5.3: Risk management policy, methods and formats Section 5.3: Risk information Section 5.3: Identification of project risks Section 5.6: Project organisation requirements for the next level supplier Section 5.7: Software procurement process implementation Section 5.7: Software procurement process for COTS, OTS or MOTS Section 6.1: Software development life cycle definition Section 6.1: Software development life cycle definition Section 6.2: Definition of software development and maintenance techniques Section 6.5: Verification and validation effort (update to SDP) Section 7: Software project plans and schedule Section 7.1: Product tree approved by the customer Section 7.2: Set of WP descriptions Section 7.3: Manpower and cost profile Section 7.5: Project schedule Software Integration Test Plan: Preliminary software integration test plan Software Product Assurance Plan: Section 5: Responsibility, authority and interrelation of personnel managing, performing and verifying work affecting quality Section 5.3: Persons responsible for quality activities Section 5.4: Software product assurance resource requirements Section 5.4: Methods, tools, and rules to be used Section 6.1: Quality measures related to the maintenance process Section 6.1: Software process assessment plan Section 6.1: Software process assessment procedure Section 6.1: Review and inspection procedures Section 6.1: Assurance activities for testing Section 6.1: Software product assurance activities Section 6.2: The software development life cycle Section 6.3: of non-conformance control process Section 6.3: Justification for methods and tools used Section 6.3: Procedures and standards Section 6.3: Design method Section 6.3: Design standards Section 6.3: Design and coding rules for numerical accuracy Section 6.3: Coding standards and description of tools Section 6.3: Justification for using low level computer language Section 6.3: Verification and validation activities Section 6.3: Complexity check procedure Section 6.4: Quality objectives Section 6.4: Details of metrics Section 6.4: Product metrics specification and justification Section 6.5: Evidence of suitability of the software development environment Section 6.6: Compliance matrix to contractual product assurance requirements Software Product Assurance Report: Section 5: Summary of verification activities results Section 5: Report of the measurement analysis and remedial actions Section 5: Agreed assessment or audit report

38 32 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS Section 5.1: Assessment of the quality of the software development process Section 5.1: Results of supplier pre-award audits Section 5.1: Software process assessment records: strengths and weaknesses Section 5.1: General results of design reviews Section 5.2: Assessment of the quality of the software product Section 5.2: Evidence of dependability and safety criticality classification Section 5.2: Software process assessment record: updates to process or project documentation Section 6: Software process assessment records: improvement plan Section 7: Software process assessment records: quality data Section 7: Metrics reports Section 7: Software quality models Software Validation Test Document: Section 7: Test certification of software to be reused Software Validation Plan: Section 4: Independent validation organisation selection Section 4: Requirements for independent validation and related organisational structure Section 6: Validation process identification Section 6: Validation methods and tools Software Verification Plan: Section 4: Organisational independence and effort identification Section 4: Identification of risks Section 4: Criticality and resources identification Section 4: Independent verification organisation selection Section 4: Requirements for independent verification and related organisational structure Section 5: Activities for verifying quality requirements Section 6: Verification process identification Section 6: Software products identification Section 6: Verification methods and tools Section 6: Verification organisation and activities Software Requirements Review Report (no mandated format): Requirements verification report Inputs without mandated format: Software behaviour verification Project specific training plan Audit plan and schedule Sub-supplier software product assurance plan Procurement details of items Software configuration management system Numerical accuracy analysis Information system Standard format for the exchange and delivery of configuration items. Agreed documentation formats and structures for multi-location use Milestone payment plan Performance matrix Contract change proposal Documents being produced/updated during this activity: Preliminary Design Review Report (no mandated format), Software Design Document added/updated (by document): Preliminary Design Review Report (no mandated format): Customer approval of technical specification Software architectural design and interface verification report Software documentation verification report - CDR

39 BSSC 2005(1) Issue 1.0 June SOFTWARE ARCHITECTURE AND INTERFACE DESIGN PROCESS Architecture and interface verification evaluation Software Design Document: Section 8.1: Software for intended reuse - evaluation of reuse potential - CDR Section 9.1: Software architectural design to requirements traceability matrices

40 34 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS 6 SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS The purpose of this process is to detail the architectural design of the system and to produce executable code The Software Design and Implementation Engineering Process transforms the architectural design produced during the Software Architecture and Interface Design Process into executable units that can be validation tested and installed at customer premises. Thins included detailing the design to the level of software units, implementing and integrating them, and producing a user manual. The Critical Design Review concludes this process. The design method used shall be documented in the Software Design Document. Documents being produced/updated during this activity: Software Design Document added/updated (by document): Software Design Document: Section 6.4: Detailed design method - CDR 6.1 Design of Software Items Component Design The purpose of this activity is to provide a decomposition of the architectural model into units in the selected programming language. In the software component design task, components of the architectural model are decomposed until they can be expressed as units in the selected programming language. A software unit is a programming entity that is discrete and identifiable with respect to compiling, combining with other units, and loading. For each of the components specified in the Software Design Document, the design detail is expanded. Any methods and CASE tools used for architectural design shall be used in this task. The format of the software component design will be heavily influenced by the method chosen. In all cases, however, the software component design task shall provide a set of component specifications that are consistent, coherent, and complete. Each specification defines the functions, inputs, outputs, and internal processing of the component. The Software Design Document, including the design traceability to the software requirements, shall be updated to be consistent and complete with respect to the detailed design. In case of dynamic system behaviour, the models, schedulability analysis, and scheduling simulations created during the architectural design shall be updated as the system design gets more detailed. It shall be ensured that the chosen design method is consistent with the computational model. As support to the verification of the software detailed design (feasibility of operations), the supplier shall refine the estimation of the technical budgets: Memory size refined for static code size, static data size, and stack size expressed on a thread basis, measuring them per lowest level design component CPU utilization, refined, considering the worst case execution time of each lowest level design component having its own control flow (therefore, including the call to the protected objects).

41 BSSC 2005(1) Issue 1.0 June SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS Documents being produced/updated during this activity: Software Budget Report, Software Design Document added/updated (by document): Software Budget Report: Section 5.1: Schedulability analysis (update during component design) - CDR Section 5.2: Scheduling simulation status (update during component design) - PDR, CDR Section 5.3: Technical budgets (update during design) - CDR Software Design Document: Section 7: Software components design (update during component design) - CDR Section 7: Software static detailed design - CDR Section 7: Software dynamic detailed design - CDR Section 7: Software elements behaviour - CDR Section 7: Proof of compatibility of design methods with the computational model - CDR Interface Design The purpose of this activity is to update the initial interface design produced during the architectural design. The initial interface design produced during the architectural design activity shall be updated to provide the additional information available at this level. The interfaces external to the software product and the interfaces between the components in the architecture shall be refined. The detailed design of the interfaces shall permit coding without the requirement for further information. The internal and external software interfaces shall be updated in the Software Design Document and Interface Control Documents to include the additional levels of detail available. Documents being produced/updated during this activity: Interface Control Document, Software Design Document added/updated (by document): Interface Control Document: Section 5: External interfaces design (update during interface design) - CDR Software Design Document: Section 6.3: Internal interfaces design (update during interface design) - CDR Update Integration Test Plan The purpose of this task is to update the integration test plan to be consistent with the results of the software detailed design. The integration test plan shall be updated to be consistent with the results of the detailed design process. Documents being produced/updated during this activity: Software Integration Test Plan added/updated (by document): Software Integration Test Plan: Software integration test plan (update after detailed design) - CDR

42 36 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS Development of Software User Manual The purpose of this activity is to provide a first version of the Software User Manual. The Software User Manual shall be drafted based on the information available during the detailed design process. Documents being produced/updated during this activity: Software User Manual added/updated (by document): Software User Manual: Initial software user manual - CDR 6.2 Coding and Testing The purpose of this activity is to create executable components and the final system from the design developed during the development process. This activity takes the detailed design and produces software code units, which are then integrated into larger components, until finally the complete system emerges. The outputs are detailed in the following subsections Develop and Document Software Units The purpose of this activity is to provide and document software code units, build procedures, and test procedures. This activity is concerned with the translation of the software component designs into a software programming language. The source code will, in turn, be translated into machine-dependent object code by the compiler and ultimately into machine code that executes on the target platform. The implementation and testing of the system is made easier if the following guidelines are followed: Use of consistent programming style Reuse of existing material Use of automated support environments. A consistent coding style can reduce complexity of the software unit. All code produced shall be consistent with suitable coding conventions for the chosen programming language. ESA has developed a coding standard for ADA and C/C++ [Ref. 13,14], which shall be applied when these languages are being used. The general guidelines in these standards are also likely to be applicable when other languages are being used. The solutions to known problems used in previous projects shall be considered for adoption. Changes and modifications to code shall follow the style of the original code. Production of consistent, well-organised code is made easier by using appropriate development tools, which can also reduce development time. Many programming languages may be acquired with a suite of tools that include: debugging compilers, source code formatting aids, built-in editing facilities, tools for source code control, extensive programming libraries of functions, and cross-compilers for specific development environments.

43 BSSC 2005(1) Issue 1.0 June SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS Coding includes compilation and build; not only does this produce the code needed for testing the runtime behaviour of the module, it is also the first step in verifying the code. Build procedures to compile and link software units and test procedures and data for testing each software unit shall be produced and documented in the Software Release Document. This volume does not mandate delivery of a Software Unit Test Plan document (SUTP), but still unit test procedures and reports must be recorded. On request by the customer, a formal Software Unit Test Plan document shall be created and submitted to the customer. In case the SUTP has to be produced, the supplier shall investigate with the customer the suitability of the Software [Unit/Integration] Test Plan (SUITP) document template in Part C. As support to the verification of the coding and testing (feasibility of operations), the Software Budget Report shall be updated with the measured values and shall be compared to the margins. The supplier shall develop, for each software item, a set of tests, test cases (inputs, outputs, test criteria) and test procedures for conducting software validation testing. This testing is done against the Technical Specification. The code or references to it shall be documented in the Software Release Document. Documents being produced/updated during this activity: Software Budget Report, Software Design Document, Software Release Document added/updated (by document): Software Budget Report: Section 5.3: Technical budgets (update during implementation) - CDR Software Design Document: Section 7: Software component design (update during unit development) - CDR Software Release Document: Section 7.2: Build procedures - CDR, AR1, AR2 Section 9: Software code - CDR without mandated format: Software unit test procedures - CDR Unit Testing The purpose of this activity is to prove that the software units conform to their specification. The supplier shall define and document the unit test requirements and shall plan for testing the software units, including stressing the software at the limits of its requirements. He shall then test each software unit ensuring that it satisfies its requirements, document the test results, and update the user manual accordingly (if needed). Unit testing verifies that the software units produced fulfil their specification as stated in the software detailed design. The method of choice would be unit testing, which is therefore described below, however, other methods may also be suitable and needed. The following aspects shall normally be considered: The code is traceable to its design, testable, correct, and compliant with the appropriate coding standards. The code implements the proper event sequence, consistent interfaces, completeness, appropriate allocation of timing and sizing budgets, and error definition, isolation and recovery. The chosen code can be derived from design or software requirements. The code is externally consistent with the requirements and design of the software item. Unit tests are organised in two ways. Black box unit testing is used to verify that a unit is doing what it is supposed to do. White box testing is used to verify that the unit is operating in the way that it was intended.

44 38 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS Where the code implements safety, security or other critical aspects, suitable rigorous methods shall be used to demonstrate correct implementation. This volume does not mandate delivery of a Software Unit Test Plan document (SUTP), but still unit test results and their evaluation must be recorded. On request by the customer, a formal Software Unit Test Plan document shall be created and submitted to the customer. In case the SUTP has to be produced, the supplier shall investigate with the customer the suitability of the Software [Unit/Integration] Test Plan (SUITP) document template in Part C. Documents being produced/updated during this activity: Software User Manual added/updated (by document): Software User Manual: Software user manual (update after unit testing) without mandated format: Software unit tests evaluation - CDR Software unit test results - CDR 6.3 Integration Planning The purpose of this activity is to ensure that software integration steps are defined thoroughly and that integration tests are provided for each step. Integration planning shall ensure that adequate tests are developed so that all data exchanged across an interface agree with the specifications in the Software Design Document. Specifically, the software behaviour shall be verified using the behavioural view of the logical model constructed during the establishment of the software requirements. The software integration plan shall define the integration sequence and the integration tests at each step. Each integration test shall verify the function and interfaces to be added at that step. The Integration Test Plan, created during the architecture and interface design, shall be updated accordingly to reflect the greater level of detail now available. It shall provide the following data: Test requirements Test procedures Test data Expected results Allocation of responsibilities Schedule information. The integration test requirements shall be updated accordingly. Documents being produced/updated during this activity: Software Integration Test Plan added/updated (by document): Software Integration Test Plan: Software integration test plan (update after coding) - CDR without mandated format: Software behaviour verification - CDR

45 BSSC 2005(1) Issue 1.0 June SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS 6.4 Integration The purpose of this activity is to combine the software units and components into a working entity that is ready to be validation tested. Integration is the activity of building a software product by combining components into a working entity. It is performed when the major components are assembled to build the system. Integration testing shall be directed at verifying that major components interface correctly. The software should be integrated incrementally. The sequence of steps for integrating the major components to create the system shall be defined. The integration sequence shall add components in order of their number of dependencies, those with the least dependencies normally being added first. This approach facilitates the diagnosis of problems and minimises the amount of test software that needs to be developed to substitute for components not yet integrated. Integration testing is performed according to the Software Integration Plan. Integration testing is done when the major components are assembled to build the software product. These major components are identified in the Technical Specification. Integration testing shall verify that the major components interface correctly, and that there is internal consistency between software units, and it shall examine the absence of run-time errors. The integration testing task may require updates to the software user manual. This shall be updated as required. Documents being produced/updated during this activity: Software Integration Test Plan, Software User Manual added/updated (by document): Software Integration Test Plan: Section 13: Software integration tests evaluation - CDR Software User Manual: Software user manual (update after integration) - CDR, AR1, AR2 6.5 Validation by the Supplier The purpose of this activity is for the supplier to validate the software in the development environment at his premises. This activity is based on a Software Validation Plan against the Software Requirements documented in the Software Requirements Specification. The Software Validation Plan is produced by the supplier and submitted to the customer for contribution, wherever applicable, as well as review and approval. A Test Readiness Review shall be conducted before the start of the tests to verify that all test facilities and test cases are available before the test campaign starts. The supplier shall verify the feasibility of testing under the following aspects: Appropriate verification points are identified and included in the detailed design in order to prepare the effective testing of the performance requirements. Assertions defining computational invariant properties or temporal properties (possibly derived from the behavioural model) are added within the design. Capability of fault injection. The test results are documented in the Software Validation Plan. This validation activity culminates with the CDR and, if this is successful, is followed by delivery and installation of the software at the customer premises. The supplier shall identify the software requirements that cannot be tested in his own environment, and shall forward to the customer a request to validate them in the customer environment. These

46 40 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS requirements shall be tracked through the software validation process and tested as soon as a suitable environment becomes available. System validation testing may require updates to the software user manual. This shall be updated as required. Documents being produced/updated during this activity: Software User Manual, Software Validation Test Document added/updated (by document): Software User Manual: Software user manual (update after validation by the supplier) - CDR Software Validation Test Document: Section 6: Test design for software validation with respect to the Technical Specification - CDR Section 6.3: Test cases for software validation with respect to the Technical Specification - CDR without mandated format: Test readiness review report - CDR Testing feasibility report 6.6 Critical Design Review (CDR) The purpose of this activity is for the customer to formally approve the software design. The CDR marks the end of the design. During the CDR, the supplier shall ensure that the software component design and the appropriate documents are evaluated, with the results of the evaluations documented in the Critical Design Review Report. The CDR is conducted by the supplier with the participation of the customer. The CDR shall comprise an evaluation of the reuse potential of the software. The detailed design shall be evaluated in accordance with the following requirements: Correctness, consistency, and traceability of the design to the Technical Specification Traceability of the validation tests to the Technical Specification Correct implementation of the proper sequence of events, inputs, outputs, interfaces External consistency with architectural design Correctness with respect to requirements and interfaces, logic flow, allocation of timing and sizing budgets, and error handling Ability to derive the chosen design from requirements Correct implementation of safety, security, and other critical requirements as shown by suitably rigorous methods Correct implementation of nonfunctional requirements. The supplier shall verify the software integration considering that the software components and units of each software item are completely and correctly integrated into the software item. In addition, the supplier shall verify the software integration test plan, design, code, tests, test results, and software user manual, considering the criteria specified below: External consistency with system requirements Traceability to software architectural design Internal consistency Interface testing coverage Requirements test coverage Conformance to expected results

47 BSSC 2005(1) Issue 1.0 June SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS Feasibility of maintenance. Completeness of the verification and validation plans Proper implementation of the re-use requirements, if applicable An evaluation of the reuse potential of the software shall be performed. The verification shall be documented in a code verification report in the Software Design Document. Problems and nonconformances detected shall be entered into the problem resolution process. The results of the evaluation shall be documented in the CDR Report, together with recommendations how to solve them. It should be noted that the life cycle chosen for the software development shall impact the CDR. If an incremental or evolutionary life cycle is chosen, there will be a number of CDRs reflecting the life cycle model. The CDR is the responsibility of the supplier. For further information concerning the inputs Numerical accuracy analysis and Performance matrix, please refer to part B, sections 4.4 and Inputs Documents subject to this review: Interface Control Document, Preliminary Design Review Report (no mandated format), Software Budget Report, Software Design Document, Software Integration Test Plan, Software Product Assurance Report, Software Problem Report, Software Release Document, Software User Manual, Software Validation Test Document Elements of above documents subject to review: Interface Control Document: Section 5: External interfaces design (update during interface design) Preliminary Design Review Report (no mandated format): Software documentation verification report Software Budget Report: Section 5.1: Schedulability analysis (update during component design) Section 5.2: Scheduling simulation status (update during component design) Section 5.3: Technical budgets Section 5.3: Technical budgets (update during design) Section 5.3: Technical budgets (update during implementation) Software Design Document: Measures for handling critical software Section 6.2: Software component list Section 6.3: Internal interfaces design (update during interface design) Section 6.4: Justification of design choices Section 6.4: Detailed design method Section 7: Software components design (update during component design) Section 7: Software static detailed design Section 7: Software dynamic detailed design Section 7: Software elements behaviour Section 7: Proof of compatibility of design methods with the computational model Section 7: Software component design (update during unit development) Section 8.1: Software for intended reuse - evaluation of reuse potential Section 8.1: Evaluation report of proposed components for reuse Software Integration Test Plan: Software integration test plan (update after detailed design) Software integration test plan (update after coding) Section 13: Software integration tests evaluation Software Product Assurance Report: Section 5: Summary of verification activities results Section 5: Report of the measurement analysis and remedial actions Section 5: Agreed assessment or audit report Section 5: Summary of validation activities results Section 5.1: Assessment of the quality of the software development process Section 5.1: Software process assessment records: strengths and weaknesses

48 42 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS Section 5.1: General results of design reviews Section 5.1: Statement of compliance with test plans and procedures Section 5.2: Assessment of the quality of the software product Section 5.2: Evidence of dependability and safety criticality classification Section 5.2: Software process assessment record: updates to process or project documentation Section 5.2: Synthesis of code analysis results and corrective actions Section 6: Software process assessment records: improvement plan Section 7: Software process assessment records: quality data Section 7: Metrics reports Section 7: Software quality models Software Problem Report: Major non-conformances Software problem information Software Release Document: Section 7.2: Build procedures Section 9: Software code Software User Manual: Initial software user manual Software user manual (update after integration) Software user manual (update after validation by the supplier) Software Validation Test Document: Updated test documentation Section 6: Test design for software validation with respect to the Technical Specification Section 6.3: Test cases for software validation with respect to the Technical Specification Section 7: Test certification of software to be reused Inputs without mandated format: Software unit test procedures Software unit tests evaluation Test readiness review report Software behaviour verification Numerical accuracy analysis Performance matrix Software unit test results Software behaviour verification Documents being produced/updated during this activity: Critical Design Review Report (no mandated format), Software Design Document, Software User Manual, Software Validation Test Document, Software Verification Plan added/updated (by document): Critical Design Review Report (no mandated format): Customer approval of the design (e.g., software architectural design, detailed design, code and software user manual) Customer approval of the software unit test plan, software integration test plan, results of unit and integration tests and results of validation with respect to the technical specification Software design verification evaluation Software integration verification results Update to software documentation verification report Verification of consistency of detailed design with architectural design Verification of consistency between software components and software units Verification of adherence of the software design to the applicable requirements and standards Verification of feasibility of maintenance Evaluation of reuse potential Recommendations for solving CDR issues

49 BSSC 2005(1) Issue 1.0 June SOFTWARE DESIGN AND IMPLEMENTATION ENGINEERING PROCESS Software Design Document: Section 8.1: Software for intended reuse - evaluation of reuse potential (update at CDR) Section 10: Traceability between design (components) and software units Software User Manual: Software user manual (update after CDR) - AR1, AR2 Software Validation Test Document: Documentation of complementary validation that cannot be tested at supplier premises - AR1 Section 7: Validation testing report with respect to the Technical Specification Section 7: Verification report with respect to the Technical Specification (if validation testing is not possible) - AR1 Section 8: Traceability of the software requirements to the validation tests Software Verification Plan: Section 6: Software code verification results

50 44 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DELIVERY AND ACCEPTANCE PROCESS 7 SOFTWARE DELIVERY AND ACCEPTANCE PROCESS The purpose of this process is to install and validate the system at customer premises. This process delivers, installs, and validates the software against the Technical Specification. The process is comprised of two parts: The first part leads to preliminary acceptance and comprises two activities: Delivery and installation in integration environment Provisional acceptance tests against the Technical Specification. These activities are usually conducted under the control of the customer and are normally carried out at his premises on the integration environment. The second part leads to final acceptance and comprises three activities: Delivery and installation in operational environment Operational acceptance tests against the Technical Specification Acceptance review. These activities are normally controlled by the customer in the operational environment, and may require the involvement of operational departments. Final acceptance triggers the software maintenance processes. The outputs are detailed in the following subsections. 7.1 Provisional Software Delivery and Installation The purpose of this activity is to set up the system in the validation environment. The product is delivered to the customer s site and installed in the validation environment using the installation procedures documented in the Software Release Document. Installation shall be undertaken from scratch to test the adequacy of the installation procedure. In particular, the resources and information to install the software product shall be determined and be available, the supplier shall assist the customer with the set-up activities, it shall be ensured that the software code and databases initialise, execute, and terminate as specified in the installation plan, the installation events and results shall be documented, the supplier shall train customer personnel in the use of the software. Documents being produced/updated during this activity: Software Release Document added/updated (by document): Software Release Document: Software release documentation - AR1 Section 7.4: Installation events and results - AR1

51 BSSC 2005(1) Issue 1.0 June SOFTWARE DELIVERY AND ACCEPTANCE PROCESS without mandated format: Software delivery - AR1 Training material 7.2 Provisional Software Acceptance The purpose of this activity is for the customer to validate the software at his premises in an Integration Environment representative of the target Operational Environment. This activity is based on a Software Validation Plan against the software requirements documented in the Software Requirements Specification. This document can be either the Software Validation Plan produced by the supplier or a separate (full or delta) Software Validation Plan produced by the customer. A Test Readiness Review shall be conducted before the start of the tests to verify that all test facilities and test cases are available before the test campaign starts. The test results are documented in the Software Validation Plan. This validation activity culminates with a Provisional Acceptance Review (AR1). Particular tests that may be required as part of operational validation are: Tests with the full ground segment including communications network. Tests under different load conditions, including the maximum expected load (e.g., maximum number of user work stations, high speed telemetry playback, etc.) Reaction and loading of software in response to on-board conditions or anomalies. Ground segment failure cases, e.g., switch of the software to redundant equipment, reaction to failures of other equipment. The tests shall include the re-generation of executable code from source code, to ensure that the build process is robust. The supplier shall support the acceptance testing process. All problems found shall be reported in a Software Problem Report. Documents being produced/updated during this activity: Software Problem Report, Software Validation Test Document, Software Validation Plan added/updated (by document): Software Problem Report: Problems and nonconformances - AR1 Software Validation Test Document: Software validation testing document against TS (update with provisional acceptance test results) - AR1 Software Validation Plan: Section 9: Provisional acceptance testing results - AR1 without mandated format: Test readiness review report - AR1 7.3 Provisional Software Acceptance Review (AR1) The purpose of this activity is to review the results of the Provisional Acceptance activity. The results of the Provisional Software Acceptance activity shall be reviewed. Recommendations for solving issues that occurred during testing shall be documented in the Acceptance Review Report. Product assurance documentation, release documentation, and the software user manual shall be reviewed.

52 46 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DELIVERY AND ACCEPTANCE PROCESS Software release documentation and the software user manual shall be updated accordingly, if necessary. The provisional software acceptance review is the responsibility of the customer. Inputs Documents subject to this review: Software Maintenance Plan, Software Product Assurance Report, Software Problem Report, Software Release Document, Software User Manual, Software Validation Test Document, Software Validation Plan Elements of above documents subject to review: Software Maintenance Plan: Activities, methods, resources, schedule, responsibilities and tools applicable to maintenance Software Product Assurance Report: Section 5: Summary of verification activities results Section 5: Report of the measurement analysis and remedial actions Section 5: Agreed assessment or audit report Section 5: Summary of validation activities results Section 5.1: Assessment of the quality of the software development process Section 5.1: Software process assessment records: strengths and weaknesses Section 5.1: General results of design reviews Section 5.1: Statement of compliance with test plans and procedures Section 5.1: Maintenance records Section 5.2: Assessment of the quality of the software product Section 5.2: Evidence of dependability and safety criticality classification Section 5.2: Software process assessment record: updates to process or project documentation Section 5.2: Synthesis of code analysis results and corrective actions Section 6: Software process assessment records: improvement plan Section 7: Software process assessment records: quality data Section 7: Metrics reports Section 7: Software quality models Software Problem Report: Major non-conformances Software problem information Problems and nonconformances Software Release Document: Software release documentation Section 5.3: Documented configuration baseline Section 7.2: Build procedures Section 7.4: Installation events and results Section 8: Documented and approved evolution of a configuration item Software User Manual: Software user manual (update after CDR) Software user manual (update after integration) Software Validation Test Document: Documentation of complementary validation that cannot be tested at supplier premises Updated test documentation Software validation testing document against TS (update with provisional acceptance test results) Section 5: Validation approach Section 6.4: Validation test procedures Section 7: Verification report with respect to the Technical Specification (if validation testing is not possible) Software Validation Plan: Section 5: Validation tasks Section 7: Validation testing facilities Section 8: Control procedures for validation process

53 BSSC 2005(1) Issue 1.0 June SOFTWARE DELIVERY AND ACCEPTANCE PROCESS Section 9: Provisional acceptance testing results Inputs without mandated format: Software delivery Performance matrix Test readiness review report Documents being produced/updated during this activity: Acceptance Review Report (no mandated format), Software Release Document, Software User Manual added/updated (by document): Acceptance Review Report (no mandated format): Recommendations for solving provisional acceptance testing issues Software Release Document: Software release documentation (update after AR1) - AR2 Software User Manual: Software user manual (update after AR1) - AR2 7.4 Final Software Delivery and Installation [optional] The purpose of this activity is to set up the system in the checkout environment. In case the checkout environment is different from the integration environment (as it would typically be for mission-specific software), the supplier shall deliver and install the product in the checkout environment. Other than this, what is said in section 7.1 applies here as well. Documents being produced/updated during this activity: Software Release Document added/updated (by document): Software Release Document: Software release documentation (update during final delivery and installation) - AR2 without mandated format: Software delivery - AR2 Training material (update during final delivery and installation) - AR2 7.5 Final Software Acceptance The purpose of this activity is for the customer to validate (checkout) the software in the Integration Environment for Infrastructure software and in the Operational Environment for mission-specific software. The software is subject to checkout, e.g., for mission-specific software by running operational procedures. The duration of the checkout period is specified in the software development contractual documentation. This validation activity culminates with a Final Acceptance Review (AR2). The supplier shall support the Acceptance Review process. All problems found shall be reported in Software Problem Reports. Documents being produced/updated during this activity: Software Problem Report

54 48 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE DELIVERY AND ACCEPTANCE PROCESS added/updated (by document): Software Problem Report: Problems and nonconformances without mandated format: Validation of operational requirements 7.6 Final Software Acceptance Review (AR2) The purpose of this activity is to review the results of the Provisional Acceptance activity. The results of the Final Software Acceptance activity shall be reviewed. Recommendations for solving issues that occurred during testing shall be documented in the Acceptance Review Report. Product assurance documentation, release documentation, and the software user manual shall be reviewed. Software release documentation and the software user manual shall be updated accordingly, if necessary. The final software acceptance review is the responsibility of the customer. Inputs Documents subject to this review: Software Product Assurance Report, Software Problem Report, Software Release Document, Software User Manual, Software Validation Test Document, Software Validation Plan Elements of above documents subject to review: Software Product Assurance Report: Section 5: Summary of verification activities results Section 5: Report of the measurement analysis and remedial actions Section 5: Agreed assessment or audit report Section 5: Summary of validation activities results Section 5.1: Assessment of the quality of the software development process Section 5.1: Software process assessment records: strengths and weaknesses Section 5.1: General results of design reviews Section 5.1: Statement of compliance with test plans and procedures Section 5.1: Maintenance records Section 5.2: Assessment of the quality of the software product Section 5.2: Evidence of dependability and safety criticality classification Section 5.2: Software process assessment record: updates to process or project documentation Section 5.2: Synthesis of code analysis results and corrective actions Section 6: Software process assessment records: improvement plan Section 7: Software process assessment records: quality data Section 7: Metrics reports Section 7: Software quality models Software Problem Report: Major non-conformances Software problem information Software Release Document: Software release documentation (update after AR1) Software release documentation (update during final delivery and installation) Section 5.3: Documented configuration baseline Section 7.2: Build procedures Section 8: Documented and approved evolution of a configuration item Software User Manual: Software user manual (update after CDR) Software user manual (update after integration)

55 BSSC 2005(1) Issue 1.0 June SOFTWARE DELIVERY AND ACCEPTANCE PROCESS Software user manual (update after AR1) Software Validation Test Document: Updated test documentation Section 5: Validation approach Section 6.4: Validation test procedures Software Validation Plan: Section 5: Validation tasks Section 7: Validation testing facilities Section 8: Control procedures for validation process Inputs without mandated format: Software delivery Training material (update during final delivery and installation) Documents being produced/updated during this activity: Acceptance Review Report (no mandated format), Software Release Document, Software User Manual, Software Validation Plan added/updated (by document): Acceptance Review Report (no mandated format): Customer approval of accepted state AR2 acceptance test report Recommendations for solving final acceptance testing issues Software Release Document: Software release documentation (update after AR2) Software User Manual: Software user manual (update after AR2) Software Validation Plan: Acceptance test plan (updated with final software acceptance test results) without mandated format: Software delivery

56 50 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE MAINTENANCE PROCESS 8 SOFTWARE MAINTENANCE PROCESS The purpose of this process is to ensure proper maintenance of the system in order to keep it operational as desired by the end-users. This process describes the activities occurring during usage of the software. This consists of the actual maintenance of the product, i.e., changes to the product. Product in this section means the combination of software and hardware required for operating the software. The maintenance process is activated when the software requires modification to its code and its associated documentation. The modification may be required either due to a problem reported or by the need for improvement or adaptation. The objective of maintenance is to modify an existing product while preserving its integrity. Software maintenance always results in a change to a product. The actual change to the product may require the initiation of any of the life cycle processes defined in this volume, e.g., requirements engineering, architecture engineering, or verification and validation. The processes invoked, and the extent to which they are applied, will depend on the nature of the change. A maintenance organisation, the maintainer, shall be designated for every product in operational use. In cases where the software development processes are invoked by the maintenance process, the term supplier is taken to mean the maintainer. Software maintenance may include migration of the software to different operational environments, or mothballing or retiring the product entirely. The maintainer shall develop documented procedures for undertaking the activities of the software maintenance process. These documented procedures are normally referred to as a Maintenance Plan. For maintenance of the software, the same procedures, methods, tools, and standards shall be used as for the development. The maintainer shall include in the Maintenance Plan procedures for receiving, recording, and tracking problems and modification requests from the operator. Furthermore, the maintainer shall implement (or establish the organisational interface with) the configuration management process for managing modifications. More detailed guidance on the scope of these procedures is given in Part B section 3. This addresses aspects such as the format of problem reporting and change control forms and the approval mechanisms for software changes. Documents being produced/updated during this activity: Software Maintenance Plan, Software Problem Report added/updated (by document): Software Maintenance Plan: Section 4: Maintenance planning Section 5: Maintenance procedures Section 5.3: Procedures for problem reporting and handling Software Problem Report: Problems and nonconformances 8.1 Maintenance Planning The purpose of this process is to provide a plan for software maintenance containing the operator s standards for testing, software maintenance, and user support.

57 BSSC 2005(1) Issue 1.0 June SOFTWARE MAINTENANCE PROCESS This activity is concerned with the development, by the operator, of the software maintenance plan. The software maintenance plan contains the maintainer's standards for testing, software maintenance, and user support. The procedures developed for this plan will be used by the maintainer of the product. Any maintenance facilities (hardware, software,...) shall be described in the maintenance plan. The operator shall establish procedures for receiving, recording, resolving, and tracking anomalies, and for providing feedback. Anomalies shall be analysed to determine whether the actual behaviour is valid (and thus the expected behaviour is incorrect) or, alternatively, the expected behaviour is correct and the actual behaviour constitutes a problem. Anomaly handling and requirements for change control are identified in Part B sections and Documents being produced/updated during this activity: Software Maintenance Plan, Software Problem Report, Software Release Document added/updated (by document): Software Maintenance Plan: Section 6: Maintenance facilities Software Problem Report: Software problem report Software Release Document: Section 7.3: Procedures for problem handling without mandated format: Operational testing specifications 8.2 System Operation This activity stands for the actual system operation in its intended environment. The system is operated in its intended environment according to procedures written by those responsible for the various operations of the system (e.g., computer operations, network operations, simulator operations, and spacecraft operations). Feedback information for software maintenance, e.g., appropriate logs or reports, shall be identified in the appropriate procedures. Documents being produced/updated during this activity: Software Problem Report added/updated (by document): Software Problem Report: Problems and nonconformances 8.3 User Support The purpose of this activity is to ensure that the system users receive proper support from the maintainer. In practice, user support often takes the form of a help desk, with availability according to the mission needs (e.g., during several working hours with call-out at other times). Typically, members of the same team that carry out software maintenance provide this user support. In this case, it maps to

58 52 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE MAINTENANCE PROCESS what is often called first-line maintenance. Therefore in the following the organisation providing user support is referred to as the maintainer. The maintainer shall provide assistance and consultation to the users as requested. These requests and subsequent actions shall be recorded and monitored. The maintainer shall record and acknowledge all user requests, forward all appropriate user requests to the following maintenance process for resolution, monitor their resolution to a conclusion, and report back to the originator of the request. Temporary work-arounds may be used subject to agreement by the originator of the problem report and in accordance with defined plans and procedures. All permanent corrections and releases containing new functionality and system improvements shall be undertaken in accordance with the Maintenance Process. During critical operations, for example, during a Launch and Early Orbit Phase (LEOP), a software support team reporting to a software coordinator will be on shift. They will monitor the software, restarting it or reconfiguring it on request, and giving advice to the end user. without mandated format: Record of user requests and subsequent actions 8.4 Problem and Modification Analysis The purpose of this activity is to analyse reported problems and modification requests with regard to whether they justify changes to the system. All reported software problems or modification requests shall be examined prior to any amendment. Only approved changes shall be implemented. The key aspect of the problem analysis activity is to find the root cause of the problem and the impact of the problem on the operation of the system. The initial aspect of the activity shall be to explicitly determine the type of problem reported, which can fall in one of the types shown in Table 8.2. Type Corrective Maintenance Improvement ( perfective maintenance ) Preventive Maintenance Meaning Changes to correct an error in the operation or in a function of the system Provision of new or improved functionality Changes to prevent fault occurrence in the product Adaptive Migration of product to a new environment Maintenance Table 8.2 Maintenance Types An initial analysis of the reported problem shall be undertaken to determine the scope of the change required. The scope shall consider aspects such as the size of the modification, the cost involved, and the time to modify. All requests shall be prioritised in terms of the following aspects: Operations needs Risk, e.g., in the case of complex change Effort required to implement request. The change shall also be assessed against its likely impact on either the software behaviour or the maintenance budget. The importance of the request can be different from the nature of the change.

59 BSSC 2005(1) Issue 1.0 June SOFTWARE MAINTENANCE PROCESS For example, a problem with an important functional aspect of the product may be rectified by a relatively simple change to the code. In the case of reusable or infrastructure software, the impact on all the projects using the product must be considered. This may involve obtaining approval of all those involved with the reusable or infrastructure software. The maintainer shall attempt to reproduce the problem and understand why it happened. This can be used to assist in examining options for changing the product. There may be a variety of options for resolving a problem, each with associated advantages and disadvantages. The results of this analysis shall be fully recorded in a problem analysis report. Prior to implementing any modification to the system, the maintainer shall obtain approval from the customer for the selected option. without mandated format: Modification analysis report and problem analysis report 8.5 Modification Implementation The purpose of this activity is to implement changes to the software and to update all affected documentation. The maintainer shall identify all software items requiring change, the extent of the change, and the likely cost. This identification shall include documentation, software units, and specific versions. All modifications are undertaken in accordance with the software engineering processes specified in this document. The software engineering process shall be entered at a point consistent with the scope of the approved change. Test and evaluation criteria for verifying and validating the modified and unmodified parts of the product shall be defined and documented. This will usually be operational testing criteria, however, other methods are also possible. In normal practice, the test documentation developed during the acceptance process can be used during this activity. Wherever necessary, the maintainer shall update and amend the existing test procedures for testing new releases of the product in its operational environment. The software shall be released for operational use when the operational testing criteria have been satisfied. The approved changes resulting from the problem and modification analysis shall be implemented. All associated documentation shall be updated accordingly. All changes to the product shall be realised in conformance with change and configuration management, as described in Part B section 3. The complete and correct implementation of the new and modified requirements shall be ensured by verification and validation. Both is usually done by (regression) testing, but other methods are possible, too. Verification usually tests against the (changed) specification of the modified component, validation tests against the requirements as defined in the Technical Specification. In case of corrective maintenance, the Technical Specification will typically be unchanged, however, adaptive and perfective maintenance may lead to changes to it. without mandated format: Operational testing results Modification identification Criteria for re-verification and re-validation of the product 8.6 Maintenance Review The purpose of this activity is to have the customer formally accept the changed product. Once the supplier has implemented the modifications agreed upon with the customer, he delivers the new product in the form of a new release. The new release changes are tested by the customer in the

60 54 BSSC 2005(1) Issue 1.0 June 2005 SOFTWARE MAINTENANCE PROCESS integration environment and then by the end users in the operational environment. The outcome of the test activities are jointly reviewed between the customer and the suppliers, e.g., in Software Review Boards. without mandated format: Baseline for changes 8.7 Software Migration [optional] The purpose of this activity is to ensure that software migration is executed and documented properly. Software migration is the activity of transferring software from one operational environment to another. This migration may be required due to a change to the underlying hardware platform or to the operating system being used. Other software or elements within a subsystem or system may also have been changed, thus requiring the software to be migrated to a new operational environment. Software migration may require changes to the product. All such changes shall be undertaken in accordance with the development processes specified in this volume. All migration activities shall be documented in a migration plan. The plan shall cover the following requirements: Requirements analysis and definition of migration Development of migration tools Conversion of the software Migration execution Migration verification Support for the old environment User and operator involvement in the activities, plus explanation (e.g., for parallel operation, extra manpower may be needed). Users shall be given notification of the migration activities. The migration justification included in the migration plan shall contain the following information: Statement of why the old environment can no longer be supported of the new environment with its date of availability of other support options available, if any, once support for the old environment has been removed. Parallel operation of the old and new systems, for a specified time, may be required. Any required training for this activity, e.g., for operations, will be defined in the Migration Plan. All those concerned with the maintenance of the system shall be informed when the migration takes place. All records relating to the old system shall be archived, subject to the requirements for parallel running. A post-operation review shall be performed to assess the impact of changing to the new environment. The result of the review shall be sent to the appropriate authorities for information, guidance and action. The software migration activity shall be executed upon customer request, if and when the migration of a software is necessary. Documents being produced/updated during this activity: Software Maintenance Plan

61 BSSC 2005(1) Issue 1.0 June SOFTWARE MAINTENANCE PROCESS added/updated (by document): Software Maintenance Plan: Section 7: Migration plan without mandated format: Post-operation review report 8.8 Software Retirement [optional] The purpose of this activity is to describe all activities concerned with controlled retirement of the software. Upon customer s request to retire a software or product, a retirement plan to remove active support by the maintainer shall be developed, documented, and executed, considering the following items: Cessation of full or partial support after a certain period of time Archiving of the software or product and its associated documentation Responsibility for any future residual support issues Transition to any new software or product Accessibility of archive copies of data. The maintainer shall provide the retirement plan and related activities, including the following items: of the replacement or upgrade with its date of availability Statement of why the software or product is no longer to be supported of other support options available, once support is removed Parallel operations of the retiring and the new software or product can be conducted for smooth transition to the new system. During this period, user training shall be provided as specified in the contract. Data used by or associated with the retired software or product shall be accessible in accordance with the contract requirements for data protection and audit applicable to the data. The retirement shall result in the co-ordinated and controlled performance of the operations necessary for the total or partial cessation of use of the software or product. The retirement of the software or product shall be executed in accordance with all legal and administrative procedures applicable to the organisation and the product. This activity needs only be executed upon customer request. Documents being produced/updated during this activity: Software Maintenance Plan added/updated (by document): Software Maintenance Plan: Section 8: Retirement plan

62 56 BSSC 2005(1) Issue 1.0 June 2005 APPENDIX A GLOSSARY 9 APPENDIX A GLOSSARY 9.1 Definitions Operational Software From ESA General Clauses and Conditions Rev. 6: Computer programs used or required on the ground to validate and control a space mission, for calibration of data derived from a space mission or for any other Agency purpose including all updates, modifications and enhancements of such programmes which (1) are developed (or are in the process of being developed), modified, enhanced or maintained by more than one party and (2) which have an expected use for the Agency s essential purposes over a period of more than 5 years Non-operational Software Non-operational software is any other software, which could include test scripts, test programs, and simulators. Simulators would become operational in the event that they are included in operational processes, for example to check command sequences or operational procedures, as an essential step before carrying out the operations. 9.2 Abbreviated Terms The following acronyms are used: AR1 AR2 ARR BSSC CASE CDR CDRR COTS CPU ECSS EGSE ESA ESOC FCT GCS GSTS ICD IRD ISO LEOP MCS MES MMI MOTS OTS Provisional Acceptance Review Final Acceptance Review Acceptance Review Report Board for Software Standardisation and Control Computer Aided Software Engineering Critical Design Review Critical Design Review Report Commercial Off-the-Shelf Software Central Processor Unit European Cooperation for Space Standardisation Electrical Ground Support Equipment European Space Agency European Space Operations Centre Flight Control Team Ground Communication Sub-net Ground Station System Interface Control Document Interface Requirement Document International Standards Organisation Launch and Early Orbit Operations Mission Control System Mission Exploitation System Man-Machine Interface Modified Off-The-Shelf Software Off-the-Shelf Software

63 BSSC 2005(1) Issue 1.0 June APPENDIX A GLOSSARY PCS PDR PDRR PSS RB RF SBR SCMP SDD SDP SETG SMP SPAP SPAR SPR SRelD SRS SITP SUTP SUM SValP SVerP SVF SVTD SWRR SWRRR TS Payload Control System Preliminary Design Review Preliminary Design Review Report Procedures, Standards and Specifications Requirements Baseline Radio Frequency Software Budget Report Software Configuration Management Plan Software Design Document Software Development Plan Software Engineering Tailoring for Ground Segments Software Maintenance Plan Software Product Assurance Plan Software Product Assurance Report Software Problem Report Software Release Document Software Requirements Specification Software Integration Test Plan Software Unit Test Plan Software User Manual Software Validation Plan Software Verification Plan Software Validation Facility Software Validation Test Document Software Requirements Review Software Requirements Review Report Technical Specification

64 58 BSSC 2005(1) Issue 1.0 June 2005 APPENDIX B REFERENCES 10 APPENDIX B REFERENCES 1. Information Technology Software Life Cycle Processes ISO/IEC 12207: ECSS-M-00B Policy and Principles, 29 August ECSS-M-10B Project Breakdown Structures, 13 June ECSS-M-20B Project Organisation, 13 June ECSS-M-30A Project Phasing and Planning 19 April ECSS-M-40A Configuration Management, 19 April ECSS-M-50A Information/Document Management, 19 April ECSS-M-60A Cost and Schedule Management, 19 April ECSS-Q-80B Space Product Assurance, 10 October ECSS-E-40 Part 1B Space Engineering: Software Part 1: Principles and Requirements, 28 November ECSS-E-70A Space Engineering: Ground Systems and Operations, Part 1: Principles and Requirements, 25 April ECSS-E-00A Space Engineering: Policy and Principles, 19 April BSSC C/C++ Coding Standard, BSSC99(1), Issue BSSC Ada Coding Standard, BSSC98(3), Issue ECSS-E Space Engineering: Ground Segment Software, Issue 1.1 Draft, 26 November ECSS-M-00-02A Tailoring of Space Standards, 25 April ECSS-M-00-03A Risk Management, 25 April 2000