Navigation Support Services

Transcription

1 OPS QMS QMS-EIMO-SERV-PR-4500-OPS Issue 1.1 May 2006 European Space Agency Agence spatiale européenne Copyright: 2004 European Space Agency

2 : ii DOCUMENT APPROVAL Prepared by L. Agrotis, J. Dow, R. Zandbergen

3 : iii CHANGE RECORD SHEET Issue/Rev s Affected Description 05/ All ESOC QMS changed to OPS QMS on front page and in header. Document number changed from QMS- ESOC-SERV-PR OPS to QMS-EIMO- SERV-PR-4500-OPS. Applicable Document numbers in Clause 4.1 changed to line up with the new QMS numbering scheme. 05/ , 7, 8 Document updated to comply with new SETG standard. DCR SERV-PR DCR-01 SERV-PR DCR-02 Approval Authority

4 : iv CONTENTS 1 INTRODUCTION SCOPE DEFINITIONS AND ABBREVIATIONS Definitions Abbreviations RELATED DOCUMENTS Applicable Documents Reference Documents RESPONSIBILITIES Head of Navigation Support Office ESOC Project Manager Operations Team Researcher System Development and Maintenance Team PROCEDURE Operational Service Provision Consultancy Research Activities In-House System Development Externally Procured Systems and Services Maintenance Systems Management Configuration and Change Management OUTPUTS AND REPORTING Outputs Reporting...15 This document contains a total of 19 pages.

5 : 1 1 INTRODUCTION include the implementation and operation of services and the delivery of products to internal and external customers in a number of areas related to precise orbit determination and satellite navigation. Responsibility for these activities resides within the ESOC Navigation Support Office (OPS-GN). The current infrastructure within the Navigation Support Office comprises two large softwarebased systems (see RD1), which form the basis for the implementation of all projects and products within the Navigation Support Office: The Tracking and Data Acquisition Facility (TDAF) for GPS and GLONASS data, for the determination of high accuracy orbits and associated products, is based on heritage orbit determination software written in FORTRAN 77. The Navigation Package for Earth Observation Satellites (NAPEOS) software suite for precise orbit determination of Low Earth Orbiting (LEO) satellites is a complete redevelopment of the orbit software in FORTRAN 90. The above infrastructure elements are in the process of significant upgrades to support new missions and contracts with external customers. This document supports compliance to ISO 9001:2000(E) clauses 7.2, 7.3, 7.4, 7.5 and 8 (see AD2). 2 SCOPE This procedure specifies all the activities carried out by the Navigation Support Office (OPS- GN) in providing its products and services to ESA and external customers. It includes: Operational Service Provision Consultancy Research Activities System Development In-House System Development Externally Procured Systems Maintenance Systems Management Configuration and Change Management Support to Acquisition of External Services and Negotiation of Contracts 3 DEFINITIONS AND ABBREVIATIONS 3.1 Definitions Unless otherwise defined below the definitions given in ECSS-P-001B apply to this procedure.

6 : Abbreviations AD Applicable Document BSSC Board for Software Standardisation and Control CCB Configuration Control Board CM Configuration Management CMS Configuration and Change Management System CR Change Request DRB Design Review Board ECSS European Cooperation for Space Standardisation ESA European Space Agency ESOC European Space Operations Centre GNSS Global Navigation Satellite System GPS Global Positioning System GUI Graphical User Interface ID Identifier ISO International Organisation for Standardisation LEO Low Earth Orbit NAPEOS NAvigation Package for Earth Observation Satellites ORR Operations Readiness Review PR Problem Report QMS Quality Management System RD Reference Document TDAF Tracking and Data Analysis Facility 4 RELATED DOCUMENTS 4.1 Applicable Documents The following documents are applicable to the extent specified herein. AD1 ECSS-P-001B ECSS Glossary of Terms AD2 ISO 9001:2000(E) Quality Management Systems Requirements. Third Edition, 15 December AD3 QMS-EIMO-GSEG-WI-1301-OPS Test Planning and Reporting AD4 QMS-EIMO-SERV-PR-4300-OPS Consultancy Services AD5 QMS-EIMO-CNFD-PR-5100-OPS Configuration Management AD6 QMS-OPS-CNFD-PR-5300-OPS OPS Document Management AD7 QMS-EIMO-CNFD-DRD-5400-OPS Change Request AD8 QMS-EIMO-PROB-PR-6200-OPS Anomaly and Problem Identification, Reporting and Resolution AD9 QMS-EIMO-PROB-DRD-6201-OPS Software Problem Reports AD10 QMS-OPS-CTRP-PR-7100-OPS Control of Procurement AD11 QMS-EIMO-CTRP-PR-7110-OPS Control of Software Procurement and Maintenance via Contract AD12 QMS-EIMO-CTRP-PR-7400-OPS Proposal Preparation and Contract Management for External Customers AD13 QMS-EIMO-CTRP-PR-7410-OPS Project Control and Management

