Unified process

The unified process is heavily use case driven. The model being use case
driven means:
Writing the user manual first, then the code. This makes sure that your
system follows the needs of the user, instead of the user following the
needs of the system.
UP is an iterative and incremental process. This means that you develop a
system through repeated cycles (iterative) and in smaller portions at a
time (incremental), taking advantage of what was learned during
development of earlier parts or versions of the system.

Phases of the Unified process

Inception phase
Here, you
- describes the initial requirements
- develop the business case for the system
- define the scope of the project
- identify the people, organizations and external systems that interact
with your system
- identify the risks of the project
- estimate time and cost of the project

As mentioned above, you identify the people, organizations and external

systems that interact with your system. In short, make use cases.

Example of artifacts in the inception phase

Vision:
The vision is a short text on what we are trying to accomplish. In short,
our end-goal for the system we are developing.
Use cases:
Below is an example of a use case.
Use case ID: UC02
Name/goal: Upload invoice
Description: The manager and accountant
need to be able to upload invoices to the
system, so they will be easier to find and keep
track of.
Priority: High
In the description, I am defining the actor; here it is the manager and/or
accountant. I am also defining what the actor(s) are interacting with, here
it is the system.
The example above is a normal use case. In most scenarios, you will also
want to make fully dressed use cases (Elaboration phase).
Elaboration phase
Here you
- produce an architectural baseline for your system
- re-visit your use cases (Does anything need to be added or changed?)
- UML diagrams usually used: Use case diagram, class diagram

Example of artifacts in the elaboration phase

Furps + (not required, but good to have)
Furps is a model that was developed by Hewlett-Packard and is used in the
software industry to rate software quality attributes. This is part of the
requirements and is divided by functional and non-functional
requirements.
The Furps Model is an acronym and stands for:

Functionality What does the customer want? Also in terms of security.

Usability How easy does the system operate? Does it look good? Is the
solution fully documented?
Reliability How reliable is the application? How does the system recover
in case of failure?
Performance How swift does the solution operate?
Supportability Can it be installed, tested, extended and configured?
Is the + added to the normal Furps model, more theoretical needs are
added that a customer might have.
Design constraints Do DBMS or I/O devices force the solution to be
implemented in a certain way?
Implementation requirements Are there standards that developers need
to be aware of?
Interface requirements Must the solution be able to interact with other
systems?
Physical requirements Is it necessary to install the solution in some
physical matter?

Use case model / use case diagram:

Below is an example of a use case model. It is basically a visual
representation of all the use cases.

Domain model

A domain model captures the most important types of objects in the

context of the business. The domain model represents the things that
exist or events that transpire in the business environment.
Below is a simple example of a domain model.

Entity relationship diagram

The ER model defines the conceptual view of a database. It works around
real-world entities and the associations among them. At view level, the ER
model is considered a good option for designing databases.

System sequence diagrams

System sequence diagrams are brief visualizations of the interaction

between an actor and a system. Below is an example of a system
sequence diagram.

Fully dressed use cases

Use case ID: UC02
Use case name: Upload Invoice
Main actor: Manager & accountant
Preconditions:
1. The manager has to be registered in the system
2. The accountant has to be registered in the system
Main scenario:
1. The main actor logs on to the system
2. The invoice is successfully uploaded
3. The main actor is show the uploaded invoice
Exceptions:
1. The invoice is already in the system
2. The invoice cannot be created
Post conditions: N/A

Construction phase
Here you
- build is system on the foundation laid in the elaboration phase
- make fully dressed use cases
- usually you base a one or more fully dressed use cases a iteration
- implement fully dressed use cases in short time boxed iterations
- UML diagrams usually used: Sequence diagram
Example of artifacts in the construction phase
Sequence diagram