SOFTWARE

SOFTWARE ENGINEERING
ENGINEERING

SOFTWARE
SOFTWARE DEVELOPMENT
DEVELOPMENT
PROCESS
PROCESS

SOFTWARE DEVELOPMENT1
DEVELOPMENT
LEARNING OBJECTIVES

1. Understand the types of software systems and how

software systems are developed in practice.

2. Understand and compare different software development

processes.

3. Understand the importance of using an iterative and

incremental software development process.

4. Understand the importance of identifying and mitigating

risks in software development.

5. Understand the components of the Unified Software

Development Process.

SOFTWARE DEVELOPMENT2
DEVELOPMENT
 12

SOFTWARE DEVELOPMENT PROCESS OUTLINE

● Overview and Survey
– software development types
– process in software development
– survey of software development processes

● Unified Software Development Process (UP)

– life cycle
– use-case and risk driven
– architecture-centric
– iterative and incremental

SOFTWARE DEVELOPMENT3
DEVELOPMENT
SOFTWARE DEVELOPMENT TYPES: SYSTEMS
AAsoftware
softwaresystem
systemisisaapurposeful
purposefulcollection
collectionof
ofinterrelated
interrelated
components
componentsthat
thatthat
thatwork
worktogether
togetherto
toachieve
achievesome
someobjective.
objective.

1. technical systems – include hardware and software, but no

procedures and processes.

2. socio-technical systems – include one or more technical

systems plus knowledge of how the system should be used to
achieve some broader (organizational) objective.

SOFTWARE DEVELOPMENT4
DEVELOPMENT
SOFTWARE DEVELOPMENT TYPES:
SOCIO-TECHNICAL SYSTEMS
Essential characteristics of socio-technical systems:
They have emergent properties (properties that appear only when the system functions as a whole).
● They are often non-deterministic (same input =/=> same output).
Their success depends not only on the system itself, but also on the organizational environment in which it operates.

–
Implications for software development:
–
–

As
Assoftware
softwareengineers,
engineers,weweneed
needtotobe
beconcerned
concernednot not
simply
simplywith
withthe
thesoftware
softwareitself,
itself,but
butwe
wealso
alsoneed
needtotohave
have
aabroader awareness of how the software interacts
broader awareness of how the software interacts with with
other
otherhardware
hardwareand
andsoftware
softwaresystems
systemsandandhow
howititisis
supposed
supposedtotobebeused
used

SOFTWARE DEVELOPMENT5
DEVELOPMENT
SOFTWARE DEVELOPMENT TYPES:PROJECTS
• Green field projects → new development Our primary focus
• Evolutionary projects → maintenance
– corrective – fix defects Most common type
– adaptive – adapt to new technology, new laws, etc.
– enhancements – add new features
– perfective – make more maintainable

3. Framework/component projects → reuse

– We start with an existing framework or plug together several
existing components.
• A framework is a software system designed specifically to be reused indifferent proje
cts or a product line, but needing to be adapted to handle specific requirements.

SOFTWARE DEVELOPMENT6
DEVELOPMENT
SOFTWARE DEVELOPMENT PROCESS:
A MANAGEMENT VIEW

•The life-cycle concept gives structure to the software

development process.
•The phases provide a basis for management and control
e.g., milestones, deliverables, etc.

SOFTWARE DEVELOPMENT7
DEVELOPMENT
SOFTWARE DEVELOPMENT PROCESS:
A MANAGEMENT VIEW

Software systems are created by a dynamic process that moves through a series of
phases called the software development life-cycle.
1. Definition phase - The problem is identified, alternate system solutions are
studied and recommendations are made about committing the resources
required to design the system.
2. Design phase - The detailed design of the system selected in the definition
phase is carried out including the allocation of resources to equipment tasks,
personnel tasks and programming tasks. The technical specifications are
prepared for the performance of all allocated tasks.
3. Development phase - The system is constructed from the specifications
prepared in the design phase; the complete system is tested; the equipment is
acquired; the manuals are completed; staff is trained.
4. Operation phase - The new system is installed or there is a changeover from
the old system to the new system; the system is in use.
milestone: A management decision point that determines whether to proceed to
the next phase, cancel the project or redo parts of the previous phase.

SOFTWARE DEVELOPMENT8
DEVELOPMENT
 12.1