7 : 3 AD14 QMS-EIMO-CTRP-PR-7420-OPS AD15 QMS-EIMO-CTRP-PR-7430-OPS AD16 QMS-EIMO-CTRP-WI-7500-OPS AD17 ECSS-E-40 Part 1B AD18 BSSC 2005(1), Issue 1.0 AD19 BSSC 2005(1), Issue 1.0 AD20 BSSC 2005(1), Issue 1.0 AD21 BSSC 2005(1), Issue 1.0 Project Quality Planning Internal Work Agreements Service Level Agreements, Format and Management Space Engineering - Software Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA Part A: Software Engineering Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA Part B: PA and Management Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA Part C: Document Templates Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA Part D: Traceability Against ECSS Standards 4.2 Reference Documents RD1 Next Generation Facilities for Terrestrial and LEO Navigation. Final Report. Prepared for ESA by Symban Ltd, Doc No SYM-ESA TR-010, Issue 3.0, October RESPONSIBILITIES 5.1 Head of Navigation Support Office The Head of the Navigation Support Office has overall responsibility for ensuring that all activities related to the provision of are conducted according to agreed procedures and principles, as detailed in this Procedure. 5.2 ESOC Project Manager The ESOC Project Manager s responsibilities are defined in AD4, AD12, AD13, AD14 and AD15. They are specific to the provision of to customers, governed by contractual arrangements for Third Party Support, Internal Work Agreements or Service Level Agreements. He reports to the Head of the Navigation Support Office. 5.3 Operations Team The Operations Team comprises a number of Operations Engineers and is headed by an Operations Team Leader who reports to the Head of the Navigation Support Office. The Team is responsible for all routine activities involving the Operational Service Provision to Navigation Support Office customers. This includes monitoring and control of the operational systems and responding to contingencies and problems that may degrade the accuracy or disrupt the availability of the. The Operations Team conducts its activities according to the procedure detailed in Section 6.1 of this procedure.

8 : Researcher A Researcher is appointed as needed by the Head of the Navigation Support Office to undertake specific research into an area of scientific or commercial interest. Such activities are intended to enhance the quality of the and to assess feasibility for new products and services. The procedure for Researcher activities is in Section 6.3 of this procedure. 5.5 System Development and Maintenance Team The System Development and Maintenance Team is responsible for all in-house system development and maintenance activities. These are performed according to the procedures detailed in Sections 6.4, 6.6 and 6.8 of this procedure. The Team is led by a System Engineering Manager who reports to the Head of the Navigation Support Office or his nominated representative. 6 PROCEDURE 6.1 Operational Service Provision The Operations function is responsible for the generation of the Navigation Support Service products, including the monitoring and operation of the software and hardware systems, first line response for problem resolution and contingency handling, and the operation of the internal and external customer interfaces. The tasks performed by the Operations Team include: 1. Operation of the systems needed for the provision of, according to authorised procedures 2. Product checks prior to release to users (automated where possible) 3. Measurement of System Performance and reporting of results (automated where possible) 4. Receiving feedback from customers 5. Maintaining traceability of Operations Team activities through automated and manual logs 6. Problem identification and reporting 7. Provision of on-call service outside working hours where needed 8. Invocation of callout procedures where escalation to on-call staff is needed 9. Training of new staff 10. Compilation and maintenance of the Operational Documentation (see Section 6.1.2) 11. Generation of Lessons Learned Operations Review Prior to commencement of operations for a new project, an Operations Readiness Review (ORR) is held to assess readiness of the Operations Team to support the project. The ORR review panel is chaired by the Head of the Navigation Support Office and assesses: Readiness and training status of Operations Team

