The Rational Unified Process

Grady Booch, Ivar Jacobson and James Rumbaugh turned their efforts to the development process after creating UML as a single complete notation for describing object models.
They came up with the Rational Unified Process (RUP), which is a general framework that can be used to describe specific development processes.

Accordingly to The Unified Software Development Process every 'software life cycle' is a cycle over four phases in the following order:

  1. Inception       - do you and the Customer have a shared understanding of the system?
  2. Elaboration   - do you have an architecture to be able to build the system?
  3. Construction - are you developing product?
  4. Transition      - are you trying to get the Customer to take ownership of the system?
A 'phase' is 'the span of time between two major milestones in the software development process'.
Major milestones can be thought of as synchronization points where
  • a well-defined set of objectives is met
  • artifacts are completed
  • decisions are met to move or not to into the next phase
  • where the managerial and the technical realm conjuncts

    • How It Works

    The inception phase contains whatever workflows are necessary to get the stakeholders to agree
    (the keyword there is agree, and not "have sure knowledge")
    on the objectives, rough architecture, and rough schedule of the project.
    If the stakeholders are extremely knowledgeable, then little analysis will be required.
    If they need to be severely educated, then lots of analysis will be required.

    The essence of RUP is iteration.
    And the essence of iteration is that each iteration ends in a deliverable -- preferably one that executes.
    Even in inception, you are going to want a few iterations that show growing functionality.
    During inception you will gather a significant (a half? a third? it depends...) fraction of the use cases.
    You will focus on those that seem to be central or key. The iterations will be implementing some of these.

    During elaboration you will tighten up your architecture and your plan.
    The nature of the iterations won't necessarily change much; but the longevity of the software produced will certainly increase.
    Early iterations (usually in the inception phase) have a tendency to get thrown out.
    During elaboration you will discover the rest of the use cases (or at least their first approximations) and will implement the minimal set.

    During construction you will drive towards giving the customer the minimum system that they need.
    The nature of the iterations will not change much,
    but your focus will be on identifying the smallest possible deliverable that will still meet at least some of the customers needs.
    During construction, the use cases will change a bit as the customer sees the growing system and feeds changes back to you.

    During transition, you will drive towards fleshing out the functionality of the system, and incorporating the mounds of customer feedback that you are surely to get.
    During transition the use cases are likely to undergo drastic changes as the customers actually use the system and realise that it is not exactly what they needed.

    Again, the essence of Rational Unified Process ( RUP ) is iteration, and the essence of iteration is the production of executable deliverables.
    You may also be producing UML diagrams, or some other form of model as well.
    Such models take two forms.
    One is a model of the architecture which is seeded during inception and established during elaboration.
    This model is likely to be a permanent document.
    The other kind of model is created at the beginning of each iteration, as a way to plan what the structure of the iteration will look like.
    These models are most likely temporary documents.
    You might find a few that are essential and should be retained; but many will be discardable.

    The transition from phase to phase is gradual.
    Management is not done by placing dates upon the phase boundaries.
    Nor are there phase gate events that mark the transition from one to another.
    Rather, management is done based upon iterations of the development.
    The first iterations start in the inception phase.

    The project plan is pretty straightforward.
    It contains a list of proposed iterations (which all parties agree is likely to change).
    Each proposed iteration has an estimate (which all parties agree are likely to change).
    The proposed iterations are not assigned dates.
    Rather decision points are identified.
    For example:

    1. by week 6, if iteration 1 and 2 are not complete, then hire one additional person.
    2. by week 10, if iterations 1-4 have not been accepted by the customer, then remove iteration 8 from the release.
    3. by week 15, if iterations 1-4 have not been accepted by the customer, then cancel the project.
    A project plan is not a statement of what will be.
    Rather it is a statement of how risks will be managed.
    It is a plan of contingencies, as opposed to purely a plan of action.
    As the project proceeds, we will learn more about how quickly the iterations are developed.
    We will learn about the iterations that we forgot when we made the project plan.
    The customer will see the developing project and will change the requirements.
    Thus, the plan must be malleable, flexible, and responsive.

    Figure 1
    As you can see the RUP works within a rich graphical tree view to fully support the modelling stages. The Architecture of the RUP The process itself has been designed using techniques similar to those for software design. In particular, it has an underlying object-oriented model, using UML. The process has two structures or, if you prefer, two dimensions: The horizontal dimension represents time and shows the lifecycle aspects of the process as it unfolds. The vertical dimension represents core process disciplines (or workflows), which logically group software engineering activities by their nature. The first (horizontal) dimension represents the dynamic aspect of the process expressed in terms of cycles, phases, iterations, and milestones. In the RUP, a software product is designed and built in a succession of incremental iterations. This allows testing and validation of design ideas, as well as risk mitigation, to occur earlier in the lifecycle. The second (vertical) dimension represents the static aspect of the process described in terms of process components: activities, disciplines, artifacts, and roles.
     Phases
     InceptionElaborationConstructionTransition
    Business Modelling
    Requirements
    Analysis & Design
    Implementation
    Test
    Deployment
    Configuration & Change Management
    Project Management
    Environment
     Iterations

    The RUP Captures Software Development Best Practices

    The Rational Unified Process captures many of modern software development's best practices in a form suitable for a wide range of projects and organizations:

    • Develop software iteratively.
    • Manage requirements.
    • Use component-based architectures.
    • Visually model software.
    • Continuously verify software quality.
    • Control changes to software.
    1. Develop Software Iteratively

    Most software teams still use a waterfall process for development projects, completing in strict sequence the phases of requirement analysis, design, implementation/integration, and test. This inefficient approach idles key team members for extended periods and defers testing until the end of the project lifecycle, when problems tend to be tough and expensive to resolve, and pose a serious threat to release deadlines. By contrast, RUP represents an iterative approach that is superior for a number of reasons:

    • It lets you take into account changing requirements. The truth is that requirements usually change. Requirements change and "requirements creep" -- the addition of requirements that are unnecessary and/or not customer-driven as a project progresses -- have always been primary sources of project trouble, leading to late delivery, missed schedules, dissatisfied customers, and frustrated developers.
    • Integration is not one "big bang" at the end; instead, elements are integrated progressively -- almost continuously. With RUP, what used to be a lengthy time of uncertainty and pain -- taking up to 40% of the total effort at the end of a project -- is broken down into six to nine smaller integrations involving fewer elements.
    • Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier. As you unroll the early iterations, you test all process components, exercising many aspects of the project, such as tools, off-the-shelf software, people skills, and so on. You can quickly see whether perceived risks prove to be real and also uncover new, unsuspected risks when they are easier and less costly to address.
    • Iterative development provides management with a means of making tactical changes to the product -- to compete with existing products, for example. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
    • Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning. Design reviews in early iterations allow architects to spot potential opportunities for reuse, and then develop and mature common code for these opportunities in subsequent iterations.
    • When you can correct errors over several iterations, the result is a more robust architecture. As the product moves beyond inception into elaboration, flaws are detected even in early iterations rather than during a massive testing phase at the end. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
    • Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on. In a non-iterative development, the same people would be waiting around to begin their work, making plan after plan but not making any concrete progress. What can a tester test when the product consists of only three feet of design documentation on a shelf? In addition, training needs, or the need for additional people, are spotted early, during assessment reviews.
    • The development process itself can be improved and refined along the way. The assessment at the end of an iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration.

    Project managers often resist the iterative approach, seeing it as a kind of endless and uncontrolled hacking.
    In the Rational Unified Process, the iterative approach is very controlled; the number, duration, and objectives of iterations are carefully planned,
    and the tasks and responsibilities of participants are well defined.
    In addition, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this, too, is carefully controlled.

    2. Manage Requirements

    Requirements management is a systematic approach to eliciting, organizing, communicating, and managing the changing requirements of a software-intensive system or application.

    The benefits of effective requirements management are numerous:

    • Better control of complex projects. This includes greater understanding of the intended system behavior as well as prevention of requirements creep.
    • Improved software quality and customer satisfaction. The fundamental measure of quality is whether a system does what it is supposed to do. With the Rational Unified Process, this can be more easily assessed because all stakeholders have a common understanding of what must be built and tested.
    • Reduced project costs and delays. Fixing errors in requirements is very expensive. With effective requirements management, you can decrease these errors early in the development, thereby cutting project costs and preventing delays.
    • Improved team communication. Requirements management facilitates the involvement of users early in the process, helping to ensure that the application meets their needs. Well-managed requirements build a common understanding of the project needs and commitments among the stakeholders: users, customers, management, designers, and testers.

    It is often difficult to look at a traditional object-oriented system model and tell how the system does what it is supposed to do.
    This difficulty stems from the lack of a consistent, visible thread through the system when it performs certain tasks.
    In the Rational Unified Process, use cases provide that thread by defining the behavior performed by a system.

    Use cases are not required in object orientation, nor are they a compulsory vehicle in the Rational Unified Process.
    Where they are appropriate, however, they provide an important link between system requirements and other development artifacts, such as design and tests.
    Other object-oriented methods provide use-case-like representation but use different names for it, such as scenarios or threads.

    The Rational Unified Process is a use-case-driven approach, which means that the use cases defined for the system can serve as the foundation for the rest of the development process.
    Use cases used for capturing requirements play a major role in several of the process workflows, especially design, test, user-interface design, and project management.
    They are also critical to business modeling.

    3. Use Component-Based Architecture

    Use cases drive the Rational Unified Process throughout the entire lifecycle, but design activities center on architecture -- either system architecture or, for software-intensive systems, software architecture.
    The main focus of early iterations is to produce and validate a software architecture.
    In the initial development cycle, this takes the form of an executable architectural prototype that gradually evolves, through subsequent iterations, into the final system.

    The Rational Unified Process provides a methodical, systematic way to design, develop, and validate an architecture.
    It offers templates for describing an architecture based on the concept of multiple architectural views.
    It provides for the capture of architectural style, design rules, and constraints.
    The design process component contains specific activities aimed at identifying architectural constraints and architecturally significant elements, as well as guidelines on how to make architectural choices.
    The management process shows how planning the early iterations takes into account the design of an architecture and the resolution of major technical risks.

    A component can be defined as a nontrivial piece of software: a module, package, or subsystem that fulfills a clear function, has a clear boundary, and can be integrated into a well-defined architecture.
    It is the physical realization of an abstraction in your design. Component-based development can proceed in several ways:

    • In defining a modular architecture, you identify, isolate, design, develop, and test well-formed components. These components can be individually tested and gradually integrated to form the whole system.
    • Furthermore, some of these components can be developed to be reusable, especially components that provide solutions to a wide range of common problems. Reusable components are typically larger than mere collections of utilities or class libraries. They form the basis of reuse within an organization, increasing overall software productivity and quality.
    • More recently, the advent of commercially successful infrastructures supporting the concept of software components -- such as Common Object Request Broker Architecture (CORBA), the Internet, ActiveX, and JavaBeans -- has launched a whole industry of off-the-shelf components for various domains, allowing developers to buy and integrate components rather than develop them in-house.

    The first point above exploits the old concepts of modularity and encapsulation, bringing the concepts underlying object-oriented technology a step further.
    The final two points shift software development from programming software (one line at a time) to composing software (by assembling components).

    The Rational Unified Process supports component-based development in several ways.

    • The iterative approach allows developers to progressively identify components and decide which ones to develop, which ones to reuse, and which ones to buy.
    • The focus on software architecture allows you to articulate the structure. The architecture enumerates the components and the ways they integrate, as well as the fundamental mechanisms and patterns by which they interact.
    • Concepts such as packages, subsystems, and layers are used during analysis and design to organize components and specify interfaces.
    • Testing is organized around single components first and then is gradually expanded to include larger sets of integrated components.
    4. Visually Model Software

    Models are simplifications of reality; they help us to understand and shape both a problem and its solution, and to comprehend large, complex systems that we could not otherwise understand as a whole.
    A large part of the Rational Unified Process is about developing and maintaining models of the system under development.

    The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.
    It gives you a standard means of writing the system's blueprints, covering conceptual items such as business processes and system functions,
    as well as concrete items such as classes written in a specific programming language, database schemas, and reusable software components.
    While it provides the vocabulary to express various models, the UML does not tell you how to develop software.
    That is why Rational developed the Rational Unified Process, a guide to the effective use of the UML for modeling.
    It describes the models you need, why you need them, and how to construct them. RUP2000 uses UML version 1.4.

    5. Continuously Verify Quality

    Often people ask why there is no worker in charge of quality in the Rational Unified Process.
    The answer is that quality is not added to a product by a few people. Instead, quality is the responsibility of every member of the development organization.
    In software development, our concern about quality is focused on two areas: product quality and process quality.

    • Product quality -- The quality of the principal product being produced (the software or system) and all the elements it comprises (for example, components, subsystems, architecture, and so on).
    • Process quality -- The degree to which an acceptable process (including measurements and criteria for quality) was implemented and adhered to during the manufacturing of the product.
      • Additionally, process quality is concerned with the quality of the artifacts (such as iteration plans, test plans, use-case realizations, design model, and so on) produced in support of the principal product.
    6. Control Changes to Software

    Particularly in an iterative development, many work products are often modified.
    By allowing flexibility in the planning and execution of the development and by allowing the requirements to evolve, iterative development emphasizes the vital issues of keeping track of changes and ensuring that everything and everyone is in sync.
    Focused closely on the needs of the development organization, change management is a systematic approach to managing changes in requirements, design, and implementation.
    It also covers the important activities of keeping track of defects, misunderstandings, and project commitments as well as associating these activities with specific artifacts and releases.
    Change management is tied to configuration management and measurements.

    To Learn More

    • Rational Unified Process 2000, Rational Software, Cupertino, CA (2000) http://www.rational.com/rup/
    • Philippe Kruchten, The Rational Unified Process -- An Introduction, 2nd ed., Addison-Wesley-Longman, Reading, MA (2000).
    • Grady Booch et al., UML Users' Guide, Addison-Wesley-Longman, Reading, MA (2000)
    • Ivar Jacobson et al., The Unified Software Development Process, Addison-Wesley-Longman, Reading, MA (1999).