Configuration Management Process Training

1. Configuration Management Process Training Process for identifying and managing the configuration and baselines of the software products

2. Agenda

3. Software Processes • The SEPG has developed the following processes: • GRC-SW-7150.3 - Software Project Planning • GRC-SW-7150.4 - Software Project Monitoring and Control • GRC-SW-7150.5 - Requirements Development • GRC-SW-7150.6 - Requirements Management • GRC-SW-7150.8 - Software Measurement • GRC-SW-7150.9 - Software Configuration Management • GRC-SW-7150.10 - Transition SW to a Higher Class • GRC-SW-7150.12 - Formal Inspection and Peer Review • GRC-SW-7150.14 - Software Acquisition SOW Guideline (being updated) • GRC-SW-7150.15 - Software Acquisition Planning • GRC-SW-7150.16 - Software Estimating • GRC-SW-7150.17 - Software Safety Planning • These are available on Software@Glenn.

4. Software Documentation Templates • The SEPG has developed the following document templates: • GRC-SW-TPLT-SMP - Software Management Plan Template • GRC-SW-TPLT-SRS - Software Requirements Specification Template • GRC-SW-TPLT-RTM - Requirements Traceability Matrix Template • GRC-SW-TPLT-SCMP - Software Configuration Management Plan Template • Software Change Request/Problem Report • GRC-SW-TPLT-MMS – Master Metrics Spreadsheet • GRC-SW-TPLT-SDD - Software Design Description Template • GRC-SW-TPLT-IDD - Interface Design Description Template • GRC-SW-TPLT-STP - Software Test Plan Template • GRC-SW-TPLT-STPr - Software Test Procedure Template • GRC-SW-TPLT-STR - Software Test Report Template • GRC-SW-TPLT-SVD - Software Version Description Template • GRC-SW-TPLT-SUM - Software Users Manual Template • GRC-SW-TPLT-SMntP - Software Maintenance Plan Template • GRC-SW-TPLT-SSP - Software Safety Plan Template • GRC-SW-TPLT-SSCA - Software Safety Criticality Assessment (new) • These are available on Software@Glenn. • They are Word documents except for the Master Metrics SS.

5. Configuration Management • This process was developed for controlling software through configuration management (CM). • Software configuration management (SCM) is essential to maintain the integrity of software configuration items and baselines throughout their development. • Software CM includes all products associated with the software development effort including, but not limited to, documentation, source code, executables, and build plans. • The process provides guidance for the development of a Software Configuration Management Plan (SCMP) and establishes a software version repository. • The SCMP may be included in the Software Management Plan (SMP) or the project CM plan at the discretion of the Software Project Lead or the Project Manager. • Establishing and implementing a SCM system • Use this process as soon as customer requirements and a SMP are in place. • All steps are performed by the Software Project Lead and/or Software Configuration Manager unless specified otherwise. • Implements NPR 7150.2B SWE-079, SWE-080, SWE-081, SWE-082, SWE-083, SWE-084, SWE-085, SWE-146, SWE-149 • Implements CMMI’s Configuration Management Specific Practices: CM SP 1.1, CM SP 1.2, CM SP 2.1, CM SP 3.1, CM SP 3.2, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6

6. Configuration Management

7. Configuration Management Identify data and software configuration items(6.1) •  The Software Project Lead identifies the data and software configuration items that are to be controlled for the project.  The lead identifies all of the items, such as data, software, documentation, and tools  that will be configuration managed for the project. • Items to be considered for management through this process: • Project Documentation • Source and Executable Files • Build Procedures and Processes • Processing Environment and Support Tools • Review Documentation and Results • Test Results • Change Requests and Problem Reports • Metrics

8. Configuration Management Plan the configuration baselines(6.2) • The Software Project Lead plans the configuration baselines for the project.  Configuration baselines are planned sets of Configuration Items (CIs) and data at particular project milestones. • Each project should use at least two configuration baselines: Requirements and Production (Release). • List the CIs and project data for the planned configuration baselines; this may be documented in the SCMP, the SMP, or another project document. • Determine when each of the controlled CIs for the project will be physically placed under control. • Determine all CI due dates in the project schedule. • List configuration baselines and define what CIs or project data are expected in each baseline.  Examples of baselines include: • Requirements (established at completion of Software Requirements Review (SRR)) • Design (established at successful completion of Software Design Review (SDR)) • Development (established at successful completion of subsystem test) • Production (established at successful completion of System Test and Software Acceptance Review (SAR), Physical Configuration Audit, (PCA) & Functional Configuration Audit (FCA))

9. Configuration Management Determine configuration management roles and responsibilities(6.3) •  The Software Project Lead determines the functions, responsibilities, and authority for the implementation of software configuration management for the project and gathers the necessary resources. • Determine the personnel necessary to implement the SCM process for the project including the Software Configuration Manager and the Change Control Board (CCB) roles/members. Not all projects will have a separate Software Configuration Manager, so the Project Lead may perform all of the steps. • Define duties and responsibilities to each of the CM roles (SW Configuration Manager, CCB members, SW team, etc). Documentation may be managed by a Configuration Manager at the project level, with input from the Software Project Lead or Software Configuration Manager. • Submit the membership list of the CCB for the project to the Project Manager for approval. Define their roles and responsibilities.  • Assign and train a Software Configuration Manager . • Train project personnel  