9 : 5 Readiness of Computer Systems and associated infrastructure Implementation status of the requirements of the Operations Plan, including Status of routine and contingency procedures Duty roster Status of on-call internal and external support arrangements Status of simulation and rehearsal activities Status of customer interfaces Documentation for Operations The Documentation set needed to support operations includes the following: Operations Plan This is high level document outlining the plan for operating the system. It defines the Operations Team roles and responsibilities and the requirements for Staffing, duty rosters and out of hours support, training (including simulations and rehearsals), on-call support, customer interfaces and Configuration Management Detailed Procedures These comprise step-by-step instructions to perform the Operations functions. They include, for example, routine and contingency operations procedures, problem notification and escalation procedures, as well as procedures for callout of external support and for handling customer interfaces Training Plan The Training Plan defines how to implement the requirements for training, specified in the Operations Plan. It includes a definition of the activities required from the Operations Engineers and the minimum set of training activities to be performed before they can adequately fulfil the functions expected from them. In particular, the Training Plan ensures adequate familiarisation with the detailed procedures. It also specifies any recurring training activities that need to be performed to maintain the team competences, with particular emphasis on ensuring team readiness for contingency response and problem resolution. Operations Log The Operations Log is a log of the main activities and events that occur during Operations. The duty Operations Engineers are responsible for maintaining this log and it is used as a basis for handovers during shift changes. The events are recorded against the date and time of occurrence and the initials of the person filing the information. They include details and confirmation of checks performed on the system, changes to steering parameters, all problems recorded, all contingency actions performed and all nonroutine information and data exchanges with internal and external customers. Change Documents Problem Reports and Change Requests are raised electronically and are used to document all anomalies observed by the Operations Staff, and to request changes to the operational configuration and databases (see Section 6.8). Status Report A regular status report of the operational system, summarising the ordinary and extraordinary activities performed on the system, the

10 : 6 availability of the system and deliverable items, configuration changes and problems encountered during the reporting period. The documentation requirements for Operational Service Provision vary according to the services being offered. High availability services with formal commitments on deliverables require the full documentation set. Services with lower availability requirements and no formal commitments on deliverables require a reduced documentation set, with a much reduced Operations Plan and without the need of a formal training plan. 6.2 Consultancy Consultancy services are provided as required by agency needs, Service Level Agreements or external contracts. Consultancy work is performed according to AD Research Activities Research activities maintain the technological edge of the offered by ESOC. They are used to focus effort on a particular area of scientific, technological or commercial interest. The objectives and potential benefits of a Research Activity can include: Identification and development of new products to form part of a Navigation Support Service Development of new techniques to improve the accuracy, reliability and latency of the products and services Development of processes to improve efficiency and minimise costs (e.g. manpower or computer resources) Support to European industry Publicising ESOC s capabilities through presentations and publication of research papers. The steps in each Research Activity follow the general pattern outlined below: 1. Identification of Research Activity and specification of the work to be performed 2. Assignment of Researcher by the Head of the Navigation Support Office and authorisation of the level of effort to be expended 3. Agreement of detailed research objectives and outputs 4. Performance of the work 5. Publication of results in Research Papers or Technical Notes 6. Optionally, presentation of results at appropriate meetings or conferences. 6.4 In-House System Development System Development is performed according to the ECSS Space Engineering Software Standards, ECSS-E-40 (see AD17), as implemented in the Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA (AD18-AD21). System development is in most cases performed incrementally to address requirements for specific projects. As the magnitude of these individual development efforts is relatively small,

