Software Engineering

The Software Process

 Why Software Engineering?

Can you approach building software as building a

bridge? Why? Why not?

How is software engineering like other

engineering disciplines?

2
 Software Process

A structured set of activities required to develop a

software system.
Fundamental Assumption:
Good processes lead to good software
Good processes reduce risk

3
 Risk Management

What can go wrong in a software

project?
How can the risk be reduced?

4
 The software process

Many different software processes but all involve:

Specification: defining what the system should
do;
Design and implementation: defining the
organization of the system and implementing it
Validation – checking that it does what the
customer wants;
Evolution – changing the system in response to
5 changing customer needs.
6
 Software Process Models

A software process model is an abstract representation of a

process.
 The waterfall model
Separate and distinct phases of specification and development
(product focused)
 Evolutionary development
Specification, development and validation are interleaved e.g.
XP (Beck), increment driven
 Component-based software engineering
The system is assembled from existing components.
 Spiral (Boehm)
7 driven by risk analysis and mitigation
 Background on software process models
➢ 1950 ：Code-and-fix model
➢ 1956 ： Stagewise model (Bengington )
➢ 1970 ： Waterfall model (Royce)
➢ 1971 ： Incremental model(Mills)
➢ 1977 ： Prototyping model(Bally and others)
➢ 1988 ： Spiral model(Boehm)

8
8
 Use of the Models in Practice

9
 The Waterfall Model

Requirements
Definition

System and
Software design
Programming
and Unit Testing

Integration and
System Testing

Operation and
10
Maintenance
 Waterfall Model
material adapted from Steve Easterbrook

perceived  View of development:

need  A process of stepwise
refinement
requirements  High-level management
view
 Problems:
design  Static view of
requirements (ignores
volatility)
code  Lack of user
involvement once spec is
written
test  Unrealistic separation of
spec from design
 Doesn’t accommodate
integrate prototyping, reuse
11
 The Waterfall Model

Requirements
Definition

System and
Software design
Programming
and Unit Testing

Integration and
System Testing

Operation and
12
Maintenance
 [1] Requirements Analysis and
Definition
• The system's services, constraints and goals are
established by consultation with system users. They
are then defined in a manner that is understandable
by both users and development staff.
• This phase can be divided into:
 Feasibility study (often carried out separately)
 Requirements analysis
 Requirements definition
13  Requirements specification
 Terminology
A requirement is a technical objective which is imposed
upon the software, i.e., anything that might affect the kind
of software that is produced
A requirement may be imposed by
the customer
the developer
the operating environment
The requirement must be documented
Requirements fall into two broad categories
functional
14 non-functional
 Functional Requirements

Functional requirements are

concerned with what the software
must do
capabilities, services, or operations
Functional requirements are not
concerned with how the software does
things, i.e., they must be free of design
15 considerations
 Non-Functional Requirements
Non-functional requirements place restrictions on the
range of acceptable solutions
Non-functional requirements cover a broad range of
issues
interface constraints
performance constraints
operating constraints
life-cycle constraints
economic constraints
political constraints
manufacturing
16
 Case Study

 We participated in a group project where we designed and developed

a cell phone game suitable for a cell phone using the programming
language Java 2 Micro Edition.
 We designed everything from the beginning with no game
requirements given to us.
 The process consists of defining system requirements, building the
system, and testing the system. The goal of the project was to have a
working game. We were restricted by time since this was a summer
program

17
 Define System Requirements

The system is designed to make the primary persona

happy but the other personas should not be unhappy
Define user scenarios
User scenarios describe how someone will interact
with the system.
This includes actual scenarios that could happen to a
person while playing through the game.

18
 Define System Requirements

Describe the user interface

Describe main interface that the user will
interact with.
This includes screen interactions and all
options the user will have.
Detailed requirements
Includes all functional, nonfunctional, and
constraint requirements that the system must
19
satisfy
 The Waterfall Model

Requirements
Definition

System and
Software design
Programming
and Unit Testing

Integration and
System Testing

Operation and
20
Maintenance
 [2] System and Software Design

System design: Partition the requirements to

hardware or software systems. Establishes an
overall system architecture
Software design: Represent the software system
functions in a form that can be transformed into
one or more executable programs
 Unified Modeling Language (UML)
21
 Case Study

 We participated in a group project where we designed and developed

a cell phone game suitable for a cell phone using the programming
language Java 2 Micro Edition.
 We designed everything from the beginning with no game
requirements given to us.
 The process consists of defining system requirements, building the
system, and testing the system. The goal of the project was to have a
working game. We were restricted by time since this was a summer
program

22
 Build System

Define the system classes

