The Unified Process

Software Project Phases

• Requirements

• Analysis

• Design

• Implementation

• Test
 Unified Process (UP)
• an iterative process for building object-oriented
systems

• meant to be agile

• alternative models may suit circumstances better

• e.g. waterfall if requirements well specified and

immutable.

• e.g. open-source if project utilises a large pool of

transient developers
 UP: Iterative Development
• Inception

• Elaboration

• Construction

• Transition
UP: Iterative Development

Jacobsen et al (1999)
 UP: Iterative Development
• neither a rush to code nor drawn out steps which
attempt to perfect each detail (cf waterfall)

• generally each iteration tackles new requirements and

extends the system

• but we might revisit items and improve them

• uses feedback and adaptation

• choose subset of requirements; analyse, design & test

• lets developer and client discover what is of value and what

works
 Benefits of Iteration
• early rather than late mitigation of risks

• early visible progress

• early feedback

• managed complexity
Inception
 Inception
• Short initial steps to explore:

• vision & business case for the project

• feasibility

• buy or build?

• rough cost estimate

• do it or ditch it?
 Inception Artifacts
• Vision & Business Case
• high level goals & constraints, business case and a summary

• Use Case Model

• functional requirements, and related non-functional requirements

• Glossary (Data Dictionary)

• noteworthy items and their definitions

• Prototypes & Proofs of Concept

• to clarify and validate; e.g. user interface sketches

• Iteration Plan
• what will be done next iteration

• Other:
• supplementary specification, risk management plan, phase plan, development case
Vision Document
 Vision Document
• Do the right thing...

• are we solving the same problem?

• the right problem?

 Vision Document
• Introduction

• Problem Statement

• Stakeholders & Key Interests

• Users & User-Level Goals

• Summary of System Features

• Project Risks
 Introduction
• short and simple

• one or two lines to say what the project is about:

• “In this project we aim to build the Student Information

System, allowing students and staff to manage the
courses that students take,and to record and monitor
their progress.”
 Problem Statement
• what are we trying to solve?

• a short paragraph:
• “Currently students’ course choices and progress are recorded
inconsistently on a number of systems in differing ways (e.g.
myMun, departmental systems, lecturers’ systems). Our system
will provide a single integrated portal that will allow all key
stakeholders to be able to record , review and manage all
courses and progress in one place, in a consistent manner. This
will reduce ambiguity and unnecessary duplication of effort, and
will increase the visibility of information and ease of access to it
where appropriate.”
Stakeholders & Key Interests

Stakeholders Key Interests

Students managing their courses and seeing their marks

Lecturers recording course marks, managing workload

allocating lecturers & TAs to courses, recording
Admin Staff
student progress
Tutors seeing how well their students are doing

IT Staff maintenance of system, educating users

...
 Users & User Level Goals

User Goals
login, view available courses, register to a course,
deregister from course, view current courses,
Student
view previous courses, view marks for a course,
view current academic standing, ...
login, create a course offering, add assignment to
Lecturer course, record marks for an assignment, view
class list, ...
...

Users are usually Stakeholders, but not all Stakeholders need be Users...
Summary of System Features
• “The system shall do...”

• “The system shall do course registering.”

• “The system shall do marks recording.”

• if the “shall do” wording gets in the way, change it:

• “The system shall allow monitoring of student progress.”

 Project Risks
• what might be difficult to design and build due to the
time available and the team’s abilities and knowledge?

• “Fully and correctly handling course eligibility

requirements might prove difficult in the time available
due to the sheer number of possible course pre-
requisites, the sometimes complex nature of them and
the possible exceptions to them.”
 Glossary (Data Dictionary)
• a list of noteworthy items and their definitions:

Term Definition & Information Aliases

a course that a student must have taken
Pre-requisite and passed before they are able to
register for a given course
the score awarded for a course
Mark Score
assignment, recorded as a percentage
...
 Summary
• We’ve seen that the Unified Process is supposed to be
iterative and agile, working on small subsets of the problem
at a time, adding to and extending our documentation and
build.

• We’ve examined how to begin building the Vision

Document and the Glossary as part of project Inception.

• Coming Next: Use Case Modelling.

References & Further Reading
• Applying UML & Patterns (Larman)

• chapters 2, 4, 7

• Object-Oriented Systems Analysis and Design (Bennett et al)

• chapters 2, 3