SOFTWARE DEVELOPMENT PROCESS:
AN ENGINEERING VIEW

set of activities
Process
(workflows)
template

user
Application requirements result
Project Product
Domain

set of artifacts
models
participate code
customers manuals
.
users ..
People
software. engineers
..
SOFTWARE DEVELOPMENT9
DEVELOPMENT
SOFTWARE DEVELOPMENT PROCESS:
AN ENGINEERING VIEW

Project – An instance of a process, carried out by people, that

results in the release of a product.

People – Clients, users, and developers (i.e., software engineers)

are involved in a project.
– Software engineers play various roles (also called workers) who are
responsible for a set of activities (e.g., analyst, designer,
programmer, etc.).
Product – All the artifacts produced by a project.
– An artifact is any kind of information created, produced, changed or
used in developing the system.
• management artifact: budget, schedules, etc.
• engineering artifact: models, code, manuals, etc.

SOFTWARE DEVELOPMENT10
DEVELOPMENT
SOFTWARE DEVELOPMENT PROCESS:
AN ENGINEERING VIEW

● Process – The complete set of activities (also called workflows)

and their sequencing that are needed to transform users’
requirements into a software product.
– A process prescribes all of the major activities.
– A process has a set of guiding principles that explain the goals of
each activity.
– A process uses resources, subject to a set of constraints (such as a
schedule) and produces intermediate and final products.
– A process may be composed of subprocesses that are linked in
some way (e.g., a hierarchy of processes)
– Each activity has an entry and an exit criteria, so that we know
when the activity begins and ends.
– The activities are organized in a sequence, so that it is clear when
one activity is performed relative to the other activities.
– Constraints or controls may apply to an activity, resource or product
(e.g., the budget may constrain the length of time in an activity or a
tool may limit the way in which a resource may be used).

SOFTWARE DEVELOPMENT11
DEVELOPMENT
 SOFTWARE DEVELOPMENT PROCESS
A MANAGEMENT VIEW AN ENGINEERING VIEW
● Definition phase ● Activities(methods)
→ focus is on WHAT – provide technical “how to's”
– project planning for building software
– requirements gathering
– feasibility ● Workflow(methodology)
– sequence in which methods
● Design phase will be applied
→ focus is on HOW – deliverables required
– software architecture – controls needed to ensure
– hardware architecture quality and coordinate
● Development phase change
→ focus is on BUILDING – milestones to assess
– coding – Tersting
– enhancements progress
● OPERATION phase ● Tools (support)
→ focus is on BUILDING – provide support for the
software development
– deployment -training
process
SOFTWARE DEVELOPMENT12
DEVELOPMENT
WHY IS PROCESS IMPORTANT IN SOFTWARE
DEVELOPMENT?
● Allows division of labour
➨ easier for each team member to know what to do

● Promotes teamwork/individual work/communication

➨ understand what others are doing (over time, among projects, etc.)

● Eases project management

➨ supervisors/managers can understand what is happening

● Allows expertise reuse/reassignment

➨ transfer among projects more easily (developers, managers, etc.)

● Eases training
➨ can be standardized (e.g., courses)

● Promotes productivity/better development

➨ development becomes repeatable (e.g., schedule/cost estimates)

SOFTWARE DEVELOPMENT13
DEVELOPMENT
SURVEY OF SOFTWARE DEVELOPMENT PROCESSES

Points to keep in mind:

– A software process is an abstract representation of the phases and
activities and thus we see the framework of the process, but not the
details of specific phases or activities.
– Each software process represents the phases and activities from a
particular perspective, and thus provides only partial information
about that process.
– The different software processes are not mutually exclusive and are
often used together in practice, especially for large systems
development.
– Our purpose here is to see the strengths (pros) and weaknesses
(cons) of different software development processes.

Goal: To understand what works best in practice and why.

SOFTWARE DEVELOPMENT14
DEVELOPMENT
CODE-AND-FIX SOFTWARE DEVELOPMENT
PROCESS
● process: write code, fix errors,
enhance functionality
● Many changes
→ code structure
becomes messy, hard to fix
● Unsuitable for large sysem
– turnover of personnel
Usually does not
– difficult to understand/fix code exist (except in the
– user requirements can easily be unmatched mind of the
developer)!
● The software development becomes:
– unpredictable
– uncontrollable
– over schedule, over budget, low quality

