Page History
| Wiki Markup |
|---|
{alias:SWE-079}
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}
{div3:id=tabs-1}
h1. 1. Requirements
4.1.1 The project shall develop a Software Configuration Management Plan that describes the functions, responsibilities, and authority for the implementation of software configuration management for the project.
h2. {color:#003366}{*}1.1 Notes{*}{color}
The Software Configuration Management Plan may be a part of the project configuration management plan. The content is defined by the requirement in Chapter 5 of NPR 7150.2.
h2. 1.2 Applicability Across Classes
Class G is labeled with "P(Center). This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.
{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=1|esc=1|ensc=0|f=1|g=p|h=0}
{div3}
{div3:id=tabs-2}
h1. 2. Rationale
{floatbox}
"The discipline of CM (configuration management) is vital to the success of any software effort. CM is an integrated process for identifying, documenting, monitoring, evaluating, controlling, and approving all changes made during the life-cycle of the program for information that is shared by more than one individual or organization." ([NASA Software Safety Guidebook(1), NASA-GB-8719.13|https://standards.nasa.gov/documents/detail/3315126])
{floatbox}
"Software configuration management is practiced during all phases of the software life cycle, from initiation of development through software maintenance, and is responsible for ensuring that any changes during the development and maintenance processes are made in a controlled and complete manner... Configuration management contributes to software safety by ensuring that documentation and source code are updated only through a formal process." ([NASA Software Safety Standard|https://standards.nasa.gov/documents/detail/3314914], NASA-STD-8719.13B)
The [NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126] describes the software configuration management (SCM) plan in this manner, "All software products, which includes far more than just code, must be configuration managed. Old files in a software build are a notorious problem, as are lost updates and other problems with changed files. The plan specifies what will be under configuration management (CM), what CM system will be used, and the process for moving an item into or out of the CM system."
Given that configuration management occurs throughout the project life cycle and is critical to controlling and tracking all elements of the project, having a plan in place ensures that the team is informed of and performs all necessary and required configuration management tasks. Development of the SCM plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned configuration management activities for the project.
The SCM plan has both internal and external uses. Internally, it is used within the project to guide, monitor, and measure the overall CM process. It describes both the CM activities planned for future acquisition phases and the schedule for implementing those activities. Externally, the SCM plan is used to communicate the CM process to the contractors involved in the program. It establishes consistent CM processes and working relationships. ([NASA Systems Engineering Handbook|http://www.ap233.org/ap233-public-information/reference/20080008301_2008008500.pdf], NASA/SP-2007-6105, Rev1)
{div3}
{div3:id=tabs-3}
h1. 3. Guidance
The SCM plan describes the software configuration management for the project, including functions, responsibilities, and implementation authority. This plan may be part of the software development plan (SDP) / software management plan (SMP) or it may be a standalone document. If the plan is a standalone document, part of its content should describe the SCM plan's relationship to other project plans, especially if configuration management activities are referenced or described in those plans.
{panel}Both providers and acquirers need to have a SCM plan. The contents of the provider plan are established in the contract.{panel}
The SCM plan primarily provides a formal method for managing change, but other activities are key to the overall process and should also be described in the plan. See ?[SWE-103|SWE-103] in this handbook for guidance on required contents, but consider the following topics as well when developing the SCM plan:
* Configuration management of deliverable and non-deliverable software development products including
** Documentation (e.g., specifications, design documents, traceability matrices, presentations, project plans)
** Source code
** Object code
** Executables
** Data
** Development and test tools (operating systems, complierscompilers, etc.)
** Development and test environments (both hardware and software)
** Testing software (e.g., test cases/scenarios, scripts (manual and automated), reports)
** Flow charts, UML or OOD products, input to automatic code generators
** Interface control documents, message formats, data formats
** COTS software
** Build procedures
** Defect lists, change requests, problem reports/corrective actions
** Metrics
* Configuration management of software assurance records
* Configuration management of safety-critical software requirements and software elements
* Configuration management of simulators, models, test suites, etc.
* Management of releases
* Configuration management of routine software configuration changes such as mission-specific database changes
* Assessment of changes for their impact on system safety
* Metrics to be collected from the configuration management system, such as lines of code, complexity, estimated and actual time for various activities (development, testing, bug fixes, etc.), number of defects
* Determinations that can be made from configuration metrics, such as defects per lines of code for a team, goodness of effort estimations, need for more time in unit testing, estimates for future updates/maintenance activities, etc.
* Processes for "handling classified information and sensitive but unclassified (SBU) information, including export controlled and proprietary information, as applicable" ([NASA Configuration Management (CM) Standard|https://standards.nasa.gov/documents/detail/3315133])
When writing the SCM plan, consider the following tailoring suggestions from [IEEE STD 828-2005|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1502775&tag=1]:
* Reflect the current project environment by using terms familiar to the planned users and maintaining consistency with project development processes
* When tailoring leads to the addition of SCM requirements for a particular project (beyond the minimum specified in a template, standard, etc.), conduct a cost-benefit analysis and obtain agreement from stakeholders
* When tailoring leads to the removal of SCM requirements for a particular project (from the minimum set specified in a template, standard, etc.), include the rationale for the removal (project has limited scope, unusual environment, etc.) and obtain agreement from stakeholders
The SCM plan may also be tailored by software classification. Goddard Space Flight Center (GSFC)'s [Requirements for Minimum Contents of Software Documents|http://software.gsfc.nasa.gov/AssetsApproved/PA1.0.0.2.doc] provides one suggestion for tailoring a SCM plan based on the required contents and the classification of the software being developed.
Development of the SCM plan, typically by engineering, should begin during project formulation. Inputs to developing the project-level plan include the program CM plan, the IEEE Standard for Software Configuration Management Plans (IEEE Std 828-2005), and any Agency or Center-specific templates and guidance material.
Once the SCM plan is created, it should be peer reviewed ([SWE-137|SWE-137]), coordinated with the project customer and other stakeholders, and reviewed at project milestone reviews such as the System Requirements Review (SRR), Software Requirements Review (SwRR), Mission Definition Review (MDR), etc. [(see 7.4 -- Maturity of Life Cycle Products at Milestone Reviews)|http://nasa7150.onconfluence.com/display/7150/7.4+-+Maturity+of+Lifecyle+Products+at+Milestone+Reviews]. The SCM plan should be reviewed by software assurance to ensure compliance with applicable standards, procedures, and to ensure the plan is being properly implemented.
{note}Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to configuration management. {note}
Additional guidance related to configuration management and topics that should be addressed in the software configuration management plan may be found in the following related requirements in this handbook:
| *[SWE-080|SWE-080]* | Track & Evaluate Changes |
| *[SWE-081|SWE-081]* | Identify Software Configuration Management Items |
| *[SWE-082|SWE-082]* | Authorizing Changes |
| *[SWE-083|SWE-083]* | Status Accounting |
| *[SWE-084|SWE-084]* | Configuration Audits |
| *[SWE-085|SWE-085]* | Release Management |
| *[SWE-103|SWE-103]* | Software Configuration Management Plan |
\\
\\
{div3}
{div3:id=tabs-4}
h1. 4. Small Projects
Configuration management activities are based on risk, so projects designated small by size of the team or budget should ensure that their SCM plans consider all the required content noted in [SWE-103|SWE-103], but only include those processes and the associated structure necessarycommensurate to managewith project risk. This might mean planning to use simpler tools or fewer personnel (filling multiple roles) to carry out the SCM processes. It could also mean planning to use a single tool for multiple purposes to reduce tool management and overhead. Note that waivers may be necessary if any required content is left out of the SCM plan.
Small projects may not require the formality of a separate SCM plan; instead SCM planning may be documented as a section of the project's Software Management Plan. Alternatively, one master SCM plan may document CM for multiple small projects.
{div3}
{div3:id=tabs-5}
h1. 5. Resources
# STEP Level 2 Software Configuration Management and Data Management course, SMA-SA-WBT-204, [SATERN|https://saterninfo.nasa.gov/] (need user account to access SATERN courses).
# IEEE Computer Society, "[IEEE Standard for Software Configuration Management Plans|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1502775&tag=1]", IEEE STD 828-2005, 2005 (need user account to access IEEE standards via this [NASA Technical Standards System|http://standards.nasa.gov/] link).
# NASA Technical Standard, "[NASA Software Safety Standard|https://standards.nasa.gov/documents/detail/3314914]", NASA-STD-8719.13B, 2004.
# NASA Technical Standard, "[NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126]", NASA-GB-8719.13, 2004.
# IEEE Computer Society, "[IEEE Guide to Software Configuration Management|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=89631&tag=1]", IEEE STD 1042-1987, 1987 (need user account to access IEEE standards via this [NASA Technical Standards System|http://standards.nasa.gov/] link).
# NASA Procedural Requirement, "[NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005D_]", NPR 7120.5D, 2007.
# Flight and Ground Software Division, MSFC, ["Software Development Process Description Document"|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499471%2FSDPDD_Rev%2BQ_080207.pdf] (Chapter 13), EI32-OI-001, Revision R, 2010.
# NASA Technical Standard, "[NASA Configuration Management (CM) Standard|https://standards.nasa.gov/documents/detail/3315133]", NASA-STD-0005, 2008.
# [Requirements for Minimum Contents of Software Documents|http://software.gsfc.nasa.gov/AssetsApproved/PA1.0.0.2.doc], 580-STD-077-01, GSFC, 2010.
# [Software Configuration Management|http://software.grc.nasa.gov/processes/GRC%E2%80%93SW%E2%80%937150.9-Software%20Configuration%20Management.pdf], GRC-SW-7150-9, Revision B, Glenn Research Center (GRC), 2011.
# [Checklist for Configuration Management|http://software.grc.nasa.gov/pilot/Processes%20and%20Checklists/SCM_CI_list.pdf], GRC.
h2. {Toolstable}
{div3}
{div3:id=tabs-6}
h2. 6. Lessons Learned
The NASA Lessons Learned database describes the importance of configuration management in these lessons learned:
* *Software maintainability* ([http://www.nasa.gov/offices/oce/llis/0838.html|http://www.nasa.gov/offices/oce/llis/0838.html]): "Configuration management of software is probably the single most important management and maintainability concept utilized in software development. Utilization of coding standards, documentation standards, release standards, common languages and other methods will provide for good configuration management. A plan should be developed very early in the development cycle for managing the configuration of the software under development, and that plan should be followed rigorously. If configuration management breaks down, the code under development is doomed to be extremely troublesome when released for operations."
* *Auto-generated code* ([http://www.nasa.gov/offices/oce/llis/1023.html|http://www.nasa.gov/offices/oce/llis/1023.html] ): "The use of the ... autocode generator for ISS software can lead to serious problems if the generated code and ... \[tool\] itself are not subjected to effective configuration control or the products are not subjected to unit-level V&V. These problems can be exacerbated if the code generated ... is modified by hand."
* *File naming* ([http://www.nasa.gov/offices/oce/llis/1481.html|http://www.nasa.gov/offices/oce/llis/1481.html] ): "The .. Team renamed a ... file ... prepared for a previous mission for use on a current mission without changing the file creation time recorded in the file header. This error caused the new file to be repeatedly recognized as an "old" file, and required operations personnel for several months to manually specify the correct file. Implement CM measures to assure adequate oversight when renaming old command sequence resources for reuse."
{div3}
{tabclose} |
