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 ProcessThe 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]
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 functionality[10] 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 ModelThe 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]
The five levels of the CMM, in order of developing maturity, are as follows:
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 StandardThis 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:
Figure 1.10. ISO 9000-3 Software Development ModelThe 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:
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 9000A 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.
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. |