A more structured software development process needed

SOFTWARE DEVELOPMENT15
DEVELOPMENT
 12.4.1

WATERFALL SOFTWARE DEVELOPMENT PROCESS

Applicable only when
produces a requirements requirements are well under-
Analysis specification document stood and unlikely to change.
produces a design specification document
Design

produces an implemented
Coding collection of modules

produces a tested
Testing assembly of modules

Maintenance

keeps the system

working and
● plus: reviews (correctness, standards), deliverables up-to-date
(documentation, code), training material, . . .

SOFTWARE DEVELOPMENT16
DEVELOPMENT
WATERFALL PROCESS — PROS AND CONS
● pros
– imposes needed discipline (rigor and formality) on the development
process
– keeps the development process predictable and easy to monitor
– enforces standards requiring production of certain documents at
certain target dates

● cons
– assumes a linear development –> sequential flow of activities
– assumes results of each phase are frozen before proceeding to the
next phase –> revision of requirements is difficult
– provides no guidance as to what to do in each phase
– all planning is oriented toward a single product delivery date
–> product usually is not available for feedback until the end
of the development

SOFTWARE DEVELOPMENT17
DEVELOPMENT
 12.4.4; 12.4.5

PROTOTYPING SOFTWARE DEVELOPMENT PROCESS

Start
● Basically a code-and-
Stop Gather
fix process BUT ...
– enforces discipline
Requirements – produces all
& Refine required artifacts
Engineer Quick ● It is useful when
Product Design requirements are
vague or unknown
– explore user interface
Refine Build – explore functionality
needed
Prototype Prototype ● Incremental
Customer development and
Evaluation of delivery
Prototype What to do with the
final prototype?

SOFTWARE DEVELOPMENT18
DEVELOPMENT
PROTOTYPING PROCESS — PROS AND CONS
● pros
– Allows requirements to be quickly explored to get a clearer
understanding of the system functionality.
– Allows user feedback and approval to be obtained
– Allows different solutions to be explored with a higher chance of
finding the “right” solution.

● cons
– Not really a complete development methodology –> often useful in
conjunction with another methodology
– The final “product” is not a complete system, but may be treated as
such by management
– The process is not visible → hard to measure progress;
documentation is often sparse or completely absent

SOFTWARE DEVELOPMENT19
DEVELOPMENT
FOURTH GENERATION (4G) SOFTWARE
DEVELOPMENT PROCESS
● 4G tools:
– database query language
– report generator
– screen painter
Requirements – charting/graphing tools
gathering – spreadsheet
– application generator
“Design”
strategy

Implementation
using 4G tools

Testing

SOFTWARE DEVELOPMENT20
DEVELOPMENT
PHASED SOFTWARE DEVELOPMENT PROCESS
Developers

Build release 1 Build release 2 Build release 3

Time
Users

Use release 1 Use release 2 Use release 3

SOFTWARE DEVELOPMENT21
DEVELOPMENT
 PHASED PROCESS — INCREMENTS &
ITERATIONS
incremental development –> partial system; full functionality

iterative development –> full system; partial functionality

SOFTWARE DEVELOPMENT22
DEVELOPMENT
PHASED PROCESS: PROS AND CONS

Pros
– Promotes system modularity � well-structured, robust, maintainable
→ Especially if an OO development process is used.
– Reduces the risk of project failure
→ Risk is confined to small parts of the system.
– Allows early training and feedback
→ Users can be trained and provide real-use feedback to developers on
early releases of the system.
– Can create new markets
→ Particularly for functionality never before offered.
– Allows frequent releases
→ Developers can fix bugs globally and frequently.
– Allows appropriate expertise to be applied
→ The development team can focus on different areas of expertise with
each release.

SOFTWARE DEVELOPMENT23
DEVELOPMENT
PHASED PROCESS: PROS AND CONS

Cons
– The system pieces need to be relatively small
→ It may be hard to map client requirements onto pieces of
the “right” size.
– It may be hard to identify common facilities needed by all
pieces.
→ The requirements are not defined in detail until a piece is
to be
implemented.

