Agile Methods with RUP and
PRINCE2
By M. Hanumanthu
Introduction
Here, the Agile techniques can fit with more traditional
software engineering methods.
We focus on the Unified Process (also known as
Rational Unified Process or RUP) and PRINCE2
The Unified Process is a design framework that guides
the tasks, people and products of the design process. It
provides the inputs and outputs of each activity, but
does not restrict how each activity must be performed.
Different activities can be used in different situations,
some being left out, others being replaced or
augmented.
Introduction
RUP was developed by Ivar Jacobson, Grady Booch
and James Rumbaugh at Rational.
They developed the UML and then went on to create
the Unified process as the process side of their
unification efforts
Prior to UML the Object Modelling techniques are
available (Booch in 1994, Rumbaugh et al., 1991,
Jacobson et al., 1992)
All of these methods provided inspiration for UML
and the unified process.
Introduction
PRINCE which stands for PRojects IN Controlled
Environments, is a project management method covering
the organization, management and control of projects.
First developed by the Central Computer and
Telecommunications Agency (CCTA), now a part of the
UK’s Office of Government Commerce (OGC) in 1989 as a
UK Government Standard for IT project management
The latest version of PRINCE2, is designed to incorporate
the requirements of existing users and to enhance the
method towards a generic, best practice approach for the
management of all types of projects.
What is a Project?
Projects are the means of introducing change in
organizations
Characteristics of projects:
◦ Temporary
◦ Cross-functional
◦ Unique
◦ Uncertainty
◦ Goal-Oriented
◦ Time-Limited
◦ Resource-Limited
◦ Deliverables
◦ Stakeholder Involvement
Structure of PRINCE2:
Processes: Processes trace progress from the start
to the end of the project
Themes: These are aspects of project management
that need to addressed continually.
Project Environment or Tailoring: Tailoring of the
PRINCE2 approach to the project environment.
PRINCE2 Principles
Guiding Obligations, or Pillars
Applying the principles is mandatory to using
PRINCE2 to manage a project.
Principles are (USE):
◦ Universal
◦ Self-validating
◦ Empowering
2. Agile Modelling and RUP
The Unified Process or the Rational Unified Process
(sometimes known as RUP) (Jacobson et al., 1999;Hunt,
2003) is a framework for handling the whole lifecycle
of a software development project.
It is referred to as a framework because it allows the
overall suite of activities to be customized and modified
as required for a particular type of application
2. Agile Modelling and RUP
Why then is the Unified Process called a process and not
the Unified Framework? It is called a process because
its primary aim is to define:
◦ Who is doing what?
◦ When they do it?
◦ How to reach a certain goal (i.e. each activity)?
◦ The inputs and outputs of each activity.
It is thus an engineered process.
In fact, it is comprised of a
number of different hierarchical
elements
2. Agile Modelling and RUP
In terms of the agile movement, it is towards the
heavyweight end of software methods and thus may
not initially appear compatible with processes such as
those that have come out of the agile movement.
The Unified Process is actually comprised of low-level
activities (such as finding classes), which are
combined together into disciplines formally known as
workflows (which describe how one activity feeds into
another). These disciplines are organized into
iterations.
2. Agile Modelling and RUP
Each iteration identifies some aspect of the system
to be considered. How this is done is considered in
more detail later.
Iterations themselves are organized into phases.
Phases focus on different aspects of the design
process, for example, requirements, analysis, design
and implementation.
In turn, phases can be grouped into cycles. Cycles
focus on the generation of successive releases of a
system (for example, version 1.0, version 1.1, etc.).
11.2.1 Overview of the Unified Process
There are four key elements to the philosophy behind
the Unified Process. These four elements are:
◦ Iterative and Incremental
◦ Use-case driven,
◦ Architecture-centric
◦ Acknowledges risk
Iterative and Incremental:
Any prototypes that are developed
11.2.1 Overview of the Unified Process
Iterative and Incremental:
Essentially, the following holds with the iterative
approach in the Unified Process:
◦ You plan a little
◦ You specify, design and implement a little
◦ You integrate, test and run
◦ You obtain feedback before the next iteration
The end result is that you incrementally produce the
system being designed.
Use-Case Driven:
use-cases help identify who uses the system and
what they need to do with the system use-cases help
identify the primary requirements of the system
To summarize the role of use-cases they:
◦ Identify the users of the system and their requirements.
◦ Aid in the creation and validation of the system’s
architecture.
◦ Help produce the definition of test cases and procedures.
◦ Direct the planning of iterations.
◦ Drive the creation of user documentation
◦ Direct the deployment of system
◦ Synchronize the content of different models.
◦ Drive traceability throughout models.
The role of Use-cases
11.2.2 Lifecycle Phases
The Unified Process is comprised of four distinct
phases. These four phases (presented in Figure
11.4) focus on different aspects of the design
process. The four phases are Inception, Elaboration,
Construction and Transition.
The four phases and their roles are outlined below.
11.2.2 Lifecycle Phases
Inception: This phase defines the scope of the project and
develops the business case for the system.
It also establishes the feasibility of the system to be built.
Various prototypes may be developed during this phase to
ensure the feasibility of the proposal.
Elaboration: This phase captures the functional
requirements of the system. It should also specify any non-
functional requirements to ensure that they are taken into
account.
The other primary task for this phase is the creation of the
architecture to be used throughout the remainder of the
Unified Process.
11.2.2 Lifecycle Phases
Construction. This phase concentrates on completing
the analysis of the system, performing the majority of
the design and the implementation of the system.
That is, it essentially builds the product.
Transition. The transition phase moves the system into
the users environment.
This involves activities such as deploying the system
and maintaining it.
Each phase has a set of major milestones that are
used to judge the progress of the overall Unified
Process
11.2.2 Lifecycle Phases
The primary milestones (or products) of the four
phases are illustrated in Figure 11.5.
11.2.2 Lifecycle Phases
The primary milestones for each phase are:
Inception. The output of this phase is the vision for the
system. This includes a very simplified use-case model
(to identify what the primary functionality of the
system is), a very tentative architecture and the most
important or significant risks are identified and the
elaboration phase is planned.
Elaboration. The primary output of this phase is the
architecture along with a detailed use-case model and
a set of plans for the construction phase.
11.2.2 Lifecycle Phases
Construction. The end result of this phase is the
implemented product that includes the software as
well as the design and associated models. The
product may not be without defects as some further
work has yet to be completed in the transition
phase.
Transition. The transition phase is the last phase of a
cycle. The major milestone met by this phase is the
final production quality release of the system.
11.2.3 Phases, Iterations and Disciplines
There can be confusion over the relationship
between phases and disciplines. Not least because a
single discipline can cross (or be involved in) more
than one phase (see Figure 11.6).
One way to view the relationships is that the
disciplines are the steps you actually follow.
However, at different times we can identify different
major milestones that should be met.
The various phases highlight the satisfaction of
these milestones.
11.2.3 Phases, Iterations and Disciplines
For example, during the Elaboration phase, part of the
requirements, analysis, design and even implementation
disciplines may act.
However, the emphasis at this time, within these
disciplines, will be on elaborating what the system
should do and how it should be structured, rather than
the more detailed analysis, design and implementation
which occur during the Construction phase.
The five disciplines in the Unified Process are
Requirements, Analysis, Design, Implementation and
Test
11.2.3 Phases, Iterations and Disciplines
The focus of each discipline is described below
(their primary products are illustrated in Figure
11.7).
11.2.3 Phases, Iterations and Disciplines
Requirements. This discipline focuses on the
activities that allow the functional and non-
functional requirements of the system to be
identified. The primary product of this discipline is
the use-case model.
Analysis. The aim of this discipline is to restructure
the requirements identified in the requirements
discipline in terms of the software to be built rather
than in the users less precise terms. It can be seen as
a first cut at a design; however, that is to miss the
point of what this discipline aims to achieve.
11.2.3 Phases, Iterations and Disciplines
Design. The design discipline produces the detailed
design that will be implemented in the next discipline
Implementation. This discipline represents the
coding of the design in an appropriate programming
language (for this book that is Java), the compilation,
packaging, deployment and documentation of the
software.
Test. The test discipline describes the activities to be
carried out to test the software to ensure that it
meets the users requirements, that it is reliable, etc.
11.2.4 Modelling and the Unified Process
Let us first review a few important points about the
Unified Process
First, it is a framework that encourages you to adapt
it to your own needs.
Secondly, the Unified Process actively encourages an
iterative and incremental approach to software
development (as illustrated in Figure 11.9). Indeed,
it is one of the key elements of Unified Process
Thirdly, there is nothing in the Unified Process that
assumes that all the modelling must be done upfront.
11.2.4 Modelling and the Unified Process
The following lists some of the adaptations you
should consider to the Unified Process to promote
the integration of Agile Modelling:
◦ You may need to lower the emphasis on “use-case
driven,” although the style is still model-centric and still
iterative, it is harder to determine all use-cases upfront
and agile model is less use-case focused.
◦ Use-cases should be used to help identify the core of the
architecture and potentially the elements of the first
iteration. The use-cases form the basis of your starting
point
11.2.4 Modelling and the Unified Process
◦ Subsequent iterations need to identify their own use-cases
(or requirements) that will help to focus and drive that
iteration
◦ The architecture is still the key to the infrastructure, but
now Agile Modelling works within the spaces left by the
architecture.
◦ Don’t go over the top with the architecture. In particular,
select appropriate models and views as necessary for
your projects requirements
◦ Don’t go over the top with design patterns! They can be
very useful but you need to know where and when to
apply them and they can make software more complicated
11.2.4 Modelling and the Unified Process
◦ The architecture is more interested in the contracts
between areas than with a fixed skeleton of code.
◦ The architecture itself can be modelled in an agile
manner. That is, the architecture is not fixed, it may well
change and evolve, but this change will be controlled and
will be effected in an agile manner
◦ The iterations and increments are more than likely to be
smaller rather than larger. That is, each increment may
represent a sub release of a software system (say
from1.4.1 to 1.4.2) rather than a full release of a software
system (from say 1.4 to 1.5)
11.2.5 Agile Modelling and Documentation
To conclude this section, agile models and their
associated documentation are “lean and mean” and
fulfill a specific purpose. They are intended to be
good enough for those who should be expected to
read them.