10. Configuration Management Define levels of control for CIs and data items(6.4) •  The Software Configuration Manager examines each of the CIs and data items to determine the proper level of control.  Levels of control normally range from no higher level approval required to change authorized only by CCB decision.

11. Configuration Management Determine change control procedures(6.5) • The Software Configuration Manager develops the change control procedures.  These may be part of the SCMP or other plan. Change-control activities may include Request; Evaluate; Approve; Defer; or Disapprove; and Implement changes to baselined CIs. The change-control procedure must accommodate the various levels of control defined above. • The Software Configuration Manager develops procedures for software items; however, the project Configuration Manager may develop procedures for documentation, including software documentation, with input from the SCM.  

12. Configuration Management Select revision control system(6.6) • The Software Configuration Manager determines what equipment and space will be needed to accommodate the SCM system.

13. Configuration Management Plan for Configuration Audits and Reviews(6.7) • The Software Configuration Manager, in conjunction with the Software Project Lead or Project Manager, identifies the configuration audits and reviews to be held for the project, such as: • Functional Configuration Audits (FCAs) verify that a CI’s actual performance agrees with its software requirements, and also verifies that all tests have been completed and documented. • Physical Configuration Audits (PCAs) verify the as-built software products against its technical documentation (requirements, design, and user manuals). • Other options for audits include checking to be sure all Change Requests (CRs) are implemented as planned, verifying the right version of all files went into the baseline, etc. • Reviews scheduled in the Software Management Plan should identify any SCM activities that are needed to support those project reviews.

14. Configuration Management Plan for the storage, handling, delivery, release, and maintenance of software products and documentation(6.8) • The Software Configuration Manager, in conjunction with the Project Lead or Project Manager, determines the procedures for building, releasing, and delivering software products and documentation. Delivery may be from the software development environment to the test environment and/or delivery to the customer. To release software to another NASA center or outside of the NASA community, refer to NPR 2210.1C for guidance. • Describe how the build, release, and delivery of software products and documentation will be controlled. • Will the builds be done by the SCM or the developers? • What is the procedure for releasing software, and performing the FCA and PCA? • How will the software products and documentation be delivered and installed, i.e., downloaded from web site, on a CD, etc.? • Define how master copies of the code and documentation will be maintained for the life of the software product. Refer to the Software Maintenance Template for guidance on the software maintenance and software retirement activities. • Define how code and documentation that contain safety or security critical functions will be handled, stored, packaged, and delivered in accordance with NASA Policy Directive (NPD) 2810.1 - NASA Information Security Policy.

15. Configuration Management Set up the Software Configuration Management System(6.9) • The Software Configuration Manager ensures that the SCM system is set up and project personnel know how to use it. • Install all tools, including the revision-control system, set up accounts, access controls, and validate functionality. • Create a repository for project data and CIs. • Define the check-in and checkout procedures for software. • Ensure that status accounting data will be maintained and provided to the project when needed.  • Prepare training material for team training. • Train the software developers on the proper use of the CM system and their responsibilities.

16. Configuration Management Draft the Software Configuration Management Plan (SCMP) (6.10) • The Software Configuration Manager develops a draft SCMP based upon the inputs from the previous steps. • Small projects may not require the formality of a separate SCMP; instead SCM planning may be documented as a section of the project’s SMP or project CM plan. Alternatively, one master SCMP may document CM for multiple small projects. • The SCMP template from the Software@Glenn website may be used as a starting point. If another template is used, ensure that all requirements in NPR 7150.2B are satisfied by the SCMP. • Tailor the SCMP according to the classification of the software. See Appendix D of NPR 7150.2B.

17. Configuration Management Submit the SCMP to project management for review and approval(6.11) • The Software Configuration Manager submits the SCMP to the Project for review. • SCM sends the SCMP to the appropriate project personnel for review • SCM evaluates comments received from the review and incorporates them as appropriate • SCM or designee sends the updated SCMP out for signature

18. Configuration Management Carry out the Software Configuration Management Plan(6.12) • The Software Configuration Manager controls changes to the CIs and project data and prepares and maintains records of the configuration status of CIs.  • The Software Project Lead ensures that software configuration audits are performed as planned.  • Team members follow the configuration management plan procedures, build and release procedures, and provide the deliverable software products to the project as planned.

19. Software Configuration Management Inputs and Outputs • Inputs • Software Management Plan, Project Requirements/ Descriptions, Project plans, Change Requests, PRACAs, RIDs • Input Criteria • Software Management Plan (SMP) and requirements • Outputs • Configuration Baselines, change control procedures, Software Configuration Management Plan, training materials, configured CIs and data items, Change Requests, released products, audit reports, CM metrics, Configuration Management System • Output Criteria • None

