Software Configuration Management

Papers & Presentations

Safety Critical Software Configuration Management Practices: This presentation explores how to apply risk based software configuration management practices to safety critical software. Most safety critical software systems today are made up of many different components and are built using many different tools. The larger the projects, the more components there typically are and the more people there are involved in creating, using, and sharing access to all of the components. Software configuration management (SCM) provides the technical and managerial mechanisms needed to identify those components, coordinate their interrelationships, manage and communicate changes to those components over time and successfully build and release a set of highly reliable deliverables. SCM is the process of applying both tools and techniques throughout the software product life cycle to ensure the completeness, correctness, and integrity of software configuration items.

Presentation Author: Linda Westfall Date Posted: March 2011

Risk-Based Configuration Control - Balancing Flexibility and Stability: There is a dichotomy in software configuration management. On one side, individual developers need the flexibility necessary to do creative work, to modify code to try out what-if scenarios, and to make mistakes, learn from them and evolve better software solutions. On the other side, teams need stability to allow code to be shared with confidence, to create builds and perform testing in a consistent environment, and to ship high-quality products with confidence. This requires an intricate balance to be maintained. Too much flexibility can result in problems including, unauthorized and/or unwanted changes, the inability to integrate software components, uncertainty about what needs to be tested and working programs that suddenly stop working. On the other hand, enforcing too much stability can result in costly bureaucratic overhead, delays in delivery, and may even require developers to ignore the process in order to get their work done.

This paper explores risk-based software configuration control. It also examines techniques that can be used to help maintain this necessary balance between flexibility and stability, as software moves through the life cycle. These techniques include:

Selecting the appropriate type and level of control for each software artifact
Selecting the right acquisition point for each configuration item
Utilizing multiple-levels of formal control authority

Paper Author: Linda Westfall Date Posted: March 30, 2007

Date Updated: December 18, 2009

Presentation Author: Linda Westfall Date Posted: December 18, 2009

Software Configuration Management Audits - An audit is a planned and independent evaluation of one or more products or processes to determine conformance or compliance to a set of agreed to requirements. Auditing is an “objective assurance and consulting activity designed to add value and improve an organization’s operations.” [Hutchins-03] Audits provide assurance by validating that the products and/or processes are implemented in accordance with their requirements and objectives. Audits are consulting activities because they provide on-going analysis of the degree to which those implementations are effective and efficient and they identify opportunities for continuous improvement. Audits also visibly demonstrate management’s support for the quality program.

In the case of Software Configuration Management (SCM) audits, three types of audits are typically performed:

Functional Configuration Audit (FCA), which is an evaluation of the completed software products to determine their conformance, in terms of completeness, performance and functional characteristics, to their requirements specification(s).
Physical Configuration Audit (PCA), which is an evaluation of each configuration item to determine its conformance to the technical documentation that defines it.
In-Process SCM Audits, which are ongoing evaluations conducted throughout the life cycle to provide management with information about compliance to SCM policies, plans, processes and systems, and about the conformance of software product to their requirements and workmanship
standards.

This paper discusses the purpose of each of these three types of SCM audits. It also provides examples of checklist items that could be used during audit evaluations and suggested evidence gathering techniques for each of the items in those checklists.

Author: Linda Westfall Date Original Version Posted: September 2, 2007

Bidirectional Requirements Traceability: Traceability is one of the essential activities of good requirements management. Traceability is used to ensure that the right products are being built at each phase of the software development life cycle, to trace the progress of that development and to reduce the effort required to determine the impacts of requested changes. This article explores:

What is traceability?

Why is traceability a good practice?

How is traceability performed?

How is traceability information used during development & testing

Author: Linda Westfall Date Original Version Posted: February 28, 2006

Recommended References

Michael E. Bays, Software Release Methodology, Prentice Hall PTR, Upper Saddle, New Jersey, 1999.

Stephan P. Berzcuk, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Addison-Wesley, Boston, 2003.

Electronic Industries Alliance (EIA) ANSI/EIA-649-2004, National Consensus Standard for Configuration Management, October 2004.

Ann Mette Jonassen Hass, Configuration Management Principles and Practices, Addison-Wesley, Boston, 2003.

IEEE Standards Software Engineering, IEEE Standard for Software Configuration Management Plans, IEEE Std. 828-2005, The Institute of Electrical and Electronics Engineers, New York, NY, 2005.

Alexis Leon, Software Configuration Management Handbook, 2^nd Edition, Artech House, Boston, 2005.

Military Handbook – Configuration Management Guidance, MIL-HDBK-61A(SE), Department of Defense, February 7, 2001.

Capability Maturity Model Integration (CMMI) for Development, Version 1.2, Carnegie Mellon University Software Engineering Institute, Pittsburgh, PA 15213-3890, CMU/SEI-2006-TR-008, ESC-TR-2006-008, (available on the SEI website).

Papers & Presentations

Recommended References

Recommended Links: