Transcript Introduction to the Unified Approach

RUP Overview
Seyyed Jamaleddin Pishvayi
[email protected]
Objectives: Rational Unified
Process Overview
Explain the role of process in software
development.
Explore the phase organization of
Rational Unified Process and its
relationship to iterative development.
Explore the discipline organization of
Rational Unified Process and its
relationship to iterative development
Introduction to disciplines
Role of Development Process
Define the steps that lead to deliverables
and who is responsible for them.
Help to control the project and reduce
confusion.
Help project management to resource, plan,
and measure progress.
Reduce risk.
Make software development predictable,
repeatable, and measurable.
Role of UML in RUP
Rational Unified Process was
developed hand-in-hand with the UML.
Many artifacts in Rational Unified
Process have a UML representation.
Rational Unified Process also includes
guidelines for UML concepts.
RUP Structure
RUP Organization along time
 Lifecycle
structure: phases, iterations
 Process enactment: planning, executing
 Activity management, project control
RUP Organization based on content
 Disciplines,
Workflows
Roles, Artifacts, Activities,
Organization Along Time
Time
Major Milestones: Business Decision
Points
Product sufficiently
mature for customers
Commit resources
for construction
Customer
acceptance
or end of life
Commit resources
for the elaboration
phase
Inception
Elaboration
Construction
Transition
time
Lifecycle
Objective
Milestone
Lifecycle
Architecture
Milestone
Initial Operational
Capability
Milestone
Product
Release
Inception Phase: Objectives
Prepare supporting environment for project
Establish project scope and boundary conditions
Determine the use cases and primary scenarios
that will drive the major design trade-offs
Demonstrate a candidate architecture against
some of the primary scenarios
Estimate the overall cost and schedule
Identify potential risks (the sources of
unpredictability)
Elaboration Phase
The overriding goal of the elaboration
phase is to analyze the problem
domain, establish a architectural
foundation, develop the project plan,
and eliminate the project’s high-risk
elements.
Elaboration Phase: Objectives
Refine support environment
Define, validate and baseline the
architecture as rapidly as is practical
Baseline the vision
Baseline a detailed plan for the
construction phase
Demonstrate that the baseline
architecture will support the vision at a
reasonable cost in a reasonable period
of time
Construction Phase
The overriding goal of the construction
phase is to develop all remaining
components and features and integrate
them into the product.
Construction Phase:
Objectives
Completing the software product for transition
to production
Minimizing development costs by optimizing
resources and avoiding unnecessary scrap
and rework
Achieving adequate quality as rapidly as is
practical
Achieving useful versions (alpha, beta, and
other test releases) as rapidly as possible
Transition Phase
The overriding goal of the transition
phase is to move the product to the
user community.
Transition Phase: Objectives
Achieving user self-supportability
Achieving stakeholder concurrence that
deployment baselines are complete and
consistent with the evaluation criteria of
the vision
Achieving final product baseline as
rapidly and cost-effectively as possible
What Is an Iteration?
Phases and Iterations
Planned (Business) Decision Points
Commit resources for the
elaboration phase
Commit resources
for construction
(Understand the problem)
(Understand the solution)
Inception
Preliminary
Iteration
Elaboration
Architect.
Iteration
Product sufficiently mature for
customers to use
(Have a solution)
Construction
Architect.
Iteration
Devel.
Iteration
Acceptance
or end of life
Devel.
Iteration
Transition
Devel.
Iteration
Planned (Technical) Visibility Points
Transition
Iteration
Transition
Iteration
Iteration: Number and
Duration
Duration driven by
+ size of organization
+ size of project
- familiarity with the process, maturity
- technical simplicity
6, plus or minus 3
Inception:
0 .. 1
Elaboration:
1 .. 3
Construction: 1 .. 3
Transition:
1 .. 2
One Iteration
In an
iteration,
you walk
through all
disciplines.
Content
Organization Based on
Content
Key RUP Elements: Roles,
Activities, Artifacts
performs
Role
Activity
Designer
Use-Case
Analysis
responsible for
Artifact
Use-Case Realizations
Roles Perform Activities and
Produce Artifacts
Business
Rules
Vision
Requirements
Stakeholder Vision
Requests (refined) Supplementary Management
Plan
Specifications
Requirements
Attributes
Example:
Requirements->
Workflow Detail->
Define the System
Develop
Vision
Manage
Dependencies
System
Analyst
Requirements
Attributes
(refined)
Capture a
Common
Vocabulary
Find Actors
and Use Cases
Use-Case Model
(refined)
Glossary
Glossary
(refined)
Use-Case
Modeling
Guidelines
Business
Object Model
Business
Use-Case Model
Use-Case Model
Use Case
(outlined)
Key RUP Element: Role
A Role defines the behavior and
responsibilities of an individual, or a set of
individuals working together as a team.
Team members can “wear different hats,”
that is, each member can play more than
one Role.
Roles Are Used for Resource
Planning
Resource
Role
Activities
Paul
Designer
Define Operations
Mary
Requirements Specifier
Detail a Use Case
Joe
System Analyst
Find Actors and Use Cases
Sylvia
Implementer
Perform Unit Tests
Stefan
Architect
Identify Design Mechanisms
Each individual in
the project is
assigned to one or
several roles
Key RUP Element: Activity
A piece of work a Role is responsible
for, that the Role may be asked to
perform
Granularity: a few hours to a few days
Repeated, as necessary, in each
iteration
Key RUP Element: Artifact
A document or model
produced, evolved, or used
by a process
The responsibility of a Role
Likely to be subject to
configuration control
May contain other artifacts
Key RUP Elements: Roles,
Activities, Artifacts
performs
Role
Designer
Activity
Use-Case
Analysis
responsible for
Artifact
Use-Case Realizations
Disciplines also contain Workflows and Workflow
Details, as you will see.
Nine Disciplines
Elements of a Discipline
If you expand any Discipline in the RUP tree
browser, you will see the following:
Key RUP Element: Workflow
The conditional flow of
high-level activities that
produces a result of
observable value.
Example:
Environment: Workflow
Workflow Details
Example:
Workflow Detail: Prepare Environment for Project
Workflow Path Is Adapted to:
Position in
 Lifecycle
 Phase
