Software Engineering

Tahir Farooq
FAST-NU
Embracing Change

In software projects one thing that is constant:

What is Software Process?
A software process is a set of related activities that leads to
the production of a software product.
Software Processes Fundamentals Activities

Software Specification:
The functionality of the software and constraints on its
operation must be defined

Software Design and Implementation:

The software to meet the specification must be
produced
Software Processes Fundamentals Activities

Software Validation:
The software must be validated to ensure that it does what
the
customer wants

Software Evolution:
The software must evolve to meet changing customer needs
Software Process Models
A software process model is a simplified representation of a
software process
Each process model represents a process from a particular
perspective
Provides only partial information
about that process
Process Model

Defines a distinct set of activities, actions, tasks,

milestones, and work products that are required to
engineer high-quality software

The activities may be linear, incremental, or

evolutionary

7
The Waterfall Model
The first published model of the
software development process
(Royce, 1970)

Because of the cascade from one phase

to another, this model is known as the
Waterfall Model

Plan and schedule all of the

process
Waterfall Model (Diagram)

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
10
The Waterfall Model
Requirements
Finish each phase
before continue to next
System Design
Why is the waterfall model
Program Design so criticized?
Which are the problems? Can
Implementation it be useful sometimes?
Integration
Testing

System Testing
Milestone and
Acceptance
deliverable at Test
each step. (Artifacts
Maintenance
such as Design
document, Requirement
Specification. etc.)
The Waterfall Model - Pros
Simple, manageable and easy to
understand
Fits to common project
management practices
(milestones, deliverables etc.)

Focus on requirements and design at

beginning, save money and time at
the end

Can be suitable for short projects

(some weeks)

Can be suitable for "stable" projects,

where requirements do not change
The Waterfall Model - Cons
Software requirements change, hard to
sign-off on a SRS.

Early commitment. Changes at the end, large impact.

Feedback is needed to understand a phase.

E.g. implementation is needed to
understand some design.

Difficult to estimate time and cost for the phases.

Handling risks are not part of the model. Pushes the risks forward.
Software "is not" developed in such a way. It evolves when problems are
more understood.
Doesn't support iteration, so changes can cause confusion
Difficult for customers to state all requirements explicitly and up front
Can We Improve the Model?
Iteration back to previous phase

Danger! e.g. a performance

problem can result in a
major requirements change.
Very expensive rollback...
Waterfall Model with Feedback (Diagram)
Communication
Project initiation
Requirements
gathering

Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test
Deployment
Delivery
Support
Feedback
15
Spiral Model (Diagram)

Planning

Communication

Start Modeling

Start

Deployment Construction

16
 Cost

Progress
 Spiral Model (Description)

Follows an evolutionary approach

Used when requirements are not well understood and risks are
high
Inner spirals focus on identifying software requirements and
project risks; may also incorporate prototyping
Outer spirals take on a classical waterfall approach after
requirements have been defined, but permit iterative growth of
the software

18
 Operates as a risk-driven modela go/no-go
decision occurs after each complete spiral in
order to react to risk determinations
Requires considerable expertise in risk
assessment
Serves as a realistic model for large-scale
software development
Prototyping Model(Diagram)

Quick
Planning
Communicati
on

Start Modeling
Deployment Quick
, Design
Delivery,
and
Feedback
Construction
Of Prototype
20
 Prototyping Model (Description)

Follows an evolutionary and iterative approach

Used when requirements are not well understood
Serves as a mechanism for identifying software
requirements
Focuses on those aspects of the software that are
visible to the customer/user
Feedback is used to refine the prototype
21
Prototyping Model(Potential Problems)
The customer sees a "working version" of the software, wants to
stop all development and then buy the prototype after a "few
fixes" are made
Developers often make implementation compromises to get the
software running quickly (e.g., language choice, user interface,
operating system choice, inefficient algorithms)
Lesson learned
Define the rules up front on the final disposition of the prototype before it is built
In most circumstances, plan to discard the prototype and engineer the actual
production software with a goal toward qualityc

22
Prototyping Model
A customer defines a set of general
objectives for software but does not
identify detailed input, processing,
or output requirements

The developer may be

