Home > Articles > Programming

  • Print
  • + Share This
This chapter is from the book

Software Process Improvement

Although the legacy models for software development just discussed are honored by time and are used extensively even today, they are surely not the latest thinking on this subject. We will describe only briefly RUP, CMM, and ISO 9000 software process improvement development models, because they will receive attention in later chapters. These are very different things but are considered here as a diverse set of technologies that are often "compared" by software development managers. RUP and CMM are the result of considerable government-sponsored academic research and industrial development. When rigorously applied, they yield good, even excellent, results. They also provide a documentation trail that eases the repair of any errors and bugs that do manage to slip through a tightly crafted process net. These newer methods are widely used by military and aerospace contractors who are required to build highly secure and reliable software for aircraft, naval vessels, and weapons systems. In our experience they have had relatively little impact on enterprise software development so far, whether internally or by way of third-party vendors.

Rational Unified Process

The Rational Unified Process (RUP) is modeled in two dimensions, rather than linearly or even circularly, as the previously described models are. The horizontal axis of Table 1.2 represents time, and the vertical axis represents logical groupings of core activities.8

Table 1.2 A Two-Dimensional Process Structure—Rational Unified Model

 

Phase

Workflow

Inception

Elaboration

Construction

Transition to Next Phase

Application model

Definition

Comparison

Clarification

Consensus

Requirements

Gathering

Evaluation

User review

Approval

Architecture

Analysis

Design

Implementation

Documentation

Test

Planning

Units test

System test

Regression testing

Deployment

User training

User planning

Site installation

User regression testing

Configuration management

Long-range planning

Change management

Detailed plan for evolution

Planning approvals

Project management

Statements of work

Contractor or team identification

Bidding and selection

Let contracts or budget internal teams

Environment

Hiring or relocation

Team building

Training

Certification


The Rational Model is characterized by a set of software best practices and the extensive application of use cases. A use case is a set of specified action sequences, including variant and error sequences, that a system or subsystem can perform interacting with outside actors.9 The use cases are very effective at defining software functionality10 and even planning to accommodate error or "noise." However, the RUP’s most important advantage is its iterative process that allows changes in functional requirements also to be accommodated as they inevitably change during system development. Not only do external circumstances reflect changes to the design, but also the user’s understanding of system functionality becomes clearer as that functionality develops. The RUP has been developing since 1995 and can claim well over 1,000 user organizations.

Capability Maturity Model

The Capability Maturity Model (CMM) for software development was developed by the Software Engineering Institute at Carnegie Mellon University. CMM is an organizational maturity model, not a specific technology model. Maturity involves continuous process improvement based on evaluation of iterative execution, gathering results, and analyzing metrics. As such, it has a very broad universe of application. The CMM is based on four principles:11

  • Evolution (process improvement) is possible but takes time. The process view tells us that a process can be incrementally improved until the result of that process becomes adequately reliable.

  • Process maturity has distinguishable stages. The five levels of the CMM are indicators of process maturity and capability and have proven effective for measuring process improvement.

  • Evolution implies that some things must be done before others. Experience with CMM since 1987 has shown that organizations grow in maturity and capability in predictable ways.

  • Maturity will erode unless it is sustained. Lasting changes require continued effort.

The five levels of the CMM, in order of developing maturity, are as follows:

  • Level 1 (Ad Hoc): Characterized by the development of software that works, even though no one really understands why. The team cannot reliably repeat past successes.

  • Level 2 (Repeatable): Characterized by requirements management, project planning, project tracking, quality assurance, configuration management.

  • Level 3 (Defined): Organization project focus and project definition, training program, integrated software management, software product engineering, intergroup coordination, peer reviews.

  • Level 4 (Managed): Quantitative process management, software quality management.

  • Level 5 (Optimizing): Defect prevention, technology change management, process change management.

Note that level 3 already seems to be higher than most software development organizations attain to, and would seem to be a very worthy goal for any development organization. However, the CMM has two levels of evolutionary competence/capability maturity above even this high-water mark. CMM as well as Capability Maturity Model Integration (CMMI) and PCMM (People Capability Maturity Model) have had enthusiastic acceptance among software developers in India. In 2000, the CMM was upgraded to CMMI. The Software Engineering Institute (SEI) no longer maintains the CMM model. IT firms in India accounted for 50 out of 74 CMM level 5-rated companies worldwide in 2003.12 They are also leading in other quality management systems, such as Six Sigma, ISO 9001, ISO 14001, and BS 7799. It would seem that embracing a multitude of systems and models has helped software developers in India take a rapid lead in product and process improvement, but still there is no silver bullet!

ISO 9000-3 Software Development Guidance Standard