11 : 7 the standards adopted are tailored in order to reduce the documentation requirements, according to the tailoring guidelines. The following simplifications are applied: The System Specification (part of the Requirements Baseline) includes the Interface Requirements that would normally be in a separate Interface Requirements Document The Configuration Management Plan has common features for all projects within the Navigation Support Office. A single document is produced, and is supplemented by individual plans for each project, documented in the Software Development Plan. The Verification and Validation Plan is integrated within the Software Development Plan for each new product. Module level Detailed Design documentation is integrated with the source code. However, the module interfaces and functions are documented either in the Detailed Design part of the Design Definition File or as part of the Architectural Design System Development Lifecycle Processes and Reviews This section explains the development lifecycle processes, as defined in AD17, and outlines the reviews and deliveries at each stage, as tailored for the requirements for development within the Navigation Support Office. A strong consideration at all stages of the design and development process is the need for consistency, reliability and availability of the final system and products. These are ensured through the design of: built-in redundancy automated product checks automated system checks to ensure availability of the critical processes and functions Requirements Engineering Process The Requirements, or System Engineering Phase, starts with the analysis of the required system and the compilation of the User and Interface Requirements. These are documented in the System Specification (see ). The requirements are reviewed at a System Requirements Review (SRR), where a Design Review Board (DRB), appointed by the CCB, approves the System Specification. At this stage the System Specification and any supporting documentation forms the Requirements Baseline and enters Configuration Control. After the SRR, the development team produces the Software Requirements Specification and the draft Interface Control Document (ICD), which together constitute the Technical Specification, as a response to the Requirements Baseline. Coding standards are defined in this phase. The System Engineering Manager prepares the first issue of the Software Development Plan, covering the entire project with specific details about the Architectural Design phase. A Software Requirements Review (SWRR) is held to review and approve the following: Software Requirements Specification Software Development Plan ICD (initial draft)

12 : 8 The Architectural Design stage is the last stage within the Requirements Engineering process and is completed at the Preliminary Design Review (PDR). During this stage the system is partitioned into components and the software requirements are allocated to each component, ensuring coverage of all the requirements. This stage also includes the top level design of the internal and external interfaces, with updates to the ICD for the external interfaces and the specification of the internal interfaces in the Architectural Design. The Software Development Plan is updated to cover planning for the Detailed Design and for Integration, Validation and Verification activities. The Software Development Plan can also include any hardware procurement requirements and planning necessary to prepare for the software development activities. At Preliminary Design Review (PDR), which marks the end of the Architectural Design, the following items are reviewed and approved by the DRB: Architectural Design (as part of the Software Design Document) ICD (Final Issue) Software Development Plan Design Engineering Process During this phase the System Development Team develops the module specifications and undertakes the coding activity, according to the agreed coding standards. After successful Unit Testing, the system is integrated in preparation for the Qualification Engineering Process. Also, the Software User Manual and Software Installation Plan are generated and revised as necessary. Any hardware items needed for the development and unit test efforts are procured according to ESA purchasing procedures. The phasing of these purchases should ensure sufficient time for preparing and installing the hardware to meet the requirements of the development team. During Design Engineering the following test activities are conducted: Unit Testing and code inspections to validate the new and modified code Integration Testing Optionally, initial Verification Testing to verify compliance with the Technical Specification (ICD and SRS) The test preparation activities involve updates to Validation and Verification Plan sections of the Software Development Plan, in preparation for the Qualification Engineering process. The set of tests, test cases and procedures for conducting software validation testing shall be provided. The final stage in the Design Engineering process is the Critical Design Review (CDR), where the following items are reviewed: The Design Definition File (DDF) comprising Architectural Design (updates) Detailed Design (if produced) The Software User Manual (SUM) The Software Development Plan, including updated plans for Validation and Verification Testing, product assurance and configuration management

