Chapter Two

Chapter Two
Software Process
& SDLC Model
Outline
Introduction
Software process
Software development life cycle
SDLC Phases
SDLC Models
Software Process assessment models
Overview of SE Instructor: Zelalem F. Aca. year 2013
Software processes
3
Process:
 a series of steps involving activities, constraints, and resources
that produce an intended output of some kind.
 Process is distinct from product – products are outcomes
of executing a process on a project
 Software Process: The sequence of steps performed to produce
software with high quality, within budget and schedule.

Software processes
4
Software process
 A structured set of activities required to develop a software

system
 A software process (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.

Software processes
5
Any software process must include the following four activities:
1. Software specification (requirements engineering): Define the main

functionalities of the software and its constrains them.
2. Software design and implementation: The software is to be

designed and programmed.
3. Software verification and validation: The software must conforms

to it’s specification and meets the customer needs.
4. Software evolution (software maintenance): The software is

being modified to meet customer and market requirements changes.
Software Process Models
6
 It is an abstract representation of a process.
 It presents a description of a process from particular perspective
 it is a simplified representation of a software process.
 Each model represents a process from a specific perspective.
Those methodologies are sometimes known as software development

life cycle (SDLC) methodologies, though this term could also be used
more generally to refer to any methodology.

Characteristics Software ProcessModels
7
There are five main characteristics of software process model
 Predictability
 Support Testability & Maintainability
 Support Change
 Early defect removal
 Process improvement and feedback

8
Predictability
 Determines how accurately the outcome of process can be
predicted before project is completed.
 It is achieved from past experiences and failures from the similar
projects.
 Predictable property is within the bound around the expected
value of property of interest .
 It increases Q & P. Decreases C & T

9
Support Change: Changes due to:

 Requirements change
 Organization and business change –leads to software supports

has to change
 Changes during development also
 Customer needs change
 Long duration projects needs to be changed

10
Early Defect Removal

 Errors occur during programming
 Correction & Detection -> Hardest activity
 Errors occurs at any stage during development.
 Greater the delay in error detection -> more expensive to correct
 Quality control in each phase -> identify, detect, prevent and
remove defects

Software Development Life Cycle (SDLC)
11
SDLC …
 It 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.
 It is a standard that defines all the tasks required for developing and
maintaining software.
Phases of SDLC
12
Major activities in SDLC (phase of SDLC) are:
1. Planning and Requirements Analysis

2. Defining Requirements
3. Designing the Software
4. Building or Developing the Software
5. Testing the Software
6. Deployment and Maintenance

Phases of SDLC
13
Planning and Requirements Analysis
 is the most important and fundamental stage in SDLC.
 It is performed by the senior members of the team with
inputs from all the stakeholders and domain experts in the

industry..
 Planning for the quality assurance requirements and
identification of the risks associated with the project is also

done at this stage.

Phases of SDLC
14
Requirements Analysis
 Business Requirements
 Stakeholder Requirements
 Solution Requirements
Functional Requirements
Non-functional Requirements
 Transition Requirements

Phases of SDLC
15
Defining Requirements
 Once the requirement analysis is done the next step is to clearly
define and document the software requirements and get them
approved from the project stakeholders.
 This is done through ‘SRS’ – Software Requirement Specification

document which consists of all the product requirements to be
designed and developed during the project life cycle.

Phases of SDLC
16
Defining Requirements - includes:

 Enterprise Analysis
 Business Planning & Monitoring
 Requirements Elicitation
 Requirements Analysis
 Requirements Management & Communication
 Solution Assessment & Validation

Phases of SDLC
17
3. Designing the Software

 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.
 This DDS is reviewed by all the stakeholders and based on various
parameters as risk assessment, budget and time constraints, the

best design approach is selected for the software.

Phases of SDLC
18
4. Developing the Software

 In this stage of SDLC the actual development starts and the
product is built.
 The programming code is generated as per DDS during this stage.
 Developers have to follow the coding guidelines defined by their
organization and programming tools like compilers, interpreters,

debuggers are used to generate and implement the code.

Phases of SDLC
19
5. Testing the Software

 This stage is usually a subset of all the stages as in the modern
SDLC models, the testing activities are mostly involved in all the
stages of SDLC.
 However this stage refers to the testing only that stage of the
software where defects are reported, fixed and retested, until the
software reaches the quality standards defined in the SRS.

Phases of SDLC
20
6. Deployment and Maintenance
 Once the software is tested and no bugs or errors are
reported then it is deployed.
 Then based on the feedback, the software may be released as
it is or with suggested enhancements in the target segment.
 After the software is deployed then its maintenance starts.

Phases of SDLC
21

SDLC Models
22
 To implement the SDLC phases various SDLC models have been
created by software development experts, universities, and
standards organizations.
 It is a framework that describes the activities performed at each
stage of a software development project.

SDLC Models
23
SDLC (Process) Models

 Waterfall Model
 V – Model
 Iterative Model
 Spiral Model
 Agile Model
 Big Bang Model

Waterfall Model
24
Waterfall Model
 Oldest and most well-known SDLC model.
 Follows a sequential step-by-step process from requirements
analysis to maintenance.
 It is also referred to as a linear-sequential life cycle model.
 Each phase must be completed before the next phase can begin.
 Systems that have well-defined and understood requirements are a
good fit for Waterfall Model.

Waterfall Model
25

Waterfall Model
26
Waterfall Model: Strengths

 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than

cost or schedule

Waterfall Model
27
Waterfall Model: Weaknesses

 All requirements must be fully specified upfront
 Deliverables created for each phase are considered
 frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of
 software development – iterations of phases
 Integration is one big bang at the end

Waterfall Model
28
When to use the Waterfall Model

 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing software/product
 Porting an existing product to a new platform

V-shape Model
29
 A variant of the Waterfall that emphasizes the verification
and validation of the product.
 Testing of the product is planned in parallel with a
corresponding phase of SDLC phases.
 This is a highly-disciplined model and the next phase starts
only after completion of the previous phase.



V-shape Model
30
V-shape Model


V-shape Model
31
V-shape Model: strengths

 Emphasize planning for verification and validation of the product in early
stages of product development.
 Each deliverable must be testable.
 This is a highly-disciplined model and Phases are completed one at a time.
 Works well for smaller projects where requirements are very well understood
 Easy to use

V-shape Model
32
V-shape Model: weakness

 Does not easily handle concurrent events.
 Does not handle iterations.
 Does not easily handle dynamic changes in requirements.
 Does not contain risk analysis activities.

V-shape Model
33
When to use V-shape Model

 Excellent choice for systems requiring high reliability
hospital patient control applications
 All requirements are known up-front
 When it can be modified to handle changing requirements

beyond analysis phase
 Solution and technology are known

Prototyping Model
34
 Prototyping Model is a software development model in which prototype is built,
tested, and reworked until an acceptable prototype is achieved.
 Developers build a prototype during the requirements phase.
 Carry out a quick design.
 Prototype is evaluated by end users
 Users give corrective feedback: It is impossible to “get it right” the first time.
 Developers further refine the prototype
 When the user is satisfied, the prototype code is brought up

to the standards needed for a final product.

Prototyping Model
35
The actual system is developed using the classical

waterfall approach.

Prototyping Model
36
Prototyping Model:weakness
 Prototyping is a slow and time taking process.
 Poor documentation because the requirements of the customers are
changing.
 It is very difficult for software developers to accommodate all the
changes demanded by the clients.
 Overall maintainability may be overlooked
 The customer may want the prototype delivered.
 Process may continue forever

Prototyping Model
37
when to use Prototyping

 Requirements are unstable or have to be clarified.
 As the requirements clarification stage of a waterfall model.
 Develop user interfaces.
 Short-lived demonstrations.
 New, original development.
 With the analysis and design portions of object-oriented

development.

Incremental Model
38
 Incremental Model is a process of software development where
requirements are broken down into multiple standalone modules of

software development cycle.
 Incremental development is done in steps from analysis design,
implementation, testing/verification, maintenance.

Incremental Model
39
 At the end, the prototypes are merged into a final design.
 It is Often used for web applications.
 Development broken down into 3 phases
1. Static prototype consisting of HTML pages
2. Screen are programmed and fully functional using a simulated
services layer
3. Services are implemented

Incremental Model
40
 Incremental development: starts with small functional subsystem and
adds functionality with each new release
 Iterative development: starts with full system, then changes
functionality of each subsystem with each new release.

Iterative Development
41
 It starts with full system, then changes functionality of each subsystem
with each new release.
 Solves “all or nothing” drawback of the waterfall model
 Combines benefit of prototyping and waterfall
 Develop and deliver software in increments
 Each increment is complete in itself
 Can be viewed as a sequence of waterfalls
 Feedback from one iteration is used in the future iterations

Iterative Development
42
 Benefits: Get-as-you-pay, feedback for improvement
 Drawbacks: Architecture/design may not be optimal, rework may
increase, total cost may be more.
 Applicability: where response time is important, all req. not known

Agile Model
43
Agile SDLC model is a combination of iterative and incremental

process models with focus on process adaptability and customer
satisfaction by rapid delivery of working software product.
 The tasks are divided to time boxes to deliver specific features for a
release.
 Iterative approach is taken and working software build is delivered

after each iteration.
 Each build is incremental in terms of features; the final build holds all
the features required by the customer.

Agile Model
44

Agile Model
45
Some Agile Methods

• Rapid Application Development (RAD)
• Scrum
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)
• Crystal Clear
• Dynamic Software Development Method (DSDM)
• Rational Unify Process (RUP)
Rapid Application Development (RAD)
46
RAD Model is based on prototyping without any specific planning.
In RAD model, there is less attention paid to the planning and more
priority is given to the development tasks.
 It is designed to give much faster development and higher quality results.
 It allows usable systems to be built in as little as 60-90 days.
 The development is distributed into component development teams
 The RAD model used for information systems development.