Classes are derived from the nouns in the user
scenarios.
Every system activity or primitive function should
reside in a class
Define system sequence diagrams
Sequence diagrams show how the classes work
together to execute each use-case function
23
 Build System

24
 [3] Programming and Unit Testing

The software design is realized as a set of

programs or program units. (Written
specifically, acquired from elsewhere, or
modified.)
Individual components are tested against
specifications.
25
 Build System

Implement the system

The class skeletons are coded
based on the code generated from
the class diagrams.
All coding takes place here.

26
 The Waterfall Model

Requirements
Definition

System and
Software design
Programming
and Unit Testing

Integration and
System Testing

Operation and
27
Maintenance
 [4] Integration and System Testing

The individual program units are:

 integrated and tested as a complete system
 tested against the requirements as specified
 delivered to the client

28
 The Waterfall Model

Requirements
Definition

System and
Software design
Programming
and Unit Testing

Integration and
System Testing

Operation and
29
Maintenance
 [5] Operation and Maintenance

 Operation: The system is put into practical use.

Maintenance: Errors and problems are identified and
fixed.
 Evolution: The system evolves over time as
requirements change, to add new functions or adapt the
technical environment.
 Phase out: The system is withdrawn from service.
30
 Discussion of the Waterfall Model

Advantages:
 Process visibility
 Dependence on individuals
 Quality control
 Cost control

31
 The Classical Software Lifecycle
The classical software Requirements
Collection
lifecycle models the Analysis
software development Design
as a step-by-step Implementation

“waterfall” between Testing

Maintenance
the various
development phases.

The waterfall model is unrealistic for many reasons:

• requirements must be frozen too early in the life-cycle
• requirements are validated too late

32
 Problems with the Waterfall Lifecycle
1. “Real projects rarely follow the sequential flow that the model
proposes. Iteration always occurs and creates problems in the
application of the paradigm”
2. “It is often difficult for the customer to state all requirements
explicitly. The classic life cycle requires this and has difficulty
accommodating the natural uncertainty that exists at the beginning
of many projects.”
 Each stage in the process reveals new understanding of the previous
stages, that requires the earlier stages to be revised.

33
 Cons

 Not a good model for complex and object-oriented

projects.
 High amounts of risk and uncertainty.
 Not suitable for the projects where requirements are at a
moderate to high risk of changing. So risk and uncertainty
is high with this process model.

34
 Problem Case Study

Publisher of books want to develop a product that

will carry out all the accounting functions of the
company and provide online information to the
head office staff regarding orders and inventory
Terminals are required for 15 accounting clerks,
32 order clerks, and 15 managers need access to
the data. The publisher will pay 30000 and wants
the complete product in 4 weeks
What
35 do you tell him?
 Case Study: Sensor Display

Consider a small system that displays the status of

several sensors (e.g., pressure, temperature, rate of
change, etc.) on a limited-size screen
What are some of its functional requirements?
What are some of its non-functional requirements?

display
System

36
 Iterative Development
In practice, development is always iterative, and
all activities progress in parallel.

Requirements Testing based on requirements

Collection

Maintenance through iteration Testing

Analysis Testing throughout implementation

Validation through prototyping
If the waterfall
Implementation model is pure
Design fiction, why is it
Design through refactoring
still the dominant
software process?
37
 Iterative Refinement

Evaluation Requirements

Implementation
(prototype) Design
38
 Phased Models
material adapted from Steve Easterbrook

Release 1
Incremental development
design code test integrate O&M (each release adds more
release 2 functionality)
Requirements

design code test integrate O&M

release 3
design code test integrate O&M
release 4
design code test integrate O&M

version 1
reqts design code test integrate O&M

lessons learnt
version 2
reqts design code test integrate O&M
lessons learnt
Evolutionary development version 3
(each version incorporates reqts design code test integrate
39 new requirements) 39
 Incremental Development

Plan to incrementally develop (i.e., prototype) the

system.
If possible, always have a running version of
the system, even if most functionality is yet to
be implemented.
Integrate new functionality as soon as possible.
Validate incremental versions against user
requirements.
40
 Incremental development

41
42
43
44
45
 Incremental delivery

Rather than deliver the system as a single delivery, the

development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
User requirements are prioritised and the highest
priority requirements are included in early increments.
It is easier to get customer feedback on the
development work that has been done.

46
 Incremental development advantages

Customer value can be delivered with each increment so

system functionality is available earlier.
Early increments act as a prototype to help elicit
requirements for later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the
most testing.
The cost of accommodating changing customer
47
requirements is reduced.
 When to use the Incremental model

 This model can be used when the requirements of the

complete system are clearly defined and understood.
 Major requirements must be defined; however, some
details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.

48
 Evolutionary Process Model
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

