- Software Development: The Need for a New Paradigm
- Software Development Strategies and Life-Cycle Models
- Software Process Improvement
- ADR Method
- Seven Components of the Robust Software Development Process
- Robust Software Development Model
- Key Points
- Additional Resources
- Internet Exercises
- Review Questions
- Discussion Questions and Projects
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 StructureRational 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 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 |
Expensive
to maintain |
CMM |
Sets
very high goals |
Completely
process-oriented |
ISO 9000-3 |
Provides
process guidelines |
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.