Software Processes &

Models
Chapter Two

Mesay A. (MSc in Software

Engineering
BSc. Computer Science) 1
Background
Software
A software is a computer
programs along with the
associated documents and the
configuration data that make
these programs operate correctly.
A program is a set of instructions
(written in form of human-
readable code) that performs a
specific task.
Mesay A. (MSc in Software Enginee 2
Background
Types of Software Systems
software systems from simple to
complex systems.
These systems may be :
developed for a particular customer,
◦ like systems to support a particular
business process, or
developed for a general purpose
◦ like any software for our computers
such as word processors.
Mesay A. (MSc in Software Enginee 3
Background
Software Engineers
It has to balance between
different people involved, such
as:
Dealing with users: User don’t
know what to expect exactly from
the software.
The concern is always about the
ease of use and response time.
Mesay A. (MSc in Software Enginee 4
Background
Software Engineers
It has to balance between
different people involved, such
as:
Dealing with technical
people: Developers are more
technically inclined people so
they think more of database
terms, functionality, etc.
Mesay A. (MSc in Software Enginee 5
Background
Software Engineers
It has to balance between
different people involved, such
as:
Dealing with management:
They are concerned with return
on their investment, and meeting
the schedule.

Mesay A. (MSc in Software Enginee 6

Background
For success in large software
developments, it is important to
follow an engineering approach,
which consisting of a well defined
Software Development Processes.

Mesay A. (MSc in Software Enginee 7

SOFTWARE
PROCESSES &
MODELS

Mesay A. (MSc in Software Enginee 8

Objectives of the chapter
To introduce software process
models
To describe three generic process
models and when they may be
used
To describe outline process
models for requirements
engineering, software
development, testing and
evolution
Mesay A. (MSc in Software Enginee 9
Topics covered
Software process models
Process iteration
Process activities
Computer-aided software
engineering

Mesay A. (MSc in Software Enginee 10

The software process
A software process (also knows
as software methodology) is a set
of related activities that leads to
the production of the software.
 These activities may involve the
development of the software from
the scratch, or, modifying an
existing system.

Mesay A. (MSc in Software Enginee 11

The software process
Any software process must include the
following four activities:
Software specification (or requirements
engineering):
◦ Define the main functionalities of the software
and the constrains around them.
◦ defining what the system should do
Software design and implementation:
◦ The software is to be designed and
programmed.
◦ Defining the organization of the system and
implementing the system;
Mesay A. (MSc in Software Enginee 12
The software process
Software verification and validation:
◦ The software must conforms to it’s
specification and meets the customer needs.
◦ checking that it does what the customer
wants;
Software evolution (software
maintenance):
◦ The software is being modified to meet
customer and market requirements changes.
◦ changing the system in response to changing
customer needs.

Mesay A. (MSc in Software Enginee 13

 The software process
When we talk about a process, we
usually talk about the activities in it.
However, a process also includes the
process description, which includes:
Products: The outcomes of the an
activity.
For example, the outcome of
architectural design maybe a model
for the software architecture.

Mesay A. (MSc in Software Enginee 14

The software process
Roles: The responsibilities of the
people involved in the process.
For example, the project
manager, programmer, etc.

Mesay A. (MSc in Software Enginee 15

 The software process
Pre and post conditions: The
conditions that must be true before
and after an activity.
For example,
the pre condition of the architectural
design is the requirements have been
approved by the customer,
while the post condition is the
diagrams describing the architectural
have been reviewed.
Mesay A. (MSc in Software Enginee 16
 The software process
Pre and post conditions: The
conditions that must be true before
and after an activity.
For example,
the pre condition of the architectural
design is the requirements have been
approved by the customer,
while the post condition is the
diagrams describing the architectural
have been reviewed.
Mesay A. (MSc in Software Enginee 17
Software Process Models
A software process model is an
abstract representation of a process.
 It presents a description of a process
from some particular perspective.
 A software process model represents
the order in which the activities of
software development will be
undertaken.
 It describes the sequence in which the
phases of the software lifecycle will be
performed.
Mesay A. (MSc in Software Enginee 18
Software Process Models
Sometimes called a Software
Development Life Cycle or SDLC
model or process paradigms.
 It is a simplified representation of a
software process.
For example, a process activity
model shows the activities and their
sequence
But may not show the roles of the
people involved in these activities
Mesay A. (MSc in Software Enginee 19
Software Process vs Software
Development Lifecycle vs Software
Development paradigms Model
Waterfall model
V model
Incremental model
RAD model
Agile model
Iterative model
Spiral model
Prototype model

Mesay A. (MSc in Software Enginee 20

 Software Process vs Software
Development Lifecycle vs Software
Development paradigms Model
 Problem
requirement
 Waterfall model gathering and identification
 V model  Requirement Analysis
 Requirement Specification or
 Incremental model
Specification of the solution
 RAD model  Requirement Design
 Agile model  Software Structure and

 Iterative model Algorithm design

 Implementation or source
 Spiral model code modules
 Prototype model  Integration and Deployment
 Maintenance

Mesay A. (MSc in Software Enginee 21

 Software Process vs Software
Development Lifecycle vs Software
Development paradigms Model
 Problem requirement • Structural Developme
gathering and identification • Object Oriented
 Requirement Analysis
Programming
 Requirement Specification or
• Component Based
Specification of the solution
Development
 Requirement Design
• Service Oriented
 Software Structure and
Development
Algorithm design
 Implementation or source
• Cloud Based Developm
code modules
 Integration and Deployment
 Maintenance

Mesay A. (MSc in Software Enginee 22

2.1 Generic software process
models
 The waterfall model
◦ Separate and distinct phases of specification and
development.
 Evolutionary development
◦ Specification, development and validation are
interleaved.
 Component-based software engineering
◦ The system is assembled from existing
components.
 There are many variants of these models
 e.g. formal development where a waterfall-like
process is used
 but the specification is a formal specification that
is refined through several stages to an
implementable design.
Mesay A. (MSc in Software Enginee 23
Waterfall model
Requirements
definition

System and
software design

Implementa tion
and unit testing

Integration and
system testing

Operation and
maintenance

Mesay A. (MSc in Software Enginee 24

Waterfall model phases
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
 The main drawback of the waterfall model
is
 the difficulty of accommodating change
after the process is underway.
 One phase has to be complete before
moving onto the next phase.
Mesay A. (MSc in Software Enginee 25
Waterfall model problems
 Inflexible partitioning of the project into
distinct stages makes it difficult to respond
to changing customer requirements.
 Therefore, this model is only appropriate
when the requirements are well-
understood and changes will be fairly
limited during the design process.
 Few business systems have stable
requirements.
 The waterfall model is mostly used for
large systems engineering projects where
a system is developed at several sites.
Mesay A. (MSc in Software Enginee 26
Evolutionary development
 There are two types of evolutionary
development:
 Exploratory development
◦ Objective is to work with customers and to
evolve a final system from an initial outline
specification.
◦ Should start with well-understood
requirements and add new features as
proposed by the customer.
 Throw-away prototyping
◦ Objective is to understand the system
requirements.
◦ Should start with poorly understood
requirements to clarify what is really
needed. Mesay A. (MSc in Software Enginee 27
Evolutionary development
Concurrent
activ ities

Initial
Specifica
tion version

Outline Interm ediate

description Development versions

Final
Validation version

Mesay A. (MSc in Software Enginee 28

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.

Mesay A. (MSc in Software Enginee 29

Component-based software
engineering
 Based on systematic reuse where
systems are integrated from existing
components or COTS (Commercial-off-
the-shelf) systems.
 Process stages
◦ Component analysis;
◦ Requirements modification;
◦ System design with reuse;
◦ Development and integration.
 This approach is becoming increasingly
used as component standards have
emerged.

Mesay A. (MSc in Software Enginee 30

Reuse-oriented
development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integration validation

Mesay A. (MSc in Software Enginee 31

Formal systems development
 Based on the transformation of a
mathematical specification through
different representations to an executable
program.
 Transformations are ‘correctness-
preserving’ so it is straightforward to
show that the program conforms to its
specification.
 Embodied in the ‘Clean room’ approach to
software
Requirements development
Formal Formal Integration and
definition specification transformation system testing

Mesay A. (MSc in Software Enginee 32

Formal systems development
Problems
◦ Need for specialised skills and training to
apply the technique
◦ Difficult to formally specify some aspects
of the system such as the user interface.
 Advantage
◦ The resulting software will have high
quality
 Applicability
◦ Critical systems especially those where a
safety or security case must be made
before the system is put into operation

Mesay A. (MSc in Software Enginee 33

2.2. Process iteration
 System requirements ALWAYS evolve in
the course of a project
 so process iteration where earlier stages
are reworked is always part of the process
for large systems.
 Iteration can be applied to any of the
generic process models.
 Two (related) approaches
◦ Incremental delivery;
◦ Spiral development.

Mesay A. (MSc in Software Enginee 34

 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.
 Once the development of an increment is
started, the requirements are frozen
though requirements for later increments
can continue to evolve.
Mesay A. (MSc in Software Enginee 35
Incremental development
Define outline Assign requirements Design system
requirements to increments architectur
e

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete

Mesay A. (MSc in Software Enginee 36

 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.
Mesay A. (MSc in Software Enginee 37
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.
Mesay A. (MSc in Software Enginee 38
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.
Mesay A. (MSc in Software Enginee 39
Spiral model of the software process

Deter
mine objecti
ves,
Ev
alua
te alternatives
alterna
tives and
identify
,e
r solv
e risks
constraints Risk
anal
ysis

Risk
anal
ysis

Risk
Opera-
anal
ysis
Pr
ototype 3 tional
Pr
ototype 2 proto
ype
Risk
REVIEW ysisProto-
anal
type 1
Requir
ements plan Sim
ulations
, models
, benchmar
ks
Life-cy
cle plan Concept of
Operation S/W
ements Pr
requir oduct
design Detailed
design
elopment Requir
Dev ement
plan valida
tion Code
Unit test
Integ
ration Design
V&V Integ
ration
and test plan
Plan ne
xt phase test
Acceptance
Service test Develop, v
erify
next-le
vel pr
oduct

Mesay A. (MSc in Software Enginee 40

Factors in Choosing a
Software Process
 Customer involvement
 Stable requirements
 Team size / proximity
 Developer experience
 Familiarity with technology
 Familiarity with domain
 Severity of impact of incorrect analysis
 Anticipated changes in technology

Mesay A. (MSc in Software Enginee 41

2.3. Process activities
 Software specification
 Software design and
implementation
 Software validation
 Software evolution

Mesay A. (MSc in Software Enginee 42

Software specification
 The process of establishing what services
are required and the constraints on the
system’s operation and development.
 Requirements engineering process
◦ Feasibility study;

◦ Requirements elicitation and analysis;

◦ Requirements specification;

◦ Requirements validation.
Mesay A. (MSc in Software Enginee 43
The requirements engineering
process
Requirements
Feasibility
elicitation and
study
analy sis
Requirements
specification

Feasibility Requirements
report validation

System
models
User and system
requirements

Requirements
document

Mesay A. (MSc in Software Enginee 44

Software design and
implementation
 The process of converting the system
specification into an executable system.
 Software design
◦ Design a software structure that
realises the specification;
 Implementation
◦ Translate this structure into an
executable program;
 The activities of design and
implementation are closely related and
may be inter-leaved.
Mesay A. (MSc in Software Enginee 45
Design process activities
 Architectural design
 Abstract specification
 Interface design
 Component design
 Data structure design
 Algorithm design

Mesay A. (MSc in Software Enginee 46

The software design
process

Requirements
specifica
tion

Design acti
vities

Data
Architectur
al Abstract Interface Component Algorithm
structur
e
design specifica
tion design design design
design

Data
System Software Interface Component Algorithm
structur
e
architectur
e specifica
tion specifica
tion specifica
tion specifica
tion
specifica
tion

Design oducts
pr

Mesay A. (MSc in Software Enginee 47

Structured methods
 Systematic approaches to developing a
software design.
 The design is usually documented as a
set of graphical models.
 Possible models
◦ Object model;
◦ Sequence model;
◦ State transition model;
◦ Structural model;
◦ Data-flow model.

Mesay A. (MSc in Software Enginee 48

Programming and
debugging
 Translating a design into a program and
removing errors from that program.
 Programming is a personal activity -
there is no generic programming process.
 Programmers carry out some program
testing to discover faults in the program
and remove these faults in the
debugging process.
Mesay A. (MSc in Software Enginee 49
The debugging process

Locate Design Repair Re-test

error erro r re pair erro r program

Mesay A. (MSc in Software Enginee 50

Software validation
 Verification and validation (V & V) is
intended to show that a system
conforms to its specification and meets
the requirements of the system
customer.
 Involves checking and review processes
and system testing.
 System testing involves executing the
system with test cases that are derived
from the specification of the real data to
be processed by the system.

Mesay A. (MSc in Software Enginee 51

The testing process

Component System Acceptance

testing testing testing

Mesay A. (MSc in Software Enginee 52

 Testing stages
 Component or unit testing
◦ Unit testing: Individual components are tested
independently;
◦ Module testing: Related components may be
functions or objects or coherent groupings of
these entities are tested.
 Sub system testing
◦ Modules are integrated into subsystems and
tested. The focus here should be on interface
testing.
 System testing
◦ Testing of the system as a whole. Testing of
emergent properties is particularly important.
 Acceptance testing (alphaMesaytesting)
A. (MSc in Software Enginee 53
Testing phases

Requirements System System Detailed

specifica
tion specifica
tion design design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and test

Acceptance System Sub-system

Service
test integration test integration test

Mesay A. (MSc in Software Enginee 54

Software evolution
 Software is inherently flexible and can change.
 As requirements change through changing
business circumstances, the software that
supports the business must also evolve and
change.
 Although there has been a distinction between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer
systems are completely new.
Mesay A. (MSc in Software Enginee 55
System evolution

Define system Assess existing Propose system Modify

requirements systems changes systems

Existing New
systems system

Mesay A. (MSc in Software Enginee 56

 Computer-aided software
engineering
 Computer-aided software engineering
(CASE) is software to support software
development and evolution processes.
 Activity automation
◦ Graphical editors for system model
development;
◦ Data dictionary to manage design entities;
◦ Graphical UI builder for user interface
construction;
◦ Debuggers to support program fault finding;
◦ Automated translators to generate new
versions of a program.
Mesay A. (MSc in Software Enginee 57
 Case technology
 Case technology has led to significant
improvements in the software process.
 However, these are not the order of
magnitude improvements that were once
predicted
◦ Software engineering requires creative
thought - this is not readily automated;
◦ Software engineering is a team activity
and, for large projects, much time is
spent in team interactions. CASE
technology does not support these much.

Mesay A. (MSc in Software Enginee 58

CASE classification
 Classification helps us understand the
different types of CASE tools and their
support for process activities.
 Functional perspective
◦ Tools are classified according to their
specific function.
 Process perspective
◦ Tools are classified according to process
activities that are supported.
 Integration perspective
◦ Tools are classified according to their
organisation into integrated units.
Mesay A. (MSc in Software Enginee 59
Functional tool
classification
Tool type Examples
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems
Configuration management tools Version management systems, system building tools
Prototyping tools Very high-level languages, user interface generators
Method-support tools Design editors, data dictionaries, code generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems

Mesay A. (MSc in Software Enginee 60

Process Activity-based tool
classification
Re-engineering tools

Testing tools

Debugg
ing tools

Program analysis tools

Language-processing
tools

Method suppor
t tools

Prototyping tools

Configuration
management tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification Design Implementation Verification

and
Validation

Mesay A. (MSc in Software Enginee 61

 CASE integration
 Tools
◦ Support individual process tasks such
as design consistency checking, text
editing, etc.
 Workbenches
◦ Support a process phase such as
specification or design, Normally
include a number of integrated tools.
 Environments
◦ Support all or a substantial part of an
entire software process. Normally
include several integrated
workbenches.
Mesay A. (MSc in Software Enginee 62
Tools, workbenches,
environments
CASE
technology

Tools Workbenches Enviro nments

File Integrated Process-centr

ed
Editors Compilers
comparators enviro nments enviro nments

Analy sis and

Programming Testing
design

Multi-method Single-method General-purpose Language-specific

workbenches workbenches workbenches workbenches

Mesay A. (MSc in Software Enginee 63

 Key points
 Software processes are the activities
involved in producing and evolving a
software system.
 Software process models are abstract
representations of these processes.
 General activities are specification,
design and implementation, validation and
evolution.
 Generic process models describe the
organisation of software processes.
 Examples include the waterfall model,
evolutionary development and component-
based software engineering etc.
 Iterative process models describe
Mesay A. (MSc the64
in Software Enginee
 Key points
 Requirements engineering is the
process of developing a software
specification.
 Design and implementation processes
transform the specification to an
executable program.
 Validation involves checking that the
system meets to its specification and user
needs.
 Evolution is concerned with modifying the
system after it is in use.
 The Rational Unified Process is a generic
process model that separates activities
from phases. Mesay A. (MSc in Software Enginee 65
Exercise (24 point)
 Discuss in detail case studies what is the
difference b/n Software process models vs
SDLC vs Software Development paradigms.
 Assume XYZ Bank is requesting you to
develop mobile banking service application
for their customers.
◦ Which software process model you will
use? Why?
◦ From which SDLC you will start you action?
Why?
◦ Which Software development paradigms
you will use? Why?
Mesay A. (MSc in Software Enginee 66
Exercise
 Assume WXYZ PLC is newly opened PLC having
10,000 employee. The PLC is requesting you to
develop HRM application which perform Attendance
Registration, Payroll development based Attendance
registration, ID card generation for their employee.
◦ Which software process model you will use? Why?

◦ From which SDLC you will start you action? Why?

◦ Which Software development paradigms you will

use? Why?

Mesay A. (MSc in Software Enginee 67

End of today’s topic
Read and ask me for more
understanding!!!

Mesay A. (MSc in Software Enginee 68