13 : 9 The Software Installation Plan The Design Justification File comprising Unit Test Specifications Unit Test Reports Integration Test Specifications Integration Test Reports (validation against ICD, Architectural Design and Module Interfaces) Validation Test Specification Problems detected during the Design Engineering Process are handled according to AD Qualification Engineering Process During this process, the detailed verification and validation test specifications are produced, and the tests are conducted and documented in Test Reports. Verification Cross Reference Matrices (VCRM) are produced for tracing the tests conducted against the Requirements Baseline and the Technical Specification (Software Requirements and ICD). The VCRM and all the test reports and specifications form part of the Design Justification File. Where development work is performed in-house, the split between Factory Acceptance Tests and Site Acceptance Tests recommended in AD18 does not apply. In addition, where appropriate, justified by the size of the project, the Qualification Review and the Acceptance Review are merged into a single Qualification and Acceptance Review. Test planning, execution and reporting is performed according to AD3. The Qualification Review, under the responsibility of the Design Review Board, aims to achieve the following objectives: Verification and Validation of the System against the Technical Specification (SRS and ICD) Verification and Validation of the System against the Requirements Baseline (System Specification) Review of validation tests to ensure correct implementation of the algorithms used in the system Review of the overall design Review of the Design Justification File Review of the SUM The Acceptance Review is held after any problems detected at the Qualification Review have been corrected and includes the same items as the Qualification Review along with the results of any re-tests. Responsibility for Final Acceptance and operational deployment resides with the CCB. Problems detected during Qualification Engineering Process are handled according to AD8 and AD Documentation for System Development This section describes the minimum documentation set within a system development project for the Navigation Support Office. Common documents define standards and procedures to

14 : 10 be applied to all projects. Project-specific documents will be produced independently for each software project. Templates for the content of each document are given in AD20. The document lifecycles are defined in AD18 and AD System Specification The System Specification is produced by the customer in order to specify the User Requirements. This document also includes the Interface Requirements that would normally go in a separate Interface Requirements Document. The structure of both documents is discussed in AD20. The System Specification is finalised at the System Requirements Review (SRR) to establish the Requirements Baseline for the subsequent design and development of the System Software Development Plan The Software Development Plan is essentially the Project Management Plan for the project. It contains all the information needed to plan and execute the project, including all relevant elements for Project Organisation, Roles and Responsibilities, Management Approach, Technical Processes and Standards, Risk management plan, Documentation Plan, Work Breakdown Structure, Cost and Schedule. In addition, depending on the scale of project to be undertaken, it includes the following plans: Product Assurance Plan Configuration Management Plan Verification, Validation and Acceptance Plans Hardware Procurement Plan The Software Development Plan is first produced for Software Requirements Review (SWRR) and is updated regularly, with formal updates prior to every major review Software Requirements Specification The SRS is the Development Team s response to the Requirements Baseline. Each requirement includes traceability with a corresponding requirement in the System Specification. The SRS is reviewed and approved at the SWRR (see Section ) and, together with the ICD, constitutes the Technical Specification (TS) of the System Interface Control Document The ICD is used to define all external interfaces to the System. As mentioned above, it is part of the Technical Specification. It is produced for the SWRR as a draft and is finalised at PDR Architectural Design The Architectural Design is part of the Design Definition File (DDF). The latter includes all documents and code listings that together constitute the system design. The Architectural Design partitions the system into components and assigns the requirements from the Technical Specification to each component, ensuring coverage of all requirements. It is also used to document all internal system interfaces.

