Transcript Rational Unified Process
Rational Unified Process
1
Agenda
Part I: Introduction Part II: Disciplines & Workflows Part III: Phases & Iterations Part IV: Configuring RUP
2
Introduction
What’s Rational?
•
Three important contributors
– – –
Grady Booch (Booch Method) James Rumbaugh (OMT Method) Ivar Jacobson (OOSE Method)
3
Introduction
Why Unified?
Unification of Development Approaches using UML
Unification of the Work Of many Methodologists
4
Introduction
What’s 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 user’s requirements into a software system[Jacobson]
5
Introduction
History Of RUP
UML
Rational Unified Process 1998 Rational Objectory Process 1996-1997 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
7
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
8
Features
Process Framework
Rational Unified Process Is specialized to My Development Process Is enacted as My Project
9
Features
The Architecture of RUP
process disciplines or workflows time and the lifecycle
10
3+1 Keywords
The 3+1 Keywords
Architecture Centric
Use Case Driven
Iterative and Incremental
}
From USDP
Risk Confronting
11
3+1 Keywords
RUP is
Use Case Driven
Use-Case Model
Specified by Realized by
Analysis Model
Implemented by
Design Model Implementation Model
Distributed by
Model
Verified by
Deployment Test Model
12
3+1 Keywords
RUP is
Iterative & Incremental Iteration 1
Requirements analysis Design Code and unit test Subsystem integration System test
Iteration 2
Requirements analysis Design Code and unit test Subsystem integration System test
13
3+1 Keywords
RUP is
Architecture Centric
Logical View Implementation View Analysts/ Designers
Structure
End-user
Functionality
Use-Case View Process View System Integrators
Performance Scalability Throughput
Programmers
Software management
Deployment View System Engineering
System topology Delivery, installation communication
14
3+1 Keywords
RUP is
Risk Confronting
Architectural prototype Draft specifications & models Elaboration Initial executable system Refined specifications & models Focus on the 20% that really matter:
•
The primary use cases
•
The architectural components
•
The driving scenarios R i s k 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 workflows.
17
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 software intensive 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
[more components to implement in this iteration] [more subsystem integration for this iteration] [more system builds for this iteration]
Implement Components 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:
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 •Microsoft Word Template •HTML Template
Examples:
•Course Registration System •Collegiate Sports Paging System (e-Business)
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 model appears to be able to accommodate reasonably expected future change. The design is appropriate to the task at hand (neither too complex nor too advanced) The design appears to be implementable The design appears to be understandable and maintainable There are no more than seven (plus or minus two) layers. The rationale for layer definition is clearly presented and consistently applied.
33
Use-Case Specification—HTML Template
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 customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable¾you 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 Inception Elaboration Construction Transition Elaboration Construction Transition
time
Understand what to build
Define the Scope of Project and Develop Business Case and Critical Use-Case
Understand how to build it
Plan Project, Specify Features, and Baseline the Architecture
Build the Product
Produce a beta product
Transition the Product to its Users
Produce final product
36
Milestones
time
Inception Elaboration Construction Transition
Lifecycle Objectives Milestone Lifecycle Architecture Milestone Initial Operational Capability 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 Elaboration Construction Transition Preliminary Iteration Architect.
Iteration Architect.
Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Minor Milestones: Releases
38
Phases
Iteration as Waterfall
In an iteration , you walk through all workflows
39
Phases
The Iteration Life Cycle: A Mini Waterfall
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
Initial Planning Requirements Capture Planning Management Environment Analysis & Design Implementation 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
Inception Elaboration Construction Transition
1 1 3 1
Project Length
3-4 month
Iteration Length
2-3 weeks Time:
10% 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 Time Devel. Iteration Transition Iteration Transition Iteration Post deployment 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 Essentials Each have different Equipment Each have different Safety and Security Each have different Risk
•
RUP is a Framework not a single Process
•
No one process fits all projects
•
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 Development Case Develop Project Specific Templates 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!
Rose Content Studio Project Console Purify Quantify PureCoverage
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,
www.rational.com/rup www.therationaledge.com
51
Rational Unified Process
This presentation can be download from: http://www.BaridSoft.ca
52