RUP Overview - PowerPoint PPT Presentation

1 / 66
About This Presentation
Title:

RUP Overview

Description:

RUP Overview Seyyed Jamaleddin Pishvayi seyyedjamal_at_asta.ir Objectives: Rational Unified Process Overview Explain the role of process in software development. – PowerPoint PPT presentation

Number of Views:134
Avg rating:3.0/5.0
Slides: 67
Provided by: astaIrav
Category:

less

Transcript and Presenter's Notes

Title: RUP Overview


1
RUP Overview
  • Seyyed Jamaleddin Pishvayi
  • seyyedjamal_at_asta.ir

2
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

3
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.

4
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.

5
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

6
Organization Along Time
7
Major Milestones Business Decision Points
time
8
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)

9
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 projects high-risk
    elements.

10
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

11
Construction Phase
  • The overriding goal of the construction phase
    is to develop all remaining components and
    features and integrate them into the product.

12
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

13
Transition Phase
  • The overriding goal of the transition phase is
    to move the product to the user community.

14
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

15
What Is an Iteration?
16
Phases and Iterations
Planned (Business) Decision Points
Commit resources for the elaboration phase
Commit resources for construction
Product sufficiently mature for customers to use
Acceptance or end of life
(Understand the problem)
(Understand the solution)
(Have a solution)
17
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

18
One Iteration
In an iteration, you walk through all disciplines.
19
Organization Based on Content
Content
20
Key RUP Elements Roles, Activities, Artifacts
21
Roles Perform Activities and Produce Artifacts
Example Requirements-gt Workflow Detail-gt Define
the System
22
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.

23
Roles Are Used for Resource Planning
Resource Paul Mary Joe Sylvia Stefan
Role Designer Requirements Specifier System
Analyst Implementer Architect
Activities Define Operations Detail a Use
Case Find Actors and Use Cases Perform Unit
Tests Identify Design Mechanisms
Each individual in the project is assigned to one
or several roles
24
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

25
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

26
Key RUP Elements Roles, Activities, Artifacts
Disciplines also contain Workflows and Workflow
Details, as you will see.
27
Nine Disciplines
28
Elements of a Discipline
  • If you expand any Discipline in the RUP tree
    browser, you will see the following

29
Key RUP Element Workflow
  • The conditional flow of high-level activities
    that produces a result of observable value.

30
Workflow Details
Example Environment Workflow
Example Workflow Detail Prepare Environment
for Project
31
Workflow Path Is Adapted to
  • Position in
  • Lifecycle
  • Phase
  • Artifacts being produced
  • Technology
  • Iteration goals

Example Analysis Design
32
Workflows Guide Iterative Development
Business Modeling Workflow Details
Requirements Workflow Details
33
Iteration Plan
Includes relevant portions of Discipline for a
particular iteration
34
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

35
Summary of Major Artifacts
36
Summary of Organization
37
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

38
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

39
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.

40
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

41
Process Element Templates
  • Attached to relevant document type
  • Predefined artifacts, prototypes
  • Documents (Microsoft Word, Adobe Framemaker)
  • MS Project
  • HTML
  • Tailored for the process

42
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.

43
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

44
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.

45
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

46
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?

47
Discipline Project Management
  • Project planning takes place at two levels
  • 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
  • Iteration Plan Level
  • Current iteration plan
  • Next iteration plan (built toward end of current
    iteration)

48
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.

49
Primary Requirements Artifacts
Use-Case Model
50
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

51
What a Business Model Shows
  • Two business models
  • Customers
  • Business processes
  • Organizational structure
  • Roles and responsibilities
  • Products
  • Internal deliverables
  • Events

52
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

53
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.

54
Use Cases Drive Analysis Design
Analysis Model (optional)
Design Model
Supplementary Specifications
55
Use-Case Realization
ltltrealizesgtgt
Sequence Diagrams
Use Case
Collaboration Diagrams
Class Diagrams
56
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.

57
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.

ImplementationModel
58
Implementation Model
  • An Implementation Model consists of
  • Components
  • Implementation Subsystems
  • Components include
  • Deliverable components, such as executables
  • Components from which the deliverables are
    produced, such as source code files

Components and implementation subsystems in a
Telephone Banking System.
59
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

60
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.)

61
Use Cases and End-User Documentation
Deployment
  • End-User Support Material
  • Users Guide
  • Online Help
  • Demos
  • Tutorials
  • Training Material

Supplementary Specification
62
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

63
The Configuration and Change Management (CCM) Cube
64
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

65
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.

66
RUP Overview
  • Seyyed Jamaleddin Pishvayi
  • seyyedjamal_at_asta.ir
Write a Comment
User Comments (0)
About PowerShow.com