The RUP is a commercial method and is sold as an online resource on CD-ROM, although numerous books and articles are available on the subject.
It was developed as a complementary methodology to the Unified Modeling Language (UML) and is a use-case-driven, architecture-centric, iterative development process for producing object-oriented software. The process is the result of the combination of many software engineering best practices as well as the acquisition by Rational of several software engineering methods. Its lineage goes back to the Objectory process, created in 1987 by methodology guru Ivar Jacobson.
Chapter 5, Modeling Software, examines the Unified Modeling Language.
RUP is actually a process framework rather than a methodology. It defines an extensive selection of disciplines, artifacts, activities, and roles each of which represents industry best practice for the development of object-oriented software. The best practices that underpin the RUP framework are as follows:
Due to the comprehensive nature of the framework, the process is often assumed to be high-ceremony and heavyweight. While RUP does emphasize the importance of certain key artifacts and activities that are central to the process, this assumption is largely incorrect. Instead, RUP encourages the developer to tailor the process to the needs of his or her specific project by selecting from the long list of elements RUP provides for just about every conceivable project type. By tailoring the process, RUP can take on the agility of a lightweight methodology if the needs of the project dictate. However, the reliance of the process on artifacts such as use cases and design models means it is unable to slim down to the feather-light weights of methods such as XP, which we cover later.
A second common misconception with the process is that it is based upon predictive methods rather than adaptive methods. Again, this assumption is incorrect: RUP promotes the best practice of developing software iteratively. Many adopters of the RUP have been guilty of overlaying the waterfall lifecycle model on top of the process framework, thereby turning it into a predictive method. This is counter to the best practices of the process and certainly goes against the intent of its creators.
To understand how RUP is applied on projects, over the next sections we look at two of the key drivers for the process: use cases and timeboxed iterative development. We also examine the core elements of the framework.
A Use-Case-Driven Process
We know that a successful system meets the needs of its end users. To achieve this goal, IT staff must work closely with the business domain experts to elicit the requirements that will ultimately drive the development effort. The interaction between business representatives and members from the project team is a critical success factor for ensuring all relevant requirements are both understood and captured correctly. Achieving this objective is a challenge, since both parties approach the engagement with very different mindsets and viewpoints. The end users focus on business concerns, while the IT staff likely thinks in terms of system design and architecture.
The question becomes, "How do we capture requirements in a form that is understandable to both the business domain experts and the IT-focused software engineers?" One of the most successful methods to date of achieving this is to develop a set of use cases.
Use cases describe what the system should do from the end user's perspective. They are text-based documents, as opposed to diagrams, that step through the flow of a set of closely related business scenarios. Each use case represents a functional slice of the system and describes how actors interact with the system in order to execute the use case.
An actor is defined as something external to the system, usually a person, who interacts with the system. The use case itself is a series of actions a system performs for the actor.
Here is an example of the structure of a typical use case:
Templates for use cases vary, with publications on the subject each presenting slight variations on a common theme. The structure of the use case shown represents the elements commonly found in use-case templates. You may wish to tailor this template to suit the needs of your own project.
The most important part of a use-case document is the flow of events section:. This describes the interplay between actors and system for a given scenario in a concise, natural language form.
A scenario is a flow of events within the use case. Very often, a use case comprises additional alternative flows to the main flow. These secondary flows typically cover exception conditions or slight deviations from the main scenario.
Let's look at an example of a use case that details the flow of events for a customer who enters the office of a travel company to reserve seats on a suitable flight. Table 3-1 shows an example of the complete use case.
The plain language of use cases, which is both business- and technology-neutral, makes them ideal for communicating system behavior to both end users and developers. Use cases are important in RUP because they provide a common thread through many activities, particularly in the area of linking requirements to design. They also serve to focus the design, implementation, and testing efforts around a central set of requirements, which form the core of the system.
Use cases are organized by producing a use-case model. A use-case model is a UML diagram that graphically illustrates how the different use cases and actors interact. Models are useful for gaining an understanding of the relationships that exist between each use case and actor. However, the true value of use cases is in the text of the use case itself, not the diagram in the model.
Ivar Jacobson initially proposed the concept of use cases. As Jacobson's Objectory is one of the foundation methodologies on which the RUP framework is built, it is not surprising that use cases are one of the driving forces of the process.
Although they are an important part of the process, use cases are not confined to object-oriented development and have enjoyed widespread acceptance in all manner of projects. They are an excellent technique for capturing and understanding customer requirements and are worth considering for inclusion in any methodology.
We next examine how the RUP framework centers on the use of iterations throughout the project lifecycle.
Iterative Development with RUP
The process prescribes an iterative approach to development with timeboxed iterations. Here, all iterations occur over a fixed duration but have a variable scope.
A RUP iteration focuses on a subset of the system's use cases. Within a typical iteration, the selected use cases are elaborated and a design is evolved followed by implementation and testing. The objective of each iteration is a functioning system. Should it appear that this objective will not be achieved, then the scope is reduced in preference to extending the timeboxed duration of the iteration or bringing more people on to the project.
The exact content of an iteration is dependent upon the particular phase of RUP within which the planned iteration is being conducted. Let's examine the different phases of a RUP project cycle.
Phases of the Process
Conventional waterfall-based processes are broken down into phases according to specific software engineering activities, with phase names denoting the associated activity. We therefore commonly have requirements, analysis and design, implementation, and testing. Only a single type of activity is undertaken in each of these phases. For example, during the requirements phase, only work relating to the gathering, analysis, and documenting of requirements is performed. Absolutely no design, coding, or testing work is undertaken as part of this early phase.
RUP projects are also divided into the four discrete phases. These are inception, elaboration, construction, and transition. Unlike in the waterfall model, these phases are not aligned by activity but instead demark the achievement of a major project milestone. Phases within the process include a number of iterations, with each iteration serving to advance the project toward the phase milestone. As an iteration is a complete mini-waterfall project, we can expect to see the general activities of requirements, analysis and design, implementation, and testing being undertaken in each phase.
A common failing in implementing the RUP is to mistakenly associate these four phases with the four phases of the classic waterfall lifecycle. This is a fact Philippe Kruchten, one of the creators of RUP, went to great pains to point out with his fellow authors in the article, How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering [Larman, 2002].
Here are the four phases of a RUP project and a brief description of the work undertaken in each phase:
A discipline represents an area of work. Disciplines are undertaken in each iteration, although the degree to which each discipline is practiced depends on the current project phase. There are nine different disciplines:
The amount of effort required in each discipline varies as the project traverses through the four different phases over time. Iterations in inception and elaboration phases will be heavy on the business modeling and requirements management disciplines. Later in the project, during the transition phase, effort in these disciplines will have trailed off but may still play a minor part in later iterations.
The Elements of RUP
The RUP framework provides all the elements necessary for building a comprehensive project around the different disciplines. For each discipline, RUP defines a set of roles, activities, artifacts, and workflows that represent the core elements of the lifecycle model. Each of these elements is an answer to the questions of who, how, what, and when.
Artifacts: The What
An artifact is a work product used to capture and convey project-related information. Artifacts can be documents, models, model elements, source code, or executables. Complete artifact sets are defined that align to each discipline; for example, artifacts from the analysis and design discipline include a software architecture document (SAD) and a design model.
Activities: The How
Producing an artifact requires undertaking an activity. The RUP views an activity as a unit of work carried out by a member of the team with a specific role. Examples of activities for the analysis and design discipline include those of architectural analysis and database design. Artifacts resulting from these two activities include a software architecture document and a data model respectively.
Roles: The Who
RUP allocates responsibilities to members of the team by handing out roles. Roles are associated with a set of performed activities and owned artifacts. From the activities and artifacts mentioned so far, the software architect is responsible for undertaking the architectural analysis activity and producing the software architecture document artifact, while the database designer produces a database model as an artifact resulting from the database design activity.
Team members are not assigned a single role but instead take on a range of roles as and when the project dictates. On smaller projects, a member of the team may hold several roles if he is undertaking a range of activities, whereas large projects may require a single person to be dedicated to a particular role.
Workflow: The When
To work with the different artifacts, activities, and roles, we need more information than merely a list of each element. It is necessary to understand how each different element interacts as part of the process. This is the purpose of workflows.
A workflow is represented in RUP as a modified activity diagram illustrating how a particular set of activities is organized. Workflows equate to the disciplines we have already covered. In fact, a discipline is a type of high-level workflow, as disciplines represent a logical grouping of a set of artifacts, activities, and roles. A discipline is therefore one type of workflow. A second type of workflow is the workflow detail, which breaks disciplines down into finer levels of granularity.
Within RUP, we therefore have phases, iterations, disciplines, roles, activities, and artifacts. The question is how you go about combining all of these elements into a coherent project plan.
Planning is a key part of RUP, which encourages the production of two types of plan: a coarse-grained phase plan and a series of detailed iteration plans.
The phase plan is a single plan that spans the duration of the entire project from inception to transition. This high-level plan defines the anticipated dates for the major project milestones, the required project resources, and scheduled dates for each of the planned iterations.
The phase plan is created early in the project during the inception phase. Detailed planning is reserved for the iteration plan, which, like traditional management plans, allocates tasks to individuals and specifies minor milestone dates and project review points. Milestone dates within the iteration plan are made with an expectation of accuracy, as the estimates are made for near-term deadlines as opposed to the long-term forecasts of the phase plan. Toward the end of the iteration, the plan is concluded and work on the plan for the next iteration commences. Thus, in RUP it is common to have two iteration plans: one plan for tracking progress to schedule in the current iteration and a second plan that is under construction for the upcoming iteration.
Two of the most frequently asked questions regarding planning for iterative processes relate to how iterations should be structured throughout the project and what should be the length of an individual iteration.
For structuring the iterations within the project, Philippe Kruchten gives some guidance in an article on planning iterative projects [Kruchten, 2002]. For very simple projects, Kruchten suggests a single iteration for each of the four phases:
Where a large project with many unknowns in terms of both problem domain and technology is under development, Kruchten advises the following structure between the phases:
The length of a timebox for a single iteration is governed by the size of the project team. Extremely large projects with hundreds of people involved require careful coordination in order to maintain momentum for the project. This coordination effort soaks up time and tends to lead to longer iterations. Smaller teams can work to iterations with shorter durations.
Ideally, iterations should be short and focused, running to weeks rather than months. Iterations of two to five weeks work well if the team size allows it. Where longer iterations are unavoidable, then consider setting minor milestones within the timeframe of the iteration. This helps keep the team focused on delivery and prevents risks from creeping back into the project. These minor milestones also help in tracking longer iteration plans.
Supporting Enterprise Projects
Enterprise J2EE developments and RUP fit well together. The way in which enterprise projects are conducted can vary greatly based on both the customer and the development team involved. Thanks to the extensive range of elements RUP provides, the process can tailor to suit most situations.
The size and scope of enterprise developments varies immensely, ranging from teams with only a handful of developers to projects comprised of hundreds of people spread across geographically distant locations. The RUP framework supports both extremes and can meet the needs of small, adaptive style projects while also providing the high-ceremony artifacts necessary for developments conducted on a much grander scale.
Although RUP supports a lightweight adaptive approach, this is not the nature of the majority of enterprise-level developments. Traditionally, such projects are highly contractual, requiring upfront fixed-price quotes for agreed-upon levels of functionality. This type of engagement is the forte of RUP. Placing great importance on early prototype and investigation work helps to drive out the risks involved in this type of project.
Another factor in adopting RUP is the current trend for offshore development. Regardless of whether you favor this contentious practice, it has become a part of the IT industry. The extensive range of artifacts RUP defines makes it possible to conduct large projects with distributed development teams spread across the world. Here, elements of the process provide a common technical vocabulary between teams of different cultures and backgrounds, allowing them to work effectively and collaboratively on a system.
Furthermore, practitioners of best practice processes such as RUP are also able to convey a high degree of professionalism. When organizations are selecting software vendors, an important criterion is often their adopted development methodology. Companies with development teams who demonstrate a knowledge and investment in an established lifecycle model are more likely to win business than those companies who see little value in such methods.
Disadvantages of RUP
RUP is not without its downsides. A major issue is the amount of time and effort that must be invested in knowledge and education of the process framework. The extensive nature of the framework means this investment is often considerable, as becoming expert in the use of the process requires both training and practical experience. Ensuring all team members receive sufficient upfront training before embarking on any project is an important part of developing an adaptive foundation within a company in order to facilitate rapid development methods.
If taking RUP on board is viewed as being too expensive, an alternative is to adopt the practices of a lightweight agile methodology. We look at the benefits of these methods next.