SOFTWARE DEVELOPMENT24
DEVELOPMENT
AGILE SOFTWARE DEVELOPMENT PROCESS
● Any phased (incremental) approach where the major goal is
responsiveness to change.
Example : Extreme Programming (XP)
● Requirements and analysis
– determine features needed; estimate time and cost for each
feature; client prioritizes features to be included in each iteration
● Implementation (for each iteration, also called a build)
– break into tasks
– for each task (where tasks can be carried out in parallel):
Major
• design test cases (test-driven development)
emphasis
• implement using pair programming is here.
• integrate into current product

Extreme Programming has only been proven successful for small scale
software projects when the client� s requirements are vague.
SOFTWARE DEVELOPMENT25
DEVELOPMENT
PHASED PROCESS — PROS

● early training and feedback

➨ allows user training and provides real-use feedback on early
releases of the system

● can create new markets

➨ for functionality never before offered

● frequent releases
➨ allows bugs to be fixed globally and frequently

● apply appropriate expertise

➨ development team can focus on different areas of expertise with
each release

SOFTWARE DEVELOPMENT26
DEVELOPMENT
 12.4.3

SPIRAL SOFTWARE DEVELOPMENT PROCESS

Planning Risk analysis

Go, no-go
decision

Toward a
completed
system

Customer evaluation Engineering

SOFTWARE DEVELOPMENT27
DEVELOPMENT
SPIRAL PROCESS — RISKS

RISK
RISK
anything
anythingthat
thatendangers
endangersor
oreliminates
eliminatessuccess
successfor
foraaproject
project

Technical risks Non-technical risks

– building the – right expertise
right system – training
– system – schedule
architecture – approvals
– new
technologies Dealing with risks
– performance
– avoid(re-plan or change requirement)
– confine(restric its scope)
– mitigate(control it)
– monitor(be on the lookout for it)

GOAL:
GOAL deal with biggest risks as early as possible
SOFTWARE DEVELOPMENT28
DEVELOPMENT
QUESTION?

The greatest risk that you have to deal with in your course project
is:

1) not knowing how to work together as a team.

2) not knowing how to use Visual Basic.
3) not knowing how to use Microsoft Access.
4) falling asleep during the lecture.
5) not knowing the exact requirements for the
system.
6) not having enough time to finish the project.

SOFTWARE DEVELOPMENT29
DEVELOPMENT
SPIRAL PROCESS — PROS AND CONS
● pros
– Accommodates good features of previous processes (waterfall +
prototyping), while risk-approach reduces their problems
– Focuses early attention on options involving reuse
– Helps prepare for evolution of the system (e.g., enhancements,
maintenance)
– Relates desired objectives (ease of use, reliability, etc.) to product
development
– Focuses on early elimination of errors and weak solutions
– Helps to answer “How much is enough?” question in resource
allocation

● cons
– Relies on expertise in risk assessment
– Needs more elaboration of the different steps in a cycle
– More appropriate for internal rather than contract development.

SOFTWARE DEVELOPMENT30
DEVELOPMENT
CASE STUDY: A BUDGET CONTROL SYSTEM
Problem: Build a budget control system for a small(~30 persons), high-
tech software consulting and development company that
monitors whether the financial transactions involved in their various
software projects are proceeding according to the original budgets.

➨ Want to take corrective action early if not on track

Scenario: The budget control activity often needs to be customized to

the particular activities of an organization. While the budget
control activity is related to other administrative activities, (e.g.,
payroll processing, income and expense monitoring, etc.),
unlike these, budget control is based both on objective data,
such as time and costs, and on subjective data, such as
estimates of the value of the "work in progress". Since staff
may be involved in several projects simultaneously, and there
is no log about their contribution to each project, it is hard to
assign costs to each project.
SOFTWARE DEVELOPMENT31
DEVELOPMENT
CASE STUDY: A BUDGET CONTROL SYSTEM

Initial findings

● The current administrative system is not suitable for providing all

of the data required for budget control since the required data is
either missing or in the wrong format.

● Real problem is not budget control per se, but understanding

what it is with respect to this company.

● Difficulties of developing a budget control system are related to:

– unusual nature of the activities of the company (not standard)
– lack of standard production rules
– need to re-schedule and re-budget most activities
– personnel turnover

➨ A precise statement of requirements is not possible

SOFTWARE DEVELOPMENT32
DEVELOPMENT
QUESTION

Which of the following software development processes, or

combinations of processes, would you use to develop the Budget
Control System? Why?

– code-and-fix
– waterfall
– prototyping
– fourth generation
– spiral
– phased

