Hewlett-Packard Laboratories

(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:

• "Does incremental reuse adoption relate to moving up the SEI Capability Maturity Model?"; and,
• "Can we do significant reuse before CMM Level 3?"

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.

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:

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.

Watts Humphrey, in his classic book "Managing the Software Process"[3], 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)[7], 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.

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[8]. 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.

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.