Software Engineering Software Engineering

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.
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
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.
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
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.
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.
DEVELOPMENT
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.
DEVELOPMENT
12.1
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
..
DEVELOPMENT
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.
DEVELOPMENT
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).
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
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)
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.

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
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, . . .
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
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?
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
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
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
DEVELOPMENT
PHASED PROCESS — INCREMENTS &
ITERATIONS
incremental development –> partial system; full functionality
iterative development –> full system; partial functionality
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.
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.
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.
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
DEVELOPMENT
12.4.3
SPIRAL SOFTWARE DEVELOPMENT PROCESS
Planning Risk analysis
Go, no-go
decision
Toward a
completed
system
Customer evaluation Engineering
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
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.
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.
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.
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

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
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
DEVELOPMENT
UNIFIED PROCESS — LIFE CYCLE
Phases
Core Workflows Inception Elaboration Construction Transition
Requirements
Analysis
Design
Implementation
Testing
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
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
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
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

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
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
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”
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
DEVELOPMENT
ARCHITECTURE — ANALYSIS MODEL (CLASSES)
Bank Withdraw money

Customer
Dispenser
Bank Withdrawal Account

Customer
Cashier
Interface
DEVELOPMENT
ARCHITECTURE — ANALYSIS MODEL (PACKAGES)
«package»
ATM
Interface
Bank
Customer
«package» «package»
Account Transaction
Management Management
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
DEVELOPMENT
ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS)
«subsystem»
ATM
Interface
Bank
Customer
dispensing
«subsystem» «subsystem»
Account Transaction
Management Management withdrawal
transactions
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
DEVELOPMENT
ARCHITECTURE — DEPLOYMENT MODEL
ATM
Bank
Client
Customer
internet
ATM intranet ATM

Data Application
Server Server
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.
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.
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
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!
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
DEVELOPMENT
ELABORATION MILESTONE CRITERIA
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
DEVELOPMENT
CONSTRUCTION MILESTONE CRITERIA
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
DEVELOPMENT
TRANSITION MILESTONE CRITERIA
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
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

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 .
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.
DEVELOPMENT

Software Engineering Software Engineering

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering Software Engineering

Uploaded by

Copyright:

Available Formats

SOFTWARE

1. Understand the types of software systems and how

2. Understand and compare different software development

3. Understand the importance of using an iterative and

4. Understand the importance of identifying and mitigating

5. Understand the components of the Unified Software

SOFTWARE DEVELOPMENT PROCESS OUTLINE

● Unified Software Development Process (UP)

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

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

3. Framework/component projects → reuse

•The life-cycle concept gives structure to the software

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

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

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

● Promotes teamwork/individual work/communication

● Eases project management

● Allows expertise reuse/reassignment

● Promotes productivity/better development

Points to keep in mind:

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

A more structured software development process needed

WATERFALL SOFTWARE DEVELOPMENT PROCESS

keeps the system

PROTOTYPING SOFTWARE DEVELOPMENT PROCESS

Build release 1 Build release 2 Build release 3

Use release 1 Use release 2 Use release 3

iterative development –> full system; partial functionality

● early training and feedback

● can create new markets

● apply appropriate expertise

SPIRAL SOFTWARE DEVELOPMENT PROCESS

Planning Risk analysis

Customer evaluation Engineering

Technical risks Non-technical risks

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

➨ Want to take corrective action early if not on track

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

● The current administrative system is not suitable for providing all

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

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

➨ A precise statement of requirements is not possible

Which of the following software development processes, or

● abstraction and generality ● risk assessment

Inception – determines the system’s life cycle objectives

Elaboration – determines the system’s life cycle architecture

Construction – builds the initial operational system

Transition – releases the product to the customer

➨ All workflows are carried out during each phase,

UNIFIED SOFTWARE DEVELOPMENT PROCESS (UP)

Selects from best practices to:

● define a set of activities (workflows)

● define a set of models

● allow component-based development

➨ use-case and risk driven

actor: Represents the users

➨ The use-case model represents all system user

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

➨ use cases drive the development process

➨ supports seamless traceability between models

A bank customer uses an ATM to withdraw and deposit money

Use-case model Transfer between