RRC RUP

Software Engineering Process
Disciplined, Modern, and Mature
An Overview Workshop for the Railroad
Commission of Texas
January 21 & 22, 2003

““Freedom to Create”Freedom to Create”
The Value of SoftwareThe Value of Software
• The theme for the most recent Rational User
Conference was “Freedom to Create”
• Indeed, ‘Software is the fuel on which modern
businesses are run, governments rule, and
societies become better connected.’ Grady Booch
• Creativity, innovation, a blending and unifying of
art and science is what software development is all
about

• As software professionals, the exciting news is that
software is a critical success factor for many
organizations, whether private of public
• The challenge is that software is expanding in size,
complexity, distribution, and importance
• With so much at stake, software professionals
must seek out, understand, and master the
processes that we need to be success

• While CMM/CMMI describes the principles and
practices underlying software management
process maturity, Rational Software
Corporation’s Rational Unified Process provides a
state-of-the-art software engineering process and a
related process framework that is complimentary
to and supportive of the Key Process Areas
defined in CMM/CMMI

• By studying each of these bodies of knowledge, we
can take the best ideas, concepts, and processes
that each has to offer and grow in our ability to
produce quality software

Rational Unified ProcessRational Unified Process
Software Engineering Best PracticesSoftware Engineering Best Practices
• The RUP has a rich history with roots that trace
back to the Objectory Process that was first
released in Sweden in 1987
• Many of the leaders in the object-oriented
software engineering industry have contributed to
the evolution of this process including Ivar
Jacobson, Grady Booch, and James Rumbaugh,
all of whom now work for Rational Software
Corporation

• Grady Booch, Chief Scientist
• Dr. Ivan Jacobson, Vice President of Process
Strategy
• Dr. James Rumbaugh, Rational Fellow
• Dr. Philippe Kruchten, Director of Process
Development

• The RUP is described in detail in Phillipe
Kruchten’s book, The Rational Unified Process:
An Introduction 2nd Edition
• This process describes how to effectively employ
commercially proven software development best
practices within the context of a defined software
engineering process
• RUP is at once disciplined and configurable to the
needs of each unique software project

• With the goal of ensuring the production of
quality software systems in a repeatable and
predictable fashion, the software engineering best
practices championed by the RUP include:
 Develop Software Iteratively
 Manage Requirements
 Use Component Architectures
 Visually Model Software
 Continuously Verify Software Quality
 Control Changes to Software

Develop SoftwareDevelop Software
IterativelyIteratively
• Developing software iteratively is a technique that
is used to deliver the functionality of a system in a
successive series of incremental releases of
increasing complexity
• Each release is developed in a specific, fixed time
period called an ‘iteration’
• Each iteration is focused on defining, analyzing,
building and testing some set of requirements

• An iterative approach to software development
enables an increasing understanding of the
problem through successive refinements
• An effective solution is incrementally grown over
multiple iterations, each of which is an executable
release (internal or external)
• Developing software iteratively is in contrast to a
classical Waterfall approach

• This approach makes it easier to accommodate
tactical changes in requirements, features, and
schedule as well as address the highest risk items
at every stage in software development lifecycle
• As mentioned above, one of the primary benefits
of this approach is risk mitigation
• Using a classical Waterfall approach, discovery
and mitigation of risks are pushed forward in time
where they are the most costly to correct

• This best practice offers the following benefits:
 Misunderstandings are made evident early in
the software lifecycle where it is most cost
effective to respond
 This approach enables and encourages user
feedback so as to elicit the system’s real
requirements
 The development team is able to focus on those
issues that are the most critical (e.g., risks)

 Continuous, iterative testing enables an
objective assessment of the project’s status
 Inconsistencies among requirements, designs,
implementations are detected early
 The workload of the team is spread more
evenly throughout the project’s lifecycle
 The team can leverage lessons learned and
therefore continuously improve the process

 Project Stakeholders can be given concrete
evidence of the project’s status throughout its
life

