This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
As shown in FIGURE 31–3, SCM is a pyramid consisting of six layers and three faces. The six layers of the pyramid shown on the front face are:
){kind=link}
Understanding of SCM—Without a total understanding, a partial implementation of SCM with work-arounds and back doors will result in disaster for an SCM system.
SCM plans and policies—The policy for the organization lays out in a clear, concise fashion the expectations that the organizational leadership has for its system.
SCM processes—The specific processes of SCM are documented for all users to recognize.
Metrics—These measures show where the organization is along the path to reaping the benefits of SCM.
Tools for SCM—It makes little sense to pick the tools to use in SCM without having completed all the previous layers.
SCM configuration items—The configuration items (CI) are those "things" that represent internal and external project deliverables. They are the final result of all the work done to implement SCM in your organization.
The second face of the SCM pyramid is the training plan and its execution while the third is the transition plan to get to an effective SCM implementation. By following this as the process map to SCM, an organization can meet the software configuration management KPA for an SEI CMM Level 2 organization.
In Chapter 30 we discussed the Software Engineering Institute (SEI) Capability Maturity Model (CMM) levels of maturity. At Level 2, an organization moves beyond just getting the job done and into an environment where a software project management process is in place, the organization sets expectations via policies, and projects have disciplined phases and milestones. This level is described as the repeatable level, built upon key process areas of requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management. The goals for SCM at maturity Level 2 are:
Software configuration management activities are planned.
Selected software work products are identified, controlled, and available.
Changes to identified software work products are controlled.
Affected groups and individuals are informed of the status and content of software baselines.
Questions that assessors might ask include:
Is a mechanism used for controlling changes to the software requirements?
Is a mechanism used for controlling changes to the software design?
Is a mechanism used for controlling changes to the code?
Is a mechanism used for configuration management of the software tools used in the development process?
SCM is a key building block of an organization's development process. Without it, no organization can achieve the quality levels needed for basic customer satisfaction.
Problems for Review
Take the outline for a software configuration management plan, adapted from the IEEE Standard for Software Configuration Management Plans (Std. 828-1990). Tailor this to your needs, removing explanatory comments as you go along. Where you decide to omit a section, you might keep the header but insert a comment saying why you omit the data.
What are five barriers to SCM in your work organizations?
What are three barriers to SCM in your project's environment?
Looking back on projects you have completed or are currently working on, how could SCM have enhanced them? If SCM was used, did it perform to everyone's satisfaction? If not, why?
Describe how you would perform SCM on a moderately sized Java implementation using a code development environment in which you had 50 classes and 200 methods.
Define the membership of a CCB for your entire organization. Define your product line and your current project.
Define 10 characteristics for CIs in your products.
Define the process in your organization for selecting an automated tool for SCM. What are the top five benefits to your organization from an automated SCM tool?
What SCM is different for developing a Web-based, browser-delivered software application?
Where does SCM fit in your product development life cycle? Provide a graphic representation of your life cycle, and identify the processes served by SCM.
Visit the Case Study
The Chinese Railway Ministry central software development group is an all-Microsoft shop. They develop software for DOS, Windows 3.1, Windows NT, and Windows CE. For development, they use the integrated visual development environment with Visual Source Safe (VSS) as the configuration management tool. Their VSS repository reached 5.5 GB in size with the revision branch of one of their train maintenance scheduling programs. At this size, Microsoft advises splitting the repository into two or more pieces. You will no longer be able to rely on the centralized VSS to handle your prototype development needs. As a matter of fact, Mr. Lu has intimated that the ministry may move off of VSS completely.
Mr. Lu requests that the ministry review your configuration management plan for not only the prototype, but for the entire system that you propose. Based on the current conditions at the ministry, you may not use the VSS. You must recommend a solution that will add no software licensing cost to your project and will be usable in a Microsoft development environment. Because your marketing team has already touted the extensive configuration management plan that you produce for each project, Mr. Lu feels that giving you, the project manager, a week to update the plan and recommend a configuration management tool is more than reasonable.
References
Ayer, S.J., and F.S. Patrinostro (1992). Software Configuration Management: Identification, Accounting, Control, and Management. New York, NY: McGraw-Hill.
Berlack, R.H. (1992). Software Configuration Management. New York, NY: John Wiley and Sons.
Bersoff, E., V. Henderson, and S. Siegel (1980). Software Configuration Management. Prentice Hall.
Buckley, F. (1993). Configuration Management: Hardware, Software, and Firmware. IEEE Computer Society Press.
DoD (1985). DoD-STD-2167A, "Military Standard for Defense System Software Development." Department of Defense.
DoD (1986). DI-MCCR-80030A, "Data Item Description for the Software Development Plan." Department of Defense.
DoD (1986). MIL-STD-480, "Engineering Changes, Deviations and Waivers." Department of Defense.
DoD (1986). MIL-STD-483A, "Configuration Management Practices for Systems, Equipment, Munitions, and Computer Programs." Department of Defense.
DoD (1989). MIL-STD-973, "Military Standard for Configuration Management." Department of Defense.
IEEE Std 828-1990, "IEEE Standard for Software Configuration Management Plans." American National Standards Institute, 1990.
IEEE Std 1042-1987, "IEEE Guide to Software Configuration Management." American National Standards Institute, 1987.
NASA D-GL-11, "Software Configuration Management for Project Managers." National Aeronautics and Space Administration, Version 0.2, March 1987.
NASA Sfw DID 04, "Software Configuration Management Plan Data Item Description." National Aeronautics and Space Administration, Version 3.0, October 15, 1986.
Pressman, Roger S. (2001). Software Engineering: A Practitioner's Approach, 5th ed. New York, NY: McGraw-Hill.
Whitgift, D. (1991). Software Configuration Management: Methods and Tools. England: John Wiley and Sons.
Web Pages for Further Information
sourceforge.net/. SourceForge is a free service to Open Source developers offering easy access to the best in CVS, mailing lists, bug tracking, message boards/forums, task management, site hosting, permanent file archival, full backups, and total Web-based administration.
http://www.cmtoday.com/yp/configuration_management.html. Welcome to the ''Yellow Pages'' for configuration management. This page references as many Web pages related to configuration management around the world as possible.
http://www.dtkhh.de/tsr.htm. European Software and Systems Initiative (ESSI) Process Improvement Experiment (PIE). Improvement of process architecture through configuration and change management, and enhanced test strategies for a knowledge-based test path generator.
http://www.iac.honeywell.com/Pub/Tech/CM/index.html. Honeywell Inc. IAC manages and updates the frequently asked questions lists for the newsgroup comp.software.config-mgmt. The information contained in these summaries is a consolidation of data obtained from user comments, vendor materials, and a variety of sources around the Internet. It does not represent an official position or opinion of Honeywell, Inc.
http://www.mks.com/products/scm/si/2134.htm. "Configuration Management and ISO 9001," by Robert Bamford and William J. Deibler II, Software Systems Quality Consulting.
http://www.sei.cmu.edu/legacy/scm/. The intent of this area is to share the configuration management research done by the SEI between 1988 and 1994 and to provide pointers to other useful sources of information on software configuration management.
http://www.sei.cmu.edu/legacy/scm/abstracts/abscm_past_pres_future_TR08_92.html. Automated support for configuration management is one aspect of software engineering environments that has progressed over the last 20 years. The progress is seen by the burgeoning interest in CM, many technical papers and conferences involving CM, a large number of CM tool vendors, and new software development environments that incorporate CM capabilities. This paper is about future issues affecting solutions to CM problems.
http://www.sei.cmu.edu/legacy/scm/papers/CM_Plans/CMPlans.MasterToC.html. The purpose of this document is to give an understanding of the importance of the role of the configuration management plan, to give the results from a set of informal discussions that shows how such plans are used, and to provide an evaluation of three standards.
http://www.sei.cmu.edu/legacy/scm/scmDocSummary.html. Summary of available CM related documents.