SOFTWARE DEVELOPMENT33
DEVELOPMENT
SOFTWARE DEVELOPMENT PROCESS —
BEST PRACTICES
Incorporating
Incorporatingbest
bestpractices
practicesleads
leadstotogood/appropriate
good/appropriate
methodologies
methodologiesand
andtools
toolsfor
forsoftware
softwareengineering
engineering

● abstraction and generality ● risk assessment

➢ Allows us to concentrate on ➢ Allows us to deal with
important aspects and to project threatening
possibly reuse software issues first
● rigor and formality ● anticipation of change
➢ Allows us to repeat what we ➢ Allows us to prepare for
have done and to produce maintenance
better quality software
● Incremental development
● separation of concerns and ➢ Allows us to evolve to
modularity the desired solution
➢ Allows us to divide
responsibilities/work and to
work on parts independently

SOFTWARE DEVELOPMENT34
DEVELOPMENT
 UNIFIED PROCESS — LIFE CYCLE
Phases
Core Workflows Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Testing

SOFTWARE DEVELOPMENT35
DEVELOPMENT
UNIFIED PROCESS — LIFE CYCLE PHASES GOALS

Inception – determines the system’s life cycle objectives

– establish feasibility → technical decisions; business requirements
– create a business case → quantifiable business benefit
– capture essential requirements to set the system scope
– identify critical risks

Elaboration – determines the system’s life cycle architecture

– create and executable architectural baseline for the system
– refine the risk assessment
– define the system’s quality attributes
– capture ~80% of the functional requirements
– create a detailed construction phase plan
– estimate: resources, time, equipment, staff, cost

SOFTWARE DEVELOPMENT36
DEVELOPMENT
UNIFIED PROCESS — LIFE CYCLE PHASES GOALS

Construction – builds the initial operational system

– complete all requirements, analysis and design
– evolve architectural baseline into the final system

Transition – releases the product to the customer

– correct defects
– prepare the user site for the new software
– tailor the software to operate at the user site
– modify the software if unforeseen problems arise
– create user manuals and other documentation
– provide user consultancy
– conduct a post project review

➨ All workflows are carried out during each phase,

but the emphasis/focus changes

SOFTWARE DEVELOPMENT37
DEVELOPMENT
 12.4.6

UNIFIED SOFTWARE DEVELOPMENT PROCESS (UP)

Selects from best practices to:

● provide a generic process framework
➨ instantiate/specialize for specific application areas, organizations,
project sizes, etc.

● define a set of activities (workflows)

➨ transforms users’ requirements into a software system

● define a set of models

➨ from abstract (user-level) to concrete (code)

● allow component-based development

➨ software components interconnected via well-defined interfaces

➨ use-case and risk driven

➨ architecture-centric
➨ iterative and incremental
SOFTWARE DEVELOPMENT38
DEVELOPMENT
UNIFIED PROCESS — USE-CASE DRIVEN

actor: Represents the users

use case: A piece of functionality required by an actor
use-case model: The complete system functionality (all use cases)

➨ The use-case model represents all system user

functionality
(functions that add value for the users)

➨ The use-case model is used to reach agreement with the

customer on the system’s required functionality
(it represents a contract between customer and developer)

➨ use cases drive the development process

(we transform the use case model into analysis,
design and implementation models)

➨ supports seamless traceability between models

SOFTWARE DEVELOPMENT39
DEVELOPMENT
UNIFIED PROCESS EXAMPLE — USE-CASE MODEL

A bank customer uses an ATM to withdraw and deposit money

from and to accounts and to transfer money between accounts.

Analysis model

Withdraw money
Design model

Implementation model
Bank Deposit money
Customer
Deployment model

Use-case model Transfer between

accounts Test model

SOFTWARE DEVELOPMENT40
DEVELOPMENT
UNIFIED PROCESS — ARCHITECTURE-CENTRIC

architecture
architecture:: AAhigh-level
high-leveloutline
outlineof
ofthe
the form
formof
ofthe
thesoftware
software
system.
system.

● represents the most significant static and dynamic aspects of

the system (subsystems, interfaces, dependencies, etc.)
➨ provides different views of the system
➨ describes the foundation of the system

● key use cases (normally 5-10%) determine the architecture

➨ use cases describe the function of the system WHAT