Manage RequirementsManage Requirements
• The Object Management Group describes a
requirement as “a desired feature, property, or
behavior of a system”
• The challenge of requirements is that they are at
once dynamic and difficult to exhaustively state
• As a result, identifying a system’s true
requirements is a continuous process

• Requirements management is concerned with:
 Eliciting, organizing, and documenting the
system’s required functionality and
constraints
 Evaluating changes to these requirements and
assessing their impact
 Tracking and documenting trade-offs and
decisions

• Eliciting, organizing, and documenting
requirements through a use case driven approach
ensures that the final product meets the end users
needs and fulfills their expectations
• Furthermore, the use case and scenario driven
approach provides a common thread through the
design, implementation, and testing of the
software

 A disciplined approach is built into
requirements management
 Communications are based on defined
requirements
 Requirements can be prioritized, filtered, and
traced
 An objective assessment of functionality and
performance is possible

 Inconsistencies are detected more easily
 With suitable tool support, it is possible to
provide a repository for a system’s
requirements, attributes, and traces, with
automatic links to external documents

Component-BasedComponent-Based
ArchitecturesArchitectures
• Components are cohesive groups of code, in
source or executable form, with well-defined
interfaces and behaviors that provide strong
encapsulation of their contents, and are, therefore,
replaceable
• Architectures based around components tend to
reduce the effective size and complexity of the
solution, and so are more robust and resilient

• Employing an architecture-centric process, the
focus is on designing a resilient component-based
architecture that is flexible, accommodates
change, is intuitively understandable, and
promotes more effective software reuse
• It enable a systematic approach to defining an
architecture comprised of both new and existing
commercially available component infrastructures

 Components facilitate resilient architectures
 Modularity enables a clear separation of
concerns among elements of a system that are
subject to change
 Reuse is facilitated by leveraging standardized
frameworks and commercially available
components

 Components provide a natural basis for
configuration management
 Visual modeling tools provide automation for
component-based development

Visually Model SoftwareVisually Model Software
• A model is a simplified view of a system
• It shows the essentials of the system from a
particular perspective while hiding the non-
essential details
• Using the industry standard Unified Modeling
Language (UML), the RUP emphasizes the visual
modeling of software to capture the structure and
behaviors of the architecture and components

• Software models are useful because:
 They provide visual abstractions that promote
communication
 Enable a better understanding of how the
system fits together
 Ensure the software building blocks are
consistent with the code
 Help maintain consistency between design and
implementation

• Important models within the RUP include, but are
not limited to:
 Use Case Diagrams
 Sequence Diagrams
 Collaboration Diagrams
 Class Diagrams
 Deployment Diagrams

 Use cases and scenarios unambiguously specify
behavior
 Models unambiguously capture software
design
 Non-modular and inflexible architectures are
exposed
 Unambiguous designs reveal their
inconsistencies more readily

 Application quality starts with good design
 Visual modeling tools provide support for
UML modeling (e.g., Rational Rose)

Continuously VerifyContinuously Verify
Software QualitySoftware Quality
• To address the consequences that result from poor
performance and poor quality, quality assessment
is built into every phase and activity of the RUP
• From the perspective of RUP, software quality is
multi-dimensional and it is the responsibility of
every member of the project team
• Product quality is concentrated on building the
right product, whereas process quality is focused
on building the product correctly

• Using objective measurements and criteria that
are directly linked to the use case driven
approach, software quality is not an afterthought
• This focus on quality results in software systems
that are:
 Reliable
 Fulfill their functional requirements
 Meet all non-functional requirements at both
an application and system level

 Project status assessment is made objective,
and subjective, because test results, and not
paper documents, are evaluated
 This objective assessment exposes
inconsistencies in requirements, designs, and
implementations
 Defects are identified early, thus reducing the
cost of fixing them

 Testing and verification are focused on areas
of highest risk, thereby increasing the quality
and effectiveness of those areas

Control Changes toControl Changes to
SoftwareSoftware
• Managing change is a critical-success factor for
every software project particularly given that
change is inevitable
• Change can occur in all software artifacts
including requirements, documents, models, etc.
• Understanding that change is inevitable,
controlling, tracking, and monitoring change is
essential in order to enable successful software
development in a project team environment