49
50
 Evolutionary

Version 1
Requirements Design Coding Test Deployment
Version 2
Requirements Design Coding Test Deployment

Version 3 Feedback
Requirements Design Coding Test Deployment

New versions implement new and

evolving requirements

(Some call it iterative)

51 51
 Evolutionary development

 Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid prototyping)
may be required.
 Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.
52
 Spiral development

Process is represented as a spiral rather than as a

sequence of activities with backtracking.
Each loop in the spiral represents a phase in the
process.
No fixed phases such as specification or design -
loops in the spiral are chosen depending on what
is required.
Risks are explicitly assessed and resolved
throughout the process.
53
 Spiral Model
material adapted from Steve Easterbrook

Determine goals, Evaluate

alternatives, alternatives
constraints and risks

budget4 budget3 budget2 budget1 prototype1 prototype2 prototype3 prototype4

Develop
Plan and
test
54 54
 Details of the Spiral

55
 Boehm’s Spiral Lifecycle
Planning = determination Risk Analysis = Analysis of
of objectives, alternatives alternatives and identification/
and constraints resolution of risks

Risk = something that

initial requirements will delay project or
increase its cost

completion go, no-go decision

first prototype
alpha demo

Customer Evaluation = Engineering =

Assessment of the Development of the
results of engineering evolving system next level product

56
 Spiral model sectors
 Objective setting
Specific objectives for the phase are identified.
 Risk assessment and reduction
Risks are assessed and activities put in place to reduce the
key risks.
 Development and validation
A development model for the system is chosen which can be
any of the generic models.
 Planning
The project is reviewed and the next phase of the spiral is
planned.
57
 The spiral model
The Risk Management Plan

➢ Identify the project’s top 10 risk items.

➢ Present a plan for resolving each risk item.
➢ Update list of top risk items, plan, and results monthly.
➢ Highlight risk-item status in monthly project reviews.
Compare with previous month’s rankings, status.
➢ Initiate appropriate corrective actions.

58
5
 Spiral Model Advantages

Focuses attention on reuse options.

Focuses attention on early error elimination.
Puts quality objectives up front.
Integrates development and maintenance.
Provides a framework for hardware/software
development.

59
 When to use Spiral model

 When costs and risk evaluation is important

 For medium to high-risk projects
 Long-term project commitment unwise because of
potential changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line

60
 V Model
Level of abstraction material adapted from Steve Easterbrook

system system
requirements integration

software acceptance
requirements test

preliminary software
design integration

“analyze “test
and detailed component and
design” design test integrate”

code and unit

debug test

61 time
61
 V Model

V- model means Verification and Validation

model.
Just like the waterfall model, the V-Shaped life
cycle is a sequential path of execution of
processes.
Each phase must be completed before the next
phase begins.
Testing of the product is planned in parallel with a
corresponding phase of development.
62
63
 V Model

Requirements begin the life cycle model

just like the waterfall model.
But, in this model before development is
started, a system test plan is created.
The test plan focuses on meeting the
functionality specified in the requirements
gathering.
64
 Build and Fix Model
 Advantage
 Appropriate for small programs
written by one person
 Disadvantage
 Understandability and
maintainability decrease rapidly
with increasing program size
 Totally unsatisfactory
 Need a life-cycle model
“Game plan”
Phases
Milestones

65
 Case Study
Test System

The final phase in the process was to test

the system.
 We ran visual acceptance tests by running
the program and playing through the game.
This proved helpful in ensuring that the
game is error free, not necessarily that the
system is error free.
66
 Case study

Children hospital
Care for children in the Alexandria city and
some Arab countries
The average length of stay of inpatients is
3.6 days
All patients are accompanied by a parent
for the entire duration of their stay at
67 hospital
 Case Study

 We participated in a group project where we designed and developed

a cell phone game suitable for a cell phone using the programming
language Java 2 Micro Edition.
 We designed everything from the beginning with no game
requirements given to us.
 The process consists of defining system requirements, building the
system, and testing the system. The goal of the project was to have a
working game. We were restricted by time since this was a summer
program

68
 Bank example
 Requirements
 Open an account for a customer (savings or chequing)
 Deposit ƒ
Withdraw ƒ
Display details of an account ƒ
Change LOC ƒ
 Produce monthly statements ƒ
Print a list of customers
 Ambiguities
 What is the difference between savings and chequing?
69
70
 Design of Bank – Identify Classes

 TELLER ƒ
 CUSTOMER ƒ
 SAVINGS_ACCOUNT ƒ
 CHEQUING_ACCOUNT ƒ
 MAIN_MENU ƒ
 BALANCE_INQUIRY ƒ
 INTEREST_RATE

71