Rational Unified Process
Agenda
Part I: Introduction
Part II: Disciplines & Workflows
Part III: Phases & Iterations
Part IV: Configuring RUP
Introduction
Whats Rational?
Three important contributors Grady Booch (Booch Method) James Rumbaugh (OMT Method) Ivar Jacobson (OOSE Method)
Introduction
Why Unified?
Unification of Development Approaches using UML
Unification of the Work Of many Methodologists
Introduction
Whats Process?
Defines Who is What, When to do it, and How to reach a certain goal.
A Software Development Process is the set of activities needed to transform a users requirements into a software system[Jacobson]
Introduction
History Of RUP
Rational Unified Process 1998
Rational Objectory Process 1996-1997 UML
Objectory Process 1987-1995
The Ericsson Approach
6
Features
Process Product
Process must be built on Technologies Tools are integral to process People: limit the skill set needed to operate Organization Pattern "Software processes are software, too"
Balance
Features
Process Product
continue
Like a software product is based on UML
Is delivered online using Web technology, not in books or binders
Released by Rational Software approximately twice a year
Features
Process Framework
Rational Unified Process
Is specialized to
My Development Process Is enacted as
My Project
Features
The Architecture of RUP
time and the lifecycle
process disciplines or workflows
10
3+1 Keywords
The 3+1 Keywords
Architecture Centric
Use Case Driven
Iterative and Incremental
Risk Confronting
From USDP
11
3+1 Keywords
RUP is
Use Case Driven
Use-Case Model
Specified by Realized by Implemented by
Analysis Model
Design Model
Distributed by Verified by
Implementation Model
Deployment Model Test Model
12
3+1 Keywords
RUP is
Iterative & Incremental
Iteration 2
Requirements analysis Design Code and unit test
Iteration 1
Requirements analysis Design Code and unit test
Subsystem integration
Subsystem integration
System test
System test
13
3+1 Keywords
RUP is
Architecture Centric
Logical View
Analysts/ Designers Structure End-user Functionality
Implementation View
Programmers Software management
Use-Case View
Process View
System Integrators Performance Scalability Throughput
Deployment View
System Engineering System topology Delivery, installation communication
14
3+1 Keywords
RUP is
Inception
Risk Confronting
Focus on the 20% that really matter: The primary use cases The architectural components The driving scenarios
Architectural prototype Draft specifications & models
Elaboration
Initial executable system Refined specifications & models
R i s k Construction Iteration 3... Intermediate system
Transition
Final system
15
Part II
Process Disciplines & Workflows
16
Definition
Workflow The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business Core workflow A core workflow shows all activities you may go through to produce a particular set of artifacts. Workflow detail A grouping of activities which are performed in close collaboration to accomplish some result. The activities are typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Workflow details are used to group activities to provide a higher level of abstraction and to improve the comprehensibility of 17 workflows.
Workflows
Workflows in RUP
Core Process Workflows
Support Process
Workflows
18
Business Modeling
To understand the structure and the dynamics of 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
19
Workflows
Requirements
To agreement with stakeholders To provide system developers better understanding of the system requirements. define the boundaries of the system. To provide a basis for planning the technical contents of iterations. 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.
glossary
vision
20
Workflows
Analysis and Design
To transform the requirements into a design of the system to-be.
To evolve a robust architecture for the system. To adapt the design to match the implementation environment, designing it for performance.
21
Workflows
Implementation
To define the organization of the code, in terms of implementation subsystems organized in layers To implement classes and objects in terms of components (source files, binaries, executables, and others) To test the developed components as units To integrate the results produced by individual implementers (or teams), into an executable system.
22
Workflows
Test
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.
Test Model
Test Case
23
Workflows
Deployment
The Deployment Workflow describes the activities associated with ensuring that the software product is available for its end users
24
Workflows
Environment
The environment workflow focuses on the activities necessary to configure the process for a project. The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team
25
Workflows
Configuration and Change Management
supports development methods maintains product integrity ensures completeness and correctness of the configured product provides a stable environment within which to develop the product restricts changes to artifacts based on project policies provides an audit trail on why, when and by whom any artifact was changed.
26
Workflows
Project Management
To provide a framework for managing softwareintensive projects. To provide practical guidelines for planning, staffing, executing, and monitoring projects. To provide a framework for managing risk.
NOT Managing people: hiring, training, coaching Managing budget: defining, allocating, etc. Managing contracts, with suppliers and customers
27
Workflows
Key Concepts
28
Workflows
Implementation Workflow
Structure the Implementation Model
Plan the Integration
Implement Components
Implement Components
[more components to implement in this iteration] [more subsystem integration for this iteration]
[more system builds for this iteration]
Implement Components
29
Workflow Details
Structure the Implementation Model
Design Model
Artifact Activity
Worker
Use-Case Specifier Structure the Implementation Model Software Architecture Document
Implementation Model
30
Activity: Structure the Implementation Model
Purpose To establish the structure in which the implementation will reside. To assign responsibilities for Implementation Subsystems and their contents.
Steps Create the initial implementation model structure Adjust implementation subsystems Define imports for each implementation subsystems Decide how to treat executables (and other derived objects) Decide how to treat test assets Update the implementation view Evaluate the implementation model Input Artifacts: Software Architecture Document Supplementary Specifications Design Guidelines Design Model Resulting Artifacts: Implementation View section of the Software Architecture Document Implementation Subsystems Implementation Model
Worker: Architect Guidelines: Guidelines: Implementation Subsystems Tool Mentor: Structuring the Implementation Model Using Rational Rose Setting Up the Implementation Model Using Rational ClearCase
31
Artifact: Software Architecture Document
Software Architecture Document Worker: Template: Microsoft Word Template HTML Template Examples: Course Registration System Collegiate Sports Paging System (e-Business) The Software Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. Architect
More Information: Checkpoints: Software Architecture Document Guidelines: Software Architecture Document
Purpose Brief Outline Timing Responsibility Tailoring Annotated Outline (hyperlinks into HTML template in a new window)
32
Checkpoints: Design Model
Topics General Layers General Layers The design appears to be understandable and maintainable There are no more than seven (plus or minus two) layers. The model appears to be able to accommodate reasonably expected future The design appears to be implementable change. The design is appropriate to the task at hand (neither too complex nor too advanced)
The rationale for layer definition is clearly presented and consistently applied.
33
Use-Case SpecificationHTML Template
<Project Name> Use Case Specification: <Use-Case Name> Version <1.0>
Use Case Specification: <Use-Case Name> 1. Use Case Name [The following template is provided for a Use-Case Specification, which contains the textual properties of the use case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use case properties] [The diagrams of the use case can be developed in a visual modeling tool, such as Rational Rose. A use-case report (with all properties) may be generated with Rational SoDA. For more information, see the tool mentors in the Rational Unified Process.] 1.1 Brief Description [The description should briefly convey the role and purpose of the use case. A single paragraph should suffice for this description.] 2. 2.1 Flow of Events Basic Flow
[This use case starts when the actor does something. An actor always initiates use Cases. The use case should describe what the actor does and what the system does in response. It should be phrased in the form of a dialog between the actor and the system. The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters customer information. It is better to say the Actor enters the customers name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageableyou may want to define things like customer information there to keep the use case from drowning in details. 34
Part III
Phases and Iterations
35
Phases
Lifecycle Phases
Inception Elaboration Construction Transition
time
Inception
Understand what to build
Define the Scope of Project and Develop Business Case and Critical Use-Case
Elaboration
Understand how to build it
Plan Project, Specify Features, and Baseline the Architecture
Construction Transition
Build the Product
Produce a beta product
Transition the Product to its Users
Produce final product
36
Milestones
Inception
Elaboration
Construction
Transition
time
Lifecycle Architecture Milestone Initial Operational Capability
Lifecycle Objectives Milestone
Product Release
37
Phases
Phases and Iterations
An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external) Within each phase are a number of iterations
Inception
Preliminary Iteration
Elaboration
Architect. Iteration Architect. Iteration Devel. Iteration
Construction
Devel. Iteration Devel. Iteration
Transition
Transition Transition Iteration Iteration
Minor Milestones: Releases
38
Phases
Iteration as Waterfall
In an iteration, you walk through all workflows
39
Phases
The Iteration Life Cycle: A MiniWaterfall
Selected scenarios Results of previous iterations Up-to-date risk assessment Controlled libraries of models, code, and tests
Iteration Planning
Requirements Capture Analysis & Design Implementation Test Prepare Release Release description Updated risk assessment Controlled libraries
40
Phases
Iteration
Requirements Capture Planning Implementation Initial Planning Management Environment Analysis & Design
Deployment
Evaluation Test
41
Phases
What the Iterative Lifecycle Is
It is planned and managed It is predictable It accommodates changes to requirements with less disruption It is based on evolving executable prototypes, not documentation It involves the user/customer throughout the process It is risk driven
42
Phases
Phases and Iterations: A Sample
Short e-Business Project 5 Project Member
No of Iterations Project Inception Elaboration Construction Transition Length 3-4 1 Time: 10% 1 3 1 month Iteration Length 2-3
weeks
30%
50%
10%
43
Phases
Risk Profile of an Iterative Development
Inception
Waterfall
Elaboration
Risk
Construction Transition
Preliminary Iteration
Architect. Iteration
Architect. Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
Transition Iteration
Transition Iteration
Postdeployment
Time
Copyright 1997 by Rational Software Corporation
44
Part IV
Configuring RUP
45
Configure RUP
Why Do You Need To Configure RUP
Each have different Objectives
Each have different Equipment
Each have different Risk
RUP is a Framework not a single Process No one process fits all projects Essentials Each have different Safety and Security
All thing will be changed
Technologies Organization
46
Configure RUP
Which Do I Need for My Project
47
Configure RUP
Who Configures The RUP?
Process Engineer
Assess Current Organization
Develop Develop Development Project Specific Templates Case
Launch Development Case
Development Organization Assessment
Development Case
Project Specific Templates 48
Configure RUP
How To Configure The RUP?
Development Case: The development-case description describes the development process that you have chosen to follow in your project Roadmap: Roadmaps provide a way of describing how to use the general-purpose process described in the Rational Unified Process to solve specific types of problems
49
Tools: Rational Suite
Jacobson: a process without integral tools is just an academic idea!
Content Studio Project Console
Purify Quantify PureCoverage
Rose
Rational Unified
Process
TeamTest
RequisitePro ClearQuest SoDA ClearCase
50
References
Unified Software Development Process, Ivar Jacobson, Grady Booch, Jim Rumbaugh Ten Essential Of RUP, Leslee Probasco Trends in Software Engineering a personal view, Ivar Jacobson Object Oriented Methodology, William F. Nazzaro What is RUP, Philippe Kruchten Introduction to Rational Unified Process, Philippe Kruchten Rational Unified Process, [Link]/rup [Link]
51
Rational Unified Process
This presentation can be download from:
[Link]
52