Control Changes toControl Changes to
SoftwareSoftware
 The workflow of requirements change is
defined and repeatable
 Change requests facilitate clear
communication
 Change rate statistics provide good metrics for
objectively assessing project status
 Changes can be maintained in a robust,
customizable system

Exercise #2Exercise #2
• Organize into your same groups and identify a
group facilitator
• Discuss and Rank the Best Practices 1 Thru 6
 Develop Software Iteratively
 Manage Requirements
 Use Component Architectures
 Visually Model Software
 Continuously Verify Software Quality
 Control Changes to Software
• After each group has completed its ranking, the
rankings will be presented and discussed

Development ProcessDevelopment Process
A Development Process Should:
• Be based upon the cumulative experience of
software professionals, with specific guidance to
convey those experience
• Define the sequence of steps that lead to
deliverables and who is responsible for them
• Provide assistance regarding who and how to
produce the deliverables it defines
• Help to control the project and reduce confusion

A Development Process Should:
• Help project management to resource, plan, and
measure project
• Provide a structure which works to mitigate and
reduce risk
• Make software development predictable,
repeatable, and measurable
• Not be another process gathering dust

Communication, Communication, Communication
• Communication lies at the heart of any process
• Process helps project team members speak the
same development language
• Process helps project team members understand
their common goals (e.g., deliverables)

RUP Structure andRUP Structure and
ContentContent
According to Grady Booch, and consistent with the
previous, a software development process has four
roles:
 Provide guidance as to the order of a team’s
activities
 Specify which artifacts should be developed
and when they should be developed
 Direct the task of individual developers and
the team as a whole
 Offer criteria for monitoring and measuring
the project’s products and activities

ContentContent
• Without a well defined process, a development
team will, in all likelihood, develop software in an
ad hoc manner
• As pointed out by the CMM, success in these
circumstances is dependent upon the skill and
heroic efforts of a few dedicated individuals
• Under such circumstances, success can not be
repeated and no learning occurs between projects

ContentContent
• In contrast, mature organizations employ both
well defined software management process and
well defined software engineering processes
• Doing so enables the development of complex
software in a repeatable and predictable fashion
• A mature and well defined software engineering
process enables and encourages all of the best
practices described earlier
• This is the approach taken by the RUP

ContentContent
• RUP is a software engineering process that
provides a disciplined approach to assigning tasks
and responsibilities
• RUP is also a process product that is developed
and maintained by the Rational Software
Corporation
• As a process product, it is integrated with
Rational’s suite of software development tools
• RUP is also a process framework that can be
adapted and extended by an organization

A Process Product
• RUP is a software engineering process that
provides a disciplined approach to assigning
tasks and responsibilities
• RUP is also a process framework that can be
adapted and extended by an organization
• RUP is also a process product that is developed
and maintained by the Rational Software
Corporation

A Process Product
• This process product provides a Web-enabled,
searchable knowledge base that captures the
combined experience of software professionals
• It can be used as a online mentor covering the
full project lifecycle
• RUP is integrated with Rational Software
Corporation’s suite of software development
tools

A Process Product
• Its tool mentors provide guidance on how to
effectively use Rational tools in the context of the
Rational Unified Process
• As such, it provides education, consulting, and
mentoring when an organization adopts the
process

Role of UML in RUP
• In order to reap the full benefits of the UML,
organizations need to know how to use this
language effectively
• RUP was developed hand-in-hand with the UML
• Many of the artifacts within RUP have a UML
representation
• The process product provides mentoring and
guidance for UML concepts

RUP Structure
• RUP is structured along two dimensions:
 Organization along time
 Organization based on content
• The time structure refers to the lifecycle aspect
of the process
• That is, how the process rolls out within the
context of a software development project
• The content structure refers to the Disciplines,
which group activities logically by nature

Organization Along Time
• The time aspect of the process is described in
terms of phases, iterations, and milestones
• RUP phases include:
 Inception
 Elaboration
 Construction
 Transition
