ConfigurationManagementFundamentals

ConfigurationManagementFundamentals - Configuration...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
10 C ROSSTALK The Journal of Defense Software Engineering July 2005 Configuration Management Fundamentals Software Technology Support Center The U.S. Air Force’s Software Technology Support Center offers an updated and condensed version of the “Guidelines for Successful Acquisition and Management of Software-Intensive Systems” (GSAM) on its Web site <www.stsc.hill.af.mil/ resources/tech_docs>. This article is taken from Chapter 9 “Configuration Management” of the GSAM (Ver. 4.0). We are pleased that all editions have been so well received and that many individuals and programs have worked hard to imple- ment the principles contained therein. The latest edition provides a usable desk reference that gives a brief but effective overview of important software acquisition and development topics, provides checklists for rapid self-inspection, and provides pointers to additional information on the topics covered. C hange is a constant feature of soft- ware development. To eliminate change is to remove the opportunities to take advantage of lessons learned, to incorporate advancing technology, and to better accommodate a changing environ- ment. Refusal to incorporate change can mean system limitations and early obso- lescence, which, in the world of technol- ogy, can sign your system’s death certifi- cate before it is born. However, change is not universally benign and must be con- trolled in its introduction to a project. All projects change something. As a project is executed, changes to the initial project plan and products are a natural occurrence. The following are common sources of changes: Requirements. The longer the delivery cycle, the more likely they will change. Changes in funding. Technology advancements. Solutions to problems. Scheduling constraints. Customer expectations. Serendipitous (unexpected) opportu- nities for an improved system. Some of these changes may appear as options while others may be mandated from above or by circumstance, as in the loss of funding. While all progress is accompanied by change, not all change is indicative of progress. If not properly handled, change can slip the schedule, affect the quality, and even kill the project. As a project draws closer to its comple- tion, the impacts of change are more severe [1]. Clearly, a mechanism is needed to control change. In software development and other projects, proposed changes must be eval- uated to determine their overall contribu- tion to the project goals. Do they lead to improvements or do they ultimately impede or lower project quality? Even those changes that are ultimately benefi- cial must be controlled in their introduc- tion and implementation. Putting a bigger engine in a plane may
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 6

ConfigurationManagementFundamentals - Configuration...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online