CI CONFIGURATION MANAGEMENT PLAN

Transcription

1 CI CONFIGURATION MANAGEMENT PLAN Version 2-00 Document Control Number /10/09 Consortium for Ocean Leadership 1201 New York Ave NW, 4 th Floor, Washington DC in Cooperation with University of California, San Diego University of Washington Woods Hole Oceanographic Institution Oregon State University Scripps Institution of Oceanography

2 Document Control Sheet Version Date Description Originator 1-00 Aug 11, 2008 Initial Draft J. Kleinert 1-01 Sep 29, 2008 Incorporated review comments J Kleinert 1-02 Oct 14, 2008 Incorporated additional comments J. Kleinert 2-00 Nov 10, 2009 Annual update A.Chave Ver i

3 Table of Contents: 1 Introduction Purpose Scope Configuration Management Planning Configuration Management Organizational Structure Configuration Management Roles and Responsibilities Executive Management Team System Engineering Team Project Manager System Engineer Senior System Architect System Development Manager Quality Manager System Development IPTs Project Analyst Financial Analyst Ocean Leadership Relationship to CI CM Configuration Management Resources Configuration Management Staffing Plan Automated Configuration Management Tools Software Development and Test Environments Configuration Identification Data Management Scope of Data Management Document Management Formal Deliveries Formal Configuration Items Naming and Numbering Conventions Hardware Numbering Convention Deliverable Software Numbering Convention Non-Deliverable Software Numbering Convention Information Item Numbering Convention File Naming Convention Formal Baseline Establishment Identification CI Functional Baseline CI Allocated Baseline CI Development Baseline CI Product Baseline OOI Product Baseline Change Control Engineering Change Classes Class I Class II System Problem Reports (SPR) Defect Tracking Change Control Boards Change Control Flow Control of the Development Baseline Developmental Controlled Item Identification System Development Libraries (SDL) Configuration Status Accounting CSA Process CSA Information Management Systems CSA Data Overview CSA Reports Ver ii

4 5.4.1 Requirements Change Reports Software Version Level and History Software Component Listing Change Documentation Tracking System Problem Report (SPR) Status Accounting Software Build Deliveries Action Items Configuration Audits Functional Configuration Audit Physical Configuration Audit Configuration Management Audits Quality Assurance Audits Glossary of Abbreviations and Acronyms Ver iii

5 1 Introduction Configuration Management is the establishment, implementation, and control of a formal set of procedures by which a uniform system of configuration identification, control, audit and accounting is established and maintained. 1.1 Purpose The Configuration Management Plan (CMP) establishes the activities, responsibilities, processes, and methods used to document and maintain the design of the Ocean Observatories Initiative Cyberinfrastructure (OOI/CI) program and to manage changes to the design and scope of the Cyberinfrastructure System. 1.2 Scope The CMP is applicable to all OOI CI System and Subsystem hardware and software technical data, software designs and code, and hardware developed or delivered as part of the OOI/CI program. The OOI/CI Program includes "sub-projects" that are groups of tasks undertaken by a specific set of subawardees or resources within the larger program. The CMP defines the roles, responsibilities, and authorities of the OOI team members in the configuration management of the CI planning, requirements flow, design, development, and implementation phases. This CI CMP is published and maintained as a separate document and is the responsibility of the System Engineer. The CI Deputy Project Director (DPD) approves the CI CMP. Changes to the OOI System Baseline are managed and controlled in accordance with the procedures defined in the Configuration Management Plan (CMP), and are evaluated for risk in accordance with the procedures defined in the Risk and Opportunity Management Plan (ROMP). 2 Configuration Management Planning CM Planning is the initial effort to describe the purpose, scope, objectives, and general approach to configuration management and any variations from the standard CM processes that are necessary to accommodate unique aspects of the project. 2.1 Configuration Management Organizational Structure The CI Project employs a CM function to establish CM procedures, oversee the application of these procedures by all project personnel, and provide all necessary reports and support for the CM function. Figure 1 depicts the relationships of the formal CM within the CI Program; reporting directly to the System Engineer who is responsible for maintaining the configuration of the system. The following paragraphs describe the roles and responsibilities of each project element involved in the CM function. 2.2 Configuration Management Roles and Responsibilities Executive Management Team The Executive Management Team consists of the Project Director, Deputy Project Directorm, Project Scientist, System Engineer, Quality Manager, Chief Architect, Project Manager and Education and Public Engagement Manager. Each of these persons is a member of the CI CCB with the role defined in Section 4.4. Ver Page 1 of 29

6 2.2.2 System Engineering Team CI Configuration Management Plan The System Engineering Team consists of the System Engineer, Senior System Architect, System Development Manager, Operations Manager and Quality Manager. Each of these persons is a member of the CI CCB with the role defined in Section Project Manager The CI Project Manager (PM) is responsible for overall management of team efforts in the development, evaluation, and documentation of activities associated with the CI project. The PM is responsible for the initial setup and approval for tailoring the CM policies, practices, and procedures. He ensures that adequate methods are implemented for identification and control of each Configuration Item (CI). The Project Manager also reviews CM activities and progress with senior management at regularly scheduled project reviews. The PM ensures that: 1) adequate CM resources, including CM tools, are available; 2) the CI CCBs and Ocean Leadership approve the CM plans and procedures; 3) all project entities follow documented and approved CM practices and procedures; 4) CM personnel, the software engineering staff, and other software-related personnel, including all subcontractors and teammates, are trained in the objectives, procedures, and methods for performing their assigned CM activities. The PM is a member of the OL SL CCB System Engineer Figure 1. OOI/CI Project Organization The System Engineer (SE) is the CI Configuration Management (CM) Manager with overall responsibility for managing the evolving configurations of the cyberinfrastructure system, and is responsible for Ver Page 2 of 29

7 evaluating proposed changes from the perspective of overall system impact. The System Engineer chairs the CI Configuration Change Board (CI CCB). He is also a member of the OL SL CCB. The SE develops, maintains, distributes, and controls this Configuration Management Plan (CMP) and associated standards and procedures for the CI project. The SE follows standard CM procedures for: 1. Assuring control of code, documentation, COTS and Customer furnished materials during development, and 2. Controlling the Software Engineering Environment (SEE) and Software Test Environment (STE), and preparing internal configuration reports as a part of developmental CM. The SE authorizes CM processes as documented in plans, standards, and procedures. He is the formal interface between the CM function and any external organizations. The SE is responsible for formal Functional Configuration Audit (FCA) and Physical Configuration Audits (PCA) of all developed software products. The SE controls the Project Repository, including reference materials, data archives, and associated files, for inventory control, storage, retrieval, status reporting, accountability, and archive/destruction. The SE manages the System Problem Reports (SPRs) and any reports related to corrective action Senior System Architect The Senior System Architect has responsibility for managing the evolving cyberinfrastructure system architecture and system design configurations, and is responsible for evaluating proposed architectural changes from the perspective of overall system impact System Development Manager The System Development Manager is responsible for controlling developmental CM. He establishes, controls and maintains the Engineer s Workspaces and the Engineering Library that consists of all source code, command lines, menu screens, PDL or other detailed design representation, unit test procedures and data, and CM procedures. Developmental control of software items begins after successful unit testing and continues until successful completion of integration testing and placement of the tested units under formal CM Library control. Control of documents that describe configuration items such as specifications, test plans, and test procedures, begins after each documentation item is completed, internally reviewed and approved, and placed under formal CM Library control Quality Manager The QM audits the CM process periodically to ensure that stated procedures are followed and effective. The QM controls a CI web page on Confluence that includes verifiable objective evidence that the CI Team is in fact following the Software Engineering Procedures System Development IPTs CM tasks are performed by members of the CI System Development Engineering staff, as well as by the SE. System Development Engineering reviews/analyzes Engineering Change Requests (ECRs) produced at the IPT level, develops appropriate implementations to fix reported problems, determines the effect of proposed changes, supports CI CCB requests for further analysis or investigation, and implements approved changes. System Development personnel perform CM tasks in accordance with the CI CMP. Software Engineering personnel are trained in the CM practices and procedures implemented by CM Project Analyst The Project Analyst provides assistance to the Project Manager in tracking and managing cost, schedule and scope of the project, and also serves as Secretary of the CI Configuration Control Board Financial Analyst The Financial Analyst maintains control of project cost and schedule data, monthly status reports, and all official contract correspondence. The Financial Analyst provides direct support to the CI CCB for all Class I change requests. Ver Page 3 of 29