Artifacts being
produced
Technology
Iteration goals
Example:
Analysis & Design
Workflows Guide Iterative
Modeling:
Development Business
Workflow Details
Requirements:
Workflow Details
Iteration Plan
Includes
relevant
portions of
Discipline
for a
particular
iteration
Iteration Plan (cont.)
Instantiation of the
discipline
One for each iteration
A fine-grained plan
Expressed in terms of
selected Workflow
Details or Activities
from the disciplines
Shows assigned
resources
Summary of Major Artifacts
Summary of Organization
Additional Process Elements
Discipline
Introduction
 Concepts
 Workflow
 Activity Overview



And associated Tool Mentors and Guidelines
Artifact Overview

And associated Templates and Guidelines
Guidelines Overview
 Roadmaps

Process Element: Concepts
Attached to the relevant Discipline
Explanation of key ideas
Examples of Concepts
 Requirements
 Requirements Management
 Types of Requirements

Traceability
 Analysis and Design
 Software Architecture
 Analysis Mechanisms

Web Architecture Patterns
Process Element: Guidelines
These are Rules, recommendations, heuristics that
support activities and their steps. They:
Describe specific techniques.
Transformations from one artifact to another
 Use of UML

Are attached to relevant discipline.
Are kept short and to the point.
Describe well-formed artifacts and focus on
qualities.
Are used also to assess the quality of artifacts.
Are tailored for the project.
Process Element: Tool
Mentors
Attached to relevant activity
Explain how to use a specific tool to
perform an activity or steps in an activity
Linked by default to Rational tools:
 RequisitePro:
requirements management
 Rational Rose: visual modeling, using UML
 SoDA: documentation generation
 ClearQuest: change management, defect
tracking
 …and more
Process Element: Templates
Attached to relevant document type
Predefined artifacts, prototypes:
 Documents
(Microsoft® Word™, Adobe®
Framemaker™)
 MS Project
 HTML
Tailored for the process
Process Element: Roadmap
Roadmaps are used to:
Apply the general-purpose process to
solve specific types of problems.
Describe process variants using
phases.
Provide a mechanism for extending and
adapting the process.
Highlight certain process features to
achieve a particular goal.
Discipline: Environment
Purpose: Support the development
organization, both with process and
tools
 Process configuration
 Adapt RUP to organization
 Process implementation
 Train and mentor RUP users
 Process
improvement
 Managing organizational change
 Development environment


Tool selection and acquisition
Tool instillation and configuration
Discipline: Environment
The primary roll in the Environment
Discipline is the Process Engineer.
The primary artifact produced by the
Process Engineer is the Development
Case.
The Development Case describes, for
each process discipline, how the project
will apply the process.
Discipline: Project
Management
Purpose:
 Provide
a framework for managing
software-intensive projects
 Provide practical guidelines for planning,
staffing, executing, and monitoring projects
 Provide a framework for managing risk
Discipline: Project
Management
Questions that must be addressed by
the project manager:
 How
many iterations are needed?
 How long should each iteration be?
 How are the contents and objectives of an
iteration determined?
 How is the progress of an iteration tracked?
