Get documents about "Introduction to the Unified Approach
Shared by: HC120808113227
-
Stats
- views:
- 3
- posted:
- 8/8/2012
- language:
- pages:
- 66
Document Sample
RUP Overview
Seyyed Jamaleddin Pishvayi
seyyedjamal@asta.ir
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, Roles, Artifacts, Activities,
Workflows
Organization Along Time
Time
Major Milestones: Business Decision
Points
Customer
Product sufficiently
acceptance
mature for customers
or end of life
Commit resources
for construction
Commit resources
for the elaboration
phase
Inception Elaboration Construction Transition
time
Lifecycle Lifecycle Initial Operational Product
Objective Architecture Capability Release
Milestone Milestone Milestone
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 Commit resources Product sufficiently mature for Acceptance
elaboration phase for construction customers to use or end of life
(Understand the problem) (Understand the solution) (Have a solution)
Inception Elaboration Construction Transition
Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition
Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration
Planned (Technical) Visibility Points
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.
Organization Based on
Content
Content
Key RUP Elements: Roles,
Activities, Artifacts
performs
Role Activity
Use-Case
Designer Analysis
responsible for
Artifact
Use-Case Realizations
Roles Perform Activities and
Produce Artifacts
Business Vision Stakeholder Vision Requirements
Rules Requests (refined) Supplementary Management
Specifications Plan
Requirements
Attributes
Example: Develop
Vision
Manage
Dependencies
Requirements-> System Requirements
Analyst Attributes
Workflow Detail-> (refined)
Capture a Find Actors
Define the System Common and Use Cases
Vocabulary
Use-Case Model
(refined)
Use-Case
Modeling Business Use Case
Glossary (outlined)
Glossary Guidelines Object Model Use-Case Model
(refined) Business
Use-Case Model
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 Activity
Use-Case
Designer 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:
Workflow Details
Environment: Workflow
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
Development Business Modeling:
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
Processimprovement
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
1. Phase Plan Level
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
2. Iteration Plan Level
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
Two business models
Customers
Business processes
Organizational
Business
structure Use-Case Model
Roles and
responsibilities
Products
Business
Internal deliverables Object Model
Events
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 non-
functional 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
Data Model
Architecture
Document
Use-Case Realization
<<realizes>>
Use Case Use-Case Realization
(Use-Case Model) (Design Model)
Use Case Sequence Diagrams Collaboration Diagrams
Class 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
Telephone Banking
Subsystems
A
Components include: <<import>> <<compilation>>
Deliverable components, Trading Services
such as executables B
Components from which
Components and implementation
the deliverables are subsystems in a Telephone Banking
produced, such as source System.
code files
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 shrink-
wrapped package, download site, etc.)
Use Cases and End-User
Documentation
Use-Case Model
Deployment
End-User Support Material
•User’s Guide
Supplementary •Online Help
Specification •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
seyyedjamal@asta.ir