unsure of the efficiency of an

 Prototyping Model
This model adds prototyping as sub-
process
A prototype is a partially developed product
that enables customers and developers to
examine some aspect of a proposed system
and decide if it is suitable for a finished
product
 Prototyping Model
Used to explore the risky aspects of the system
o Risk of developing the wrong system
o User interface without functionality
o Technical risks
Prototype may be thrown away or
evolve into product
 Prototyping Model

List of List of List of List of

Revisions Revisions Revisions Revisions

Revise Customer
Prototype Review

Prototype Prototype Prototype

Tes
Requirements Design System
t

System Delivered
Requirements System
 Prototyping Model (Pros)
Suitable for large systems for
which there is no manual
process to define the
requirements

Much feedback from

customer

Quality of software is
good
 Prototyping Model (Cons)
It may be impossible to tune the
prototype to meet non- functional
requirements

Lot of time at customer

The changes made during

prototype development will
probably have degraded the
system structure
 V Model
The V-model is a variation of the waterfall model that
demonstrates how the testing activities are related to analysis
and design
Developed by the German Ministry of Defense
Unit and system testing verify the program design,
ensuring that parts and whole work correctly
Acceptance testing, conducted by the customer rather than
developers, validates the requirements, trying each system
function meets a particular requirement in the specification
V Model Maintenance

Validate Requirements, Verify Specification Acceptance Test

Requirements
(Release
testing)

System Design System Testing

Verify System Design
(Architecture High- (Integration testing
level Design) of modules)

Verify Module Design

Module Design Module Testing
(Program Design, (Integration
Detailed Design) testing of units)
Verify Implementation

Implementation
of Units (classes,
procedures, Unit Testing
functions)
 V Model (Pros)
It defines tangible phases of the process, and proposes a
logical sequence in which these phases should be
approached
It also defines logical relationships between the phases
It demands that testing documentation is written as soon
as possible
It gives equal weight to development and testing
It provides a simple and easy to follow map of the
software development process
 V Model (Cons)
It is too simple to accurately reflect the software development process
It is inflexible; it has no ability to respond to change
It produces inefficient testing methodologies
Incremental Development Iterative Development
 Phased Development
Design a system so it can be delivered in pieces, letting users
have some functionality while the rest is under development

There are usually two or more systems in parallel:

a) The operational or production system in use by customers
b) The development system which will replace the current release
Phased Development

Phased Development

Incremental Iterative
Development Development
 Incremental Development

Incremental development partitions a system by functionality

Early release starts with small, functional subsystem, later

releases add functionality
Incremental Development

How? By delivering
several releases?
Incremental Model (Diagram)
Increment #1

Communication
Planning
Modeling Constructio
Increment #2
n Deploymen
Communication t
Planning
Modeling Constructio
Increment #3 n
Deployment
Communication
Planning
Modeling Constructio
n Deploy

38
Incremental Model (Description)

Used when requirements are well understood

Multiple independent deliveries are identified
Work flow is in a linear (i.e., sequential) fashion within
an increment and is staggered between increments
Iterative in nature; focuses on an operational product
with each increment
Provides a needed set of functionality sooner while
delivering optional components later
Useful also when staffing is too short for a39 full-scale
 Iterative Development

Iterative development improves overall system in each release

Delivers a full system in the first release, then changes the functionality
of each subsystem with each new release
 Iterative Development
When should the releases take When should the releases take
place? place?
Time-boxing - The time period is Prioritized functionality - Do the
fixed for each iteration. most important parts first.
 Iterative vs. Incremental Development
Incremental Development
Add a new "part" at each increment

Iterative Development
Improve a "working system" at each iteration
 Iterative Development - Pros
Misunderstandings and inconsistency are made clear early (e.g.
between requirement, design, and implementation)
Encourage to use feedback -> elicit the real requirements
Forced to focus on the most critical issues
Continuous testing offers project assessment
Workload is spread out over time (especially test)
The team can get "lesson learned" and continuously improve the
process
Stakeholders gets concrete evidence of progress
 Iterative Development - Cons
Problem with current business contracts, especially fixed-price contracts

With short iterations it can be hard to map customer requirements to iterations

Activity