Read an Excerpt

Chapter 1: Introduction

What is a software process? A software process is a set of project phases, stages, methods, techniques, and practices that people employ to develop and maintain software and its associated artifacts (plans, documents, models, code, test cases, manuals, etc.). Consider the hunting process of Figure 1.1. Although I'm sure the X-Files will eventually provide an explanation as to why the Neanderthals became extinct, my theory is that the implementation of an inappropriate process such as the one presented is a likely candidate to explain their downfall. The point is that not only do you need a software process, you need one that is proven to work in practice, a software process tailored to meet your exact needs.

Why do you need a software process? An effective software process will enable your organization to increase its productivity when developing software. First, by understanding the fundamentals of how software is developed you can make intelligent decisions, such as knowing to stay away from SnakeOil v2.0 - the wonder tool that claims to automate fundamental portions of the software process. Second, it enables you to standardize your efforts, promoting reuse and consistency between project teams. Third, it provides an opportunity for you to introduce industry best practices such as code inspections, configuration management, change control, and architectural modeling to your software organization.

An effective software process will also improve your organization's maintenance and support efforts, also referred to as production efforts, in several ways. First, it should define how to manage change and appropriately allocate maintenancechanges to future releases of your software, streamlining your change process. Second, it should define, first, how to smoothly transition software into operations and support and then, how the operations and support efforts are actually performed. Without effective operations and support processes, your software will quickly become shelfware.

An effective software process considers the needs of both development and production.

Why adopt an existing software process, or improve your existing process using new techniques? The reality is that software is growing more and more complex, and without an effective way to develop and maintain that software, the chances of you succeeding will only get worse. Not only is software getting more complex, you're also being asked to create more software simultaneously. Most organizations have several software projects currently in development and have many more in production - projects that need to be managed effectively. Furthermore, our industry is in crisis; we're still reeling from the simple transition from using a two-digit year to a four-digit year, a "minor" problem with an estimated price tag of $600 billion worldwide. The nature of the software we're building is also changing from the simple batch systems of the 1970s for which structured techniques were geared, to the interactive, international, user-friendly, 24/7, high-transaction, high-availability online systems for which object-oriented and component-based techniques are aimed. And while you're doing that, you are asked to increase the quality of the systems that you're delivering, and to reuse as much as possible so that you can work faster and cheaper. A tall order, one that is nearly impossible to fill if you can't organize and manage your staff effectively. A software process provides the basis to help do just that.

Software is becoming more complex, not less.

1.1 The Unified Process

The Unified Process is the latest endeavor of Rational Corporation (Kruchten, 1999), the same people who introduced what has become the industry-standard modeling notation: the Unified Modeling Language (UML). The heart of the Unified Process is the Objectory Process, one of several products and services that Rational acquired when they merged with Ivar Jacobson's Objectory organization several years ago. Rational enhanced Objectory with their own processes (and those of other tool companies that they have either purchased or partnered with) to form the initial version (5.0) of the Unified Process officially released in December of 1998.

Figure 1.2 presents the initial lifecycle of the Unified Process made up of four serial phases and nine core workflows. Along the bottom of the diagram, you see that any given development cycle through the Unified Process should be organized into iterations. The basic concept is that your team works through appropriate workflows in an iterative manner so at the end of each iteration, you produce an internal executable that can be worked with by your user community. This reduces the risk of your project by improving communication between you and your customers. Another risk reduction technique built into the Unified Process is the concept that you should make a "go/no-go" decision at the end of each phase. If a project is going to fail, then you want to stop it as early as possible in its lifecycle - an important concept in an industry with upwards toward an 80-90% failure rate on large-scale, mission-critical projects (Jones, 1996).

The Inception phase is where you define the project scope and define the business case for the system. The initial use cases for your software are identified and the key ones are described briefly. Use cases are the industry standard technique for defining the functional requirements for systems, providing significant productivity improvements over traditional requirement documents because they focus on what adds value to users as opposed to product features. Basic project management documents are started during the Inception phase, including the initial risk assessment, the estimate, and the project schedule. As you would expect, key tasks during this phase include business modeling and requirements engineering, as well as the initial definition of your environment including tool selection and process tailoring.

You define the project scope and the business case during the Inception phase.

The Elaboration phase, the topic of this volume, focuses on detailed analysis of the problem domain and the definition of an architectural foundation for your project. Because use cases aren't sufficient for defining all requirements, as you'll see in Chapter 4 (which describes the Requirements workflow), a deliverable called a supplementary specification is defined which describes all non-functional requirements for your system. A detailed project plan for the Construction phase is also developed during this phase based on the initial management documents started in the Inception phase.

You define the architectural foundation for your system during the Elaboration phase.

The Construction phase, often the heart of software projects (typically to their detriment), is where the detailed design for your application is developed as well as the corresponding source code. I say that projects focus on this phase to their detriment because organizations often do not invest sufficient resources in the previous two phases and therefore lack the foundation from which to successfully develop software that meets the needs of their users. The goal of this phase is to produce the software and supporting documentation to be transitioned to your user base.

You finalize the system to be deployed during the Construction phase.

The purpose of the Transition phase is to deliver the system to your user community. There is often a beta release of the software to your users, typically called a pilot release within most businesses, in which a small group of users work with the system before it is released to the general community. Major defects are identified and potentially acted upon during this phase. Finally, an assessment is made regarding the success of your efforts to determine whether another development cycle/increment is needed to further enhance the system.

You deliver the system during the Transition phase.

The Unified Process has several strengths. First, it is based on sound software engineering principles such as taking an iterative, requirement-driven, architecture-based approach to development in which software is released incrementally. Second, it provides several mechanisms, such as a working prototype at the end of each iteration and the "go/no-go" decision point at the end of each phase, which provides management visibility into the development process. Third, Rational has made, and continues to make, a significant investment in their Rational Unified Process product (http://www.rational.com/products/rup), an HTML-based description of the Unified Process that your organization can tailor to meet its exact needs.

The Unified Process also suffers from several weaknesses. First, it is only a development process. The initial version of the Unified Process does not cover the entire software process; as you can see in Figure 1.2, it is very obviously missing the concept of operating and supporting your software once it has been released into production. Second, the Unified Process does not explicitly support multi-project infrastructure development efforts such as organization/enterprise-wide architectural modeling, discussed in Chapter 5 (which describes the proposed Infrastructure Management Workflow), missing opportunities for large-scale reuse within your organization. Third, the iterative nature of the lifecycle is foreign to many experienced developers, making acceptance of it more difficult, and the rendering of the lifecycle in Figure 1.2 certainly doesn't help this issue...