1. The Rational Unified Process® RUP® - For Dummies
Speaker Support Notes
The Rational Unified Process® RUP® - For Dummies

2. What You Should Walk Away With …
Speaker Support Notes
What You Should Walk Away With …
Understand some of the high level fundamentals of RUP
Know of Rational’s 6 best practices for software development
Develop s/w iteratively
Manage requirements
Use component-based architectures
Visually model software
Continuously verify software quality
Control changes to s/w
Be familiar with RUP’s phases & disciplines
Understand value on running projects based upon risk-driven, iterative approach to software development
Know that RUP is set of guidelines not rules
6 Best Practices:
1)Develop s/w iteratively
2) Manage requirements
3) Use component-based architectures
4) Visually model software
5) Continuously verify software quality
6) Control changes to s/w

3. What You Should Walk Away With …
Speaker Support Notes
What You Should Walk Away With …
See first that the design is wise and just; That ascertained, pursue it resolutely
-- William Shakespeare

4. What If… Speaker Support Notes
You were asked to deliver your current project 20% sooner than you planned?
Will you able to say yes?
If you were able to do it?
What would that mean to
Your organization?
Your team?
You personally?
Let me start by asking you a couple of questions:
(Go through the questions, pausing after each top-level bullet)
(Make sure you don’t give the impression that RUP helps you do as much or more in 80% of the time. What RUP helps you do is make sure that you are focused on delivering the most important value to your customer as quickly as possible.)
I am going to talk to you today about the Rational Unfied Process. It is a software development process product that can help you achieve the results you want from your software development projects.

5. Agenda Overview … Speaker Support Notes Best Practices Agenda
Develop Iteratively
Manage Requirements
Use Component Architecture
Model Visually (UML)
Continuously Verify Quality
Manage Change
Disciplines’ Agenda
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
Phases Agenda
Inception
Elaboration
Construction
Transition

6. Disciplines / Phases / Iterations
Speaker Support Notes
Disciplines / Phases / Iterations
Organization by CONTENT
One picture that says it all …
Disciplines and Iterations : Content Vs. Time
4 Phases
Iterative cycles within Elaboration / Construction / Transition
Discuss the Disciplines
Discuss the phases and amount of time involved in each
The Rational Unified Process (RUP) is a software engineering process.  It provides a disciplined approach to assigning tasks and responsibilities within a development organization.  Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. The figure at the top shows the overall architecture of the RUP.
The RUP has two dimensions:
the horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds
the vertical axis represents disciplines, which group activities logically by nature.
The first dimension represents the dynamic aspect of the process as it is enacted, and it is expressed in terms of phases, iterations, and milestones.
The second dimension represents the static aspect of the process: how it is described in terms of process components, disciplines, activities, workflows, artifacts, and roles (see Key Concepts).
The graph shows how the emphasis varies over time. For example, in early iterations, we spend more time on requirements, and in later iterations we spend more time on implementation.
Organization by TIME

7. The Rational Unified Process
Speaker Support Notes
The Rational Unified Process
RUP Process Made Practical
Sustained development of quality software
Delivered on-time and on-budget
Requires more than “heroic” individuals
Cohesive teamwork & common understanding of development tasks
Ensures implementation is predictable and repeatable
In this presentation I will tell you why we say RUP is “process made practical,” and what that means to you.