47
 Build a rapid prototype

 Give it to user for evaluation & obtain feedback
 Prototype is refined
With active participation of users
Requirements User Constru

Cut over
Planning Description ction

48

49
RAD Strengths
 Reduced cycle time and improved productivity with fewer people.
 Time-box approach mitigates cost and schedule risk
 Customer involved throughout the complete cycle minimizes risk of not
achieving customer satisfaction and business needs
 Focus moves from documentation to code.
 Uses modeling concepts to capture information about business, data, and
processes.

50
RAD WEAKNESS
 Accelerated development process must give quick responses to the
user
 Risk of never achieving closure
 Hard to use with legacy systems
 Requires a system that can be modularized
 Developers and customers must be committed to rapid fire
activities in an abbreviated time frame.

51
When to use RAD
 Reasonably well-known requirements
 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
 System can be modularized

Spiral Model
52
 Spiral Model is a risk-driven software development process model.
 Spiral Model helps to adopt software development elements of multiple process
models for the software project based on unique risk patterns ensuring efficient
development process.
 It is a combination of waterfall model and iterative model.
 Combines iterative model, emphasizes risk assessment, customer participation,
prototyping.
 It Combines development activities with risk management to minimize and control risks.

Spiral Model Phases
53
Planning •It includes estimating the cost, schedule and resources for the
iteration.
 •It also involves understanding the system requirements for continuous