8 Ocean Leadership Relationship to CI CM Organizations external to the CI project have the ability to affect its CM activities, either directly or indirectly. Various groups within the Ocean Observing Community may initiate and generate ECRs and submit them to the SL CCB whose content involves a potential change in cyberinfrastructure configuration items and elements. Impact on the CI CM activity can also occur in the form of specific mandates from the SL CCB that requires CM involvement. 2.3 Configuration Management Resources General facilities and office equipment are provided by UCSD or its subcontractors as part of the CI Project facility, which includes office computers, Microsoft Office, , and Internet access. For example, Microsoft Project is used to maintain the schedule for conducting CM activities as part of the CI Integrated Master Schedule (IMS), which is a server document that is updated monthly based on CI progress reports. The CI Program provides the System Development Environment (SEE) and the System Test Environment (STE) that includes file transfer facilities, code compare utilities, and other vital CM capabilities. Specific resources shown in Table 1 are used to perform and coordinate specific CM tasks. Refer to the CI PEP for a more detailed description of planned general project support tools and facilities. Table 1. Collaboration and Configuration Management Tools Tool Type Vendor Description Confluence Collaboration Atlassian Web-based collaborative environment / WIKI site JIRA Collaboration Altassian Action Item / Issue tracking system built on a relational database. Alfresco CM Alfresco Document Management and Workflow management software. Git CM Open source Software Version Control with source code repository/library, build/release control, status accounting, and access control Subversion CM Open source Document revision control for documents and drawings in progress that require revision control and archiving and offline editing capabilities. DOORS CM Telelogic Requirements Management and traceability built on an object-oriented database Enterprise Architect CM Sparxsystems Software architecture documentation The CI development occurs in multi-site, multi-contractor facilities. The development environments are networked and a single instance of the CM tool (Git) is located at UCSD to control the software. Synchronizing the versions and the development environment according to configuration management will be done by remote log-in and under strict control. For a complete description of the SEE and STE, refer to the OOI SEMP, Section The System Test Environment of CI will mirror the operational OOI environment as closely as possible Configuration Management Staffing Plan The SE serves as Configuration Manager Automated Configuration Management Tools The CI CM environment consists of computer-based CM tools. A brief description of the suite of CM tools that are used to support the CI appears in Table 1. Because of the multi-site nature of the development environment, the Git tool is used to ensure the integrity of the CM process. The software configuration management tools to be used by the CI project have been selected specifically to implement and enforce restrictions of the controlled items, thus making control of project materials Ver Page 4 of 29

9 significantly easier and more effective. The CM tools are used to: 1) enforce pre-determined access restrictions; 2) direct user class privileges; 3) perform data collection, retrieval, storage, and manipulation; 4) provide online reporting capabilities; and 5) facilitate electronic interaction between parties. The CM tools will support control of project materials by providing repositories for controlled items, controlling software code and other software materials, maintaining status accounting records, and providing Project Repository inventory management. All support tools, associated manuals and documentation, operating environments, and supporting software are under CM control. Training in the use of selected CM tools and their application to this project's environment is provided to all affected members of the project organization Software Development and Test Environments The SEE and STE facilitate the control of software, firmware, and documentation/data during development. Software items are developed, tested, and released as a software baseline with sufficient supporting documentation to permit re-establishment of a previous version. The CI software development and test environments are described in the OOI SEMP. The initial SEE/STE configurations and all changes are treated in the same manner as software items, and will be reviewed and approved by the CI ERB prior to implementation. In CI, both the SEE and STE are composed of NDI (COTS and Customer provided) elements. CM maintains an up-to-date record of the contents of each SEE/STE configuration. Support software for the SEE/STE is clearly labeled with the item name, version, and classification. The initial SEE/STE build includes both installation and checkout of the resulting environments. After initial installation and checkout, the SEE/STE configurations are placed under control and made available for development and testing. Changes to the environments and updates to individual COTS elements from changes released by the vendors are tracked and processed via the CI's developmental control process. 3 Configuration Identification The configuration identification process uniquely identifies the elements within the Cyberinfrastructure baseline configuration. This unique identification promotes the ability to create and maintain master inventory lists of baselines. As part of the System Engineering effort, the Cyberinfrastructure has been decomposed into five releases that are designated as configuration items and serve as the critical elements subjected to rigorous formal control. The compilation of all the configuration items is called the Configuration Item list. This list may reflect items that are developed, vendor produced, or provided by the customer for integration into the final system. These items may be deliverable items under the contract or enabling products used to produce the deliverable items. 3.1 Data Management All project materials that have the potential to influence project success are identified and controlled. Formal configuration items, i.e., deliverable software and hardware, and their associated descriptive documentation are identified and controlled as described in Section Scope of Data Management Other items, which the project plans to place under control as they become available throughout the life of the project, include: System Engineering Environment (SEE) System Test Environment (STE) The project Statement of Work (SOW). Bill of Materials (BOM) The standard software process tailored for project-unique requirements. Ver Page 5 of 29

10 The project's software process and software life cycle models, as defined and tailored in the OOI SEMP. Any waivers and/or deviations applied for and approved All project plans, e.g., PEP, SEMP, QA/QC Plan, Test Plans, and this CMP. Records of Project Reviews. System Problem Reports (SPRs), Modification Requests (MRs), Change Requests (CRs), and Engineering Change Requests (ECRs) Peer review and Formal Inspection comments/minutes. Documentation of any non-compliant items. Support software and tools. Customer Furnished Information and materials. Reference materials. Action item tracking list. Copies of project records that do not change and reference materials that the project utilizes are filed in the Project Repository Document Management Configuration Management is responsible for tracking and maintenance of all CI documents with version numbers and dates in accordance with the requirements for document management established by the OOI Configuration Management Plan. Documents such as project plans, test materials, user manuals, and training materials are prepared by the responsible project team under the supervision of the responsible technical lead/manager (i.e., the Software, Test, System Engineer, or QA Manager) and appropriately labeled/identified. The responsible OOI/CI Manager assures that corrections have been made for all of the identified problems after each deliverable item of documentation has successfully completed the appropriate scheduled peer review. Refer to the OOI Configuration Management Plan for instructions on how to classify documents, proper styles and formats, document change control, change request process, relevant terms, and definitions of information fields. Both deliverable and non-deliverable documentation items are placed under formal CM control and posted on the collaborative web site Formal Deliveries Documentation items and other deliverables that exist in electronic formats are electronically delivered to the OOI Program Office and posted on the appropriate collaboration site. The Cyberinfrastructure Program Contracts Manager submits an electronically signed transmittal letter electronically to accompany all deliverables. 3.2 Formal Configuration Items The OOI Cyberinfrastructure Project has identified numerous items that are subject to configuration management that is primarily software and hardware but also encompasses specifications, descriptions, plans, procedures, and other items as described in Table 2. The examples provided in the table are comprehensive but not exhaustive. Table 2. Cyberinfrastructure Configuration Items Category Specifications Category Purpose and Examples Specify a required function, performance, or process (e.g., requirements specification) Examples: L2 Cyber-User Requirements, L3 CI System Requirements, L3 CI-RSN Interface Requirements Specification, L3 CI-CG Interface Requirements Specification, L4 CI Subsystem Requirements. Hardware Specification Ver Page 6 of 29

