Feature The following article is the introductory chapter from The Unified Development Process by Ivar Jacobson, Grady Booch, and James Rumbaugh. These “three amigos”have been influential in creat- ing a standardized object-oriented analysis and design notation, UML. This offering describes the three amigos’vision of a standardized software development process. —Steve McConnell, editor-in-chief The Unified Process Ivar Jacobson, Grady Booch, and James Rumbaugh, Rational Software oday, the trend in software is toward bigger, more complex systems. This is due in part to the fact that computers become more powerful T every year, leading users to expect more from them. This trend has also been influenced by the expanding use of the Internet for exchanging all kinds of information—from plain text to formatted text to pictures to diagrams to multimedia. Our appetite for ever-more sophisticated software grows as we learn from one product release to the next how the product could be improved. We want software that is better adapted to our needs, but that, in turn, merely makes the software more complex. In short, we want more. We also want it faster. Time to market is another important driver. Getting there, however, is difficult. Our demands for powerful, complex software have not been matched with how software is developed. Today, most people de- velop software using the same methods that were used as long as 25 years ago. This is a problem. Unless we update our methods, we will not be able to accomplish our goal of developing the complex software needed today. The software problem boils down to the difficulty developers face in pulling to- gether the many strands of a large software undertaking. The software development community needs a controlled way of working. It needs a process that integrates the many facets of software development. It needs a common approach, a process that 96 IEEE Software May/June 1999 Feature ♦ provides guidance to the order of a team’s ac- tivities, ♦ directs the tasks of individual developers and the team as a whole, ♦ specifies what artifacts should be developed, and ♦ offers criteria for monitoring and measuring a Figure 1. A software development process. project’s products and activities. The presence of a well-defined and well-man- aged process is a key discriminator between hyper- The term user refers not only to human users but productive projects and unsuccessful ones. The to other systems. In this sense, the term user repre- Unified Software Development Process—the out- sents someone or something (such as another sys- come of more than 30 years of experience—is a so- tem outside the proposed system) that interacts lution to the software problem. with the system being developed. An example of an interaction is a human who uses an automatic teller machine. He or she inserts the plastic card, replies THE UNIFIED PROCESS IN A to questions called up by the machine on its view- NUTSHELL ing screen, and receives a sum of cash. In response to the user’s card and answers, the system performs First and foremost the Unified Process is a soft- a sequence of actions that provide the user with a re- ware development process. A software develop- sult of value, namely the cash withdrawal. ment process is the set of activities needed to trans- An interaction of this sort is a use case. A use case form a user’s requirements into a software system is a piece of functionality in the system that gives a (see Figure 1). However, the Unified Process is more user a result of value. Use cases capture functional than a single process; it is a generic process frame- requirements. All the use cases together make up work that can be specialized for a very large class of the use-case model, which describes the complete software systems, for different application areas, dif- functionality of the system. This model replaces the ferent types of organizations, different competence traditional functional specification of the system. A levels, and different project sizes. functional specification can be said to answer the The Unified Process is component-based, which question, What is the system supposed to do? The means that the software system being built is made use case strategy can be characterized by adding up of software components interconnected via well- three words to the end of this question: for each defined interfaces. user? These three words have a very important im- The Unified Process uses the Unified Modeling plication. They force us to think in terms of value to Language when preparing all blueprints of the soft- users and not just in terms of functions that might ware system. In fact, UML is an integral part of the be good to have. Unified Process—they were developed hand in However, use cases are not just a tool for speci- hand. fying the requirements of a system. They also drive However, the real distinguishing aspects of the its design, implementation, and test; that is, they Unified Process are captured in the three key drive the development process. Based on the use- words—use-case driven, architecture-centric, and case model, developers create a series of design and iterative and incremental. This is what makes the implementation models that realize the use cases. Unified Process unique. The developers review each successive model for conformance to the use-case model. The testers test the implementation to ensure that the components THE UNIFIED PROCESS IS of the implementation model correctly implement USE-CASE DRIVEN the use cases. In this way, the use cases not only ini- tiate the development process but bind it together. A software system is brought into existence to Use-case driven means that the development serve its users. Therefore, to build a successful sys- process follows a flow—it proceeds through a series tem we must know what its prospective users want of workflows that derive from the use cases. Use and need. cases are specified, use cases are designed, and at May/June 1999 IEEE Software 97 Feature the end use cases are the source from which the How are use cases and architecture related? Every testers construct the test cases. product has both function and form. One or the While it is true that use cases drive the process, other is not enough. These two forces must be bal- they are not selected in isolation. They are developed anced to get a successful product. In this case func- in tandem with the system architecture. That is, the tion corresponds to use cases and form to architec- ture. There needs to be interplay between use cases and architec- The architecture must be designed to allow the ture. It is a “chicken and egg”prob- system to evolve, not only through its initial lem. On the one hand, the use development but through future generations. cases must, when realized, fit in the architecture. On the other hand, the architecture must allow use cases drive the system architecture and the sys- room for realizations of all the required use cases, tem architecture influences the selection of the use now and in the future. In reality, both the architec- cases. Therefore, both the system architecture and ture and the use cases must evolve in parallel. the use cases mature as the life cycle continues. Thus the architects cast the system in a form. It is that form, the architecture, that must be designed so as to allow the system to evolve, not only through THE UNIFIED PROCESS IS its initial development but through future genera- ARCHITECTURE-CENTRIC tions. To find such a form, the architects must work from a general understanding of the key functions, The role of software architecture is similar in na- that is, the key use cases, of the system. These key ture to the role architecture plays in building con- use cases may amount to only 5 percent to 10 per- struction. The building is looked at from various cent of all the use cases, but they are the significant viewpoints: structure, services, heat conduction, ones, the ones that constitute the core system func- plumbing, electricity, and so on. This allows a tions. Here is the process in simplified terms: builder to see a complete picture before construc- ♦ The architect creates a rough outline of the ar- tion begins. Similarly, architecture in a software sys- chitecture, starting with the part of the architecture tem is described as different views of the system that is not specific to the use cases (such as plat- being built. form). Although this part of the architecture is use- The software architecture concept embodies the case independent, the architect must have a gen- most significant static and dynamic aspects of the eral understanding of the use cases prior to the system. The architecture grows out of the needs of creation of the architectural outline. the enterprise, as sensed by users and other stake- ♦ Next, the architect works with a subset of the holders, and as reflected in the use cases. However, identified use cases, the ones that represent the key it is also influenced by many other factors: the plat- functions of the system under development. Each form the software is to run on (such as computer ar- selected use case is specified in detail and realized chitecture, operating system, database manage- in terms of subsystems, classes, and components. ment system, and protocols for network ♦ As the use cases are specified and they mature, communication), the reusable building blocks avail- more of the architecture is discovered. This, in turn, able (such as a framework for graphical user inter- leads to the maturation of more use cases.