Introduction to the USDP

Unified software development process

Overview of the USDP
Unified software development process
 Inception
• Inception: This phase focuses on establishing the business
case for the project and identifying its scope, objectives, and
constraints. The goal of this phase is to determine whether
the project is feasible and to develop a high-level plan for the
project.
 Elaboration
• This phase focuses on refining the project plan and
developing a more detailed understanding of the
requirements, architecture, and design of the system. The
goal of this phase is to reduce the technical risks associated
with the project and to develop a detailed plan for the
construction of the system.
 Construction:
• This phase focuses on building and testing the system. The
goal of this phase is to produce a working system that meets
the requirements of the stakeholders.
 Transition:
• This phase focuses on deploying the system into the
production environment.
• The goal of this phase is to ensure that the system is stable,
reliable, and meets the needs of the stakeholders.
 USDP process :
• The USDP process also emphasizes the importance of
communication, collaboration, and continuous improvement
• It encourages team members to work together closely and to
communicate frequently to ensure that everyone is on the
same page
• Additionally, it encourages teams to reflect on their
processes and to make continuous improvements based on
feedback from stakeholders and from their own experiences
 USDP Overall :
• Overall, the USDP process is a comprehensive and flexible
methodology for developing large, complex, and mission-
critical software systems
• It emphasizes the importance of understanding user needs,
managing technical risks, and delivering high-quality
software on time and within budget.
 UML is only a language
The UML is a language, not a design process
• It is used to describe the results of a modelling process
• It is not a modelling process

A software design process defines:

• who does what, when and how to build a software artefact or change an existing
software application
A software design process provides guidance to participants in the
process
 USDP
The Unified Software
• grew out of thirty years of development and
Development Process
experience
(Jacobson et al, 1999)

The USDP is a set of

activities that transforms • Uses the UML to describe the products of the
user requirements into process
software

• Use-case driven
The USDP is: • Architecture-centric
• Iterative and incremental
 Use-case driven
• Use cases are at the centre of the entire development process
– The requirements capture focuses on use cases
– The analysis process begins to add detail to the use cases
– The design process proposes a solution to satisfy the use
cases and analysis model
– The implementation builds the proposed solution
– The testing process verifies that the implementation satisfies
the use cases
 Architecture-centric
A software architecture answers the question, “What form
does the system take?”

Software architecture defines the significant aspects of the

application
• Static – structure (i.e. key classes, etc.)
• Dynamic – behaviour (i.e. key interactions, etc.)

The application is designed and implemented around the

architecture
 Iterative and incremental
The USDP is iterative

• Each iteration addresses a sub-set of the use case model

The USDP is incremental

• Each iteration adds value, building on the previous cycles

• Each iteration produces a working system (albeit partial)
• Each iteration produces an increment

Each iteration is a mini-project

• It follows a complete workflow – requirements, analysis, design, implementation and

testing
• i.e. it is not hacking!
 Workflows of the USDP
Requirements
• Define what the system should do

Analysis
• Refine and structure requirements

Design
• Derive models of the solution

Implementation
• Write the application software; derived from the design

Testing
• Verify that the implementation meets requirements
 Phases &
workflows
Jacobson et al (1999), p.11
Requiremen
ts workflow
Jacobson et al (1999), p.118
 Requirements capture…
• …is difficult because:
– Customers don’t always know exactly what they want
– Customers don’t always understand the problem to be solved
– The problem domain is always changing
– Big systems are very complex
– Analysts cannot always be 100% perfectly accurate, precise, consistent
– Each software project is unique (i.e. no exact precedent)
– Customers and developers do not always speak the same technical
language
Other considerations on requirement, capture

• …is essential because:

– Developers and customers must agree on the desired
outcome of the project
– The context of the problem must be properly understood
– Developers must know what the system should do
– Developers must know what the system should not do
– the whole project depends on this workflow
 Capture functional reqs.

By describing all use

In the USDP, functional A use case describes cases for all users, the
requirements are one way of using the system’s functional
captured as use cases system requirements are
captured

This is a natural
Usually, each user
way for the user to
will have multiple
think about system
use cases
requirements
 Requirements workflow