11 Category Descriptions Plans Procedures Records Reports Requests Hardware Items COTS Software Category Purpose and Examples Describes a planned or actual function, design, performance, or process Examples: Concept of Operations Description, System Architecture Descriptions (i.e., DoDAF AVs, OVs, SVs, and TVs), Database Design Description, Hardware Architecture Description Defines when, how, and by whom specific activities are to be performed, including options and alternatives, as required Examples: Project Execution Plan, System Life Cycle Plan, Operations and Maintenance Plan, Configuration Management Plan, System Integration Plan, Quality Assurance Plan, Defines in detail when and how to perform certain jobs, including needed tools Examples: Test procedures, Validation Procedures, Process Procedures Describe the materials an organization retains (e.g., quality records, legal records, fiscal records, historical records) Examples: Source Code Record, Executable Object Code Record, Quality Assurance Records, Describes the results of activities such as investigations, assessments, and test Examples: Test Results Report, Validation Results Report, Problem Report, Problem Resolution Report, Records information needed to solicit a response Examples: Change Request, Modification Request, Commercial Off the Shelf Hardware Items Examples: CyberPop, hardware servers, workstations, routers, switches, etc. Commercial Off-the Shelf (COTS) Software Items Examples: Dynamic Object Oriented Requirements System (DOORS), JIRA, Confluence, etc. 3.3 Naming and Numbering Conventions The Cyberinfrastructure uses naming conventions for Hardware, Software, and information items in order to provide a unique identification for every item under Configuration Control Hardware Numbering Convention The naming convention for Cyberinfrastructure hardware is presented in Table 3, and specification of Site Numbers and Codes is in Table 4. This naming convention is applied to all CI hardware such as servers, routers, switches, and so forth. For Example: CI01POAP-CP00100-ROUTRA002 is the second model A router installed at the Portland Acquisition Point CyberPoP. CI09SAMP-CP00100-SUNWSB001 is the first model B Sun work station installed in the Seattle Management Point Table 3. Hardware Numbering Conventions Field Name Owner System Site Number Site Code Node Type Designator Description A 2 character alpha code CI that denotes the OOI/Cyberinfrastructure as the custodial system. A 2 character numeric code that denotes the site number for installation for installation A 4 character alpha code that provides a representation of the site name in abbreviated form A 2 character denoting the type of node (CP=CyberPoP, PL=platform) Ver Page 7 of 29

12 Node Site Sequence Port Number Hardware Class Hardware Model Hardware Sequence A 3 digit mixed alpha-numeric code sequentially number the nodes at a site A 2 digit numeric code that sequentially identifies the port on a node (typically not meaningful for CI and set to 00) A 5 character alpha-numeric code that represents a hardware category. A single character alpha code that denotes a specific model or series of hardware. A 3 digit numeric code that sequentially identifies hardware installed at the same location. Table 4. Site Numbers and Codes Site Name Site Number Site Code Portland Acquisition Point 01 POAP Woods Hole Acquisition Point 02 WHAP San Diego Distribution Point 03 SDDP Seattle Distribution Point 04 SADP McClean Distribution Point 05 MCDP San Diego Observatory 06 SDOE Engineering Center Corvallis Management Point 07 COMP San Diego Management Point 08 SDMP Seattle Management Point 09 SAMP Washington DC Management 10 WAMP Point Woods Hole Management Point 11 WHMP Amazon Execution Point 12 AMEP Microsoft Execution Point 13 MIEP Teragrid Execution Point 14 TGEP Open Science Grid Execution 15 OSEP Point Pioneer Array Marine Network 16 PAMP Endurance Array Marine 17 EAMP Network Station Papa Marine Network 18 SPMN Southern Ocean Marine Network 19 SOMN Irminger Sea Marine Network 20 ISMN Argentine Basin Marine Network 21 ABMN Hydrate Ridge Marine Network 22 HRMN Axial Marine Network 23 AXMN Deliverable Software Numbering Convention The naming convention for Cyberinfrastructure System Software is presented in Table 5. This naming convention is applied to all software that will be developed for, or incorporated into, the delivered Cyberinfrastructure System. It does apply to non-developmental items such as relational databases that are obtained from commercial sources. It does not apply to software that is obtained to support development activities such as requirements management systems, system design tools, compilers, debuggers, or configuration management tools. For Example: CI17EAMN-PL004DM-DC is the third revision for the 10th software unit in the 1st software component in the DC software element in the Data Management Subsystem installed in the 4th platform on the Endurance Array Table 5. Software Numbering Conventions Ver Page 8 of 29

13 Field Name Owner System Site Number Site Code Node Type Node Site Sequence Subsystem Software Element Software Component Software Unit Revision Designator Description A 2 character alpha code CI that denotes the OOI/Cyberinfrastructure A 2 character numeric code that denotes the site number for installation for installation A 4 character alpha code that provides a representation of the site name in abbreviated form A 2 character denoting the type of node (CP=CyberPoP, PL=platform) A 3 digit mixed alpha-numeric code that sequentially numbers the nodes at a site (e.g., the number of the platform in an array) A 2 character alpha code that represents the subsystem (AS=Analysis&Synthesis, PP=Planning&Prosecution, SA=Sensing&Acquisition, DM=Data Management, CO=Common Operating Infrastructure, CE=Common Execution Infrastructure) A 2 character alpha-numeric code that represents a software element A 2 character alpha-numeric code that denotes a software component A 2 character alpha-numeric code that denotes a software unit A 3 digit numeric code that sequentially identifies revisions to the software unit Non-Deliverable Software Numbering Convention Non-deliverable software is purchased to support system engineering, implementation, integration, and testing activities such as requirements management systems, system design tools, compilers, debuggers, and configuration management tools. These tools will not be subject to configuration control Information Item Numbering Convention The CI IO has established a naming convention for Information Items (e.g., documents, drawings, etc.) that is presented in Table 6 and applied to all information items generated as part of the CI System Development effort. The primary categories shown in the following bulleted list comply with the numbering series requirements established by the OOI CMP : Programmatic Documents : Systems Engineering Documents : Installation Documents : Subsystem Documents : Programmatic Drawings : Systems Engineering Drawings : Installation Drawings : Subsystem Drawings The four digit numbers presented in Table 6 that represent information item categories are concatenated with a five digit number that is assigned sequentially to form a complete Information Item number. For example, the DoDAF Operational View 2 (OV2) drawings for the Planning and Prosecution Subsystem would be , , etc. All CI controlled and released level Information items shall have a unique information item number assigned. The CI Configuration Manager shall assign and track the requests and issuance of the information item numbers. Table 6. Information Item Numbering Conventions Programmatic Documents (2000 series) 2010 Plans 2020 Reports Ver Page 9 of 29

