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