With this structure, the Rational Unified Process
The Rational Unified Process model is built on three fundamental entities: workers, activities, and artifacts.
Workflows relate activities and workers in sequences that
Guidelines, templates, and tool mentors complement the description of the process by providing detailed guidance to the practitioner.
The Rational Unified Process is a process framework that is organized to enable the configuration of its static structure.
This chapter describes the lifecycle structure of the Rational Unified Process ”that is, how the process rolls out over time. We introduce the concept of iterative development, with its phases, milestones, and iterations, as well as the factors that drive the process: risk mitigation and incremental evolution.
It has become fashionable to blame many problems and failures in software development on the sequential, or waterfall, process depicted in Figure 4-1. This is rather surprising because at first this method seems like a reasonable approach to system development.
Many engineering problems are
Completely understand the problem to be solved, its requirements, and its constraints. Capture them in writing and get all interested parties to agree that this is what they need to achieve.
Design a solution that satisfies all requirements and constraints. Examine this design
Implement the solution using your best engineering techniques.
Verify that the implementation satisfies the stated requirements.
Deliver. Problem solved!
That is how skyscrapers and bridges are built. It's a rational way to proceed but only because the problem domain is relatively well known;
By contrast, software engineers have had only a few decades to explore their field. Software developers worked very hard, particularly in the seventies and eighties, to accumulate experimental results in software design and construction. In 1980, I would have sworn that the sequential process was the one and only reasonable approach.
If the sequential process is ideal, however, why aren't the projects that use it more successful? There are many reasons:
We made the wrong assumptions.
The context of software development is somewhat different from that of other engineering disciplines.
We have failed to
We have tried to stretch an approach that works in certain
We are still only in the exploratory phase of software engineering. We do not have the experience of hundreds of years of trial and error that makes building a bridge appear to be a mechanical process. This is the primary reason.
Let us review two fundamentally wrong assumptions that often hinder the success of software projects.
Notice that in the description of the sequential process we assume in step 1 that we can capture the entire problem at the beginning. We assume we can nail down all the requirements in writing in an unambiguous fashion and begin the project with a stable foundation. Despite all our efforts, though, this almost always proves to be
The users change.
The users' needs cannot be frozen in time. This is
The problem changes.
After the system is implemented or while it is being implemented, the system itself affects the perspective of users. Trying out features or seeing them demonstrated is quite different from reading about them. As soon as the end users see how their intentions have been translated into a system, the requirements change. In fact, the one point when users know exactly what they want is not two years before the system is ready but rather a few weeks or months after delivery of the system when they are beyond the initial learning phase. This is known as the IKIWISI effect: "I'll Know It When I See It." 
uncertain, sometimes attributed to U.S. Judge Stewart Potter; Barry Boehm used this acronym at a workshop on software architecture at the University of Southern California in 1997.
Users don't really know what they want, but they know what they do not want when they see it. Therefore, efforts to detail, capture, and freeze the requirements may ultimately lead to the delivery of a perfect system with respect to the requirements but the wrong system with respect to the real problem at the time of delivery.
The underlying technology changes.
New software or hardware techniques and products emerge, and you will want to exploit them. On a multiyear project, the hardware platform bid at the beginning of the project may no longer be manufactured at delivery time.
The market changes.
The competition might introduce better products to the market. What is the point of developing the perfect product relative to the original spec if you end up with the wrong product relative to what the
We cannot capture requirements with sufficient detail and precision.
The second step of the sequential process assumes that we can confirm that our design is the right solution to the problem. By "right" we imply all the obvious qualities: correctness, efficiency, feasibility, and so on. With complete requirements tracing, formal derivation methods, automated proof, generator techniques, and design simulation, some of these qualities can be achieved. However, few of these techniques are readily available to
Software engineering has not reached the level of other engineering disciplines (and perhaps it never will) because the underlying "
The sequential, or waterfall, process does work. It has worked fine for me on small projects
The sequential process breaks down when you tackle projects having a significant level of novelty, unknowns, and risks. You cannot anticipate the difficulties you may encounter, let alone how you will counter them. The only thing you can do is to build some
The absence of fundamental "laws of software" and the pace at which software evolves make it a risky domain. Techniques for
That's why we bring risk analysis into the picture.
If you stretch what works for a three-month project to fit a three-year project, you expose the project not only to the changing contexts we have discussed but also to other subtle effects
But picture developers in the middle of the design phase of a three-year project. The target is to finish the design within four months. In a sequential process, the developers may not even be around to see the final product up and running. Progress is measured in pages or diagrams and not in operational features. There is nothing tangible, nothing to get the
There is little feedback on the quality of the current activity, because defects will be found later, during integration or test, perhaps 18 months from now. The developers have few opportunities to improve the way they work. Moreover,
The developers have only one shot at each kind of activity, with little opportunity to learn from their mistakes. You have one shot at design, and it had better be good. You say you've never designed a system like this? Too bad! You have one shot at coding, and it had better be good. You say this is a new programming language? Well, you can work longer hours to learn its new features. There's only one shot at testing, and it had better be a no-fault run. You say this is a new system and no one really
In the sequential process, the goal of each step except the last one is to produce and complete an intermediate artifact (usually a paper document) that is reviewed, approved, frozen, and then used as the starting point for the next step. In practice, sequential processes place an excessive emphasis on the production and freezing of documents. Some limited amount of feedback to the
Often, timeliness is the most important factor in the success of a software project. In many industries, delivery of a product on time and with a short
For these reasons and a few others that we will cover later, software organizations have tried another approach.