CMM as a Framework for Adopting Systematic Reuse
Martin L. Griss, Laboratory Scientist, (email@example.com)
Software Technology Laboratory
(OBM10 - Published in the Object Magazine, March, 1998, pp. 60-62,69.)
When I discuss software reuse architecture, process, and organization, I almost always get asked two related questions:
In this and subsequent columns, I discuss how incremental reuse adoption ("reuse program") can be integrated with improving the software development process ("SEI program").
The answer to the questions is a qualified "yes." It makes good business sense to link incremental reuse improvement to a staged SEI process improvement effort. One can certainly do significant reuse before reaching CMM Level 3, and a staged reuse program can help in moving the SEI program forward more quickly. An effective process improvement plan will address these two programs together.
It is believed that until CMM Level 3 ("Defined Process") is achieved, when the entire organization is able to follow an explicitly defined process, it is hard to systematically make sweeping process and technology changes. In particular, effective pervasive software reuse requires many, if not most, projects in the organization to follow compatible managed processes to create, support or reuse assets. CMM Level 3 is a significant indicator that the organization has achieved a process maturity and readiness for change to this level of formal multi-project coordination.
Highly cost-effective, organization-wide reuse will require the discipline and formal processes characteristic of CMM Level 3 or higher. However, significant progress to increased reuse can be made with lower levels of process maturity. Even a lesser amount of reuse can be of significant value in reaching critical business goals such as reduced time to market. To achieve significant reuse at CMM 2 or below requires more active management attention and active championship than in more process mature CMM Level 3 organization.
First and foremost, introducing systematic software reuse is a significant process improvement, driven by critical business need. The CMM is a process improvement framework that summarizes key guidelines about mature software process, which can be directly applied to improved reuse practice. The change to a set of concurrent, managed and supported multi-project creator/reuser process demands significant organization changes and standardized process throughout the organization.
In this column I will start with high-level connections between incremental reuse adoption and the SEI CMM. In my next column, I will describe how specific SEI CMM Key Process Areas (KPAs) and the Personal Software Process (PSP) can support reuse.
Incremental Adoption of Reuse
In my first two columns for Object Magazine[1,2] I discussed how reuse should be adopted incrementally. It is best to introduce large-scale reuse in stages, making organization and process changes in a series of steps. For most organizations, I encourage focussing staged improvement steps on a set of pilot projects. I also suggest that the improving reuse-oriented process can be used as a vehicle to focus more general process improvement.
To illustrate the stages, I use a simplified Reuse Maturity Model (RMM), Figure 1. An organization becomes ready for a transition when its business issues motivate change.
Figure 1 Incremental adoption of reuse is driven by compelling business need.
These stages are:
RMM 1 - No-reuse - Some code sharing may occur, but people work independently on fairly unrelated projects. They do not communicate about their code, and often take pride in "doing it all" themselves.
RMM 2 -Informal code salvaging - Chunks of code are copied and adapted from one system, into a new systems. This occurs when developers are familiar with each other's code, trust each other, and feel the need to reduce time to market, even though they would prefer to rewrite the software.
RMM 3 -Planned black-box code reuse - While informal code salvaging will reduce development time and testing, maintenance problems soon increase. Multiple copies of the software, each slightly different, have to be managed. Defects found in one copy have to be found and fixed multiple times. The next stage is a planned "black box" code reuse strategy in which carefully chosen instances of code are reengineered, tested and documented for reuse. Projects are then encouraged or required to use this copy without modification.
RMM 4 - Managed workproduct reuse -This addresses the changes inevitably needed to satisfy an increasing number of reusers arises. Should everyone be "forced" to use only the standard version? Should multiple versions be maintained? Should adaptation be allowed? Who decides? Should test files, designs and specifications also be reused? This leads to a component management process, with distinct creator and reuse projects, and a support organization. People need education and help in using these components. Strong configuration management processes and tools are needed.
RMM 5- Architected reuse - To get higher levels of reuse, and more coverage from design to implementation, it is important to architect the components and the systems that will use them. This is the only way to ensure that components fit together. The development and use of a common architecture involves even more organizational commitment and structure. Groups of people have to work together to agree on and then enforce interfaces and feature sets.
RMM 6 - Pervasive domain-specific reuse -Product lines are planned, and architecture and components are defined to ensure maximum reuse. Component development is carefully scheduled and resourced to optimize the use of resources and ensure the quickest return on the reuse investment. People will specialize in different roles, such as architecting for reuse, domain engineering, component engineering and reuse library management. Separate teams operate in a concurrent, coordinated way
This simplified RMM summarizes reuse experiences at several organizations within HP and elsewhere. Benefits, such as improved time to market, higher-quality systems, or lower overall development costs, increase as the levels of reuse and the sophistication of the reuse program increase.
CMM is a Reuse-Friendly Process Improvement Framework
Watts Humphrey, in his classic book "Managing the Software Process", and his more recent work on the Personal Software Process[4-6], stresses the importance of individual and organizational self-discipline in achieving improved software development productivity and predictability. This work led to the Software Capability Maturity Model (CMM), a framework for describing and evaluating the capability of software development organizations. It identifies five levels that an organization must go through, as the organization increases its mastery of key process elements and improves its discipline. These steps are summarized in Table 1, identifying the focus of improvement efforts and the Key Process Areas (KPAs) that must be addressed at each level.
Key Process Areas
Continuous process improvement
Technology change management
Process change management
Product and process quality
Quantitative process management
Software quality management
Engineering processes and organizational support
Organization process focus
Organization process definition
Integrated software management
Software product engineering
Project management processes
Software project planning
Software project tracking and oversight
Software subcontract management
Software quality assurance
Software configuration management
Competent people and heroics
No specific formal processes
Table 1 Focus and Key Process Areas in SEI Capability Maturity Model
The CMM prescribes a series of process practices that must be mastered at each level. Each provides a base for improved reuse practice. The desire to improve reuse is a business motivator to focus attention on the corresponding CMM areas. Of course, the kind and precision of reuse practiced at CMM level 1 or 2 is different from reuse that can be practiced at Level 3 or higher.
Projects and organizations can not easily jump steps needed to achieve mastery at a particular level, although they can be working on mastering and institutionalizing skills on one level while learning and installing activities associated with other steps. It is common to find different projects at different CMM levels within a single organization; some projects will have mastered skills and disciplines that other projects are still struggling with. Each level represents a cluster of related activities and skills that must be mastered and institutionalized before there is enough stability, experience and trust in the process to move to the next steps.
While the CMM describes the kinds of processes found to be key to improving organizational discipline (the KPAs at each step in Table 1), and how well the organization should perform these, it does not prescribe the processes in detail. The CMM enables and facilitates good work, but does not guarantee it. Engineers must use effective personal practices. A specific process improvement plan must describe standard processes, metrics and training, that match the specific business and software development needs of the organization. This is where the Personal Software Process (PSP)[4-6] (PSP) comes in, with its bottom-up approach to process improvement. PSP demonstrates process improvement principles for individual engineers so they see how to efficiently produce quality products.
The PSP and the CMM are mutually supportive. The CMM provides the orderly support environment engineers need to do superior work, and the PSP equips engineers to do high quality work and participate in organizational process improvement. More about how the PSP supports reuse in my next column.
Because of the strict requirements of CMM, it normally takes an organization about 36 months to go from Level-1 to Level-2 . The HP Software Engineering Systems Division (SESD) was able to reach 100% level-2 CMM compliance in less than a year. To support its transition, SESD created an online WWW based "Project Notebook", containing PSP-like standard templates and guidelines for all lifecycle phases of a project.
Integrating Reuse Adoption with CMM and PSP-Driven Improvement
To get increasingly systematic reuse, certain processes and skills have to be defined with increasing rigor, and followed with increasing precision. Several of the CMM KPAs support reuse. An effective reuse program will require multi-project management. Configuration management is key to effective multi-project black-box reuse. Peer reviews help ensure the quality of components. Requirements need to be carefully managed.
Informal code salvaging (RMM 2) can be practiced by individuals without much coordination (at CMM 1) by finding the "best" starting source. They then "own" the source, and get minimal support from the developers of the source. Informal code salvaging can be made more systematic by sharing a common "platform" source, under configuration control, and propagating defect repair consistently. This moves towards repeatable performance (at CMM 2).
In order for black box code reuse (RMM 3) to work, the organization needs more discipline and more standards. Individuals and projects have to trust the quality of components and responsiveness of other projects to component support. Initially, the organization will know that this works because they have done it before, and they will trust it will work. This means that the organization should be operating in a repeatable (CMM2) way.
The CMM 2 Repeatable level is based on reusable assets in the form of templates, checklists, and procedures that specifically address project management practices within a team. CMM 3 Defined level requires that these assets be made explicit for the organization in a Process Repository, with the understanding that the assets have been broadened for multi-team use and that specific guidelines are followed for "tailoring" the assets to suit a project's needs. These are analogous to "black box" code objects for reuse (repeatable construction aids) that a project is likely to need on the next project. And then stepping up to a more general process for constructing reuse objects for multiple teams or products, it is expected that the life cycle artifacts (specifications, designs, tests) will be integral to the process of reusing the assets in specific projects. In this way, reusable "code" can be considered just another artifact of the overall software development process, but with the need for specific procedures to ensure the "reusability" across teams.
At CMM Level 1 or 2, Creator and Reuser projects can be at different levels of both CMM and RMM. CMM Level 2 is mostly about getting each project team to operate with repeatable project. These practices are not necessarily the same or consistent across the organization. This "impedance mismatch" can lead to significant problems and incompatible expectations, and to sub-optimal reuse. For example, if Creators are at a lower level of process maturity, their schedule is less predictable and their software might be of lower quality, and accompanied by fewer supporting workproducts than the higher maturity Reusers expect. Conversely, if the Creators are at higher maturity levels, they will deliver software and supported workproducts that require more adherence to architectural and black box reuse standards for effective reuse than the Reusers are accustomed to.
Effective systematic reuse is intimately related to increased process maturity. As individuals, projects and the entire organization become more skilled and disciplined in following standard processes, using and creating standard templates, documents and software artifacts, their levels of reuse increase.
Significant reuse process improvement begins near CMM 2. Efforts to improve the reuse program helps move the organization towards CMM 3 and higher. Black box and managed reuse require significant configuration management and project coordination, characteristic of CMM Level 2. Architected reuse requires more wide-spread organizational structure and formal process and workproduct standards, characteristic of CMM Level 3.
One should design a coordinated SEI CMM driven process improvement and systematic reuse program. Many of the CMM process improvement steps and KPAs can be oriented towards improving the production, handing and use of various reusable artifacts. More on how the specific KPAs and PSP support reuse in my next column.
Thanks to Doug Lowe for numerous suggestions for this column.
 M Griss "Software Reuse: A process of getting organized." Object Magazine, May 1995.
 M Griss and P Collins-Cornwell "Pilots in incremental adoption of reuse" Object Magazine, July 1995.
 WS Humphrey,"Managing the Software Process", Addison-Wesley, 1989
 WS Humphrey, "A Discipline for Software Engineering," Addison-Wesley, 1995.
 WS Humphrey, Using a Defined and Measured Personal Software Process, IEEE Software, May 1996, pp. 77-88.
 WS Humphrey, The Personal Software Process and Personal Project Estimating, American Programmer, vol. 9, no. 6, June 1996, pp. 2-15.
 MC Paulk, et al, "Capability Maturity Model, Version 1.1", IEEE Software 10(4), July 1993, pp.18-27.See alsot http://www.sei.cmu.edu/technology.for CMM and PSP.
 B Curtis, WE Hefley, and S Miller. "People Capability Maturity Model", Software Engineering Institute, CMU/SEI-95-MM-02, Sept 1995.
 DE Lowe and GM Cox, Implementing the Capability Maturity Model for Software Development, HP Journal, August 1996.