15 : 11 The Architectural Design is first released at PDR and is updated throughout the design and maintenance lifecycle Detailed Design The Detailed Design is part of the DDF and is used to document the module specifications and any changes to existing code. It is only produced separately for very large development projects involving a number of developers. For smaller projects, the detailed design is incorporated in the Architectural Design, to include the definition of the module hierarchy and interfaces, the function of each module and the details of any algorithm to be implemented. Further details, like the logic used and pseudo code, are documented in the code itself. The Detailed Design is released at CDR and is updated throughout the design and maintenance lifecycle Software User Manual The Software User Manual (SUM) contains all the necessary information to enable the intended users to operate the software. Depending on the complexity of the system, multiple user groups may be targeted (operator, analyst etc). The SUM includes instructions for initialising the software, along with descriptions and instructions of how to execute each operation applicable to each specific user group. In addition, it contains definitions of all error messages and suggested recovery actions when error conditions are encountered Design Justification File The Design Justification File contains the Test Specifications and Test Reports for each phase of the system development. Each test phase is conducted according to the plans and schedules defined in the Software Development Plan. The Test Specifications for each phase address the test requirements in the Requirements Baseline and the Technical Specification. They define for each test case: purpose of the test required test tools the test setup and configuration input data expected results how to run the test A number of individual tests may be grouped together in order to be executed by a single procedure. The detailed test procedures are included in the Test Specifications. Individual test cases are designed to be applicable to a number of test phases (unit, integration, qualification, acceptance). Traceability matrices of test against requirement and vice versa are produced to accompany each Test Specification. A Test Report is written for each test phase, to record and evaluate the results of each test. It includes the as ran? test procedure with the names of the people conducting and

16 : 12 witnessing the tests, a record of all entries collected during its execution and attached printouts generated by the test. A Test Evaluation section contains a summary of the tests conducted, with observations and anomalies recorded against each test case and an assessment of any further work needed Software Installation Plan The Software Installation Plan defines how the product is to be installed, including the setup requirements on the operational systems for creating directory paths, user accounts and installation of additional software and hardware Release Note A Release Note contains the constituent Configuration Items and versions that make up a specific software release Project Configuration File The Project Configuration File contains the identification of each system or subsystem that makes up a particular release of a software project Coding Standards A coding standard is agreed for each of the languages used for software development. These include FORTRAN 77, FORTRAN 90, C/C++ and TCL/TK. The standard lays guidelines and requirements for: Coding style Code Modularity Commenting Naming conventions Language features to be permitted and avoided Standard methods and module calls to be used for a number of common functions, e.g.: file access, error trapping, error messages, warning messages Location of templates and examples to assist in code generation 6.5 Externally Procured Systems and Services External procurements of Navigation Support Office systems and services are performed according to the procedures documented in AD10 and AD11. Technical oversight during software development is provided by the Contract Technical Officer who is identified in the contract. Purchases of COTS software are performed according to AD Maintenance The Maintenance processes adopted by the Navigation Support Office are in accordance with the ECSS Space Engineering Software Standards, ECSS-E-40 (see AD17). Software and System Maintenance is performed within the Navigation Support Office by the System Development and Maintenance Team, with the possible exception of externally supplied items under warranty which may be maintained by the supplier.

17 : 13 The Maintenance process is implemented through tools integrated into the Configuration Management System (see Section 6.8) and is conducted according to the following principles: 1. Maintenance Team members use a common approach to software maintenance 2. Full audit trails and change justification and design files are kept for all changes to the system (software, data or documentation) 3. Deployments to operational systems are from Configuration Management (CM) baselines allowing full regression capability to any previous baseline 4. Maintenance releases are tested to common standards 5. Change is managed to minimise risk to the integrity and functionality of operational systems Two formal maintenance processes have been defined, to handle problem resolution and system modifications (see Section 6.8). 6.7 Systems Management The Systems Management functions to support Navigation Support Service requirements are split between the following ESA groups: The Ground Facilities Operations Division Operational Computer Systems Section (OPS- ONI) is responsible for: Purchasing of all operational computers and associated hardware Unix systems configuration, operation and maintenance The Ground Facilities Operations Division Operational Communications Section (OPS- ONC) is responsible for: Operations and development network configuration (OPSLAN, DEVLAN) Network operation and maintenance The Navigation Support Office (OPS-GN) is responsible for: Selection of operational computers and associated hardware and software GNSS receiver procurement GNSS receiver and remote computer configuration, operation and maintenance Routine system monitoring during office hours The Computer and Communications Centre (part of OPS-ON) is responsible for: Providing routine and out of hours support to the Operational Systems Liaising with vendor support centres for the Operational Systems maintenance Liaising with vendor support centres for network infrastructure maintenance The ESA Information Systems Department (OPS-I) is responsible for: Corporate Hardware Selection and Procurement Configuration, operation and maintenance of Corporate IT Services Systems selection and purchasing involves the specification and evaluation of appropriate hardware and system software configurations to satisfy the requirements of the Navigation Support Services. The evaluation and design tradeoffs are normally conducted in the context of the System Development process (see Section 6.4). The evaluation involves consultations