➨ architecture describes the form of the system HOW
GOAL –> A stable architecture early in the development
SOFTWARE DEVELOPMENT41
DEVELOPMENT
DETERMINING ARCHITECTURE

Constraints & Enablers

Use cases
System software

drive guides Middleware

Legacy systems
Architecture
Standards & policies

Non-functional
requirements
Experience
Distribution needs
• previous architecture
• architecture patterns --> object broker, client/server, layers, etc.
architecture baseline: a skeleton of the system with all critical
parts, but with few software “muscles”
SOFTWARE DEVELOPMENT42
DEVELOPMENT
ARCHITECTURE — USE-CASE MODEL

A bank customer uses an ATM to withdraw and deposit money

from and to accounts and to transfer money between accounts.

Withdraw money

Bank Deposit money

Customer

Transfer between
accounts

SOFTWARE DEVELOPMENT43
DEVELOPMENT
ARCHITECTURE — ANALYSIS MODEL (CLASSES)

Bank Withdraw money

Customer

Dispenser

Bank Withdrawal Account

Customer

Cashier
Interface

SOFTWARE DEVELOPMENT44
DEVELOPMENT
ARCHITECTURE — ANALYSIS MODEL (PACKAGES)

«package»
ATM
Interface
Bank
Customer

«package» «package»
Account Transaction
Management Management

SOFTWARE DEVELOPMENT45
DEVELOPMENT
ARCHITECTURE — DESIGN MODEL (CLASSES)

Card Reader

Display

Bank
Customer Client Transaction Account
Key Pad Manager Manager Manager

Withdrawal Account
Dispenser
Feeder
Cash
Counter
Dispenser
Sensor Persistent
Class

SOFTWARE DEVELOPMENT46
DEVELOPMENT
ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS)

«subsystem»
ATM
Interface
Bank
Customer
dispensing

«subsystem» «subsystem»
Account Transaction
Management Management withdrawal
transactions

SOFTWARE DEVELOPMENT47
DEVELOPMENT
ARCHITECTURE — IMPLEMENTATION MODEL
Design Model Implementation Model

«executable»

client.exe
Client
Manager «resides» «compilation»

Dispenser
Feeder «resides»
«file»

Dispenser client.c «compilation»

Sensor «resides»

Cash «resides»
Counter

«file»

dispenser.c

SOFTWARE DEVELOPMENT48
DEVELOPMENT
ARCHITECTURE — DEPLOYMENT MODEL

ATM
Bank
Client
Customer

internet

ATM intranet ATM

Data Application
Server Server

SOFTWARE DEVELOPMENT49
DEVELOPMENT
 DETERMINE SOFTWARE ARCHTITECTURE: 4+1 VIEW
Analysis Model Use-case Model

Implemen
Design Logical Implementation -tation
Model
Model View View
Test
Analysts/ Model
End-user Programmers
Designers
Structure Functionality Software management
Use-Case
View
Deploy
Process Deployment -ment
View View Model
System Integrators System Engineering
Performance System topology
Scalability Delivery, installation
Throughput communication

In the UP, software development is primarily

a model building activity.
SOFTWARE DEVELOPMENT50
DEVELOPMENT
DETERMINE SOFTWARE ARCHTITECTURE: 4+1 VIEW

● The use-case view defines the system�s external behaviour.

● The logical view describes the logical structures (classes and
their interactions) and how they will be implemented.
● The implementation view describes the physical components of
the system (executable files, libraries of code, databases, etc.).
● The process view deals with issues of concurrency within the
system.
● The deployment view describes how physical components are
distributed across the physical environment (processors,
networks).
– The process and deployment views address nonfunctional
requirements such as fault-tolerance, performance, etc.

SOFTWARE DEVELOPMENT51
DEVELOPMENT
UNIFIED PROCESS — ITERATIVE & INCREMENTAL

iteration: One step through the workflows

increment: Growth in the product from iteration to iteration

➨ Each increment establishes a new baseline for the system

➨ The iterations/increments must be controlled to be effective

● Developing the system in small steps allows us to:
– mitigate risks – plan better
– develop a robust architecture – integrate subsystems more
easily
– get feedback – attain early learning

➨ How to select what to put in an iteration?

1. use cases that extend product usability
2. highest risk use cases