This guidance standard is a guideline for the application of standards to the development, supply, and maintenance of computer software. It is not a development model like RUP or even a organization developmental model like CMM. Neither is it a certification process. It is a guidance document that explains how ISO 9001 should be interpreted within the software industry (see Figure 1.10). It has been used since 1994, having been introduced as ISO 9001 Software Quality Management.13 It was updated in 2002 as ISO 9000-3. Prudent compliance of ISO 9000-3 may result in the following benefits:

  • Increases the likelihood of quality software products

  • Gives you a competitive advantage over non-ISO 9000 certified development vendors

  • Assures customers of the end product’s quality

  • Defines the phases, roles, and responsibilities of the software development process

  • Measures the efficiency of the development process

  • Gives structure to what is often a chaotic process

Figure 1.10

Figure 1.10 ISO 9000-3 Software Development Model

The document was designed as a checklist for the development, supply, and maintenance of software. It is not intended as a certification document, like other standards in the ISO 9000 series. Copies of the guideline can be ordered from the ISO in Switzerland. Also, many consulting firms have Web sites that present the ISO 9000-3 guidelines in a cogent, simplified, and accessible way.14

The Tickit process was created by the British Computer Society and the United Kingdom Department of Trade and Industry for actually certifying ISO 9000-3 software development.15 This partnership has turned the ISO 9000-3 guideline standard into a compliance standard. It allows software vendors to be certified for upholding the ISO 9000-3 standard after passing the required audits. As with other ISO 9000 standards, there is a great deal of emphasis on management, organization, and process that we will not describe in this brief overview. Rather, we will emphasize the ISO development procedures that control software design and development. These include the use of life-cycle models to organize and create a suitable design method by reviewing past designs and considering what is appropriate for each new project. The following three sets of issues are addressed:

  • Preparation of a software development plan to control:

    • Technical activities (design, coding, testing)

    • Managerial activities (supervision, review)

    • Design input (functional specs, customer needs)

    • Design output (design specs, procedures)

    • Design validation

    • Design verification

    • Design review

    • Design changes

    • Development of procedures to control the following documents and data:

    • Specifications

    • Requirements

    • Communications

    • Descriptions

    • Procedures

    • Contracts

  • Development of procedures to plan, monitor, and control the production, installation, and service processes for managing the following:

    • Software replication

    • Software release

    • Software installation

    • Develop software test plans (for unit and integration testing)

    • Perform software validation tests

    • Document testing procedures

Much of this sounds like common sense, and of course it is. The advantage of incorporating such best practices and conventional wisdom into a guidance standard is to encourage uniformity among software vendors worldwide and leveling of software buyers' expectations so that they are comfortable with purchasing and mixing certified vendors' products.

Comparison of RUP, CMM, and ISO 9000

A brief comparison of these process improvement systems is provided in Table 1.3. Such a comparison is a bit awkward, like comparing apples and oranges, but apples and oranges are both fruit. In our experience, software development managers often ask each other, "Are you using RUP, CMM, or ISO 9000?" as if these were logically discrete alternatives, whereas they are three different things.

Table 1.3 Comparison of RUP, CMM, and ISO 9000

Method

Pros

Cons

RUP

Well supported by tools
Supports OOP development
More than 1,000 users

Expensive to maintain
High training costs
Used downstream with RSDM

CMM

Sets very high goals
Easy to initiate
Hundreds of users

Completely process-oriented
Requires long-term top management support

ISO 9000-3

Provides process guidelines
Documentation facilitated
Comprehensive, detailed

Some firms may seek to gain certification without process redesign


The RUP is very well supported by an extensive array of software development and process management tools. It supports the development of object-oriented programs. It is expensive to install and has a rather steep learning curve with high training costs but is well worth the time and cost to implement. RUP is estimated to be in use by well over 1,000 firms. Its usability with RSDM will be detailed later. The CMM sets very high ultimate goals but is easy to initiate. However, it does require a long-term commitment from top management to be effective over time and to be able to progress to maturity level 3 and beyond. It is estimated to have well over 400 users in the United States. As stated earlier, it is very popular in India, where the majority of CMM user firms are located. ISO 9000-3 was updated in 2002. It is essential for the development of third-party enterprise software to be sold and used in the EEC. A large number of consulting firms in both Europe and North America are dedicated to training, auditing, and compliance coaching for ISO 9000. Users report that it works quite well, although at first it appears to be merely institutionalized common sense. Perhaps the only downside is, because it is a required certification, some firms may just try to get the certification without really redesigning software development processes to conform to the guidelines.

Table 21.4 in Chapter 21 compares different quality systems currently common in software companies. These systems serve different needs and can coexist. The need for integration is discussed in Chapter 21 (see Case Study 21.1) and Chapter 27.

  • + Share This
  • 🔖 Save To Your Account