01 02 03 04
Find actors Describe use Prototype the Structure the
and use cases cases in detail user interface use case
• Using activity • Sketches, and model
diagrams prototype
software
Analysis workflow

• Jacobson et al (1999),
p.179
 Purpose of analysis
• According to Jacobson et al (1999:173, 177-8), two of the
purposes of the analysis workflow are:

– Achieve a more precise specification of the requirements

– Give structure to the whole system

 Analysis classes

The interface of an The attributes of an

Conceptually closer to
Focus on functional analysis class is analysis class are high-
the domain than the
requirements described in terms of level, conceptual, linked
design
responsibilities to the problem domain

Non-functional
requirements Structure and type
Methods are left
become special of attributes are left
until the design
requirements of the until design
class
 Analysis classes
• Relationships are shown in the analysis model
– More conceptual than in class diagrams for the design
e.g. navigability is not a worry for analysis, but essential for design

• Three stereotypes for analysis classes in UML:

– Boundary

– Entity

– Control
Analysis classes: Boundary
e.g. windows, forms, sensors, etc.
Model interaction between the
No need to be very detailed about
system and its actors structure (i.e. buttons, panels, etc.)

Every boundary class is associated with at least one actor

Every actor is associated with at least one boundary class

 Analysis classes: Entity

1 2 3
Model information Model individuals, Not just data;
that persists over objects or events in include behaviour
time within the the real world that as well
system are of interest • Remember: behaviour
within the system is represented as
responsibilities
 Analysis classes: Control
• Model control within the system
– Coordination of operations
– Sequencing of events
– Control of other objects
– Complex business logic than involves several other
objects
– Delegation of tasks to other objects
Example analysis model

• Jacobson et al (1999),
p.187
Example analysis model
Jacobson et al (1999), p.188
 Workflow for each iteration
Analyse a use case Analysis a class

• Identify analysis • Responsibilities,

classes attributes,
• Describe analysis relationships, special
objects interactions reqs.
• Capture special
requirements
 Design
workflow
Jacobson et al (1999), p.217
 Purpose of design
• According to Jacobson et al (1999:215-216) the purposes of the design
workflow are:
– Acquire an in-depth understanding of all requirements
– Create an appropriate point of departure for implementation
• Subsystems, interfaces and classes
– Capture major interfaces between subsystems – an architectural
requirement
– Create an abstraction of the implementation
• Implementation is a straightforward refinement of the design
 Design classes
Specify the classes in
the implementation Specify the
• Attributes & types; relationships between
Methods & parameters; classes
etc.

Must stay in step with

the implementation
Specify interfaces in classes
the implementation • Change the code –
change the design
 Design classes for use-cases

The design • Design the classes that are involved in a

use-case realisation
process is use- • A design class may be involved in more
case driven than one use-case realisation

Interaction
diagrams • Sequence diagrams
describe use-
case behaviour
Implement
ation
workflow
Jacobson et al (1999), p.268
 Purpose of implementation
• According to Jacobson et al (1999:267) the purposes of the
implementation workflow are:
– Encode the design by increments
– Unit test the implementation to ensure compliance with
use-case requirements
 Implementation workflow
Implement a subsystem
• Write code for the classes in the subsystem
• Follow the class design precisely
(or update the design to keep it in step with the code)
• Unit test the classes using black-box tests

Repeat for another subsystem

• Until system is complete
UML in the workflows
Structure Diagrams Behaviour Diagrams

Package Use Case

Requirements &
Diagram Diagram
Analysis
State
Activity Machine
Class
Diagram Diagram
Diagram
Component
Diagram
Interaction Diagrams
Object
Diagram Sequence Communication
Deployment
Diagram Diagram Diagram

Composite Interaction Timing

Overview Diagram
Structure Diagram
Diagram
UML in the workflows
Structure Diagrams Behaviour Diagrams

Package Use
Diagram Design & Case
Design
Implementation Diagram State
Class Activity Machine
Diagram Diagram Diagram
Component
Diagram
Object Interaction Diagrams
Diagram Deploymen Sequence Communicati
t Diagram Diagram on Diagram

Composite Interaction Timing

Structure Overview Diagram
Diagram Diagram
References
• Jacobson, I.; Booch, G.; Rumbaugh,
J. (1999) The Unified Software
Development Process. Addison-
Wesley