Introduction to the Unified Process

What is software engineering

Using engineering approaches to

Developing software
Maintaining software
Acquiring software
Retiring software

Why software engineering

Better products and/or better management

for large, complex, and/or mission-critical software

Knowledge areas of software engineering

Software requirement analysis
Software design
Software construction (coding)
Software testing
Software maintenance
Software configuration management
Software quality analysis

(quality assurance, verification and validation, reliability)

Software Engineering Process
Software engineering management
Software engineering infrastructure

(development methods and environments)

Quality factors of software

Correctness

The ability of software systems to perform their exact tasks, as defined by their specification

Robustness

The ability of software systems to react appropriately to abnormal conditions.

Extendibility

The ease of adapting software systems to changes of specification.

Reusability

The ability of software elements to serve for the construction of many different applications.

Compatibility

The ease of combining software elements with others.

Efficiency

The ability of a software system to place as few demands as possible on hardware resources. (e.g. cpu time, memory space, disk space, network bandwidth)

Portability

The ease of transferring software systems various hardware and software environments.

Ease of use

The ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems.

Functionality

The extent of possibilities provided by a software system.

Timeliness

The ability of a software system to be released when and before its users want it.

What is a software development process

It is the set of activities needed to transfer a user’s requirements into a software system.

It defines who is doing what when and how to build a new software system or enhance an existing software system.

It provides guidance to the order of a team’s activities
It directs the task of individual developers and the team as a whole.
It specifies what artifacts should be developed.
It offers criteria for monitoring and measuring a project’s products and activities.

It serves as a guide for all the participants:

customers, users, developers, and managers.

Reality bases of a software development process

Technologies

e.g. programming languages, operating systems, computer systems, network capabilities, development environments.

Tools

To support the process.

People

The expected skill set of target developers.

Organization patterns

The process must fit in the company’s overall organization patterns.

What is the unified process

It is a generic software development process framework for building object-oriented software systems, with different classes of systems application areas, types of organizations, competence levels, and project sizes.

It is component-based.

It uses UML as the modeling language.

Key features of the unified process

Use-case driven

Users:

Human users or other computer systems that interact with the system to input data or receive outputs.

Use-case:

A piece of functionality in the system that gives a user a result of value.

It describes per-user based system functionality.

Use-case model:

It consists of all use-cases together.

It captures the overall system functional requirements.

It describes the system’s complete functionality.

Use-case driven

The development process proceeds through a series of workflow or models that are derived from the use cases and realize the use cases in different development stages.

Models as workflow derived from use cases

Use-Case Model

All use cases and their relationships to users

Analysis Model: specifies use cases

Use case refinement

Conceptual model with initial system behaviors

Design Model: realizes use cases

Static structure of the system

Collaboration of system elements (classes, interfaces, subsystems)

Implementation Model: implements use cases

Source code components

Mappings from classes to components

Deployment Model: distributes use cases

Mappings from components to distributed computers

Test Model: verify use cases

Test cases

Architecture-centric

Software architecture describes the most significant static and dynamic aspects or views of the system.

Architectural views:

Design view (classes and relationships)

Implementation view (Source/compilation/executable components)

Process view (Multi process/threads computation)

Deployment view (Distributed computation)

System architecture depends on

Use cases (what the system will do)

Application domain (consistent with domain architecture style)

Target platforms (computer architecture, OS, database, network)

Reusable building blocks (components, application framework)

Target deployment strategies (distributed systems)

Legacy systems (mainframes)

Nonfunctional requirements (performance, reliability)

System architecture vs. use cases

Use cases: the function of the system

Architecture: the form of the system

The system function must be realized by a software system in certain form.

The architecture must be designed to allow the system evolve, when use cases evolve.

How to identify or create a software architecture

Step 1: create use-case independent architectural foundation

Step 2: Specify and realize key use cases

Step 3: Discover architecture features

Step 4: Repeat steps 1-3 to build more foundations and realize

more use cases.

Iterative and incremental

Iterations

A development project is planned into several iterations or mini-projects.

Each iteration goes through all development stages (analysis, design, implementation, testing) and ends with an internal release of the product.

Increments

Each iteration implements more use cases or system functions.

How to select an iteration

Select a group or subset of use cases that extend the functionality from system produced from the last iteration.
The selected group must have the highest risk in terms of realization among all currently unrealized use cases.

What to do in an iteration

Analysis: identify and specify the relevant use cases
Design: specify software system using architecture guideline
Implementation: code the design in components
Test: verify if the components satisfy the use cases

Why controlled iterations

Reduce the cost risk to the expenditures

(only one repeated iteration for mistakes)

Reduce the risk to not meeting the product release deadline.

(deal with highest risks first)

Speed up the tempo of the whole development effort (short focus)

Acknowledge changing requirements

(realize new requirements in future iterations)

The life of the unified process

The entire life of the development process for a product consists of a sequence of cycles from birth to death
Each cycle ends with a product (public) release for a product version.
Each cycle is constituted of four phases in sequence:

Inception (vision of the end products and its business case)

Simplified use-case model for most critical use cases

Architecture outline

Risk identification and prioritization

Planning for the next phase with cost estimation

Elaboration

Specifying all or most use cases

Architecture design with different views for the whole system

Realizing critical use cases

Forming an architecture baseline

Construction

Building or implementing components

Transition

Preparing beta release to selected users (manufacturing)

Maintaining the beta release and responding feed backs.

User training and assistance

Each phase terminates in a milestone consisting of a certain set of artifacts.

Contents of a product release from a cycle that can be carried on to the next cycle

All models (use-case, analysis, design, implementation, deployment, and test)
A representation of the architecture