Software Engineering

Process Models
Software Process
Process Series of predictable steps - a road
map that helps create a timely and
high quality entity

Software Process is a
Software Process
framework for the tasks that are
required to build high quality
software to create timely and
high quality result
Software
Development Life
Cycle

3
Introduction
• The SDLC is a framework that describes the
activities performed at each stage of a software
development project.
• SDLC process is used by the software industry
to design, develop and test high quality
software.
• It aims to produce the quality software that
meets or exceeds customer expectations,
reaches completion within time and budget.
5
 Software Development Process
• Commonly has these activities:
1. Requirements analysis, WHAT ,
WHY
2. Design - HOW
3. Coding,
4. Testing,

Software Process
5. Evaluation and Maintenance

6
Software Development Life Cycle
(SDLC)
Common stages Goals of each stage
• Requirements
• Define a clear set of actions to perform
• Design
• Implementation • Produce tangible (trackable) items
• Testing
• Allow for work revision
• Release
• Maintenance • Plan actions to perform in the next stage

• Key question: how to combine the stages and in what order

7
1. Requirement Analysis
• State the problem precisely!
• Forms the basis of agreement between
user and developer
• Specifies “what” not “how”
• Hard task - needs often not understood
well
• Requirementspecifications of even
medium systems can be many hundreds

Software Process
of pages
• Outputis the SW Requirements Spec
(SRS) document 8
 2. Design
•A major step in moving from problem domain to solution
domain
• Most methodologies focus on architecture or high level design
• Based on the requirements specified in SRS, usually more
than one design approach for the product architecture is
proposed and documented in a DDS - Design Document
Specification.
• ThisDDS is reviewed by all the stakeholders and based on
various parameters as risk assessment, design modularity ,

Software Process
budget and time constraints , the best design approach is
selected for the software
• Outputs is Design Document Specification (DDS) 9
 3) Coding
• Converts design into code in specific language
• Goal:Implement the design with simple and easy to
understand code

• Coding phase affects both testing and maintenance

 Well written code reduces testing and maintenance effort

• Output is code

Software Process
10
4) Testing & Quality Assurance
• Defects are introduced in each phase
• Must be found and removed to achieve high quality
• Goal: Identify most of defects
• Outputs are
 Test plans/results, and
 the final tested (hopefully reliable) code

Software Process
11
Evaluation and Maintenance
• Oncethe client starts using the developed
software, then the real issues start coming up.
• Inthis stage, the team is required to fix the
issues, roll out new features and refine the
functionalities as required.
• The method where the care is taken for the
finished product is thus known as maintenance.

12
 Overview of SDLC
SDLC PHASE ACTIVITIES
1. Planning •Define the system to be developed
•Set the project scope
•Develop the project plan
2. Analysis •Gather business requirements
3. Design •Design the technical architecture
•Design system models
4. Development •Build technical architecture
•Build databases and programs
5. Testing •Write test conditions
•Perform testing
6. Implementation •Write user documentation
•Provide training
7. Maintenance •Build a help desk
•Support system changes
13
Types of Activities in
Process models

14
Two Types of Activities
• Anystandard software process model would primarily
consist of two types of activities:

 A set of framework activities, which are always

applicable, regardless of the project type,

 A set of umbrella activities, which are the non SDLC

activities that span across the entire software development
life cycle.

15
 Software
Project
Tracking and
Control
Software
Configuratio Document
n Preparation
Management and
Production

Umbrella Software
Quality
Umbrella Formal
Technical

Activities
Assurance Activity Reviews

Re-usability Risk
Management Management

Measurement
and Metrics

16
 Software Process
• Software project tracking and control
 allows the software team to assess progress against the project plan and
take any necessary action to maintain the schedule.
• Risk management
 assesses risks that may affect the outcome of the project or the quality of the
product.
• Measurement & Metrics
 This will include all the measurement of every aspects of the software
project.
 Measurement consists of the effort required to measure the software.
 The software cannot be measured directly. It is measured by direct
and indirect measures.
 Direct measures like cost, lines of code, size of software etc.
 Indirect measures such as quality of software which is measured by
some other factor. Hence, it is an indirect measure of software.
Software Process
• Software quality assurance
 defines and conducts the activities required to ensure
software quality.
• Technical reviews
 assesses software engineering work products in an
effort to uncover and remove errors before they are
propagated to the next activity.
Software Process
• Software configuration management
 manages the effects of change throughout the software
process.
• Reusability management
 defines criteria for work product reuse and establishes
mechanisms to achieve reusable components.
• Document preparation and production
 All the project planning and other activities should
be hardly copied and the production get started
here.
Generic Process
Framework

