Rational Unified Process (RUP)

The Essentials

1. Vision—Develop a Vision

2. Plan—Manage to the Plan

3. Risks—Mitigate Risks and Track Related Issues

4. Business Case—Examine the Business Case

5. Architecture—Design a Component Architecture

RUP – The Essentials

6. Prototype—Incrementally Build and

Test the Product

7. Evaluation—Regularly Assess Results

8. Change Requests—Manage and Control Changes

9. User Support—Deploy a Usable Product

10.Process—Adopt a Process that Fits Your Project

RUP – The Essentials (continued)

In RUP, the Vision artifact captures very high-

level requirements and design constraints, to give the reader an understanding of the system to be developed. It provides input to the project-approval process, and is therefore intimately related to the Business Case. It communicates the fundamental "why's and what's" related to the project and is a gauge against which all future decisions should be validated.

1. The Vision Artifact

Should answer the following questions:• What are the key terms? (Glossary) • What problem are we trying to solve?

(Problem Statement) • Who are the stakeholders? Who are the

users? What are their needs? • What are the product features? • What are the functional requirements? (Use

Cases) • What are the non-functional requirements? • What are the design constraints?

The contents of the Vision

• The essence of Project Management:

– conceiving a new project; – evaluating scope and risk; – monitoring and controlling the project; – planning for and evaluating each iteration

and phase

• Project Management: – Overview

2. Plan—Manage to the Plan

Project Management: Overview

• It is essential to identify and attack the highest

risk items early in the project and track them, along with other related issues. The Risk List is intended to capture the perceived risks to the success of the project. It identifies, in decreasing order of priority, the events which could lead to a significant negative outcome.

• Along with each risk, should be a plan for mitigating that risk. This serves as a focal point for planning project activities, and is the basis around which iterations are organized.

3. Risks—Mitigate Risks and Track Related Issues

• Risk Magnitude: Most Damaging• Description

– Areas of risk include the inability to deliver a solution that meets capacity requirements or to issue a page to a paging device. While the technology to provide such capability exists, the ability to send as many as 500,000 pages within 5 minutes will need to be proven.

• Impacts – System not functional, probably resulting in loss of subscribers.

• Indicators – Failed or delayed delivery of messages within established time frame of

5 minutes.• Mitigation Strategy

– Context has provided similar pager capability for other projects, therefore this area of technical risk is relatively low. Context Integration must provide an estimate of time required to process and push information to subscribers based on average and maximum projected workloads, which are currently 200,000 to 500,000 subscribers. Context Integration will develop a scalable system. will provide hardware resources necessary to meet processing requirements. Context can not guarantee the ability of each paging gateway service to deliver service levels within the desired specifications.

Technical Risk : Capacity and Capability

• The Business Case provides the necessary information, from

a business standpoint, to determine whether or not this project is worth investing in.

• The main purpose of the Business Case is to develop an economic plan for realizing the project Vision. Once developed, the Business Case is used to make an accurate assessment of the return on investment (ROI) provided by the project. It provides the justification for the project and establishes its economic constraints. It provides information to the economic decision makers on the project's worth, and is used to determine whether the project should move ahead.

• The description should not delve deeply into the specifics of the problem, but rather it should create a compelling argument why the product is needed. It must be brief, however, so that it is easy enough for all project team members to understand and remember. At critical milestones, the Business Case is re-examined to see if estimates of expected return and cost are still accurate, and whether the project should be continued

4. Business Case—Examine the Business Case

1.  Introduction. [The introduction of the Business Case should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Business Case.]

2.   Product Description. [To give a context to the reader, briefly describe the product that is to be developed. Include the name of the system and possibly an acronym, if one is used. Explain what problem it solves and why the development will be worth the effort. Refer to the Vision document.]

3.    Business Context. [Define the business context for the product. In which domain is it going to function (for example, telecom or bank) and what market—who are the users? State whether the product is being developed to fulfill a contract or if it is a commercial product. If it is a continuation of an existing project, this should also be mentioned.]

4.    Product Objectives. [State the objectives for developing the product— the reasons why this is worthwhile. This includes a tentative schedule, and some assessment of schedule risks. Clearly defined and expressed objectives provide good grounds for formulating milestones and managing risks; that is, keeping the project on track and ensuring its success.]

5.    Financial Forecast. [An example of a possible cost-benefit analysis table is shown below.]Financial Forecast - <n> years Value TotalsBenefits  [revenue enhancement] $  [expense reduction] $  [intangibles (good will, visibility)] $ $   Costs  [capital] $  [expense] $ $   ROI (benefits/costs)  % 

6.   Constraints. [Express the constraints under which the project is undertaken. These constraints impact risk and cost. They could be things like external interfaces that the system must adhere to, standards, certifications or a technical approach employed for strategic reasons, such as using a certain database technology or distribution mechanisms.]

Business Case Template – RUP

5. Architecture—Design a Component Architecture

• In the Rational Unified Process (RUP), the architecture of a software system (at a given point) is the organization or structure of the system's significant components interacting through interfaces, with components composed of successively smaller components and interfaces. – What are the main pieces? – And how do they fit together?  – Do we have a framework on which the rest of the

software can be added?

6. Prototype—Incrementally Build and Test the Product

• The RUP is an iterative approach of building, testing, and evaluating executable versions of the product in order to flush out the problems and resolve risks and issues as early as possible.

7. Evaluation—Regularly Assess Results• Regular status assessments provide a mechanism for

addressing, communicating, and resolving management issues, technical issues, and project risks. In addition to identifying the issues, each should be assigned a due date, with a responsible person who is accountable for the resolution. This should be regularly tracked and updated as necessary.

8. Change Requests—Manage and Control Changes

• Change Requests are used to document and track defects, enhancement requests and any other type of request for a change to the product. The benefit of Change Requests is that they provide a record of decisions, and, due to their assessment process, ensure that impacts of the potential change are understood by all project team members. The Change Requests are essential for managing the scope of the project, as well as assessing the impact of proposed changes.

9. User Support—Deploy a Usable Product The purpose of a process is to produce a usable

product.  All aspects of the process should be tailored with this goal in mind.  The product is typically more than just the software.  At a minimum, there should be a User’s Guide, perhaps implemented through online help.  You may also include an Installation Guide and Release Notes. Depending on the complexity of the product, training materials may also be needed, as well as a bill of materials along with any product packaging.

10. Process—Adopt a Process that Fits Your Project

It is essential that a process be chosen which fits the type of product you are developing. Even after a process is chosen, it must not be followed blindly — common sense and experience must be applied to configure the process and tools to meet the needs of the organization and the project.