SOFTWARE DEVELOPMENT52
DEVELOPMENT
UNIFIED PROCESS — MILESTONES
milestone
milestone:: aamanagement
managementdecision
decisionpoint
pointininaaproject
project
that
thatdetermines
determineswhether
whethertotoauthorize
authorize
movement
movementto tothe
thenext
nextiteration/phase
iteration/phase

Inception phase — agreement among customers/developers on the

system’s life cycle objectives
→ Agreement on what we should build.
Elaboration phase — agreement on the viability of the life cycle
architecture, business case and project plan
→ Decide if the system is feasible (technology, cost, time).
Construction phase — agreement on the acceptability of the
software product both operationally and in terms of cost
→ Right product? Built right? Acceptable cost?
Transition phase — final agreement on the acceptability of the
software product
→ The client signs off!
SOFTWARE DEVELOPMENT53
DEVELOPMENT
INCEPTION MILESTONE CRITERIA
Conditions of satisfaction Deliverables

agreement on project objectives a vision document that states the

project’s main requirements,
features, etc.

definition and agreement on the system scope an initial use-case model (10-20%)
capture and agreement on key requirements a project glossary

agreement on cost and schedule estimates an initial project plan

business case raised by project manager a business case

risk assessment performed by project manager a risk assessment document or

database

confirmation of feasibility through technical one or more throwaway prototypes

studies or prototyping

an outline architecture an initial architecture document

SOFTWARE DEVELOPMENT54
DEVELOPMENT
ELABORATION MILESTONE CRITERIA
Conditions of satisfaction Deliverables

creation of a resilient, robust executable the executable architectural

baseline baseline
demonstration that the executable architectural UML Static Model,, UML Dynamic
baseline identifies and solves important risks Model, UML Use-case Model

the vision of the product has stabilized vision document

the risk assessment has been refined updated risk assessment

revision and agreement on the business case updated business case

creation of and agreement on a project plan updated project plan

estimating resources required in the next
phases
verification of the business case against the business case and plan
project plan

customer agreement to continue the project sign-off document

SOFTWARE DEVELOPMENT55
DEVELOPMENT
CONSTRUCTION MILESTONE CRITERIA
Conditions of satisfaction Deliverables

the software product is sufficiently stable and of the software product

sufficient quality to be deployed in the user the UML Model
community test suite

the customer has agreed and is ready for the user manuals
transition of the software product to their description of this release
environment

the actual expenditures versus the planned project plan

expenditures are acceptable

SOFTWARE DEVELOPMENT56
DEVELOPMENT
TRANSITION MILESTONE CRITERIA
Conditions of satisfaction Deliverables

beta testing is completed, necessary changes the software product

have been made, and the users agree that the
system has been successfully deployed

users are actively using the product

product support strategies have been agreed user support plan

with users and implemented user manuals

SOFTWARE DEVELOPMENT57
DEVELOPMENT
 UNIFIED PROCESS — LIFE CYCLE ITERATION
Phases
Core Workflows Inception Elaboration Construction Transition

Requirements

Analysis

Iteration
Design

Implementation

Testing

iter. iter. iter. iter.

— — — — —
#1 #2 #n-1 #n

major milestone increment

SOFTWARE DEVELOPMENT58
DEVELOPMENT
UNIFIED PROCESS — LIFE CYCLE ITERATION(cont’d)

● Each iteration is assessed at its conclusion:

– New/missed requirements?
– Existing requirements changed?
– How do remaining risks affect the project?
We do not start next iteration unless the goals of the
current iteration have been achieved!
● After each iteration we need to do regression testing � to make
sure that what worked before still works!
● The planning is iterative, just like the development.

Ultimate Success: A sequence of iterations that always move

the project forward, never having to go back .
SOFTWARE DEVELOPMENT59
DEVELOPMENT
SOFTWARE DEVELOPMENT PROCESS: SUMMARY

● A software development process needs to consider both

management and engineering views.
● A software development process needs to consider the
characteristics of the:
– organization → size; access to users/client; need for formality.
– project → small/large; vague/well-defined; novel/well-known.
– people → availability of expertise; skill of developers.
● The Unified Software Development Process is object-oriented
and incorporates best practices of previous processes.
– It integrates management and engineering views.
– It can be adapted for different types of organizations, projects and
people.

SOFTWARE DEVELOPMENT60
DEVELOPMENT