Power Point PPT: Why Software Configuration Management
Software engineers usually find coding to be the most satisfying aspect of their job. This is easy to understand because programming is a challenging, creative activity requiring extensive technical skills. It can mean getting to “play” with state-of-the-art tools, and it provides almost instant gratification in the form of immediate feedback. Programming is the development task that most readily comes to mind when the profession of software engineering is mentioned.
That said, seasoned engineers and project managers realize that programmers are part of a larger team. All of the integral tasks, such as quality assurance and verification and validation, are behind-the-scenes activities necessary to turn standalone software into a useful and usable commodity. Software configuration management (SCM) falls into this category—it can’t achieve star status, like the latest “killer app,” but it is essential to project success. The smart software project manager highly values the individuals and tools that provide this service.
This chapter will answer the following questions about software configuration management.
What Is Software Configuration Management?
Software configuration management (SCM) is the organization of the components of a software system so that they fit together in a working order, never out of synch with each other. Those who have studied the best way to manage the configuration of software parts have more elegant responses.
Roger Pressman says that SCM is a “set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”>
We think that Pressman’s description is a better description because we often view SCM as meaning software change management.
Wayne Babich describes SCM as “the art of identifying, organizing, and controlling modifications to the software being built by a programming team. It maximizes productivity by minimizing mistakes.”>
The Software Engineering Institute says that it is necessary to establish and maintain the integrity of the products of the software project throughout the software life cycle. Activities necessary to accomplish this include identifying configuration items/units, systematically controlling changes, and maintaining the integrity and the traceability of the configuration throughout the software life cycle.
Military standards view configuration as the functional and/or physical characteristics of hardware/software as set forth in technical documentation and archives in a product. In identifying the items that need to be configured, we must remember that all project artifacts are candidates—documents, graphical models, prototypes, code, and any internal or external deliverable that can undergo change. In SW PM terminology, a configuration item might be a proposal/estimate or bid, project plan, risk management plan, quality assurance plan, CM plan itself, test plan, system requirements specification, system design document, review metric, code, test result, tool (editors, compilers, CASE), and so on. There are basic objects and aggregate objects to be configured. The number of relationships among them reflects the complexity of the configuration task.
Why Is SCM Important?
Software project managers pay attention to the planning and execution of configuration management, an integral task, because it facilitates the ability to communicate status of documents and code as well as changes that have been made to them. High-quality released software has been tested and used, making it a reusable asset and saving development costs. Reused components aren’t free, though—they require integration into new products, a difficult task without knowing exactly what they are and where they are.
CM enhances the ability to provide maintenance support necessary once the software is deployed. If software didn’t change, maintenance wouldn’t exist. Of course, changes do occur. The National Institute of Standards and Technology (NIST) says that software will be changed to adapt, perfect, or correct it. Pressman points out that new business, new customer needs, reorganizations, and budgetary or scheduling constraints may lead to software revision.
CM works for the project and the organization in other ways as well. It helps to eliminate confusion, chaos, double maintenance, the shared data problem, and the simultaneous update problem, to name but a few issues to be discussed in this chapter.
Who Is Involved in SCM?
Virtually everyone on a software project is affected by SCM. From the framers of the project plan to the final tester, we rely on it to tell us how to find the object with the latest changes. During development, when iterations are informal and frequent, little needs to be known about a change except what it is, who did it, and where it is. In deployment and baselining, changes must be prioritized, and the impact of a change upon all customers must be considered. A change control board (CCB) is the governing body for modifications after implementation.
How Can Software Configuration Be Implemented in Your Organization?
We used to say, “Make a plan and stick with it—never waffle,” and “Requirements must be frozen—how else will we know what to code?” Now, we say, “Plans are living documents—they will be in a continual state of change as project knowledge increases.” We now know that requirements are never frozen—they merge, morph, and evolve and become expanded, enhanced, and extended. As long as artifacts of software development can undergo change, we will need some method of managing the change.
Because SCM is such a key tool in improving the quality of delivered products, understanding it and how to implement it in your organization and on your projects is a critical success factor. This chapter will review SCM plan templates and provide you with a composite SCM plan template for use in any of your projects. We will cover the issues and basics for a sound software project CM system, including these:
Identification, control, audit, and status accounting are the four basic requirements for a software configuration management system. These requirements must be satisfied regardless of the amount of automation within the SCM process. All four may be satisfied by an SCM tool, a tool set, or a combination of automated and manual procedures.
SCM Tools
The minimum features for SCM tools are closely related to the task of handling the different product deliverables produced within the project software engineering process. Tool requirements and selection criteria are based on a series of features that provide a consistent look and feel with state-of-the-art software development environments. An SCM tool must have multiuser support, an intuitive graphical user interface, conformity to the organization’s development environment, scalability, flexibility in integrating other software development tools, ease of setup, modifiable models, process management, extensive support for the development phase, and management of nondevelopment objects.
Basic selection criteria includes the following:
Many configuration management tools in the market promise to fulfill more or less all of the requirements. Chapter 24, “Use of Tools,” presented a general model for the selection of tools to support software development and project management. The keys to any tool selection are to know your project’s tool requirements, to understand how tools relate to the project’s success factors, and to do a current market search for tools. The following is an example of using that tool selection method for an SCM tool. This is simply an example, and it must be updated with individual key project success factors, tool requirements, and the tools available in the market based on the project’s schedule requirements.
A quick search of the market in SCM tools provided the list of potential candidates for the tool as shown in Table 31–1.
Name of Tool |
Description and Company |
Internet Address |
AllChange 2000 SE |
IntaSoft |
|
CCC/Harvest, CCC/Manager, CCC QuikTrak |
Computer Associates (formerly Platinum) |
|
ClearCase |
Rational (formerly PureAtria) |
|
CMVC, now VisualAge Team Connection |
Configuration Management and Version Control, IBM |
|
Continuus |
Continuus |
|
eChange Man |
Serena |
|
Enabler aqua |
Softlab |
|
Endevor |
Computer Associates |
|
Perforce |
Perforce Software |
|
PVCS |
MERANT (formed by a combination of MicroFocus and Intersolv) |
|
PVCS Dimensions |
MERANT (formerly PCMS Dimensions from SQL Software) |
http://www.merant.com/ |
Razor |
Visible Software |
|
RCE (VRCE) |
Revision Control Engine (Visual RCE) DuraSoft GmbH |
|
Sablime |
Lucent Technologies |
|
SCCS |
Source Code Control System |
Comes with most Unix distributions. |
SCLM |
Software Configuration Library Manager, IBM |
|
SCM |
Source Code Manager, UniPress Software, Inc. |
|
SoftBench |
HP |
http://www.devresource.hp.com/ |
Source Integrity |
MKS |
|
StarTeam |
StarBase |
|
TeamSite |
Interwoven |
|
TRUEchange |
McCabe and Associates |
|
TurnOver |
Soft Landing Systems |
|
Visual Age TeamConnection |
IBM |
|
Visual Enabler |
Soft Lab |
|
Visual Source Safe |
Microsoft Corp. (PC) / Metrowerks (Macintosh) |
From the list, four were picked as possible commercial products that would meet the project’s requirements:
Following an example from SEI, we formed a ranking system for comparing the tools. Table 31–2 shows the rating for the considered tools.
SEI Template for Ranking CM Plans.
Source: SEI, from Configuration Management Plans: The Beginning to your CM Solution.
The result of this first ranking allows one of the potential tools, PVCS, to be dropped. This would then leave three for the project manager and tool evaluation team to take a more in-depth look. Note that there has been no discussion of price at this time. Once the technical decision has been made, the cost decision should follow. Do not introduce price early in the evaluation. If there is discomfort with the technical capabilities and life cycle coverage of a tool, adding in a cost variable will only further confuse the decision. Many software project tools become less desirable after full life cycle cost is analyzed and estimated. Make the technical decision first.
|
PCMS |
ClearCase |
Continuus/CM |
PVCS |
Multiuser support |
4 |
3 |
3 |
2 |
Intuitive GUI |
3 |
4 |
3 |
3 |
Environment conformity |
3 |
4 |
4 |
4 |
Scalability |
4 |
4 |
4 |
2 |
Flexibility in integrating other software development tools |
2 |
3 |
1 |
3 |
Ease of setup |
3 |
3 |
3 |
4 |
Modifiable models |
4 |
3 |
4 |
3 |
Process management |
4 |
2 |
4 |
2 |
Development phase support |
4 |
4 |
4 |
3 |
Nondevelopment objects |
4 |
4 |
4 |
4 |
Total |
36 |
35 |
34 |
30 |
These values are used to indicate ratings: 5 = Excellent; 4 = Good; 3 = Fair, 2 = Unsatisfactory; 1 = Unknown |
As a final note on tools, working strictly in a Microsoft development environment with Microsoft tools working under Visual InterDev, Visual Source Safe (VSS) is included as an integral part of the tool suite. VSS is an adequate SCM tool for small commercial product development that is strictly targeted to Microsoft platforms. If you’re developing on Microsoft platforms and have delivery targets on Linux or Unix, investigate the use of WinCVS. WinCVS is a shareware package that is very capable in providing large-project, multiplatform SCM. It compares favorably with most and betters some commercial SCM tools.
SCM benefits an organization in four areas: control, management, cost savings, and quality. These four benefits are mapped to an organization’s overall goals and objectives when the decisions are made to bring a SCM tool in-house. The features of a SCM tool further support these benefits.
SCM Benefits the Organization in Four Major Ways
Control
Control in SCM provides the ability to review, approve, and incorporate changes into a configuration item. There must be one controlling SCM tool so that there is only one set of training, license management, installation, and user procedures. All project personnel use the tool. Inherent in the tool is a standardized, measurable process for change. Integrity maintenance of CIs is enforced throughout the product life cycle. The tool permits only controlled change to the baseline CIs, and all changes are tracked.
Management
Management in SCM is concerned with the automation of identifying and guiding configuration items through their life cycle to final assembly as part of product and delivery. Identification of CIs through a unique naming convention allows version, release, update, and full change tracking. Baselining of CIs with the ability to produce product deltas from the baseline satisfies requirement and schedule changes along with product family support. Rapid reviews and audits of CIs are accomplished through the analysis of historic information collected. Project status reporting is accomplished in a clear and consistent format based on SCM collected information on all CIs under configuration management.
Cost Savings
Cost savings are realized across the entire product development life cycle with SCM. Maintaining product integrity through defined, tracked, and audited CIs provides a managed bill of materials for the product released to customers. Cost savings scale with SCM use and application across applications. This scaling is dependent on the depth of control needed for each application product release tree. Deep combinations for product families can be analyzed for risk exposure and cost savings directly impacted by the amount of configuration management applied. Side effects are reduced through controlled change by understanding the impact on all versions and releases. Accurate and repeatable release control is produced in a repeatable fashion over entire product families for all customers and users.
Quality
Software development is a people-intensive activity, and quality must be considered at every person-to-tool interface. Ensuring a high-quality work environment must address the process of building software products in an automated fashion. This must include tracking CIs to the tools that produced them and the clients that ultimately receive the product. Measuring the end product to ensure high quality is done through tracking the changes made to a product throughout its life cycle. Repeatable management and change control in a documented and measured fashion allows accurate estimation of future efforts. Quality is an ongoing process. The lessons learned in one product must be transferred to new, related products and entire product families.
When planning for SCM in your product development organization, you must first understand the classes of potential problems that can exist. Once the classes are understood, the inherent problems that are causing configuration management issues may be easily identified.
Potential SCM Problem Classes
A template that may be used in the creation of a software configuration management plan (SCMP) appears in Appendix F, “Project Artifact Templates.” It includes management issues (organization, responsibility, etc.), SCM activities (configuration item identification, change control, status accounting, audit, and reviews), tools, techniques and methods, supplier control, and standards collection and retention.
SCM Staffing
On any given project, a few engineers or developers specialize in and become your SCM experts. While they are the gurus, everyone on your project will be a user of the product that they select, develop, and maintain. It is better to have a few highly experienced people than a large number of inexperienced people. These experienced few must be able to see congruence between software products and perceive what is missing from a software product.
We can group the characteristics and abilities needed by the four SCM functions: identification, control, auditing, and status accounting.
Once the staffing of the SCM function is complete and the overall organization’s SCM policy is established, the configuration control board (CCB) is identified. The CCB is the heart of the control function. It infuses sustained visibility into the process of change throughout the system life cycle and traceability into the process of change. The membership in the CCB is not limited to the developers or product line management. All stakeholders in the product must be represented. This includes the end-user usually represented by marketing, subcontractors used in the product development, product development funders, and the product developers. The CCB is the final decision maker as to what bug fixes, enhancements, and feature sets get included in the next product release.
The CCB has periodic meetings, with the results documented. These meetings can be done in a rapid fashion, and doing them online or via email is an adequate way to gain consensus and come to a decision. Important to status accounting is the documentation of CCB meeting minutes. The basic purpose of the minutes is to provide the CCB decision makers with the information needed to make intelligent, informed decisions. The amount of detail varies with the meeting frequency and technical content.
When planning for SCM in your product development organization, you must first understand the classes of potential problems that can exist. Once the classes are understood, the inherent problems that are causing configuration management issues may be easily identified.
Potential SCM Problem Classes
A template that may be used in the creation of a software configuration management plan (SCMP) appears in Appendix F, “Project Artifact Templates.” It includes management issues (organization, responsibility, etc.), SCM activities (configuration item identification, change control, status accounting, audit, and reviews), tools, techniques and methods, supplier control, and standards collection and retention.
SCM Staffing
On any given project, a few engineers or developers specialize in and become your SCM experts. While they are the gurus, everyone on your project will be a user of the product that they select, develop, and maintain. It is better to have a few highly experienced people than a large number of inexperienced people. These experienced few must be able to see congruence between software products and perceive what is missing from a software product.
We can group the characteristics and abilities needed by the four SCM functions: identification, control, auditing, and status accounting.
Once the staffing of the SCM function is complete and the overall organization’s SCM policy is established, the configuration control board (CCB) is identified. The CCB is the heart of the control function. It infuses sustained visibility into the process of change throughout the system life cycle and traceability into the process of change. The membership in the CCB is not limited to the developers or product line management. All stakeholders in the product must be represented. This includes the end-user usually represented by marketing, subcontractors used in the product development, product development funders, and the product developers. The CCB is the final decision maker as to what bug fixes, enhancements, and feature sets get included in the next product release.
The CCB has periodic meetings, with the results documented. These meetings can be done in a rapid fashion, and doing them online or via email is an adequate way to gain consensus and come to a decision. Important to status accounting is the documentation of CCB meeting minutes. The basic purpose of the minutes is to provide the CCB decision makers with the information needed to make intelligent, informed decisions. The amount of detail varies with the meeting frequency and technical content.