Discipline: Project Management
Project planning takes place at two levels
Phase Plan Level
1.



Dates of major milestones: end of each phase and its
objectives
Staffing profiles: which resources are required over time.
Dates of minor milestones: end of each iteration and its
objectives
Iteration Plan Level
2.


Current iteration plan
Next iteration plan (built toward end of current iteration)
Discipline: Requirements
Purpose:
Establish and maintain agreement with the customers
and other stakeholders on what the system should do.
 Provide system developers with a better understanding
of the system requirements.
 Define the boundaries of (delimit) the system.
 Provide a basis for planning the technical contents of
iterations.
 Provide a basis for estimating cost and time to develop
the system.
 Define a user-interface for the system, focusing on the
needs and goals of the users.

Primary Requirements Artifacts
Requirement
Functional
NonFunctional (URPS)
Supplementary Specification
Use-Case Model
Discipline: Business Modeling
Purpose
 Understand
structure and dynamics of
organization in which system is to be
deployed
 Understand problems in target organization
and identify improvement potentials
 Ensure customer/end user common
understanding of target organization
 Derive system requirements to support
target organization
What a Business Model
Shows
Customers
Business processes
Organizational
structure
Roles and
responsibilities
Products
Internal deliverables
Events
Two business models
Business
Use-Case Model
Business
Object Model
Discipline: Analysis & Design
Purpose:
 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 nonfunctional requirements and the
implementation environment
Design is a refinement of analysis
Primary artifact is Design Model
The Design Model Artifact:
Consists of a collection of models that
collaborate to describe the structure and
behavior of the system.
Is an object model describing the
realization of use cases.
Serves as an abstraction of the
implementation model and its source
code.
Is used as essential input to activities in
implementation and test.
Use Cases Drive Analysis &
Design
Analysis Model (optional)
Use-Case Model
Analysis
and Design
Design Model
Supplementary
Specifications
Architecture
Document
Data Model
Use-Case Realization
<<realizes>>
Use Case
(Use-Case Model)
Use Case
Use-Case Realization
(Design Model)
Sequence Diagrams
Class Diagrams
Collaboration Diagrams
Discipline: Test
Purpose: Testing focuses primarily on the
evaluation or assessment of quality realized
through a number of core practices:

Finding and documenting defects in software quality.
 Generally advising about perceived software quality.
 Proving the validity of the assumptions made in design
and requirement specifications through concrete
demonstration.
 Validating the software product functions as designed.
 Validating that the requirements have been implemented
appropriately.
Test discipline acts in many respects as a service
provider to the other disciplines.
Discipline: Implementation
The purposes of Implementation are:
 To
implement classes and objects in terms
of components
 To define the organization of the
components in terms of implementation
subsystems
 To test the developed components as units
 To create an executable system
Implementation results in an
Implementation Model.
Implementation
Model
Implementation Model
An Implementation
Model consists of:
Components
 Implementation
Subsystems

Telephone Banking
A
Components include:
Deliverable components,
such as executables
 Components from which
the deliverables are
produced, such as source
code files

<<import>>
<<compilation>>
Trading Services
B
Components and implementation
subsystems in a Telephone Banking
System.
Concept: Build
Operational version of a system or part
of a system
Demonstrates a subset of the
capabilities provided in the final product
Integral part of the iterative lifecycle
Provides review points
Helps uncover integration problems as
soon as they are introduced
Discipline: Deployment
Purpose: Manage the activities associated
with ensuring that the software product is
available for its end users, such as:
 Product
deployment
 Testing at the installation and target sites
 Beta testing
 Creating end-user support material
 Creating user training material
 Releasing to customer (in the form of shrinkwrapped package, download site, etc.)
Use Cases and End-User
Documentation
Use-Case Model
Deployment
Supplementary
Specification
End-User Support Material
•User’s Guide
•Online Help
•Demos
•Tutorials
•Training Material
Discipline: Configuration &
Change Management
Purpose: Track and maintain integrity of
project artifacts
Change control
 Configuration identification and management
 Configuration status accounting
 Change tracking
 Version selection
 Software manufacture
 Workspace management

The Configuration and Change
Management (CCM) Cube
Configuration Management (CM)
Describes the product structure
(logically correct configurations)
Identifies which artifacts are to be
tracked
Identifies dependencies among artifacts
Maintaining traceability between
artifacts
Isolate individual and team workspaces
Change Request Management
(CRM)
Addresses:
The capture and management of
requested changes to one or more
artifacts by various stakeholders.
A change request has a lifecycle: new, logged,
approved, assigned and complete.
 Not all change requests are acted on. The
potential impact of a proposed change determines
if it will be acted on.

RUP Overview
Seyyed Jamaleddin Pishvayi
[email protected]