Software Process Improvement Sequences

The six stages along the path to process improvements usually occur in the same sequence from company to company. The sequence is based on practical considerations. For example, software managers have to produce the cost justifications for investments, so they need to be fully aware of the impacts of the latter stages. Unless project management excellence is achieved first, it is not likely that the latter stages will even occur. Let us consider the initial assessment and baseline stages, and then examine each of the six improvement stages in turn .

18.1.1 Stage 0: Software Process Assessment and Baseline

The first, or 0, stage is numbered so that it is outside the set of six improvement phases. There is a practical reason for this. Neither an assessment nor a baseline, by itself, causes tangible improvement. Some companies forget this important point and more or less stop doing anything after the initial assessment and baseline.

A successful software process improvement begins with a formal process assessment and the establishment of a quantitative baseline of current productivity and quality levels. The assessment is like a medical diagnosis to find all of the strengths and weaknesses associated with software. The baseline is to provide a firm quantitative basis for productivity, schedules, costs, quality, and user satisfaction in order to judge future rates of improvement.

Software process assessments are often performed by consulting groups licensed to use the methodology developed by the Software Engineering Institute (SEI). However, other assessment methods are available as well. Assessments are concerned primarily with qualitative information such as the presence or absence of a quality assurance function.

In addition to qualitative assessment information, it is also useful to record quantitative baseline data. A baseline is a snapshot of the organization's productivity levels, quality levels, schedules, and costs at the time of the assessment. The baseline data serve to demonstrate future progress. Function point metrics are widely used for baseline data collection, because they cover such a wide range of activities.

Many companies also commission quantitative benchmarks to judge their performance against similar companies in the same industry, such as banking, insurance, telecommunications, defense, or whatever. A benchmark is a formal comparison of software methods and quantitative results against those of similar organizations. External benchmarks are often performed by third-party consulting groups such as Compass Group, David Consulting Group, Gartner Group, the International Function Point Users Group, Meta Group , Howard Rubin Associates, and Software Productivity Research. These companies have large collections of software data from many companies and industries.

Assessments, baselines, and benchmarks are all valuable and are synergistic. Assessments alone lack the quantification of initial quality and productivity levels needed to judge improvements later. A quantitative baseline is a prerequisite for serious process improvements, since the cost justification for the initial investments have to be proved by comparing results against the baseline. External benchmarks against other companies are an optional but useful adjunct to software process improvement tasks .