14 2030 Business Operations (cost book, IMS, accounting) 2040 Risk and Opportunity Management 2050 Communication and Outreach 2060 Milestone Reviews Systems Engineering Documents (2100 series) 2110 Plans 2115 Source Documents 2120 Requirements and Interoperability 2130 DoDAF 2140 AV Design Docs 2150 OV Design Docs 2160 SV Design Docs 2170 TV Design Docs 2180 Change Control 2190 ILSP Installation Documents (2200 series) 2210 Integration and Test Plans 2220 Verification and Validation Plans 2230 Integration and Test Reports 2240 Verification and Validation Reports 2250 Instrument Agent Docs 2260 Coastal Deployment Docs 2270 Global Deployment Docs 2280 RSN Deployment Docs 2290 External Observatory Interface Docs Subsystem Documents ( series) 2310 Sensing & Acquisition Plans and Reports 2315 S&A Requirements 2320 S&A OV Docs 2325 S&A SV Docs 2330 S&A TV Docs 2335 S&A Technology Docs 2340 Analysis & Synthesis Plans and Reports 2345 A&S Requirements 2350 A&S OV Docs 2355 A&S SV Docs 2360 A&S TV Docs 2365 A&S Technology Docs 2370 Planning & Prosecution Plans and Reports 2375 P&P Requirements 2380 P&P OV Docs 2385 P&P SV Docs Ver Page 10 of 29

15 2390 P&P TV Docs 2395 P&P Technology Docs 2400 Data Management Plans and Reports 2405 DM Requirements 2410 DM OV Docs 2415 DM SV Docs 2420 DM TV Docs 2425 DM Technology Docs 2430 Common Operating Infrastructure Plans and Reports 2435 COI Requirements 2440 COI OV Docs 2445 COI SV Docs 2450 COI TV Docs 2455 COI Technology Docs 2460 Common Execution Infrastructure Plans and Reports 2465 CEI Requirements 2470 CEI OV Docs 2475 CEI SV Docs 2480 CEI TV Docs 2485 CEI Technology Docs Programmatic Drawings (2500 series) 2510 Plan Drawings 2520 Report Drawings 2530 Business Operations Drawings (cost book, IMS, accounting) 2540 Risk and Opportunity Management Drawings 2550 Communication and Outreach Drawings 2560 Milestone Review Drawings Systems Engineering Drawings (2600 series) 2610 Plan Drawings 2620 Requirements and Interoperability Drawings 2630 DoDAF Drawings 2640 AV Design Drawings 2650 OV Design Drawings 2660 SV Design Drawings 2670 TV Design Drawings 2680 Change Control Drawings 2690 ILSP Drawings Installation Drawings (2700 series) 2710 Integration and Test Plan Drawings 2720 Verification and Validation Plan Drawings 2730 Integration and Test Report Drawings 2740 Verification and Validation Report Drawings Ver Page 11 of 29

16 2750 Instrument Agent Drawings 2760 Coastal Deployment Drawings 2770 Global Deployment Drawings 2780 RSN Deployment Drawings 2790 External Observatory Interface Drawings Subsystem Drawings ( series) 2810 Sensing & Acquisition Plan and Report Drawings 2815 S&A Requirements Drawings 2820 S&A OV Drawings 2825 S&A SV Drawings 2830 S&A TV Drawings 2835 S&A Technology Drawings 2840 Analysis & Synthesis Plan and Report Drawings 2845 A&S Requirements Drawings 2850 A&S OV Drawings 2855 A&S SV Drawings 2865 A&S TV Drawings 2870 A&S Technology Drawings 2870 Planning & Prosecution Plan and Report Drawings 2875 P&P Requirements Drawings 2880 P&P OV Drawings 2885 P&P SV Drawings 2890 P&P TV Drawings 2895 P&P Technology Drawings 2900 Data Management Plan and Report Drawings 2905 DM Requirements Drawings 2910 DM OV Drawings 2915 DM SV Drawings 2920 DM TV Drawings 2925 DM Technology Drawings 2930 Common Operating Infrastructure Plan and Report Drawings 2935 COI Requirements Drawings 2940 COI OV Drawings 2945 COI SV Drawings 2950 COI TV Drawings 2955 COI Technology Drawings 2960 Common Execution Infrastructure Plan and Report Drawings 2965 CEI Requirements Drawings 2970 CEI OV Drawings 2975 CEI SV Drawings 2980 CEI TV Drawings 2985 CEI Technology Drawings Ver Page 12 of 29

17 3.3.5 File Naming Convention The unique Information Item number assigned to each information item shall be used to name all CI information item files, particularly those exchanged with the Marine IOs, the OOI Program Office, and in the preparation of any technical data package. File names shall begin with the Information Item number, followed by the information item name or acronym (if approved for use), and followed by the system designator CI. Underscores are used as separators, no spaces permitted in file names. A dash is used as part of the information item number. For example: _CMP_CI.doc This file naming convention complies with the naming convention in the OOI CMP and cannot be modified without Ocean Leadership approval. 3.4 Formal Baseline Establishment Identification Configuration identification includes establishing and maintaining baselines that define the system or subsystem configuration items at any point in time. Based on the program/system life cycle phase, different baselines are progressively established. CI uses configuration baselines as an integral configuration management concept. A baseline is defined as a snapshot of the products maturity between two Program phases; it therefore serves as both the completion stage of one Program phase and the initiation point of the following phase. The controlled baselines for the CI program include Functional Baseline Allocated Baseline Development Baseline Product Baseline Formal Baselines are typically established at project milestones, the most notable of which are the Formal Reviews that are the point of demarcation between the end of one system development activity and the beginning of another. Examples of these formal reviews include Preliminary Design Review (PDR), Final Design Review (FDR), Life Cycle Objective Review (LCAR), and Life Cycle Architecture Review (LCAR). Each of the following paragraphs identifies the Formal Reviews associated with each of the Baselines. However, this CMP does not provide details about the Formal Reviews CI Functional Baseline The Functional Baseline for the CI System applies to all software and hardware items where required functions are specified in a descriptive manner qualified by performance parameters. When authenticated and placed under configuration control, the following CI information items establish the CI Functional Baseline. CI Concept of Operations L2 Cyber-User Requirements L3 CI System Requirements L3 CI RSN Interface Requirements Specification L3 CI CG Interface Requirements Specification L4 CI Subsystem Requirements The CI Functional Baseline is initially established at the OOI System Requirements Review (SRR) and subsequently updated at the OOI Preliminary Design Review (PDR) and OOI Final Design Review (FDR). During each increment of the CI Spiral Development, the CI Functional Baseline is revisited during the Inception Phase and updated at the Life Cycle Objective Review (LCOR). Ver Page 13 of 29