communication between the system analyst and the customer
Risk Analysis •Identification of potential risk is done while risk mitigation

strategy is planned and finalized
Engineering •It includes testing, coding and deploying software at the

customer site
Evaluation •Evaluation of software by the customer. Also, includes

identifying and monitoring risks such as schedule slippage and
cost overrun
Spiral Model
54

Spiral Model
55
Each loop of the spiral from X-axis clockwise through 360o represents one
phase.
One phase is split roughly into four sectors of major activities.
1. Planning: Determination of objectives, alternatives & constraints.
1. Risk Analysis: Analyze alternatives and attempts to identify and

resolve the risks involved.
2. Development: Product development and testing product.
3. Assessment: Customer evaluation

Spiral Model
56
Spiral Model Strengths

 Changing requirements can be accommodated.
 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky parts
can be developed earlier which helps in better risk management

Spiral Model
57
Spiral Model Weaknesses

 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Management is more complex.
 End of the project may not be known early
 Developers must be reassigned during non development phase

activities
Spiral Model
58
When to use Spiral Model

 A heavy-weight, plan-driven, highly-structured approach for large projects.
 Especially designed for those with higher chances of failure.
 Definitely an iterative process.
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex
 Significant changes are expected

Selection of a Life Cycle Model
59
 Selection of a model is based on:

a) Requirements
b) Development team
c) Users
d) Project type and associated risk

Reasons for Using SDLC Models
60
 Provides the base for project planning, estimating &

scheduling.
 Provides framework for standard set of terminologies,
activities & deliverables.
 Provides mechanism for project tracking & control.
 Increases visibility of project progress to all stakeholders.

Advantages of Choosing an Appropriate SDLC
61
 Increased development speed
 Increased product quality
 Improved tracking & control
 Improved client relations
 Decreased project risk
 Decreased project management overhead

Based On Characteristics Of Requirements
62
Requirements Waterf Prototy Iterative Evolutiona Spir RAD
all pe enhanceme ry al
nt developme
nt
Are requirements No No No No Yes
easily
understandable and
defined?
Do we change Yes No No Yes No
requirements
quite often?
Can we define No Yes Yes No Yes
requirements
early in the cycle?
Requirements are Yes Yes Yes Yes No

indicating a complex
system to be built

Based On Status Of Development Team
63
Development team Water Prototyp Iterative Evolutiona Spiral RAD
fall e enhancem ry
ent developme
nt
Less experience on No Yes No No Yes No
similar projects?
Less domain Yes No Yes Yes Yes No