8. The Spirit of RUP Speaker Support Notes
Attack major risks early and continuously
… Or they attack you
Use working software as primary measure of progress
Completed plans, requirements, and design are good - working software is better
Produce only artifacts you need
When in doubt, don’t produce it
Accommodate changes in requirements and design
Allow for changes, but manage them
Some people think a process is just overhead. If you look at RUP, without considering how you might configure it, you could come to that conclusion. RUP is meant to be configured. When you configure the process, and follow the spirit of RUP, you don’t have a lot of overhead. What you have is a streamlined process that benefits your whole team.
(A primary directive for configuring a process is this: Ask yourself this question. If I don’t perform a specific activity or produce a certain artifact, will anything bad happen? If the answer is no, then don’t do it. If you follow this guideline, you avoid having a process that adds overhead with no value.)
Let’s look in some detail about the true spirit of RUP.
RUP is risk driven. You constantly identify and prioritize risks, your mitigation strategy, and continuously make sure you are addressing the biggest risks.
When you develop iteratively, you deliver working software at the end of every iteration, except perhaps the first couple of iterations when you are defining the product. This helps you avoid the problem of not being able to deliver to your customer. You may not have 100% of the system complete, but if you have 80%, it will be a working 80% and it will be the most important 80% that delivers the most value to your customer. (Think about buildings. Weather, or other circumstances that are often beyond your control, may cause you to be complete later than planned. But, if you get the shell built first, you will be able to continue working while there may be limited occupancy.)
By configuring the process correctly (go back to the prime directive) you only produce things that are important to producing software.
One of the best practices embodied in RUP is managing requirements. There is detailed information about how to capture requirements with use cases, and using the requirements all the way through coding and testing. By using use cases you ensure that you deliver software that does something useful for the customer.

9. The Spirit of RUP Speaker Support Notes
Ensure that you deliver value to your customer
Design, implementation, and testing address customer needs
Documenting customer needs is good, implementing them is better
Baseline an executable architecture early
First build the skeleton structure, then fill in the holes
Work closely as one team
Affects organization, tooling and team values
Quality is a way of life, not an afterthought
Quality from the beginning, quality by design
The first bullet is similar to the second bullet on the previous slide.
RUP invites you to spend time on architectural issues. While you can expect your architecture to evolve, spending some time up front pays off in the long run. The emphasis on architecture is a differentiator between RUP and some other methodologies.
Since RUP helps you unify your team, it enables the team to work more effectively and help them develop a team culture.
RUP stresses continual quality focus. You might even say that it has a maniacal emphasis on quality. The newly revised and restructured Test discipline provides the most up-to-date testing information for your quality professionals and your developers.

10. Agenda Phases … Speaker Support Notes Phases Agenda: Inception
Elaboration
Construction
Transition

11. Agenda Phases: Overview…
Speaker Support Notes
Agenda Phases: Overview…
The software lifecycle of the Rational Unified Process (RUP) is
Four sequential phases,
Each concluded by a major milestone;
At each phase-end an assessment is performed to determine whether the objectives of the phase have been met.
A satisfactory assessment allows the project to move to the next phase.

12. Agenda Phases: Overview …
Speaker Support Notes
Agenda Phases: Overview …
Inception
Elaboration
Construction
Transition
Effort
~5 %
20 %
65 %
10%
Schedule
10 %
30 %
50 %

13. Agenda Disciplines … Speaker Support Notes
Disciplines’ Agenda:
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
A discipline shows all activities you may go through to produce a particular set of artifacts:
Roles,
Activities, and
Artifacts that are involved

14. Discipline: Business Modeling
Speaker Support Notes
Discipline: Business Modeling
Purpose
To understand the structure and the dynamics of the organization in the target organization
To understand current problems in the target organization and identify improvement potentials
To ensure that customers, end users, and developers have a common understanding of the target organization
To derive the system requirements needed to support the target organization.
Relation to Other Disciplines
Requirements
Analysis & Design
Environment

15. Discipline: Requirements
Speaker Support Notes
Discipline: Requirements
Purpose
To establish agreement with the customers and other stakeholders on what the system should do
To provide system developers with a better understanding of the system requirements
To define the boundaries of the system
To provide a basis for estimating cost and time to develop the system
To define a user-interface for the system, focusing on the needs and goals of the users
Relation to Other Disciplines
Business Modeling
Analysis & Design
Test
Configuration & Change Mgt
Project Management
Environment

16. Discipline: Analysis & Design
Speaker Support Notes
Discipline: Analysis & Design
Purpose
To turn the requirements into a design of the system-to-be
To develop a comprehensive architecture for the system
To adapt the design for performance
Relation to Other Disciplines
Business Modeling
Requirements
Test
Environment
Project Management