20
Software Process
◼ Generic process framework for software
engineering encompasses five activities
◼ Communication
◼ with customer, identify project objectives,
gather requirements to define software features
and functions
◼ Planning
◼ Software project plan
◼ Define technical tasks, risks, resources
required, work product, and the work
Software Process
◼ Generic process framework for software
engineering encompasses five activities
◼ Modeling
◼ Create sketch, what it looks like architecturally
◼ Construction
◼ Code generation and testing
◼ Deployment
◼ Deliver to customer to evaluate delivered
product and provide feedback
 Process Flow
◼ Describes how framework activities, the actions and
tasks that occur within each framework activities are
organized with respect to sequence and time
Process Flow
A linear process flow executes each of
the five framework activities in
sequence, beginning with
communication and culminating with
deployment
Process Flow
An iterative process flow repeats one or
more of the activities before proceeding
to the next
Process Flow
An evolutionary
process flow executes
the activities in a
“circular” manner.
Each circuit through
the five activities
leads to a more
complete version
of the software
Process Flow
A parallel process flow
executes one or more
activities in parallel
with other activities
(e.g., modeling for one
aspect of the software
might be executed in
parallel with
construction of another
aspect of the software).
Software Process
Models

28
Waterfall Model
Waterfall Model
Also known as the classic life cycle or Linear
Sequential model.

It suggests a systematic, sequential approach to

software development that begins at the system level
and progress through analysis, design, coding, testing
and support.
Waterfall Model
• Used when
 The requirements of a problem are reasonably well
understood
 When work flows from communication through
deployment in a reasonably linear fashion.
V-model
◼ A variation in the representation of the waterfall model is
called V-model
◼ In reality there is no fundamental difference between
classical lifecycle and the V-model
◼ V model provides a way of visualizing how verification and
validation actions are applied to earlier engineering work
◼ It is also known as Verification and Validation model. V-
Model is an extension of the waterfall model and is based on
association of a testing phase for each corresponding
development stage.
34
Disadvantages
• Real projects rarely follow the sequential flow that the
model proposes.
• It is often difficult for the customer to state all
requirements explicitly.
• A working version of the program will not be available
until late in the project time span.
• Linear nature leads to “blocking states ”.
Coping with change
• Change is unavoidable in all large software projects.
 Business changes lead to new and changed system
requirements
 New technologies open up new possibilities for improving
implementations
 Changing platforms require application changes

Chapter 2 Software Processes

• Change leads to rework so the costs of change include
both rework (e.g. re-analysing requirements) as well
as the costs of implementing new functionality

36
Reducing the costs of rework
• Change avoidance, where the software process includes
activities that can anticipate possible changes before
significant rework is required.
 For example, a prototype system may be developed to show
some key features of the system to customers.

• Changetolerance, where the process is designed so that

Chapter 2 Software Processes

changes can be accommodated at relatively low cost.
 This normally involves some form of incremental development.
Proposed changes may be implemented in increments that have
not yet been developed. If this is impossible, then only a single
increment (a small part of the system) may have be altered to
incorporate the change. 37
The Incremental
Model

38
The incremental model
• Thereare situations in which initial software
requirements are reasonably well defined
• Additionally,there may be compelling need to
provide a limited set of software functionality to
users quickly and then refine and expand on that
functionality in later software releases
• In
such case you choose a process model that is
designed to produce that software in increments.
Incremental model

1st increment is often a core product, basic requirements are addressed

Planning for the next increment
Repeat until complete product is produced
 The incremental model
• Theproblem is broken into increments, and each
increment is tackled as a linear sequence
• Furtherincrements can either be done after the
previous ones, or can overlap with the previous ones
• Incremental
delivery focuses on the delivery of an
operational product with each increment
• Early increments are stripped-down versions of the
final product
 The incremental model
• For example, word-processing software developed
using increments paradigm might deliver basic
file management, editing, and document
production functions in the first increment
• Second
increment: more sophisticated editing
and document production capabilities
• Third: spelling and grammer checking
• Fourth: Advanced page layout
 Incremental model advantages
Early delivery is guaranteed
Progress of the whole project is not delayed if one
of the resources is not available for part of it
Particularly useful when staffing is unavailable for
a complete implementation
Early increments can be implemented with fewer
people
If the core product is well received, then additional
staff (if required) can be added to implement the
next increment.
In addition, increments can be planned to manage
technical risks.
44
Video
https://www.youtube.com/watch?v=vDZfHqAwlkc

45
Evolutionary Process
Models

46
 Evolutionary Process Models
 Business and product requirements change (creeping
requirements)
 Above issues cannot be handled by linear sequential model
 Evolutionary process models produce an increasingly more
complete version of the software with each iteration.
 a set of core product or system requirements is well
understood, but the details of product or system extensions
have yet to be defined. (Product evolves over time)
 Evolutionary models are iterative. They are characterized