knowledge (new to
the technology)
Less experience on Yes No No No Yes No

tools to be used
Availability of No No Yes Yes No Yes

training if required

Based On User’s Participation
64
Involvement Waterfal Prototype Iterative Evolutionar Spiral RAD
of Users l enhanceme y
nt developmen
t
User involvement in No Yes No No No Yes
all phases
Limited user Yes No Yes Yes Yes No

participation
User have no previous No Yes Yes Yes Yes No

experience of
participation in similar
projects
Users are experts of No Yes Yes Yes No Yes

problem domain

Based On User’s Participation
65
Project type Waterf Protot Iterative Evolutionary Spiral RAD
and risk all ype enhanceme development
nt
Project is the No No Yes Yes No Yes
enhancement of the
existing system
Funding is stable Yes Yes No No No Yes
for the project
High reliability No No Yes Yes Yes No
requirements
No Yes Yes Yes Yes Yes
Tight project
schedule
Use of reusable No Yes No No Yes Yes
components
Are resources (time, No Yes No No Yes No
money, people etc.)
scare?

Software Process Assessment
66
 Software process assessments are used to evaluate the form
and content of a software process, which may be specified by

a standardized set of criteria.
 The process is assessed to evaluate methods, tools, and
practices, which are used to develop and test the software.
 The aim of process assessment is to identify the areas for
improvement and suggest a plan for making that

improvement

67
• It examines whether the software processes are effective and

efficient in accomplishing the goals
• This is determined by the capability of selected software

processes.
• The capability of a process determines whether a process with

some variations is capable of meeting user's requirements.
• In addition, it measures the extent to which the software process

meets the user's requirements.

68
• Software process assessment models typically include

assessment criteria for software processes that are regarded as
constituting good practices.
• These practices may address software development processes only,

or they may also include topics such as
 software maintenance,
 software project management,
 systems engineering, or
 human resources management
•
Software Process Model
69
Several models have been proposed for assessing an

organization’s software development capabilities.
 Among them the basic models are listed and discussed
hereunder slides:
• Software Capability Maturity Model (CMM)
• ISO 9001
• ISO/IEC 15504 (SPICE)

70
END!

Chapter Two

Uploaded by

Document Information

Original Description:

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

Chapter Two

Uploaded by

Copyright:

Available Formats

Chapter Two

 a series of steps involving activities, constraints, and resources

that produce an intended output of some kind.

 Process is distinct from product – products are outcomes

of executing a process on a project

 Software Process: The sequence of steps performed to produce

software with high quality, within budget and schedule.

Overview of SE Instructor: Zelalem F. Aca. year 2013

 A structured set of activities required to develop a software

 A software process (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.

Overview of SE Instructor: Zelalem F. Aca. year 2013

Any software process must include the following four activities:

1. Software specification (requirements engineering): Define the main

2. Software design and implementation: The software is to be

3. Software verification and validation: The software must conforms

4. Software evolution (software maintenance): The software is

 It is an abstract representation of a process.

 It presents a description of a process from particular perspective

 it is a simplified representation of a software process.

 Each model represents a process from a specific perspective.

Those methodologies are sometimes known as software development

Overview of SE Instructor: Zelalem F. Aca. year 2013

There are five main characteristics of software process model

 Support Testability & Maintainability

 Early defect removal

 Process improvement and feedback

Overview of SE Instructor: Zelalem F. Aca. year 2013

predicted before project is completed.

 It is achieved from past experiences and failures from the similar

 Predictable property is within the bound around the expected

value of property of interest .

 It increases Q & P. Decreases C & T

Support Change: Changes due to:

 Organization and business change –leads to software supports

 Changes during development also

 Customer needs change

 Long duration projects needs to be changed

Overview of SE Instructor: Zelalem F. Aca. year 2013

Early Defect Removal

 Correction & Detection -> Hardest activity

 Errors occurs at any stage during development.

 Greater the delay in error detection -> more expensive to correct

 Quality control in each phase -> identify, detect, prevent and

Overview of SE Instructor: Zelalem F. Aca. year 2013

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.

Major activities in SDLC (phase of SDLC) are:

1. Planning and Requirements Analysis

Overview of SE Instructor: Zelalem F. Aca. year 2013

Planning and Requirements Analysis

 is the most important and fundamental stage in SDLC.

 It is performed by the senior members of the team with

inputs from all the stakeholders and domain experts in the

 Planning for the quality assurance requirements and

identification of the risks associated with the project is also

Overview of SE Instructor: Zelalem F. Aca. year 2013

Overview of SE Instructor: Zelalem F. Aca. year 2013