CM Automation
OVERVIEW
Automating software configuration management (CM) consists of all the steps involved in introducing a CM tool into an organization and ensuring that it is routinely used on all projects. Implementing an automated CM system is a complex process. It affects all levels of the organization; therefore, an in-depth evaluation of the organization is required to determine how the processes and people will be affected.
Failure to understand the issues involved in the automation of CM technology is the main reason why organizations do not successfully deploy the CM tool. A defined strategy that addresses these complex issues becomes a necessity. Before beginning the automation effort, organizations must consider complex technical issues that may affect the effort. These issues include:
- The size and intricacy of the software system
- Client/server and Web-based systems support
- Heterogeneous hardware and software platforms
- Tool integration
- Legacy systems
- Interfaces to external systems
AUTOMATING CM
Many organizations thought that purchasing an CM tool would solve their problems, but soon discovered that there was no "silver-bullet" CM tool. To attempt to automate an immature CM process will not raise an organization's level of maturity as defined by the SW-CMM. In all likelihood , such attempts would only further amplify any process shortcomings and inadequacies. "Automating a money-losing process allows you to lose more money faster and with greater accuracy" [Ventimiglia 1997]. A tool alone will not solve an organization's CM problems and, in fact, Brown et al. [1999] have referred to the impractical reliance on a software configuration management tool as the "silver-bullet antipattern." Choosing the right tool to satisfy an organization's CM requirements will in itself fail if other issues are not addressed. To ensure an effective CM solution, an organization must address the complexities that it faces when implementing a change. These complexities include:
- Technical. These issues relate to how the tool operates, how it will be installed to maximize performance, and how it will be customized. For example, how will the tool be installed over the company's network in the client/server architecture given the different platforms, and how can it be used to suit the parallel development activities of the various teams ?
- Managerial. These issues relate to the necessary planning, monitoring, setting of priorities, making of schedules, and resource management. For example, who will be allocated to fulfill the automation activities, how will the product schedules be affected, and who will implement the tool first?
- Process related . These issues relate to the way the company does its business. For example, what is the current flow throughout the company, and how do the developers, testers, QA personnel, build managers, document writers, etc. work together to ensure this flow?
- Organizational. These issues relate to the infrastructure in the company. For example, how will the tool affect the responsibilities of each department and their intercommunication?
- Cultural. These issues relate to the way people operate and achieve their goals. For example, what kind of culture exists at the company, and what is the best way to invoke change in that culture?
- Political. These issues relate to "who is stepping on whose toes." For example, how will the organizational boundaries change, who will be responsible for what, and how will people be rewarded based on making the change?
- People related. These issues relate to people's comfort level. For example, how will resistance be managed, and will people lose their jobs because of this tool? This complexity is closely tied to the cultural issue.
- Risk related. These issues relate to unknown information and tricky problems. For example, how will the effect of making concurrent changes, such as a new operating system and new hardware, as well as reengineering the legacy code, impact the new CM system [Dart 1994]?
The CM automation effort must be treated as a project with realistic goals and a defined schedule. CM automation can be successfully carried out using the phases listed below developed by Susan Dart, a former member of the environment team at the Software Engineering Institute (SEI). The phases provide structured guidance, identify tasks , and address the complexities involved with automating CM. Key activities are carried out during each phase of the implementation. At all phases, it is important to reinforce management's commitment to the automation effort and to provide training.
The phases are as follows :
- Phase 1: Preparation and Planning
- Phase 2: Process Definition
- Phase 3: Tool Evaluation
- Phase 4: Pilot Project Implementation
- Phase 5: Roll-out to Other Projects
- Phase 6: Capture and Communicate Improvements
Phase 1 Preparation and Planning
This is the stage most organizations fail to perform, thereby resulting in the unsuccessful automation of CM. The purpose of this phase is to plan for the automation activities, to establish management support, and to assess the status of current CM activities.
First, a CM automation team is created. The automation team is responsible for implementing the automation strategy and plays an important role in the implementation effort. The team monitors and participates in all phases of the automation effort. Members of the automation team typically include:
- A leader who is responsible for the automation effort
- A sponsor who has the authority to empower the team and provide the support required to tackle difficult CM problems
- A champion or technical expert who understands the technology
- Representatives from the user community
The automation team begins by developing the CM automation plan. The plan details the benefits of CM, outlines the automation schedule and resources required, defines the policies and procedures involved in the automation effort, establishes success criteria, and establishes the roles of the automation team.
Next, the requirements are defined and prioritized. Developing a clear understanding of the organization's strategic goals is required to evaluate the CM requirements. The evaluation of CM requirements should not be conducted in a vacuum . All members of the organization who will be affected by CM must be surveyed to identify their CM requirements and to determine their roles in the CM process. Careful attention must be paid to the training requirements of all people affected by the CM tool, process, and procedures.
In addition, all levels of management must be aware of the benefits of CM. Many times, this involves showing financial and scheduling benefits, that is, increase in programmer productivity by automating CM tasks.
Next, an inventory of present hardware and software platforms is conducted and future hardware and software platforms are identified. And, finally, a risk management plan is developed. This plan identifies risks that could affect the outcome of the automation effort. The automation team is responsible for identifying and addressing risks throughout the project.
Phase 2 Process Definition
The goals of this phase are to define the current CM process, evaluate the process, and define a new, improved process if required. The process is then analyzed to identify which areas would benefit from automation. A defined software change process is pertinent to the successful implementation of CM. Without a defined process, the organization will make little progress in the adoption. A variety of methods exist to define the process. Additional information on process definition can be obtained from the SEI, IEEE, or the Software Technology Support Center. During this phase, process-related requirements will be identified. These should be added to the requirements developed in phase 1, as appropriate.
Phase 3 Tool Evaluation
This phase consists of matching the organization's requirement to CM tools. Before the evaluation begins, tool requirements identified in phase 1 are refined and prioritized. The evaluation method is chosen , and test scenarios required to test the capabilities of the tools are developed. It is important to include representatives from all users' groups in the evaluation to gain a better understanding of how different groups will use the tool. Results of a study conducted by the Gartner Group determined that the cost of the software tool represents only 10 percent of the total cost of implementing a solution. Lost productivity accounts for 50 percent, and the remaining 40 percent of the solution is derived from the cost of manpower [Softool 1992].
Many tool vendors are expanding the functionality of their tools to meet the requirements of today's software development organizations. Several companies sell their products as a series of components . For example, the case product handles version control and process control, whereas the problem reporting function may be purchased separately. State-of-the-art CM tools may contain the following features:
- Version control
- Configuration support
- Process support
- Change control
- Team support
- Library and repository support
- Security and protection
- Reporting and query
- Tool integration
- Build support
- Release management
- Customization support
- Graphical user interfaces
- Distributed development
- Client-server development support
- Web support
The CM process should first be defined before tool selection. The tool should implement or automate the defined processes. The tool alone should not be used to define a project's CM process or procedures. It may take as long as six months to completely understand the functionality of a CM tool.
When evaluating CM tools, it is important to assess not just the functionality and robustness of the tool, but the CM-readiness of the tool vendor as well. Appendix Y provides a "Supplier SM Market Analysis Questionnaire" that should be filled out by each potential CM vendor. The key question is: Does the CM tool vendor practice configuration management, or do we have a typical case of the "shoemaker's children?"
Phase 4 Pilot Project Implementation
The purpose of this phase is to determine how well the CM tool, processes, and procedures satisfy the organization's requirements. A pilot project allows testing of the tool's functionality on a real project with real data. In addition, the pilot allows for the prototyping of processes and procedures and provides feedback on how users respond to the tool.
It is important to select a pilot that will address all areas of CM but not affect the project's critical path . The automation team develops standards, policies, and procedures, as well as ensures users are trained to perform their CM duties . Successes and failures are documented and compared to the success criteria identified in the automation plan.
Phase 5 Rollout to Other Projects
This phase involves incremental migration of the tool into other projects. Training and dealing with resistance to change are key activities of this phase. The CM tool, process, procedures, and training needs are examined and adapted for each project. The automation team implements, evaluates , and monitors roll-out activities. This stage is complete when CM is routinely used on all projects.
Phase 6 Capture and Communicate Improvements
This phase involves evaluation of automation activities, capturing strategies that worked, and making recommendations for process improvements. The use of measurements and metrics can be very beneficial during this phase. More details on CM automation can be found in "Adopting an Automated Configuration Management Solution," by Susan Dart in Proceedings of the Software Technology Conference , April 1994.
A SELECTION OF CM TOOLS
A variety of Web sites are dedicated to listing CM tools, including:
- Free or public domain tools: http://www.cmtoday.com/yp/free.html
- Tools FAQ from the comp.software.config-mgmt newsgroup: http://www.daveeaton.com/scm/CMTools.html
- Open directory project CM tools list: http://dmoz.org/Computers/Software/Configuration_Management/Tools
- CM Today Yellow Pages: http://www.cmtoday.com/yp/commercial.html
- Omniseek CM tools: http://www.omniseek.com/srch/{23049}
Table 14.1 contains a listing of CM tools compiled by the author's students.
|
SUMMARY
Configuration management, given the level of detail required, is not possible without the use of an automated tool. This chapter discusses an approach to automation as well as provides a list of CM tools.
| Note |
The introduction to this chapter was adapted from the following report: Software Technology Support Center, United States Air Force, Ogden Air Logistics Center, Software Configuration Management Technologies and Applications, April 1999, www.stsc.hill.af.mil. |
REFERENCES
[Brown et al. 1999] Brown, William, Hays McCormick, and Scott Thomas, AntiPatterns and Patterns in Software Configuration Management , John Wiley & Sons, New York, April 1999 .
[Dart 1994] Dart, Susan A., "Adopting an Automated Configuration Management Solution," Proceedings of Software Technology Conference , April 1994 .
[Softool 1992] Softool Corporation, Successful Software Strategies Seminar Series: Improving Your Configuration Management Implementation Strategy, Washington, D.C., 1992 .
[Ventimiglia 1997] Ventimiglia, Bob, Advanced Effective Software Configuration Management , Technology Training Corporation, 1997 .
Preface
- Introduction to Software Configuration Management
- Project Management in a CM Environment
- The DoD CM Process Model
- Configuration Identification
- Configuration Control
- Configuration Status Accounting
- A Practical Approach to Documentation and Configuration Status Accounting
- Configuration Verification and Audit
- A Practical Approach to Configuration Verification and Audit
- Configuration Management and Data Management
- Configuration Change Management
- Configuration Management and Software Engineering Standards Reference
- Metrics and Configuration Management Reference
- CM Automation
- Appendix A Project Plan
- Appendix C Sample Data Dictionary
- Appendix D Problem Change Report
- Appendix E Test Plan
- Appendix G Sample Inspection Plan
- Appendix I System Service Request
- Appendix J Document Change Request (DCR)
- Appendix K Problem/Change Report
- Appendix L Software Requirements Changes
- Appendix M Problem Report (PR)
- Appendix N Corrective Action Processing (CAP)
- Appendix P Project Statement of Work
- Appendix Q Problem Trouble Report (PTR)
- Appendix S Sample Maintenance Plan
- Appendix T Software Configuration Management Plan (SCMP)
- Appendix U Acronyms and Glossary
- Appendix V Functional Configuration Audit (FCA) Checklist
- Appendix W Physical Configuration Audit (PCA) Checklist
- Appendix X SCM Guidance for Achieving the Repeatable Level on the Software
- Appendix Y Supplier CM Market Analysis Questionnaire
EAN: 2147483647
Pages: 235
- Measuring and Managing E-Business Initiatives Through the Balanced Scorecard
- A View on Knowledge Management: Utilizing a Balanced Scorecard Methodology for Analyzing Knowledge Metrics
- Technical Issues Related to IT Governance Tactics: Product Metrics, Measurements and Process Control
- Governing Information Technology Through COBIT
- Governance Structures for IT in the Health Care Industry