in a manner that enables you to develop increasingly more
complete versions of the software.
 Two Models
 Prototyping Model
 Spiral Model
48
 Prototyping
• Often,a customer defines a set of general objectives for
software, but does not identify detailed requirements for
function and features
•A quick design focuses on what the customer will see.
From this, a prototype is constructed
• The user evaluates it and improvements are made
• This
continues in an iterative fashion until a satisfactory
product is achieved
• Ideally,
prototype serves as a mechanism for identifying
software requirements
• No cost constraints
Prototyping

Quicker design
focuses on a
representation of
aspects visible to
end users.
e.g. human
interface layout
or output display
formats
Benefits
• Misunderstandings between developers and users
identified
• Incomplete requirements found
•A working system is available quickly to demonstrate
feasibility
• Usedas a basis for writing the specification for
production of quality software
 Problems
▪ Customer excepts a working model in a short time
putting pressure onthe team.
▪ Developer may compromise speed for efficiency (complex
efficiency)
▪ In-appropriate tools or algorithms may become a part of
thesystem
▪ In-focused customer may cause the system to either never
completed or to take too much time
• e.g.
• Govt. sector
The Spiral model
• Boehm’s (1988) spiral model couples the iterative
nature of prototyping with the controlled and
systematic aspects of the linear sequential model.
• Software is developed in a series of incremental
releases.
• Duringthe early releases, there may be just a paper
model, but the system becomes increasingly more
complete.
• Unlike any of the other models, this model keeps
revisiting the system throughout its lifetime.
Spiral model
The Spiral model
• Thefirst circuit around the spiral might result in
development of a product specification
• Subsequent passes around the spiral might be used to
develop a prototype
• When high risk involve we use this model
• Thefollowing might progressively more sophisticated
version of the software
SPIRAL (CONT…)
Planning based Risk analysis based
or customer or customer
comments comments
Risk Analysis on Initial
Initial Requirements Requirements
Initial prototype

Next Level prototype

Go or no-go
decisions

Engineered System

56
Differences between Spiral and
Incremental Model
• Both models, incremental and spiral offer partial
deliveries to the customer at different phases
BUT ….
• The Incremental Model focuses on the delivery
of a fully-tested production code in a step-by-step
fashion; each step adds more functionality
• The Spiral Model focuses on the development of
prototypes at each stage which will be used only
for information gathering and then throw-away
The RAD model
Rapid Application Development
• Rapid Application Development is an adaptation of
linear sequential software development process
model that emphasises an extremely short
development cycle.
• A component-based construction approach is used.
• To use this approach, the project scope must be
constrained and the requirements should be well
understood.
• A task that should take no more than ninety days
to complete is modelled, generated and implemented.
• There can be several teams working on different
components during this ninety day time-box
 RAD model
Team # 1
Communication
Project Initiation
Requirement Modeling
Gathering Analysis
Design

Construction
Code
Test
Team # 2

Modeling
Analysis
Planning Design
Estimating
Scheduling Deployment
Tracking Construction
Delivery
Code
Support
Test
Team # n Feedback

Modeling
Analysis
Design

Construction
Code
Test

60 – 90 days
Advantages of RAD
• Less time
• Reusability
Problems with RAD
• For large, scalable projects, RAD requires sufficient
human resources to create the right number of RAD
teams
• RAD requires developers and customers who are
committed to the rapid-fire activities necessary to
complete a system in this time frame, or failure will
result.
• RAD is not suitable for many project types.
 Personal Software Process (PSP)
• Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, a defect estimate (the number of defects projected for the work) is
made. All metrics are recorded on worksheets or templates. Finally, development tasks
are identified and a project schedule is created.
• High-level design. External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.
• High-level design review. Formal verification methods (Chapter 21) are applied to
uncover errors in the design. Metrics are maintained for all important tasks and work
results.
• Development. The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
• Postmortem. Using the measures and metrics collected (this is a substantial amount
of data that should be analyzed statistically), the effectiveness of the process is

79
determined. Measures and metrics should provide guidance for modifying the process to
improve its effectiveness.
 Team Software Process (TSP)
• Build self-directed teams that plan and track their work, establish
goals, and own their processes and plans. These can be pure
software teams or integrated product teams (IPT) of three to about
20 engineers.
• Show managers how to coach and motivate their teams and how to
help them sustain peak performance.
• Accelerate software process improvement by making CMM Level 5
behavior normal and expected.
 The Capability Maturity Model (CMM), a measure of the effectiveness of a
software process, is discussed in Chapter 30.

• Provide improvement guidance to high-maturity organizations.

80
• Facilitate university teaching of industrial-grade team skills.
Read Chapter 2 from Book

81