18 3.4.2 CI Allocated Baseline CI Configuration Management Plan The Allocated Baseline for the CI System applies to all software and hardware items where requirements from the Functional Baseline are allocated to elements of the system architecture and the system design is provided in a descriptive manner. When authenticated and placed under configuration control, the following CI information items establish the CI Allocated Baseline. DoDAF All Views (AVs) DoDAF Operational Views (OVs) DoDAF System Views (SVs) DoDAF Technical Views (TVs) The CI Allocated Baseline is initially established at the OOI Preliminary Design Review (PDR) and subsequently updated at the OOI Final Design Review (FDR). During each Increment of the CI Spiral Development, the CI Allocated Baseline is revisited during the Elaboration Phase and updated at the Life Cycle Architecture Review (LCAR) CI Development Baseline The Development Baseline for the CI System applies to all software and hardware items where the Functional Baseline and the Allocated Baseline guide the implementation of the system. When authenticated and placed under configuration control, the following CI information items establish the CI Allocated Baseline. Database design description Source code record Executable object code record Test or validation procedures Software verification results report Test or validation results report User documentation description The CI Development Baseline is initially established at the beginning of the Construction Phase in the first Increment of the CI Spiral Development and grown in small steps during the Construction Phase until it reaches the planned level of maturity for the increment, culminating with the Initial Operating Capability Review (IOCR). During each subsequent Increment of the CI Spiral Development, the CI Development Baseline is grown in small steps during the Construction Phase culminating with the Incremental IOCR CI Product Baseline The Product Baseline for the CI System applies to all software and hardware items where the Developmental Baseline has been evolved to reflect the as built End Products and provided in a descriptive manner. When authenticated and placed under configuration control, the following CI information items establish the CI Product Baseline. As Built CI Concept of Operations As Built L2 Cyber-User Requirements As Built L3CI System Requirements As Built L3CI-RSN Interface Agreement As Built L3 CI-CG Interface Agreement As Built L4 CI Subsystem Requirements As Built DoDAF All Views (AVs) As Built DoDAF Operational Views (OVs) As Built DoDAF System Views (SVs) As Built DoDAF Technical Views (TVs) As Built Database design description As Built Source code record Ver Page 14 of 29

19 As Built Executable object code record As Built Test or validation procedures As Built Software verification results report As Built Test or validation results report As Built User documentation description The CI Product Baseline is initially established at the end of the first increment of the CI Spiral Development at the first CI Product Readiness Review (PRR). During each subsequent increment of the CI Spiral Development, the CI Product Baseline is revisited during the Transition Phase and updated at the Incremental PRR OOI Product Baseline The Product Baseline for the OOI System-of-Systems is established by integration of the Cyberinfrastructure, Regional Observatory, and Coastal /Global Observatory Product baselines and ensuring the OOI Product Baseline is ready for operational testing through the Operational Testing Readiness Review (OTRR). 4 Change Control Managing the collection of items to be baselined is another aspect of configuration management. Configuration control maintains the integrity of the configuration items identified by facilitating approved changes (e.g. via engineering change requests) and preventing the incorporation of unapproved changes into the baseline. Change control should be in effect beginning at project initiation. 4.1 Engineering Change Classes All engineering changes to the established Baselines shall be categorized by CI as Class I, II, or III as defined below. Class I and Class II changes may be included within the same System Problem Report (SPR). However, should this be the case, each document identified by the SPR must identify the appropriate class Class I A Class I Engineering Change modifies an established Functional, Allocated, and/or Product technical baseline with cost and schedule impacts above established cost and schedule thresholds. Customer approval must be obtained before the change can be introduced. a) Affects any physical or functional requirement in baselined configuration documentation, (form, fit and function as related to a requirement), 1) Technical requirements and specifications that affect reliability, maintainability, availability, form, fit, function or interface characteristics 2) Interchangeability, substitutability, or replaceability as applied to configuration items and to all subassemblies and parts of repairable configuration items b) Affects any approved functional, allocated or product configuration documentation, cost, warranties, or contract milestones, 1) Cost to the OOI program in excess of $25,000 per control account, singular and cumulative per control account 2) Schedule to the OOI program in excess of 4 weeks increase in work package schedule, singular and cumulative per control account c) Affects approved product configuration documentation and one or more of the following: 1) Safety, correction of a hazard or conformance to applicable design standards, 2) Compatibility, interoperability, interfaces, or logistic support, 3) Retrofit of tested or delivered units, 4) Interchangeability, substitutability, or replaceability of any item down to non-repairable subassemblies, 5) Sources on a source control drawing Ver Page 15 of 29

20 d) Affects system configuration to the extent that retrofit (replacement of components) action would be taken on a formally tested or commissioned component Class II A Class II Engineering Change modifies an established Functional, Allocated, and/or Product Baseline without cost and schedule impacts or with cost and schedule impacts below established thresholds. Customer must be notified of the change after it has been introduced. a) Minor in nature, such that the cost of processing the change request may equal or exceed the cost of performing the work, b) Do not exceed any single difference of 10% of the control account baseline budget or $25,000 between a control account estimate to complete and the baseline budget to complete, whichever is lower, c) EVM items, task level or lower, under the management of a CAM. 4.2 System Problem Reports (SPR) CI uses the System Problem Report (SPR) form, which is exactly the same as the OOI Engineering Change Request (ECR) form with a couple of minor modifications to distinguish between a Modification Request (MR) and a Change Request (CR). Modification Requests (MRs) indicate the system design, implementation, or performance does not comply with baselined requirements. This means that after a work product has exited from a process activity, it is found to be non-compliant. This causes rework of affected work products, which is the responsibility of the contractor. A certain percentage of rework is normal and is allowed for in the original estimates. Change Requests (CRs) indicate the system design, implementation, and performance comply with baselined requirements, but the customer desires a change in the baselined requirements. This causes breakage of work products due to requirements changes, which is the responsibility of the customer - additional funding (or an equitable adjustment) is needed. This minor nuance catalyzes the tracking of breakage versus rework and an easier identification and tracking of defects. 4.3 Defect Tracking The major difference between a CR and an MR is that Modification Requests are the primary vehicle for the identification and tracking of defects while CRs are not considered as defects. The Incremental Spiral Development Life Cycle methodology does not consider a divergence between the system requirements and the system implementation to be a defect during the Inception, Elaboration, or Construction Phases. However, after the system has passed the Initial Operating Capability Review (IOCR), any non-compliance with the baselined requirements is considered and counted as a defect. A System Problem Report (SPR) is used to document the deviation and request a modification to correct the deviation. The Modification Request is tracked to closure. 4.4 Change Control Boards Ocean Leadership and the Cyberinfrastructure Project have established the three separate configuration review boards named in the following list that are organized and operated in a hierarchical manner, as shown in Figure 2. As denoted in the following paragraphs, a chairperson who acts as facilitator has been designated for each of the review boards along with the required membership. CI Configuration Control Board (CI CCB) System Level Configuration Control Board (SL CCB) Ver Page 16 of 29

