Chapter 2: Unified process model

Table of Contents

Foundation of RUP Work flows

RUP key concepts Iterations

Artifacts  Phases

Roles

Activities

Disciplines
Rational Unified Process (RUP)
• One commercial implementation of the Unified Process
• Developed by Jacobson, Booch, Rumbaugh
• Evolved from the Objectory process and the earlier Ericsson approach
• Now an IBM product1
• Vocabulary and concepts
• Artefacts, roles, disciplines, activities
• Use case-driven, architecture-centered, iterative, incremental, risk
management-oriented Use Case-Driven Process
• RUP is a process
framework (not a
process on its own)
• Intended to be
customized to
project needs
[1] http://www-01.ibm.com/software/awdtools/rup/
RUP Vocabulary (1)
• Artefact
• Data element produced during the development (document, diagram,
report, source code, model…)
• Role
• Set of skills and responsibilities
• RUP defines 30 roles to be assigned (not all need to be fulfilled,
depends on the project)
• 4 role categories: analysts, developers, testers, and managers
• Activity
• Small, definable, reusable task that can be allocated to a single role
RUP Vocabulary (2)
• Discipline
• Set of activities resulting in a given set of artefacts
• RUP includes 9 disciplines: engineering (business modeling,
requirements, analysis and design, implementation, test, deployment)
and support (configuration and change management, project
management, environment)
• Guidance for a discipline is provided as workflows: sequence of
activities that produces a result of observable value
 Disciplines, Phases, and Iterations
Identify most of the Identify and detail
Detail the use cases Track and capture
use cases to define
(80% of the requirements) remaining use cases requirements changes
scope, detail critical
use cases (10%)
Inception Phase
• Overriding goal is obtaining buy-in from all interested parties
• Initial requirements capture
• Cost-benefit analysis
• Initial risk analysis
• Project scope definition
• Defining a candidate architecture
• Development of a disposable prototype
• Initial use case model (10%-20% complete)
• First pass at a domain model
Elaboration Phase
• Requirements Analysis and Capture
• Use Case Analysis
• Use Cases (80% written and reviewed by end of phase)
• Use Case Model (80% done)
• Scenarios
• Sequence and Collaboration Diagrams

• Class, Activity, Component, State Diagrams

• Glossary (so users and developers can speak common vocabulary)
• Domain Model
• To understand the problem: the system’s requirements as they exist within
the context of the problem domain
• Risk Assessment Plan revised
• Architecture Document
Construction Phase
• Focus is on implementation of the design
• Cumulative increase in functionality
• Greater depth of implementation (stubs fleshed out)
• Greater stability begins to appear
• Implement all details, not only those of central architectural value
• Analysis continues, but design and coding predominate
Transition Phase
• The transition phase consists of the transfer of the system to
the user community
• Includes manufacturing, shipping, installation, training, technical
support, and maintenance
• Development team begins to shrink
• Control is moved to maintenance team
• Alpha, Beta, and final releases
• Software updates
• Integration with existing systems (legacy, existing versions…)
Business Modeling Discipline
• Objectives
• Understand the structure and the dynamics of the organization in
which a system is to be deployed (the target organization)
• Understand current problems in the target organization and identify
improvement potential
• Ensure that customers, end users, and developers have a common
understanding of the target organization
• Derive the system requirements needed to support the target
organization
• Explains how to describe a vision of the organization in which
the system will be deployed and how to then use this vision
as a basis to outline the process, roles, and responsibilities
Business Modeling Discipline – Artefacts
Business Modeling Discipline – Roles
Requirements Discipline
• 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 the system
• Provide a basis for planning the technical contents of
iterations
• Provide a basis for estimating the cost and time to develop
the system
Requirements Discipline – Artefacts
Requirements Discipline – Roles
Requirements Discipline – Tasks
• Includes the following tasks
• List candidate requirements
• Candidate features that could become requirements
• Understand system context
• Based on business model, domain model or simple glossary
• Capture functional requirements
• Develop use cases and user interface support of use cases
• Capture non-functional requirements
• Tied to use cases or domain concepts
• Defined as supplementary requirements
• Validate requirements
Other Disciplines – Engineering (1)
• Analysis and Design Discipline
• Transform the requirements into a design of the system-to-be
• Evolve a robust architecture for the system
• Adapt the design to match the implementation environment
• Implementation Discipline
• Define the organization of the implementation
• Implement the design elements
• Unit test the implementation
• Integrate the results produced by individual implementers (or teams),
resulting in an executable system
Other Disciplines – Engineering (2)
• Test Discipline
• Find and document defects in software quality
• Provide general advice about perceived software quality
• Prove the validity of the assumptions made in design and requirement
specifications through concrete demonstration
• Validate that the software product functions as designed
• Validate that the software product functions as required (that is, the
requirements have been implemented appropriately)
• Deployment Discipline
• Ensure that the software product is available for its end users
Supporting Disciplines
• Configuration & Change Management Discipline
• Identify configuration items
• Restrict changes to those items
• Audit changes made to those items
• Define and manage configurations of those items
• Project Management Discipline
• Manage a software-intensive project; manage risk
• Plan, staff, execute, and monitor a project
• Environment Discipline
• Provide the software development organization with the software
development environment – both processes and tools – that will
support the development team
• This includes configuring the process for a particular project, as well
as developing guidelines in support of the project
RUP Best Practices
• RUP is a set of best practices
• Guidelines for creating good documents, models...
• Focus on having the right process (neither too heavy nor insufficient)
• Iterative development
• Each iteration considers the 9 disciplines to some degree
• Requirements management to establish an understanding of
customer / project
• With use cases, requirements management tools and processes
• Component based architecture
• Promotes reusability, unit testing
• Visual modeling (using UML)
• Continuous verification of quality (reviews, metrics,
indicators…)
• Change management (baselines, change requests…)
RUP and Agility?
• There is no contradiction between these two terms
• A definition of agile processes can lead to a cumbersome process…
• A definition of rich processes can lead to an agile process…

• Customizable software process engineering frameworks

• Rational Method Composer
• A tool for defining and monitoring your own development process
• http://www-01.ibm.com/software/awdtools/rmc/
• Eclipse Process Framework (EPF) – an Eclipse Project
• Predefined and extensible roles, tasks, and development styles
• Integration of tools - Metamodel-based
• http://www.eclipse.org/epf/