• The phase boundaries in RUP correspond to
significant decision points in the life of project

Organization Along Time
• Milestones help project stakeholders asses the
progress of a project at key points
• Milestones give project stakeholders the
opportunity to change the course of a project

Inception Phase
• The overriding goal of the inception phase is to
achieve concurrence among all stakeholders on
the objectives for the project
• The inception phase is of significance primarily
for new development efforts
• For projects focused on enhancements to an
existing system, the inception phase is more brief
• The milestone for this phase is concerned with
evaluating the basic viability of the project

Elaboration Phase
• The goal of the elaboration phase is to baseline
the architecture of the system in order to provide
a stable basis for the bulk of the design and
implementation effort in the construction phase
• The architecture evolves out of a consideration
of the most significant requirements and an
assessment of risk
• The stability of the architecture is evaluated
through one or more architectural prototypes

Elaboration Phase
• The milestone for this phase is concerned with
establishing a managed baseline for the
architecture of the system

Construction Phase
• The goal of the construction phase is on
clarifying the remaining requirements and
completing the development of the system based
upon the baselined architecture
• The management mindset undergoes a transition
from the development of intellectual property
during inception and elaboration, to the
development of deployable products during
construction and transition

Construction Phase
• The milestone for this phase is concerned
milestone determines whether the product is
ready to be deployed into a beta-test
environment

Transition Phase
• The focus of the Transition Phase is to ensure
that software is available for its end users
• The Transition Phase can span several iterations,
and includes testing the product in preparation
for release, and making minor adjustments
based on user feedback
• User feedback should focus mainly on fine
tuning the product – behavioral/structural issues
should have been refined much earlier

Transition Phase
• By the end of the Transition Phase lifecycle
objectives should have been met and the project
should be in a position to be closed out
• In some cases, the end of the current life cycle
may coincide with the start of another lifecycle
on the same product, leading to the next
generation or version of the product

What is an Iteration?
• According to RUP, an iteration is a pass through
all the disciplines resulting in a release (internal
or external)
• Each iteration can be seen as a mini-project with
a plan (i.e., and Iteration Plan), deliverables, and
assessment
• Each iteration can also be seen as a mini-
waterfall

Iteration: Number and Duration
• The duration of each iteration will be project
dependent and defined, in part, by the overall
project ‘timebox’
• The number of iterations is also project
dependent, but Rational recommends 6, plus or
minus 3
 Inception: 0 .. 1
 Elaboration: 1 .. 3
 Construction: 1 .. 3
 Transition: 1 .. 2

Organization Along Content
• The content of RUP is organized into Disciplines
• Each Discipline is a logical grouping of roles,
activities, and artifacts
 Roles: the who
 Activities: the how
 Artifacts: the what
• A Role performs certain Activities and is
responsible for certain Artifacts, or the work
products of the process

Organization Along Content
• The grouping activities into disciplines is mainly
an aid to understanding the project from a
‘traditional’ waterfall perspective
• For example, it is more common to perform
certain requirements activities in close
coordination with analysis and design activities

RUP’s Nine Disciplines
• Business Modeling
• Requirements
• Analysis and Design
• Implementation
• Test
• Deployment
• Configuration and Change Management
• Project Management
• Environment

Business Modeling - Purpose
• To understand the structure and the dynamics of
the organization in which a system is to be
deployed (the target organization)
• To understand current problems in the target
organization and identify improvement
potentials
• To ensure that customers, end users, and
developers have a common understanding of the
target organization

Business Modeling - Purpose
• To derive the system requirements needed to
support the target organization

Requirements - Purpose
• To establish and maintain agreement with the
customers and other stakeholders on what the
system should do
• To provide system developers with a better
understanding of the system requirements
• To define the boundaries of (delimit) the system
• To provide a basis for planning the technical
contents of iterations

Requirements - Purpose
• To provide a basis for estimating cost and time
to develop the system
• To define a user-interface for the system,
focusing on the needs and goals of the users

Analysis and 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 implementation
environment (e.g., J2EE), designing it for
performance

