Software Configuration Management
 

Home
Up
Consulting Services
Training
Events & Activities
CSQE Quizzes
About Our Team
How to Contact Us

Papers & Presentations

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 Posted: September 2, 2007

 

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

Author: Linda Westfall      Date Posted: March 30, 2007

 

Vertical and Horizontal Requirements Relationships:  This article explores a common question raised about Capability Maturity Model – Integration (CMMI®) expectations regarding the management of vertical and horizontal relationships within the context of requirements traceability.  It seems that the CMMI® really does not define vertical and horizontal traceability explicitly.  In order to document/prove/provide evidence of vertical and/or horizontal requirements traceability, we first need an understanding of exactly what vertical and horizontal traceability are in the context of software systems.  In hopes of finding an acceptable answer, it is necessary for this paper to:

  • First examine the statement in question and how it has changed between versions 1.1 and 1.2 of the CMMI®

  • Second, research how the CMMI® defines traceability and how the definitions have changed between the most recent versions
  • Third, attempt to understand how the CMMI® intends for us to interpret the meaning
  • Finally put all of this into perspective with an example

Author: Theresa Hunt        Date Original Version Posted: February, 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?

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

 

Book Reviews

A Guide to Software Configuration Management

Author:  Alexis Leon        Date Posted: Jan 3, 2002

Recommended References

A Guide to Software Configuration Management; Alexis Leon; Artech House, Boston, 2000; ISBN 1-58053-072-9. (see review)

Software Configuration Management; H. Ronald Berlack; John Wiley & Sons, 1992; ISBN-0-471-53049-2.

Recommended Links

Data and Analysis Center for Software (DACS) and the Defense Software Collaborators (DSC) - http://www.dacs.dtic.mil/

For more information about consulting services or training offered by The Westfall Team

Send an email to:  lwestfall@westfallteam.com

Or call: 972-867-1172

© 1999-2008 Westfall Team, Inc.