21 OOI Configuration Control Board (OOI CCB) CI Configuration Control Board (ERB): The CI System Engineer is the CI CCB Chair and the Project Analyst is the board Secretary who is a nonvoting member of the board. As Configuration Manager, the SE tracks the status of ECRs, forwarding them to the Secretary when complete and ready for board review. The Secretary schedules CI CCB meetings, ensures that all necessary documentation is available to the board at least one week prior to the meeting, and keeps the minutes and action items for each meeting. Board membership consists of the Executive Management Team and the System Engineering Team (Sections and 2.2.2). This group is divided into two types of CI CCB members. The core CI CCB membership consists of the Project Director, Deputy Project Director, Project Manager, System Engineer, Quality Manager, Senior System Architect, System Development Manager and Operations Manager. Each person has a single vote, and a quorum of 66% of the core members (except for the Project Director and Deputy Project Director, who collectively count as a single member for the purpose of achieving a quorum) must be present to hold a board meeting. The remaining members of the Executive Management Team (Project Scientist, Chief Architect and EPE Manager) may attend CI CCB meetings at their discretion, and will be able to vote if present. The Chair will request their attendance when issues that he believes to require their advice are under consideration. If a board member cannot attend a given meeting, then he/she should forward their comments and vote in advance of the meeting to the Secretary, who will provide the comments to the board and hold the vote in confidence until the remainder of the board has voted. An absentee member does count toward the board quorum. Under unusual circumstances, a board member may appoint an alternate from within the project who is not already a member of the board, and the alternate may vote for the member. For Class II changes that do not affect the project cost, schedule or scope baselines (such as revisions to projectc plans), an vote by a quorum of the CI CCB will be allowed. All board attendees are expected to review the issues before the board in advance of the meeting and formulate a list of comments or issues for consideration by the entire board. The originator of an ECR will collect the comments and issues in advance of a board meeting, and attempt to reconcile any conflicts in order to formulate a clear recommendation to the board. The ECR originator will attend the CI CCB meeting if not already a member, and present the ECR and recommendations to the board for further discussion prior to the vote. The IO CCB s roles and responsibilities include: 1. Track, review, evaluate and document all requested changes and board actions. 2. Ensure requested change is beneficial to the system. 3. Evaluate alternatives that would achieve the same results. 4. Evaluate all impacts and their effect on scope, cost, and schedule. 5. Approve or reject requests for change. 6. Document the approved change, and communicate decisions to all stakeholders. 7. Ensure the EVMS system is appropriately updated when a change has been approved. 8. Track and report the cost and schedule changes to the COTR and OOI Program Office. 9. Forward all IO approved Class I ECRs to the System Level CCB for review and approval. 10. Notification of System Level CCB and provision of documentation for all IO approved Class II ECRs (notification only, not for approval). Ver Page 17 of 29

22 CI Configuration Management Plan Figure 2. Change Control Flow System Level Configuration Control Board (SL CCB): The SL CCB is chaired by the OOI System Engineer and is chartered to approve or reject all Class I changes to the OOI System-of-Systems technical, cost and schedule baselines, as well as changes that have an impact between the systems (i.e., Coastal, Global, Regional, and Cyberinfrastructure). The OOI Project Manager, OOI Contract Officers Technical Representatives (COTR), OOI Associate Director (Science), OOI Quality Representative and the IO Project Managers, Designated Project Scientists and System Engineers are members of the SL CCB. OOI Configuration Control Board (OOI CCB): The OOI CCB is chaired by the OOI Program Director and is chartered to approve or reject all Class I changes that require a change to OOI Guiding Principles, Science Traceability and related scope. The OOI Project Director, OOI Project Manager, OOI System Engineer, OOI Associate Director (Science) and the IO Project Directors are members of the OOI CCB. 4.5 Change Control Flow Referring once again to Figure 2, CI Change Control begins with a member of the technical staff using a System Problem Report (SPR) to generate a Modification Request (MR). In most instances this is the result of a Quality Control activity such as an inspection or formal test of some sort that has exposed a non-compliance with baselined requirements. However, an MR can also be generated to highlight an opportunity. The MR is presented to the ERB. The review board assigns an analyst to the MR who performs an initial analysis of the impacts to the system in terms of cost, schedule, function, and performance and returns the assessment and recommendations to the review board. The review board can reject the modification, approve the MR if it is a Class III change, or advance the MR to the PRB if it is a Class I or II change. Upon receiving a Class I or II MR from the ERB, the PRB may request additional analysis if the initial analysis is deemed insufficient. The PRB can reject the modification, approve the MR if it is a Class II change, or advance the MR to the System Level if it is a Class I change. When advancing the MR to the Ver Page 18 of 29

23 System Level, the OOI Engineering Change Request (ECR) is used in compliance with the OOI CMP. If the impact of the MR is limited to the CI System, the ECR should be placed on the agenda of the SL CCB. Upon receiving a Class I change from the CI CCB, the SL CCB or SL ICWG may request additional analysis if the supporting analysis is deemed insufficient. The SL CCB/ICWG may need to consult with NSF as detailed in the OOI CMP. The SL CCB/ICWG can reject the ECR or approve it. If the ECR is approved, the SL CCB/ICWG will request the preparation of an Engineering Change Proposal (ECP) that details the technical modifications to be made along with the associated cost and schedule impacts. The ECP is prepared by the Implementing Organizations with each IO contributing in accordance with the relative modifications that will occur in their system. The SL CCB/ICWG may reject or approve the ECP. If the ECP is approved, it is provided to the Implementing Organizations for execution. 4.6 Control of the Development Baseline Control of the evolving Developmental Baseline is necessary to provide coordination and control over developing software and software materials. The Cyberinfrastructure Software Development Manager manages items under development and is responsible for reviewing software changes, test results, and documents. Software items and their corresponding Software Development Files (SDFs) are initially placed under developmental control when all code walkthrough comments have been closed and unit testing has been successfully completed. Software items are promoted from developmental control to formal CM control when the software items are successfully integrated, tested, and released. Documentation associated with the software items is promoted from developmental control to formal CM control when it has been updated and approved by either the CI ERB. All formally controlled Cyberinfrastructure Baselines (i.e., Functional, Allocated, Developmental, and Product) remain under CI internal project CM control during the entire OOI System Development Life Cycle. However, formal control of the Product Baseline transfers to the OOI Program Office with the SL CCB acting as its agent after formal acceptance of the Initial Operational Capability (IOC) at Release Developmental Controlled Item Identification The Cyberinfrastructure Engineering Library embraces the design, code, and test materials. The Developmental Baseline is internal to CI and is established to facilitate control of internal development activities. Items of the Developmental Baseline will be placed under control when they are internally reviewed and approved by peers. Software units will complete unit testing prior to being placed under control. Each item under development will be identified with a unique identifier, as outline in Section The CI Subsystem Development IPTs are responsible for all design materials and software modules/units. The System Integration and System Test Teams are responsible for all materials required to support formal testing, (Test Plans, the Software Test Description, Test Procedures, Test Data, and Test Result Reports) System Development Libraries (SDL) Developmental items are controlled using a logical three-tiered object-based System Development Library (SDL) library process (Figure 3) and electronic versions of controlled project materials. The System Development Libraries are segments of the CI Project Repository. They consist of Engineer s Workspace, the Engineering Library, and the CM Library. The Git CM tool 1. Accepts data based on established criteria; 2. Records relationships between controlled units/modules/packages; 3. Schedules changes; 4. Embeds changed items with change identifier(s); 5. Associates changes with its change documentation; 6. Supports audits; and 7. Performs backups and archiving. Ver Page 19 of 29

24 All controlled configuration and non-configuration items (process artifacts, contract-related documents, etc.) will be controlled in electronic manifestations. Engineer Controlled IPT Lead Controlled CM Controlled (Software Development Manager) Engineer s Workspace Engineering Library CM Library OOI/CI -Aug08 -FDR-031 Code and Unit Test Software Integration and Testing - Informal Testing Formal Test and Release Tier 1 Tier 2 Tier 3 Figure 3. System Development Libraries (SDLs) The CI CM Manager is responsible for establishing the multi-tiered, System Development Library system. The libraries themselves are controlled items. The Engineering and CM Libraries are logical elements of the Git library system. The engineers workspaces contain the resources required to perform their assigned tasks and are controlled by the engineer. The Subsystem Development IPT Leads controls the Engineering Library which is a repository for: 1) in-process and approved products requiring read access by multiple users, such as review material; 2) other work products requiring coordinated support, regular backup and offsite storage, such as soft copy Software Development Files; 3) support software and tools; 4) data files; and 5) all machine-readable portions of the software baseline. The CM Manager controls the CM Library under the guidance of the Software Development Manger. It contains the code and associated design and test documentation that has been formally tested and released for formal CM control System Development Library Access As shown in Table 7, the individual developers control the engineers workspaces; the Subsystem Development IPT Leads control the Engineering Library; and CM controls user access to the CM Library. All items within the Engineering Library are available as read-only to all project entities. Only the Subsystem Development IPT Leads have write access to the Engineering Library and only the CM Manager has write-access authority to the CM Library. The Git tool provides engineering Library control. The System Development Library supports multiple levels of change control simultaneously through its multi-tiered structure. Software baselines are created and maintained by CM from controlled software items and their specifications in the CM Library, as authorized by the CI ERB. Table 6. System Development Library Accesses Characteristics Engineer s Library Engineering Library CM Library Entry Criteria Design Approved by Successful Unit Test ERB Design information items consistent with code Configuration item integration complete No Significant defects open Read Access Everyone Everyone Everyone Approval Authority ERB for Changes Developer can make any changes that are consistent with approved design Subsystem Development IPT Leads can approve any changes that are consistent with baselined requirements and has no significant cost or schedule impacts Write Access Developer Subsystem Development IPT Lead or CM Ver Page 20 of 29

25 Problem Tracking Responsibility Status Accounting Responsibility Promotion Criteria Developer Developer Successful Unit Test designated representative Subsystem Development IPT Lead or designated representative Subsystem Development IPT Lead or designated representative Software item integration complete CM CM Design information items consistent with code No significant defects open System Development Library Environment When a product has been matured to an acceptable level at one tier, it is promoted and processed through the next tier in accordance with rules that are illustrated in Figure 4, which adhere to established directory permissions to support and enforce these rules. Step 1: Software is promoted from lower level library to the In Box (A) at the higher level Step 2: Software is placed in Controlled Storage Area (B) after quality check Step 3: Software is copied from Controlled Storage Area (B) into Integration Area (C ) for integration, testing, etc. Step 4: Previous Step 3 generates MRs Software that contains defects is trashed Step 5: Software is copied from Controlled Storage Area (B) into Controlled Work Area (D) and modified in response to the MRs Step 6: Updated Software is placed into Level 3 In Box (A) for quality check Step 7: Process is repeated until all software has been completely integrated and all defects removed. CM Library Tier 3 C 4 - MRs 5 3 B Level 3 B Level D A D A Engineering Library Author's Library Tier 2 Tier 1 Systems Engineering Software Engineering Test Engineering Legend A. In Box area B. Controlled Storage Area C. Integration Area D. Controlled Work Area OOI/CI -Aug08 -FDR-030 Figure 4. Levels of Control The Engineering and CM Libraries reside on a hardware server at UCSD as a part of the Git tool and meet general CM requirements. Primary engineers workspaces reside on this same hardware platform, although both developers and testers will make use of PCs to generate associated documentation. The promotion of materials from the engineers workspaces to the Engineering and CM Libraries is facilitated because the Libraries reside within the Git tool. Documents developed in a PC environment are saved and entered into Git for control within the System Development Library structure. Ver Page 21 of 29

26 System Development Library Maintenance CI Configuration Management Plan After initial installation and checkout of the backup/restore system, full system backups are performed weekly with rules for retaining backups to be determined. Incremental backups of changed/modified project files are performed on a daily basis between full backups. The backup media (type to be determined) will be stored in a secure area, the specific cabinet/site to be determined. Backups will be performed in accordance with procedures structured for the multi-site development. The System Administrator will accomplish these procedures. Software and hardware upgrades include upgrades to their related manuals, e.g., operator manuals. System restores and system upgrades are performed by the CM Manager/System Administrator, as approved by the CI ERB. System restores are performed in accordance with procedures, the specifics of which are to be developed. The System Administrator performs routine maintenance and tuning of the Engineering Library hardware and software. Backup and restore procedures are thoroughly tested prior to activation of the System Development Libraries within the System Development Environment (SDE). 5 Configuration Status Accounting Configuration Status Accounting (CSA) is performed by CM to record and report information to management. CM maintains a status of approved documentation that identifies and defines the functional and physical characteristics, status of proposed changes, and status of approved changes. Status Accounting synthesizes the output of Configuration Identification and Change Control. All changes authorized by the configuration review boards (overall and subordinate) culminate in a comprehensive traceability of all transactions. Such activities as check-in and check-out of source code, builds of configuration items, deviations of manufactured items, waiver status are part of the status tracking. By statusing and tracking project changes, a gradual change from the build-to to the as-built configuration is captured. 5.1 CSA Process The purpose of the CSA process is to facilitate project management and technical lead ability to identify, produce, inspect, deliver, operate, and maintain controlled materials in a timely and efficient manner. CI CSA activities include: Development and documentation of specific procedures for using and maintaining the CI CM database. Implementation of status accounting procedures at the required time, including a system of CSA Reports (CSARs) to document problems, proposed changes, and modifications to software and documentation items under control. CSARs will be prepared and distributed monthly, at the beginning of the project; biweekly, as project activities increase; and if needed, weekly, as releases are prepared and/or the project nears an end. These reports are distributed to PM, Systems Engineering, Software Engineering, Quality Assurance, Test Engineering, and all technical leads. The same reports are also available to the OOI Program Office, if desired. 5.2 CSA Information Management Systems CSA is accomplished utilizing the facilities of the Git, DOORS, System Architect, and JIRA tools that reside and operate on servers at UCSD. 5.3 CSA Data Overview The CSA system maintains standardized records of the most current versions of the information items which describe the controlled items and their component parts, and maintains a record of the most current identification numbers. Specific information is entered into the CSA system (Git) when the item is first placed under formal control and is updated as changes are approved and applied. Where multiple configurations configuration threads are being simultaneously maintained, the system Ver Page 22 of 29

27 identifies all currently approved documentation and identification numbers for those configurations. The status of each allocated system/software requirement is tracked via a traceability matrix, which is also maintained under formal change control. The CSA system is used: 1) To monitor and track all reporting documentation (SPRs, ECRs, Deviations, and Waivers); 2) To report review board activities; 3) To track action items; 4) To record audit results; and 5) To maintain listings of controlled items. Other information and reports provided include change activities that track the total number of changes over time from each major source, including total number of changes proposed, open, approved, and incorporated into controlled items. Requirements of the CSA apply to associate contractors (teammates), vendors, and suppliers. Data maintained are sufficient to make known the status of controlled items at any time and to support the recovery of a previous version. 5.4 CSA Reports CM establishes and maintains the data required to report the status of all controlled items. This data is resident and maintained in the DOORS, Enterprise Architect, Git, and JIRA tools. The data, as well as the format of the CI CSARs, are identified in the following paragraphs in this section. CI CSARs include the following reports as a minimum: Requirements Change Reports The Dynamic Object Oriented Requirements System (DOORS) manages the system requirements at all levels from a configuration management perspective. Each requirement is entered into the DOORS database as an object, objects are grouped into formal modules, and a formal module is the equivalent of a Requirements Specification Document. Links between requirements objects are established to create and maintain the Requirements Traceability Matrix. DOORS maintains records for each of the formal modules (i.e., requirements specifications) used for CI to describe and control the performance and/or design of the CI System, Subsystems, and Elements. The records maintained by DOORS for each module contains a complete change history for the module and a complete change history for each object (i.e., requirement) within the module. Capabilities are provided to generate a wide variety of reports based on this information Software Version Level and History Git establishes and maintains records for each item of software purchased or developed and maintained as a part of, or in support of, the CI system. The records include 1) the software unit's identifier; 2) the related software specification number and title; 3) the software title; 4) the current version and interim version level; 5) where applicable, the ECR number authorizing the change; 6) the identifier of change document (System Problem Report) describing the detailed change to the software and associated documentation; 7) the effective release date of the current version; 8) the number, title, version, and date for the current Software Programmers Manuals; 9) the number, title, version, and date for the current test procedures; 10) the current part number for the software/medium combination; 11) the contract number; and 12) the Contract Data Requirements List (CDRL) number. Git also maintains a historical file of the software version level and interim version of the software from the date of initial release of the software through the current version Software Component Listing Git establishes and maintains records identifying the CI system software components by name and identifier. The record identifies the number and name of all source code and object code components and units that comprise the system. The CSA process documents the initial approved configuration of the CI system and facilitates comparison between the implementation of each approved change and the Ver Page 23 of 29

