Unified process

The Rational Unified Process (RUP) is an iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is not a single concrete prescriptive process, but rather an adaptable process framework. As such, RUP describes how to develop software effectively using proven techniques. While the RUP encompasses a large number of different activities, it is also intended to be tailored, in the sense of selecting the development processes appropriate to a particular software project or development organization. The RUP is recognized as particularly applicable to larger software development teams working on large projects. Rational Software offers a product (known below as the Rational Unified Process Product) that provides tools and technology for customizing and executing the process.

Background of the Rational Unified Process

The creators and developers of this software engineering process focused on diagnosing the characteristics of different failed software projects; by doing so they tried to recognize the root causes of these failures. They also looked at the existing software engineering processes and their solutions for these symptoms.

A representative list of failure causes includes the following:

• Ad hoc requirements management
• Ambiguous and imprecise communication
• Brittle architecture
• Overwhelming complexity
• Undetected inconsistencies in requirements, designs, and implementations
• Insufficient testing
• Subjective assessment of project status
• Failure to attack risks
• Uncontrolled change propagation
• Insufficient automation

Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of their study was a system of software best practices they named the Rational Unified Process. Since knowing these problems will not guarantee a successful software product unless the solutions are also considered, they went on to create the Rational Unified Process Product (RUPP). The Process was designed with the same techniques the team used to design software; it has an underlying object-oriented model, using the Unified Modeling Language (UML).

Overview of the Rational Unified Process

Looking at the Overview screen on the RUPP (Rational Unified Process Product) shows you a high level view of the Process. The chart identifies which disciplines are the most active during each phase of the process. For example, the red shape labeled Business Modeling shows heavy activity only in the Inception and Elaboration phases, where as the blue shape representing Project Management shows a more graduated activity over the life of the Process.

The Rational Unified Process overview shows the process structure from two viewpoints:

• The vertical axis of the picture on the right frame represents the static aspects of the RUP. From this view the process is described in activities, artifacts, workers and workflows associated with each discipline.
• The horizontal axis represents time and the dynamic aspects of the RUP. From this point of view the process is described in cycles, phases, iterations, and milestones.

Using the RUP, software product lifecycles are broken into individual development cycles. These cycles are further broken into their main components, called phases. In RUP, these phases are termed as:

Inception Phase

In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

• Stakeholder concurrence on scope definition and cost/schedule estimates.
• Requirements understanding as evidenced by the fidelity of the primary use cases.
• Credibility of the cost/schedule estimates, priorities, risks, and development process.
• Depth and breadth of any architectural prototype that was developed.
• Actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled, or can repeat this phase after being redesigned to better meet the criteria. Depending on the nature of the project, the inception phase normally takes about 5% of the total project time. On some cases where elaborated market analysis and economic impact analysis are required, it is normally more than that. The inception phase is normally divided in few iterations (1-2).

Elaboration Phase

The Elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form. It is in this phase that most of the risk analysis is made in the project. Different risks sources are analyzed:

Risk analysis

Requirement risk

What is the chance of building the wrong system. Does the client really know what he wants. If he knows what he wants, is this really what he needs? Solutions: The RUP advocates the use of the use case driven approach to deal with the requirements risk. It also advocates the use of prototyping to get feedback on the more uncertain aspects of the requirements.

Technological risk

Assume the use of object-oriented and Java technology, how much is known about object-oriented design? Will Java do the job? Do we have to use software libraries or hardware that we are not sure will fullfill the needs of the project? Solutions: Develop prototypes to test the uncertain technologies.

Skill risk

Does our staff have the necessary expertise to deal with the various aspects of this project? Solutions: Train the staff before the project is started to make sure that everyone is productive during the project. Rely on mentoring whenever possible, which might even include the hiring of external experts.

Political risk

Is there any political influences that may affect the project?

This phase must pass another Milestone by meeting the following criteria:

• A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
• A description of the software architecture in a software system development process
• Architecture prototype, which can be executed.
• Business case and risk list which are revised.
• A development plan for the overall project, including the prioritization of use cases and the assignment of use cases into iterations of theconstruction phase.

If the project cannot pass this milestone, there is still time for it to be cancelled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made. The elaboration phase normally consists in few iterations (2-4). Highly risky projects can diverge from this norm by requiring more iterations. A good rule of thumb is that elaborationshould take about a fifth of the total length of the project.

The Construction Phase

In this phase the main focus goes to the development of components and other features of the system being developed. This is the phase when the bulk of the coding takes place. It builds the system in a series of iterations. Each iteration is based on one or a few use cases, including:

• Detail analysis
• Detail design
• Coding
• Testing
• Integration of the use cases from previous iterations

Each iteration is incremental in function. It builds on the use cases developed in the previous iterations. An iteration is incremental in terms of code base and also involves the rewriting of some existing code to make it more flexible (i.e. refactoring operations). It is generally in the construction phase that more UML diagrams are used to model different aspect of the design:

Class diagram

roughs out concepts for the implementation of the use case developed in this iteration and see how to fit into the software from previous iterations.

sequence diagram

to represent how classes are communicating with one another to achieve the use case.

activity diagram

In cases where elaborated branching or iteration is present in the use case, an activity diagram is often better.

state diagram

In cases where a class has complex dynamic behaviour (many state changes in response of events),use state diagram.

package diagram

To help visualize the logical pieces of the system and help define the architecture of the system in terms of packages.

The RUP also advocates the use of design patterns to address common problems. Patterns are well known model developed and collected by those with experiences to a set of common problems.

Most of the time and iterations of the development will be concentrated in the Construction phase. Depending on the number of use cases, there could potentially be tens of Construction iterations. The last iteration of this phase produces the first external release of the software. After this phase, the software is deployed iteratively through the Transition phase.

Transition Phase

In the transition phase the product has moved from the development organization to the end user. The activities of the phase include: Training of the end users and maintainers, Beta testing of the system to validate it against the end users expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end-users, the entire cycle may begin again. Note that Transition-level iterations do not involve further development aside from fixing existing small problems. Depending on the nature of the software (e.g. beta-release, customer-release, shrink-wrapped, or downloadable software), this phase can involve different activities (see the Deployment workflow below).

Phases vs. Iterations

A typical project using the RUP will go through several iterations. Dividing the project into iterations has advantages, such as risk mitigation, but it also needs more guidance and effort than the traditional sequential approach. The RUP defines a Project Management Discipline that guide the project manager through iteration management. Using iterations, a project will have one overall phase plan, but multiple iteration plans. Each phase can be conducted in several iterations. Each iteration starts by defining the iteration goals and the iteration plan. At the end of each iteration, a verification stage will check if the iteration goals are met before the iteration is closed. If goals are not met, another iteration can be started with more specific or relaxed goals. If the goals cannot be met and neither relaxed, the project can be reduced in scope or even stopped.

As depicted in the following figure, the process can be seen from different viewpoints. Management will tend to emphasize on the development phases and workflows, while the developers will emphasize on the different releases.

Some of the releases will be internal (i.e. will not represent operational software releases), while some others will be external releases (i.e. will be operational software releases). The latter are all released during a transition iteration, using the deployment workflow (see below).

RUP process elements

The static 4:

• Roles are who – a role is the behavior and responsibilities of a person or team, not the person themselves.
• Artifacts are what – they are the outcome of activities, including all the documents and models produced while working through the process.
• Workflow is when – it is a sequence of activities or the design of processes that must be completed.
• Activity is how – it is the actual tasks a worker performs.

This side of the process is called static because it describes how things are done. It is not dependent on the project at hand. For example, the description of the tasks and deliverables of a use-case designer is the same for each project.

Disciplines

In RUP all activities are organized into nine Disciplines:

Engineering

• Business Modeling Discipline
• Requirements Discipline
• Analysis & Design Discipline
• Implementation Discipline
• Test Discipline
• Deployment Discipline

Supporting

• Configuration and Change Management Discipline
• Project Management Discipline
• Environment Discipline

Workflows

Each discipline is implemented in the following of workflows. For example, the Deployment discipline is implemented using the following workflow:

Each activity in the workflow is associated with different actors producing and consuming different artifacts when achieving a certain activity. For example, the Manage Acceptance Tests activity in the preceding workflow can be detailed as the following detailed activity diagram:

Best Practices of RUP

1. Develop software iteratively
2. Manage requirements
3. Use component based architecture
4. Visually model software
5. Verify software quality
6. Control changes to software

Develop software iteratively

Given the time it takes to develop large sophisticated software systems it is not possible to define the problem and build the solution in a single step. Requirements will often change throughout a project's development, due to architectural constraints, customer's needs or a greater understanding of the original problem. Iteration allows the project to be successively refined and addresses a project's highest risk items as the highest priority task. Ideally each iteration ends up with an executable release – this helps reduce a project's risk profile, allows greater customer feedback and helps developers stay focused.

The RUP uses iterative and incremental development for the following reasons:

• Integration is done step by step during the development process, limiting it to fewer elements.
• Integration is less complex, making it more cost effective.
• Parts are separately designed and/or implemented and can be easily identified for later reuse.
• Requirement changes are noted and can be accommodated.
• Risks are attacked early in development since each iteration gives the opportunity for more risks to be identified.
• Software architecture is improved by repeated scrutiny.

Manage requirements

Requirements Management in RUP is concerned with meeting the needs of end users by identifying and specifying what they need and identifying when those needs change. Its benefits include the following:

• The correct requirements generate the correct product; the customer's needs are met.
• Necessary features will be included, reducing post-development cost.

The Rational Unified Process implemented a section about requirements management because they believe that managing requirements improves the chance of success of a software development project.

Use component based architecture

Component Based Architecture creates a system that is easily extensible, promotes software reuse and intuitively understandable. A component often relates to a set of objects in object-oriented programming.

Software Architecture is increasing in importance as systems are becoming large and more complex. RUP focuses on producing the basic architecture in early iterations. This architecture then becomes a prototype in the initial development cycle. This architecture evolves with each iteration to become the final system architecture. RUP also asserts design rules and constraints to capture architectural rules. By developing iteratively it is possible to gradually identify components which can then be developed, bought or reused.

Visually model software

Abstracting your programming from its code and representing it using graphical building blocks is an effective way to get an overall picture of a solution. Using this representation, technical resources can determine how best to implement a given set of inter-related logics. It also builds an intermediary between the business process and actual code through information technology. A model in this context is a visualization and at the same time a simplification of a complex design. RUP specifies which models are necessary and why.

The Unified Modeling Language (UML) can be used for modeling Use-Cases, Class diagrams and other objects. RUP also discusses other ways to build models.

Verify software quality

Quality Assessment is the most common failing point of all software projects, since it is often an afterthought and sometimes even handled by a different team. RUP assists in planning quality control and assessment by building it into the entire process and involving all members of a team. No worker is specifically assigned to quality; RUP assumed that each member of the team is responsible for quality. The process focuses on meeting the expected level of quality and provides test workflows to measure this level.

Control changes to software

In all software projects, change is inevitable. RUP defines methods to control, track and monitor changes. RUP also defines secure workspaces, guaranteeing a software engineer's system will not be affected by changes in another system. This concept ties in heavily with component based architectures.

With the iterative approach, the need for change management is even more necessary because of the sheer volume of artifacts developed. These artifacts will also need to be updated as the iterations evolve. The Change Management workflow in RUP deals with three specific areas:

• Configuration Management
• Change Request Management
• Status and Measurement Management

Configuration Management

Configuration management is responsible for the systematic structuring of the products. Artifacts such as documents and models need to be placed under version control and these changes must be visible. It also keeps track of dependencies between artifacts so all related articles are updated when changes are made.

Change Request Management

During the system development process many artifacts with several versions exist. CRM keeps track of the proposals for change.

Status and Measurement Management

Change requests have states such as new, logged, approved, assigned and complete. A change request also has attributes such as root cause, or nature (like defect and enhancement), priority etc. These states and attributes are stored in database so useful reports about the progress of the project can be produced. Rational also has a product to maintain change requests called ClearQuest.

Limitations

The limitations of the product are in understanding its implementation as it is a formal process and requires customization first and foremost. RUP was not intended not, envisioned, nor promoted to be used straight "out of the box." This confusion has led to RUP being branded as a weightly and expensive process; which has been proven inaccurate. For the process to be implemented successfully an Organizational Assessment and the production of a Development Case must be accomplished before beginning the process.

The Rational Unified Process Product

The Rational Unified Process Product (RUPP) is a web-enabled set of tools that define the Process. The fundamentals of the Process are the implementation of the six best practices. By implementing iterative development, requirements management, component-based architecture, visual modeling software, software quality verification, and controlling software changes the RUP tries to prevent failure by attacking the root causes of project failure.

The RUPP documents process implementation for teams and project managers. It also outlines processes for the software engineers, describes which products (artifacts) should be produced and provides tools and templates to enhance the management process. In RUPP there are guidelines for all processes that lead to producing an artifact. With IBM's purchase of the company, IBM Global Services will sell the tools, now integrated with the Eclipse IDE, and the consultancy. Tight integration with that Java development platform may make it a very effective development tool. Its pricing, however, will keep it beyond the reach of most developers.

References

• Wikipedia:Rational Unified Process

External links

• Rational Software at IBM
• Process Description - The Rational Edge website (pdf)
• Implementing RUP/UP in 10 Easy Steps - X-tier SAE website (doc)