Since it is likely that the quantitative data will be collected using function point metrics. A short discussion of function point metrics may be useful. Function point metrics were developed by A. J. Albrecht and colleagues at IBM in the mid 1970s (Albrecht 1979). The function point metric was placed in the public domain by IBM in 1978, and responsibility for function point counting rules was taken over by a non-profit organization in 1984. The organization responsible for defining function point counting rules is the International Function Point Users Group (IFPUG). (Refer to the IFPUG Web site (http://www.IFPUG.org) for additional information.) A new primer on function point analysis was recently published by Herron and Garmus (2001), who are officers in the IFPUG organization).

Function points are derived from the external aspects of software applications. Five external attributes are enumerated: inputs, outputs, inquiries, logical files, and interfaces. Because the counting rules are complex, accurate counting of function points is normally carried out by specialists who have passed a certification exam administered by the IFPUG organization.

Compared to lines of code, or LOC, metrics function points offer some significant advantages for baselines and benchmarks. Because coding is only part of the work of building software, LOC metrics have not been useful for measuring the volume of specifications, the contributions of project management, or the defects found in requirements and design documents. Further, LOC metrics tend to behave erratically from language to language. Indeed, for some languages such as Visual Basic, there are no effective LOC counting rules.

Because function point metrics can measure all software activities (i.e., requirements, design, coding, testing, documentation, management, etc.), they have become the de facto standard for software baselines and benchmarks. This is not to say that function point metrics have no problems of their own. But for collecting quantitative data from software projects, function points offer such significant advantages to LOC metrics that most of the published software benchmark data uses function point metrics. Let us now consider what happens after the assessment, baseline, and benchmark data are collected.

18.1.2 Stage 1: Focus on Management Technologies

Because software project management is a weak link on software projects, the first improvement stage concentrates on bringing managers up to speed on critical technologies such as planning, sizing, cost estimating, milestone tracking, quality and productivity measurement, risk analysis, and value analysis. It is necessary to begin with managers, because they are the ones who need to calculate the returns on investment that will occur later. They also have to collect the data to demonstrate progress. Unless managers are trained and equipped for their roles, it is not likely that progress will be significant.

18.1.3 Stage 2: Focus on Software Processes and Methodologies

The second stage concentrates on improved approaches for dealing with requirements, design, development, and quality control. Since tools support processes, rather than the other way around, new development processes need to be selected and deployed before investments in tools occur.

Some of the proved processes deployed in this stage include joint application design (JAD), any of several formal design methods such as Warnier-Orr, Yourdon, Merise, the Unified Modeling Language (UML), and several others. Formal design and code inspections and formal change management procedures are also selected and deployed during this stage.

18.1.4 Stage 3: Focus on New Tools and Approaches

As improved software processes begin to be deployed it is appropriate to acquire new tools and to explore advanced or new technologies. It is also the time to explore difficult technologies with steep learning curves such as client-server methods and the object-oriented paradigm. Jumping prematurely into client-server projects, or moving too quickly toward object-oriented analysis and design, usually means trouble because poorly trained practitioners are seldom successful. The first-time failure rate of new technologies is alarmingly high. Therefore, careful selection of new technologies and thorough training of personnel in the selected technologies are prerequisites to successful deployment of new technology.

Some of the kinds of tools acquired during this stage might include configuration control tools, code complexity analysis tools, test case monitors , analysis and design tools, and perhaps advanced language tools for Java or very high-level programming languages.

18.1.5 Stage 4: Focus on Infrastructure and Specialization

To reach the top plateau of software excellence, it is necessary to have a top- notch organizational structure as well as excellent tools and methods.

The infrastructure stage deals with organization and specialization, and begins to move toward establishment of specialized teams for handling critical activities. It has long been known that specialists can outperform generalists in a number of key software tasks. Some of the tasks where specialists excel include testing, maintenance, integration, configuration control, technical writing, and quality assurance. Policies on continuing education are important too during this stage.

In addition to better development processes and better tool suites, industry leaders are usually characterized by better organizational structures and more specialists than average companies, and much better than laggards.

18.1.6 Stage 5: Focus on Reusability

Reusability has the best return on investment of any software technology, but effective reuse is surprisingly difficult. For a general discussion of software reuse, refer to Jacobsen et al. (1997).

If software quality control is not at state-of-the-art levels, then reuse will include errors that cause costs to go up instead of down. Also, reuse includes much more than just code. In fact, an effective software reuse program should include a minimum of six reusable artifacts:

1. Reusable requirements
2. Reusable designs and specifications
3. Reusable source code
4. Reusable user documents
5. Reusable test plans
6. Reusable test cases and test scripts

If only source code is reused, the return on investment will be marginal. Optimal benefits occur only when reusability spans all major deliverable items.

18.1.7 Stage 6: Focus on Industry Leadership

Organizations that go all the way to the sixth stage are usually the leaders in their respective industries. These organizations are the kind that would be found at level 5 on the SEI capability maturity model (CMM). These organizations may be in a position to acquire competitors. They can almost always outperform their competitors in all phases of software development and maintenance work unless the competitors are also at the top.

Industry leadership is a coveted goal that many companies strive to achieve, but few do. Among the attributes of industry leadership that are visible to outside consultants , the following twelve factors stand out:

• Effective project management tool suites
• Effective software development tool suites
• Effective quality assurance and testing tool suites
• Effective software processes and methods
• Effective organizational structures
• Effective management teams
• Effective technical teams with substantial specialization
• High morale among the software staff
• High user-satisfaction levels as noted by customer surveys
• High regard by top corporate management
• High regard by industry analysts
• High regard by competitive organizations

No company examined so far has been excellent in every attribute of software success, but the leaders are superior in many attributes.

Let us examine the costs, timing, and anticipated results of software process improvement activities as noted among our clients engaged in process improvement activities.