28 authorizing documentation, such as the SPR or ECP. A historical record documenting all the changes that have been approved is established and kept current Change Documentation Tracking Git maintains historical records documenting all the changes that have been approved and can generate a variety of reports based on the information System Problem Report (SPR) Status Accounting Git provides reporting capabilities on all SPR data from initiation to verification and final closure. CSA reports follow a standardized format and are distributed to affected lead project personnel. The method used to collect and report on change is addressed in Section 5.3, CSA Data Overview. Project and CM staff typically access the project's SPR system online to: 1) identify the current, approved configuration; 2) report found problems and propose new changes; 3) facilitate configuration review board problem/change review and analysis; 4) enter cost, schedule, and technical impact assessments for analysis and tracking; 5) document all approved and implemented changes to controlled items; and 6) record other related activities. An SPR is completed on-line using the Git configuration management tool Software Build Deliveries Git documents the exact delivered configuration of each unit, as well as certain specifically identified critical components of each unit, and tracks changes to the configuration of each unit and component. The CSA identifies the total number of units and the version of the units included in a specific software configuration Action Items JIRA tracks action items established as part of project reviews, formal reviews, formal audits, FCAs and PCAs. The action items are maintained in a historical file throughout the life of the project. 6 Configuration Audits Configuration audits are performed independently by CM and product assurance to evaluate the evolution of a product to ensure compliance to specifications, policies, and contractual agreements. Formal audits are performed at the completion of a product development cycle. They are the Functional and Physical Configuration Audits. 6.1 Functional Configuration Audit The Functional Configuration Audit (FCA) is intended to validate that the development of a configuration item has been completed and it has achieved the performance and functional characteristics specified in the System Specification (functional baseline). 6.2 Physical Configuration Audit The Physical Configuration Audit (PCA) is a technical review of the configuration item to verify the asbuilt maps to the technical documentation. 6.3 Configuration Management Audits The Configuration Management group performs periodic in-process audits to ensure that system and software development groups are following the configuration management process. Ver Page 24 of 29

29 6.4 Quality Assurance Audits CI Configuration Management Plan The Quality Assurance g group performs periodic in-process audits to ensure that system and software development groups are following the configuration management process. Ver Page 25 of 29

30 7 Glossary of Abbreviations and Acronyms Acronym AC ACEIT ACWP AI ATP AUW BAC BCR BCWP BCWS C&A CA CAIV CAM CAP CCB CDR CDRL CFE CFP CFSR CI CI CIO CLIN CMMI CMP CMT COE COL CONOPS COTS CPI CPR CSCI CWBS DID DOORS DR EAC ECR Definition Accomplishment Criteria Advanced Cost Estimating Integrated Tools Actual Cost of Work Performed Action Item Authority to Proceed Authorized Un-priced Work Budget At Completion Baseline Change Request Budgeted Cost of Work Performed Budgeted Cost of Work Scheduled Certification and Accreditation Control Account Cost as An Independent Variable Cost Account Manager Contractor Acquired Property Change Control Board Critical Design Review Contract Data Requirements List Customer Furnished Equipment Customer Furnished Property Contract Fund Status Report Configuration Item (Do Not Use See HWCI, HI, CSCI, or SI) Cyberinfrastructure (Do Not Use See OOI/CI) Chief Information Officer Contract Line Item Number Capability Maturity Model Integration Configuration Management Plan Core Management Team Common Operating Environment Consortium for Ocean Leadership Concept of Operations Commercial Off The Shelf Cost Performance Index Cost Performance Report Computer Software Configuration Item Cost Work Breakdown Structure Data Item Description Dynamic Object Oriented Requirements System Discrepancy Report Estimate at Completion Engineering Change Request Ver Page 26 of 29

31 Acronym EDI EMD EMT ERB EV EVMS FAR FOC FQT FY HI HWCI I&T IA IAP IBR ICD ICWG ILS IMP IMS IOC IOOS IPPD IPT IS IT KPR LCA LCC LCCE LCO LRE MA MOSA MP MPP NSF O&S OOI/CI PDR PEP PIA PKI PM Definition Electronic Data Interchange Engineering and Manufacturing Development Executive Management Team Engineering Review Board Earned Value Earned Value Management System Federal Acquisition Regulation Full Operational Capacity Factory Qualification Test Fiscal Year Hardware Item Hardware Configuration Item Integration and Test Information Assurance Information Assurance Plan Integrated Baseline Review Interface Control Document Interface Control Working Group Integrated Logistics Support Integrated Master Plan Integrated Master Schedule Initial Operational Capacity Integrated Ocean Observing System Integrated Product and Process Development Integrated Product Team Information Systems Information Technology Key Program Reviews Life Cycle Architecture Life Cycle Cost Life Cycle Cost Estimate Life Cycle Objective Latest Revised Estimate Mission Assurance Modular Open Systems Approach Metric Plan Master Phasing Plan National Science Foundation Operations and Sustainment Ocean Observing Initiative / Cyberinfrastructure Preliminary Design Review Program Execution Plan Program Independent Assessment Public Key Infrastructure Program Manager Ver Page 27 of 29

32 Acronym PMB PMP PMR POC PRB PSM PSRR PWA QA QAP QFD QPI RE RFC RFP RMP ROM ROMB SA SAT SCA SCM SDP SDR SDRL SE SEMP SI SMP SMT SOO SOW SPI SRR SSDR SWA TCPI TIM TPM TRD TRR TVP UB UIS VDT Definition Performance Management Baseline Program Management Plan Program Management Review Point of Contact Project Review Board Program Subcontract Manager Pre-Ship Readiness Review Primary Work Authorization Quality Assurance Quality Assurance Plan Quality Function Deployment Quality Performance Index Responsible Engineer Request for Change Request for Proposal Risk Management Plan Rough Order of Magnitude Risk & Opportunity Management Board Significant Accomplishment Site Acceptance Test Subcontract Administrator Supply Chain Management Software Development Plan System Design Review Subcontractor Data Requirements List Systems Engineering Systems Engineering Management Plan Software Item Subcontract Management Plan Subcontract Management Team Statement of Objectives Statement of Work Schedule Performance Index System Requirement Review System/Segment Design Review Secondary Work Authorization To Complete Performance Index Technical Interchange Meeting Technical Performance Measurement Technical Requirements Document Test Readiness Review Test and Verification Plan Undistributed Budget User Interface Specifications Visual Display Terminals Ver Page 28 of 29

33 Acronym WBS WG WLI WP Definition Work Breakdown Structure Working Group Watch List Item Work Package Ver Page 29 of 29

34 Ver Appendix Page A-1