Written by Raj
Rational Unified Process (RUP)
IBM Rational Unified Process (RUP)
The IBM Rational Unified Process is an approach that is used to develop software. It contains information about the type of work we need to perform to develop software (tasks), the sets of responsibilities we assign to people (roles), what we have to produce (work products), and assistance in performing this work (guidance).
The process has been developed over the last 26 years as a collection of IBM Rational field experience helping customers develop software and IBM Rational's experience building their own products. This work has led to the OMG standard Software Process Engineering Meta model (SPEM), and the Eclipse Process Framework project.
1. SPEM is a standard way of describing a process [ 1] and was originally developed by Rational Software, IBM, and other companies.
2. The Eclipse Process Framework project is an open-source project that provides tooling to build development and other processes, and provide basic content. IBM and others initiated this project. IBM provided both the initial tooling and content and now uses this open source project as the basis for its commercial IBMRational Method Composer product. The Web site for the Eclipse Process Framework is at:
http://www.eclipse.org/epf
There are a few key definitions we have to understand before we can effectively understand RUP. Figure below shows these concepts.
Key concepts in RUP [from RUP V7.1]
1. Method is the combination of method content along with process (the way we combine the method content to create an approach we can follow in a project).
2. Method content is the information in the process, the words and pictures.
3. Work product "
is something meaningful resulting from a process
" [RUP]
4. Role "
a set of related skills, competencies, and responsibilities." [RUP]
5. Task "
describes a unit of work assigned to a Role that provides a meaningful result." [RUP]
6. Guidance "
is an abstract concept that generalizes all forms of content whose primary purpose is to provide additional explanations and illustrations to elements such as Roles, Tasks, Work Products, Activities, or Processes." [RUP]
7. Process "
defines the structured work definitions that need to be performed to develop a system." [RUP]
8. Capability pattern "
describes a reusable cluster of Activities in commonprocess areas that produces a result of observable value." [RUP]
9. Delivery process "
describing a complete and integrated approach forperforming a specific type of project." [RUP]
10. Activity "
define the breakdown as well as flow of work." [RUP]
We tend to pick a specific delivery process when we start looking for a process for our team or project (for example, RUP for small projects) and then adapt it for our local needs. This local version is called a development case. If we like our adapted process and want to use it elsewhere, we can use the Rational Method Composer to create our own delivery process (for example, JK Enterprises development case).
RUP is delivered as a large set of HTML pages that we use as a library of information. We pick out the parts of the library we need for our project as a development case.
RUP follows a set of core principles that are worth understanding as we use RUP. This forms the motivation for using a process, and specifically for using RUP.
Core Principles of RUP
RUP has six core principles that provide the rationale for the process:
1. Adapt the process
2. Balance competing stake holder priorities
3. Collaborate across teams
4. Demonstrate value iteratively
5. Elevate the level of abstraction
6. Focus continuously on quality
Adapt the Process
Adapt the process means use the right amount of process for a particular project. Too much process kills projects, too little can lead to unconstrained chaos. an interesting side-effect of having a process that is role-base is the process can be scaled from very small teams to very large teams without changing the core principles. The work products, tasks and other aspects of the process may vary - but we should still be able to recognize a RUP-based process.
Balancing Competing Stakeholder Priorities
Balancing competing stakeholder priorities recognizes the need to constantly balance priorities on a project. Creating a clear set of requirements based on the real needs of the business, and then regularly checking that these needs and requirements have not changed, is one example of this balancing act. Build, buy or reuse of services is another example. There are cost versus time versus functionality balancing acts in this case.
Collaborate Across Teams
Collaborate across teams refers to the need to motivate the individuals on the team, break down the barriers between different teams or parts of the team, and ultimately extend this collaboration to the business, development and operations. SOA-enabled solutions extend this collaboration to outside the enterprise.
Demonstrate the Value Iteratively
Demonstrate the value iteratively has several aspects. The first is that we need deliver real code regularly, starting right at the beginning of the project. It gives the stakeholder chance to see what we are doing and provide feedback. The second aspect is that iterations allow the plan to be adapted as the project proceeds. The third is the chance to accept and manage change with changing business priorities and stakeholder expectations. The last aspect is that we drive out risk continuously from the project by demonstrating working software. We also constantly reassess the keys risks and adapt the plans accordingly Elevate the Level of Abstraction
Elevate the level of abstraction is a principle aimed at simplifying how we work and communicate. We achieve this by the reuse of existing assets, the use of modeling tools and making use of architecture. A significant benefit of SOA-based solutions relies on this elevation of the level abstractionservices being reused, modeling and transformations to translate business requirements to code as quickly as possible, and the use of SOA as an architectural style.
Focus Continuously on Quality
Focus continuously on quality emphasizes the need to have quality as a priority throughout the life cycle. Testing is not the discipline that introduces quality into our solution - it can only catch the lack of quality in what has gone before. As each iteration involves some form of testing, we have a regular monitor on quality throughout the project.
Key Concepts
The key concepts of RUP include:
1. RUP summary chart
2. Iterative development
3. Phases (inception, elaboration, construction, transition)
4. Architecture-driven
5. Use case driven
RUP Summary Chart
The RUP summary chart is shown in Figure below:
Figure RUP summary chart
The RUP summary chart captures many of the concepts in RUP in one diagram. The chart shows a project with time on the x axis, and the disciplines on the y axis. Each RUP project is divided into four phases (Inception, Elaboration, Construction, and Transition). Each phase is broken down into zero or more iterations. An iteration is a vertical slice through the disciplines as shown in figure . This iteration is the first iteration in the Construction phase.
The bumps on the chart indicate the level of effort required for each discipline. Notice, for example, how the business modeling and requirements disciplines are biased towards the beginning of the project but still continue into the Transition phase. One of our favorite questions about this chart is based around testing: "Why to the bumps on the testing discipline line get bigger and bigger over time?"
We now look at some of these terms and ideas in more detail.
Iterative Development
Iterative development is the concept of breaking a project into a set of iterations.
An iteration encompasses the development activities that lead to a product release-a stable, executable version of the product, together with any other peripheral elements necessary to use this release. [RUP]
The project effectively becomes a set of smaller projects. The traditional software development project life cycle of gathering requirements, designing, implementing and testing the solution is discarded. However, an iteration contains these traditional disciplines, hence the idea of an iteration as a mini project. A project consists of a number of iterations.
This approach has many advantages including:
1. Faster feedback on all aspects of the project
2. Faster exposure (and consequently faster mitigation) of risk
3. Ability to validate any estimation techniques within the project
The focus of each iteration is to produce some form of working, tested code. In earlier iterations, this code might be a prototype of a certain aspect of the service or composite services. In later iterations, the working code will be complete builds of the services or composite services but with reduced functionality. This reduced functionality could be stubbed out code, no or reduced handling or simulation of an intended function (for example, a database access and retrieval may be simulated).
Project managers are concentrating on using the iterations to mitigate or expose risk. Contrary to natural inclinations, we encourage projects to attempt the highest risk aspects up front. This in turn allows us to spend the most time on addressing the risks. Each iteration should start with an assessment of what has changed since the start of the last iteration. Risks and priorities changes may steer us to change the plan for this iteration, bring some work forward and pushing some work back.
Phases
Each RUP project is broken into four phases. The phases in order of execution are:
1. Inception
2. Elaboration
3. Construction
4. Transition
Inception is the phase where we scope out the project. During the iterations in this phase we define business use cases (or revise them if some already exist). We define our business goals, key performance indicators and metrics. We create initial as-is and to-be business process models. We take initial ideas about the services required and implement a few (with skeleton code if required). We test the services
Elaboration is the phase where we make sure we can have a working end-to-end automated business process or processes. Updates are made to all the work products created in the Inception phase. Some of the code previously stubbed out is filled in. Tests from the previous phase are rerun and expanded to cover the new functionality. Services are automating portions of or whole business processes so we have some useful business functionality.
Construction is where we complete the coding and testing. Many of the work products such as the business process models, requirements, service model, and others are further refined as appropriate and locked down as complete. At the end of the phase, the software is ready to be released to alpha and beta testing. Further changes to requirements based on feedback would be scheduled for future releases, or we could remain in Construction. Given that the stakeholders have already seen running code during the preceding two phases, we have bee tracking changes in business processes and business goals, it is less likely than major changes will surprise us at this point.
Transition is the phase that can vary the most. It entirely depends on what kind of software you are building. For a product release (like a release of IBM Rational tools), transition is focused on alpha and beta testing. We are finishing training materials, marketing materials, deciding on the color of the box or CD, and checking that the copyright notices appear on the accompanying literature . We are fixing any critical defects found in the alpha and beta releases. An internal project for the business will be working with operations to get system and user acceptance testing completed, and planning for deployment. Once transition is complete, further changes to the software require a new project (run iteratively of course). Maintenance has a slightly different shape of project.
Each phase has strict entry and exit criteria or gates. By the end of each phase we require that:
1. InceptionScope of the project has been agreed
2. ElaborationArchitecturally significant aspects of the project are up and running as tested code
3. ConstructionThe coding is complete
4. TransitionThe project is live
It is very important that a project does not proceed to the next phase if these high-level goals have not been achieved. We can add iterations to the phase to enable us to achieve the goals of the phase. This has an obvious impact on schedule, but we may catch up later by accomplishing more in future iterations or we de-scope the functionality we plan to deliver. Iterative development makes this easier as at the end of each successful iteration, we have a stable build of the code and the associated work products that should be suitable for release.
Architecture-Driven
RUP is an architecture-driven process. Defining and building an executable architecture is the focus of the Elaboration phase of any RUP project. An executable architecture means code that demonstrates and proves the effectiveness of our architectural decisions.
Use Case Driven
Prior to the introduction of SOA concepts, RUP focused on aligning iterations to system use cases. This is still true in that we would expect to take systems use cases through to implementation during a iteration; there are higher-level drivers of the goal of an iteration.
Automating a business process or task becomes the new goal of the iteration. We have to implement system use cases as part of this goal, but now we focus on implementing a thread of the business process from beginning to end. We may not handle all cases in the process and we may not cover all exceptions or branches in the process flow, but we have to implement something useful end-to-end.
If we use business use case realizations as an alternative to business process flows, then we are implementing these business use case realizations. Either way, the focus of the iteration is to deliver some business useful functionality.