Implementation - Purpose
• To define the organization of the code, in terms
of implementation subsystems organized in
layers
• To implement classes and objects in terms of
components
• To test the developed components as units
• To integrate the results produced by individual
implementers, into an executable system

Test - Purpose
• The Test discipline acts in many respects as a
service provider to the other disciplines
• Testing focuses primarily on the evaluation or
assessment of product quality realized through a
number of core practices:
 Finding and documenting defects in software
quality
 Generally advising about perceived software
quality

Test - Purpose
 Proving the validity of the assumptions made
in design and requirement specifications
through concrete demonstration

Test - Purpose
 Validating the software product functions as
designed
 Validating that the requirements have been
implemented appropriately

Deployment - Purpose
• The Deployment Discipline describes the
activities associated with ensuring that the
software product is available for its end users
• The Deployment Discipline describes three
modes of product deployment:
 The custom install
 The "shrink wrap" product offering
 Access to software over the internet

Configuration and Change Management - Purpose
• To paraphrase the SEI’s CMM ‘Configuration
and Change Management controls change to,
and maintains the integrity of, a project’s
artifacts’
• This Discipline involves:
 Identifying configuration items
 Restricting changes to those items
 Auditing changes made to those items
 Defining and managing configurations of
those items

Project Management - Purpose
• To provide a framework for managing software-
intensive projects
• To provide practical guidelines for planning,
staffing, executing, and monitoring projects
• To provide a framework for managing risk
• Within RUP, however, not every aspect of the
Project Management Discipline is covered (e.g.,
managing people, budget, and contracts)

Environment - Purpose
• Focuses on the activities necessary to configure
the process for a project
• Describes the activities required to develop the
guidelines in support of a project
• Provides the software development organization
with the software development environment,
both processes and tools, that will support the
development team

Organization of Disciplines
• Within RUP, each Discipline consists of the
following:
 Introduction
 Concepts
 Workflow
 Activity Overview
 Artifact Overview
 Guidelines Overview

following:
 Introduction
Purpose of the discipline and its relationship
to other disciplines

following:
 Concepts
Key concepts that are important for
understanding the discipline

following:
 Workflow
A conditional flow of events when conducting
the discipline, expressed in terms of
workflow details
A workflow detail is a grouping of activities
that are done together

following:
 Activity Overview
The activities that are performed in this
discipline, and the roles that are responsible

following:
 Guidelines Overview
More detailed explanation on how to use and
produce the artifacts of the process
The rules and recommendations that support
activities and their steps

Additional Process Elements – Tool Mentors
• 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
 ClearQuest – change management and defect
tracking

Additional Process Elements – Templates
• Predefined artifact prototypes in the following
formats:
 Documents – MS Word, Adobe Framemaker
 MS Project
 HTML
• The templates have been tailored for the process

Additional Process Elements – White Papers
• RUP’s knowledge base is extended through the
provision of various White Papers
• For example, White Papers are provided for:
 A Comparison of RUP and XP
 Requirements Management with Use Cases
 Modeling Web Application Architectures
with UML
 Reaching CMM Levels 2 and 3
 The Estimation of Effort base on Use Cases

Additional Process Elements – Work Guidelines
• Provide practical information on techniques to
help you perform certain tasks throughout the
process
• Guidelines are provided for:
 Workshops
 Requirements Elicitation
 Testing
 Reviews

Process Product Demonstration

ResourcesResources
• Ivan Jacobson, Grady Booch, James Rumbaugh
(1999). The Unified Software Development Process.
Addison Wesley Longman, Inc.
• Philippe Kruchten (2000). The Rational Unified
Process: An Introduction 2nd
Edition . Addison
Wesley.
• Rational University (2002). Rational Unified
Process Fundamentals: Student Manual. Rational
Software Corporation.

ResourcesResources
• Rational Software Corporation – RUP White
Papers available on the Web at:
www.rational.com/products/rup/whitepapers.jsp

RRC RUP

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to RRC RUP

Similar to RRC RUP (20)

RRC RUP