20. Using the Software Configuration Management Plan (SCMP) Template • The SCMP template has been developed for use in the Flight Software Branch. • Projects outside the branch are welcome to use it • The template covers all requirements associated with a Class A Safety Critical software development effort. • All projects should tailor the SCMP template to the specific needs of the project. • Designed to cover NPR 7150.2B requirements and CMMI’s Configuration Management process area • The SCMP is intended for documenting the way configuration management of the software will be handled by the team and is used by all software team members as they develop software products.

21. Software Measurement ProcessResources, Tools, and Templates • Available from Software@Glenn: • http://software.grc.nasa.gov • GRC-SW-7150.9 Software Configuration Management Process • GRC-SW-TPLT-SCMP Software Configuration Management Plan template • Software Change Request/Problem Report • NPR 7150.2B: NASA Software Engineering Requirements • Other CM tools • Subversion revision control software • TortoiseSVN Subversion client • CVS revision control software • TortoiseCVS CVS client • See Software@Glenn>>Tools for additional CM tools

22. Software Measurement ProcessResources, Tools, and Templates (cont.) • Available from the Agency • NASA Engineering Network: Software Engineering Community of Practice • https://nen.nasa.gov/web/nen/home: Click on Communities->Software Engineering • NASA Software Engineering Handbook • https://swehb.nasa.gov/

23. Feedback on the Configuration Management • Processes, checklists, templates and forms available at Software@Glenn: http://software.grc.nasa.gov • To ask questions • Lisa Lambert, x3994 • grc-sepg-lead@lists.nasa.gov • We value your feedback • The feedback form is on the Feedback page of Software@Glenn. • Send the feedback form to grc-sepg-lead@lists.nasa.gov. • Group feedback sessions available upon request. • Based on feedback, the process will be updated. • The updated process will be made available on Software@Glenn. • Share your products as examples for future projects!

24. Questions?

25. Backup

26. CMMI v1.3 Configuration Management • Specific Goals and Practices • SG 1 – Establish Baselines • SP 1.1 – Identify Configuration Items • SP 1.2 – Establish a Configuration Management System • SP 1.3 – Create or Release Baselines • SG 2 – Track and Control Changes • SP 2.1 – Track Change Requests • SP 2.2 – Control Configuration Items • SG 3 – Establish Integrity • SP 3.1 – Establish Configuration Management Records • SP 3.2 – Perform Configuration Audits

27. CMMI v1.3 Generic Goal 2 • Generic Goal 2 and Practices • Goal 2 – Institutionalize a managed process • GP 2.1 – Establish an organizational policy • GP 2.2 – Plan the process • GP 2.3 – Provide resources • GP 2.4 – Assign responsibility • GP 2.5 – Train people • GP 2.6 – Control work products • GP 2.7 – Identify and involve relevant stakeholders • GP 2.8 – Monitor and control the process • GP 2.9 – Objectively evaluate adherence • GP 2.10 – Review status with higher level management • 27

28. NPR 7150.2B RequirementsSWEs: 079, 080, 081, 082, 083, 084 • SWE-079: The project manager shall develop a software configuration management plan that • describes the functions, responsibilities, and authority for the implementation of software • configuration management for the project. • SWE-080: The project manager shall track and evaluate changes to software products. • SWE-081: The project manager shall identify the software configuration items (e.g., software • records, code, data, tools, models, scripts) and their versions to be controlled for the project. • SWE-082: The project manager shall establish and implement procedures to: • a. Designate the levels of control through which each identified software configuration item is required to pass. • b. Identify the persons or groups with authority to authorize changes. • c. Identify the persons or groups to make changes at each level. • SWE-083: The project manager shall prepare and maintain records of the configuration status of • software configuration items. • SWE-084: The project manager shall perform software configuration audits to determine the • correct version of the software configuration items and verify that they conform to the records • that define them.

29. NPR 7150.2B Requirements(cont.) SWEs: 085, 146, 149 • SWE-085: The project manager shall establish and implement procedures for the storage, • handling, delivery, release, and maintenance of deliverable software products. • SWE-146: The project manager shall define the approach to the automatic generation of software source code including: • a. Validation and verification of auto-generation tools. • b. Configuration management of the auto-generation tools and associated data. • c. Identification of the allowable scope for the use of auto-generated software. • d. Verification and validation of auto-generated source code. • e. Monitoring the actual use of auto-generated source code compared to the planned use. • f. Policies and procedures for making manual changes to auto-generated source code. • g. Configuration management of the input to the auto-generation tool, the output of the auto-generation tool, and modifications made to the output of the auto-generation tools. • SWE-149: The project manager shall ensure that when an OSS component is acquired or used, the following conditions are satisfied: • a. The requirements that are to be met by the software component are identified. • b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions). • c. Proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed. • d. Future support for the software product is planned and adequate for project needs. • e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.