17. Discipline: Implementation
Speaker Support Notes
Discipline: Implementation
Purpose
To define the organization of the code, in terms of subsystems organized in layers
To implement classes and objects in terms of components (source files, executables, and others),
To test the developed components as units
To integrate the results produced by individual developers (or teams), into an executable system
Relation to Other Disciplines
Requirements
Analysis & Design
Test
Environment
Deployment
Project Management

18. Discipline: Test Speaker Support Notes Purpose
To verify the interaction between objects
To verify the proper integration of all components of the software
To verify that all requirements have been correctly implemented
To identify and ensure defects are addressed prior to the deployment of the software
Relation to Other Disciplines
Requirements
Analysis & Design
Implementation
Environment
Management

19. Discipline: Deployment
Speaker Support Notes
Discipline: Deployment
Purpose
The custom install
The "shrink wrap" product offering
Access to software over the internet
Relation to Other Disciplines
Requirements
Testing
Configuration & Chg Mgt
Environment
Project Management

20. Discipline: Config. & Chg Mgt
Speaker Support Notes
Discipline: Config. & Chg Mgt
Purpose
Identifying configuration items
Restricting changes to those items
Auditing changes made to those items
Defining and managing configurations of those items
Ensure completeness and correctness of the configured product
Provide an audit trail on why, when and by whom any artifact was changed
Relation to Other Disciplines
Business Modeling
Requirements
Analysis & Design
Testing
Deployment
Configuration & Chg Mgt
Environment
Project Management

21. Discipline: Project Management
Speaker Support Notes
Discipline: Project Management
Purpose
To provide a framework for managing software-intensive projects.
To provide practical guidelines for planning, staffing, executing, and monitoring projects.
To provide a framework for managing risk
Risk management
Planning an iterative project, through the lifecycle and for a particular iteration
Monitoring progress of an iterative project, metrics
Relation to Other Disciplines
Business Modeling
Requirements
Analysis & Design
Deployment
Implementation
Testing

22. Discipline: Environment
Speaker Support Notes
Discipline: Environment
Purpose
To configure the process for a project
to provide the software development organization with the software development processes and tools
Relation to Other Disciplines
Business Modeling
Requirements
Analysis & Design
Testing
Deployment
Configuration & Chg Mgt
Implementation
Project Management

23. Summary: Overall Benefits
Speaker Support Notes
Summary: Overall Benefits
With the rational unified process solution you will:
Optimize the collaboration of your complete team
RUP helps you unify your team
Deliver the right product on time and on budget
RUP helps you focus on delivering working software
Effectively be able to adopt new techniques and tools on your projects
RUP helps you leverage new tools and technologies
Restate the original question and show how RUP helps you say YES!

24. Summary … Speaker Support Notes Best Practices Agenda
Develop Iteratively
Manage Requirements
Use Component Architecture
Model Visually (UML)
Continuously Verify Quality
Manage Change
Disciplines’ Agenda
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
Let me start by asking you a couple of questions:
(Go through the questions, pausing after each top-level bullet)
(Make sure you don’t give the impression that RUP helps you do as much or more in 80% of the time. What RUP helps you do is make sure that you are focused on delivering the most important value to your customer as quickly as possible.)
I am going to talk to you today about the Rational Unfied Process. It is a software development process product that can help you achieve the results you want from your software development projects.
Phases Agenda
Inception
Elaboration
Construction
Transition

25. Speaker Support Notes
Thank You
Thank you.

26. Speaker Support Notes Reference Articles:
Accessing the RUP against ISO/IEC : Information Technology – Software Process Assessment Part 5: An Assessment Model And Indicator Guidance
Using the RUP for Small Projects: Expanding Upon eXtreme Programming by Gary Pollice, Rational Software
The Rational Unified Process An Introduction (2nd Edition)
- White Papers