18 : 14 with OPS-ONI, who are responsible for purchasing and maintaining the selected platforms (see above), and is aimed to ensure that: the selected hardware platforms and software can be supported by OPS-ONI the Systems are expandable to satisfy future projected requirements the selected platforms comply with the availability and reliability requirements and with the redundancy concepts for the system the budget is adequate for the purchases the purchases represent good value for money the recurring maintenance costs are reasonable and affordable 6.8 Configuration and Change Management Configuration and Change Management for the Navigation Support Office is performed in accordance with AD5 and implemented through the use of a commercially procured Configuration and Change Management System (CMS). The CMS is used to automate the configuration control and change management processes that are needed for the activities outlined in the previous sections. The Configuration Control Board is chaired by the Head of the Navigation Support Office or his nominated representative and is composed of Project Manager, Configuration Manager and Experts as needed. A single Configuration Management Plan for all Navigation Support Office products is produced and updated as needed by the Configuration Manager. This specifies the structure of the CMS, the location of the Configuration Items and the implemented lifecycle processes and procedures. The Configuration Items held under the Navigation Support Office CMS include: 1. Documentation 2. Software 3. Scripts 4. Make files and build scripts 5. Executables and binaries 6. Sample steering and test data files for each product build 7. Database files 8. Hardware and System Configuration Files 9. Problem Report Databases 10. Change Request Databases 11. Deployment History 12. Baseline History During a System Development activity the CMS functions are used for creating review and release baselines and for tracking changes to sources and documents. These functions are implemented so as to allow development to proceed without the overhead of timeconsuming authorisation loops, but with the benefits of visibility and traceability during the development process.

19 : 15 The Configuration Management processes applicable to Maintenance activities relate to Problem Reporting and Change Management. These are implemented in accordance with AD7, AD8 and AD9 and are automated within the Navigation Support Office CMS. 7 OUTPUTS AND REPORTING 7.1 Outputs The following outputs shall be retained as specified: Output Responsibility Retention Period Operations Plans Operations Team Leader, Configuration Manager Product expiry + 3 years Operations Procedures Operations Team Leader, Configuration Manager Product expiry + 3 years Software Source Code and Binaries Software Development Plan System Specification Design Definition File Design Justification File Configuration Management Plan Change Documents (Change Requests, Problem Reports) Contractual Documents (relating to service provision to external customers) Configuration Manager ESOC Project Manager, Engineering Manager ESOC Project Manager, Engineering Manager ESOC Project Manager, Engineering Manager ESOC Project Manager, Engineering Manager Configuration Manager Configuration Manager ESOC Project Manager, Configuration Manager Software retirement + 5 years Product expiry + 3 years Software retirement + 3 years Software retirement + 3 years Software retirement + 3 years Product expiry + 3 years Product expiry + 3 years Contract completion + 3 years 7.2 Reporting Reporting needs are specific to the individual customers of the. For external contracts these are covered by contractual commitments between ESOC and the customer. They include in general: Output Responsibility Retention Period Progress Reports ESOC Project Manager Contract expiry + 3 years Service Reports ESOC Project Manager, Operations Team Leader Contract expiry + 3 years Minutes of Meetings ESOC Project Manager Contract expiry + 3 years Deliverable Documents Lists ESOC Project Manager Contract expiry + 3 years