Software

S ft Development
D l t
Life
Lif CCycle
l Models
M dl

Amitysoft Technologies Pvt Ltd, 6/22, 2nd Floor, Dhandapani Street, Near Shrine Vailankanni Sr Sec School, T.Nagar, Chennai - 600 017.
Phone: (044) 42035577, 24328077. Email:[email protected] Web: www.amitysoft.com
Topics
•What is Software?
•SDLC and phases involved in SDLC
•Life Cycle Models
•Quality Fundamentals
•Verification and Validation

Slide 2
C
Concepts
t off Software
S ft

Slide 3
Concept of Software System
• Software is basically a set of one or more programs which
instruct the computer to perform certain operations
• Software can be classified into system software and
application software.
• System software focus upon directing the computer and
its p
peripherals
p such as Windows or Mac OS, operate
p the
machine itself
• Application
pp software focus upon
p solving g human p problems
in business, science , such as spreadsheet or word
processing programs, provide specific functionality.

Slide 4
Different kinds of software

USERS

Embedded or
‘APPLICATIONS’ Business
Real-time software

Utility Users tools Dev. tools

INFRASTRUCTURE
SYSTEM SOFTWARE

Slide 5
Software
S ft Development
D l t
Lif Cycle
Life C l

Slide 6
SDLC
• Software development life cycle [SDLC] represents the
overall development process by which a software
system is defined and realized
• Principle engineering processes in the SDLC are
requirements,
q design,
g coding
g and testing
g

Slide 7
Phases of SDLC
The different phases of SDLC are
• Requirement Gathering and Analysis
• Planning
• Design
• Development or Coding
• Testing
• Deployment and Maintenance

Slide 8
Requirements and Analysis
• User requirements are understood and translated into
system
t requirements
i t
• Enables designers to understand the problem domain
• Enables testers to understand what is the expected
behavior of the system
• The requirements are documented Software Requirement
Specification (SRS) document
• Output document is well understood by both the customer
and supplier

Slide 9
Planning
• In this phase schedule, scope and resource requirements
f a release
for l i planned
is l d
• The resource available is matched with the scope of the
project to set milestone and final release date.
• Both project plan and test plan document are delivered.

Slide 10
Design
• System that meets the requirements specified in the
S ft
Software R
Requirement
i t Specification
S ifi ti document
d t is
i designed
d i d
• Design is split into architectural design, High level design
and low-level design
• The design steps are documented in a system design
description (SDD) document that will be used by the
development team to produce a software that realize the
design
g is a solution Blue-Print
• Design

Slide 11
Architecture Design
• Approach/top-view of the Technical solution.
• Defines structural layers and communication processes.
• Alternative architectures are considered.
• Enables developers and testers to understand the big
picture of a software solution.

Slide 12
High-Level Design
• This includes application design, database design, user-
interface design, background process design, menu design,
library design, security design.

• Enable testers to understand the interactions between

various system functions

Slide 13
Low-level Design
• Components or units or programs are specified for
implementation.

• Enable testers to understand the individual behavior of

programs.

Slide 14
Coding
• Implements the low-level design using the chosen tools.

• Results in source code.

• Also referred as construction.

construction

Slide 15
Testing
• Testing exercises the system and its components to find
errors.
• Reduces the risk of product failure.
• Last stage before delivery to customer.

Slide 16
Preparations for testing - 1
Understand the application domain – Typical application
d
domains
i are financials,
fi i l Sales,
S l T l
Telecom d
domains,
i i
insurance,
manufacturing
Understand the technology & platform – Software may be
developed based on client-server, multi-tier, e-commerce/ web
technology, RDBMS, OS
Learn how to use the application – Assume as a end-user
and run the application to get a feel of how the software
works.

Slide 17
Preparations for testing – 2
Study the Software Requirements Specification (SRS)
d
document
t – The
Th software
ft h to
has t be
b tested
t t d only
l based
b d on the
th
SRS. The tester must have sound knowledge of the
requirements
i t off software.
ft
Study the Design – Go through the Architecture, Design
documents in order to prepare test cases.
Study the Source Code – If specified the test engineer
needs to carry out white box testing then, study the source
code to generate test cases.

Slide 18
Deployment and Maintenance
• The tested product is used by the customer for confirming its
behavior

• Discrepancies in the actual and the expected behavior in

the product ends up as the product defects which are to be
corrected

• Maintenance can be corrective maintenance, adaptive

maintenance or preventive maintenance.

Slide 19
Life Cycle Models

Slide 20
Life Cycle model
A Life cycle model describes how the phase combine together to form a
complete project.
project
Some of the common Life cycle models are
• Waterfall model
• Prototyping
• Iterative Enhancement Model
• Agile Model
• Spiral
• V-model

Slide 21
Waterfall Model
Simple waterfall model

Requirement D

Design C

Construction
T

Testing

Slide 22
Waterfall Model
This is the simplest model where in the phases are organized
in a linear order.
order In this model,
model sequence of activities are:
• Feasibility requirements and analysis
• Requirement analysis and Project planning
• Design
• Coding
• Testing
g

Slide 23
Waterfall Model
• On successful demonstration of the feasibility of a project,
the requirements analysis and project plan are prepared

• The design starts only after completion of requirement

phase
h

• Coding begins only after design is complete. Then testing is

carried out

• On successful completion of testing, the system is installed.

After this, operation and maintenance of the system begins

Slide 24
Waterfall Model
Application:
• This model is used where in the requirements are known
fully and there is no change in requirement
• Conversion of existing project into new project
• Short duration projects

Slide 25
Waterfall Model
Limitations:
• Not suitable for change driven projects
• Not suitable for large project
• It assumes uniform and orderly sequence of steps
• For change
g driven p
projects,
j modified waterfall model is
used. One important consideration is that the changes
should be manageable

Slide 26
Prototype Model
• This is used for systems which are not clear to both the
customer and the developer.
developer

• Initially a GUI is prepared with the basic idea in mind. This

forms the requirements phase.

• Then design, coding and testing are carried out by using

any appropriate models.

Slide 27
Prototype Model
Prototype model

D
D C T
C

Requirements

Slide 28
Prototype Model
• The goal of prototype based development is to counter the
limitation of waterfall model.
model

• Basic idea is that instead of freezing the requirements

before design or coding can proceed, a prototype is built to
understand the requirements. Prototype is developed on
th currently
the tl known
k requirements.
i t

Slide 29
Prototype Model
• This is an alternative idea for which there is no manual or
existing system to help determine the requirements.
requirements

• After prototype is developed, the end user and the client

are permitted to use and play with the application.

• They provide feedback and based on this, prototype is

modified.

Slide 30
Prototype Model
Advantages

• It is well suited for the projects where the requirements are

hard to determine and the confidence in obtained
requirements is low.

• For projects where the requirements keeps changing

Disadvantages

• High development cost and time

Slide 31
Iterative Enhancement Model
• Core of the requirement should be known.

• The basic idea is that the software should be developed in

increments, each increment adding some functional
capability to the system until the full system is implemented.

Slide 32
Iterative Enhancement Model
Iterative enhancement model

D
Core of the
requirements is
known C

Release Release
1 2

Slide 33
Iterative Enhancement Model
Advantages:

• Customer will always get the software that works.

• Useful for Product development.

• Cost benefit.

Slide 34
Agile Model
• It is a lightweight software development model, which was developed in
1990s .
1990s'.

• It is a development method based on iterative and incremental model

• R
Requirements
i t andd solutions
l ti will
ill evolve
l through
th h collaboration
ll b ti between
b t
self-organizing and cross-functional teams

• Gives customer satisfaction by giving rapid and continuous delivery of

small and useful software.

• Time boxed iterative approach.

approach

• It encourages rapid and flexible response to changes

Slide 35
Agile Development Process

Slide 36
Agile Model
Advantages

• Ability
Abilit to
t respond
d for
f changes
h

• The changes are integrated immediately, which saves

trouble later.

• No gguesswork between the development

p team and the
customer

• Delivers high quality product in short time period by

providing customer satisfaction

Slide 37
Agile Model
Disadvantages

• A
As requirements
i t kkeeps on changing,it
h i it iis diffi
difficult
lt tto estimate
ti t
effort and time required for project

• The added problem is if the customer representative is not

sure, then the project going off track increase manifold.

• Only senior developers are in a better position to take the

decisions necessary for the agile type of development.

Slide 38
Spiral Model
Proposed by Barry Boehm

• Activities organized in spirals that has many iterations.

• Each iteration begins

g with determination of objectives,
j ,
alternatives and constraints.

• Evaluation of different alternatives based on objectives,

objectives and
to identify and resolve risk.

Slide 39
Spiral Model

Slide 40
Spiral Model
• This step may involve activities such as bench marking,
simulation and prototyping

• Design verification activities and Testing activities

• Plan for next iteration

Slide 41
Spiral Model
Advantages:
• Risk evaluation is the key activity in each of the spiral
• Each spiral’s planning has its defined objectives and
constraints
• Each spiral comes to an end when reviews are carried-out
with respect to its defined objectives and identified risks
• Each spiral has GO/NO-GO for the project at the end of the
review.
• Preferred for high risk projects.

Slide 42
Testing in V-model
• Even though test execution can start only after the code is
built we can start testing related activities much early in the
built,
life cycle

• Test Plans are prepared along with Project Plans

• Test Cases are prepared along with Requirements &

Design stages.

• This approach
pp helps
p the tester to start the testing
g
immediately when the code is made ready.

Slide 43
Figure 2.4 Phases of testing for different
p
development phases.
p

Slide 44
Testing in V-model
• Sufficient effort is directed towards the planning and design
of the tests.
tests

• Depicts the importance of specifying requirements and

designing the solution for testability.

• Depicts the engineering inputs provided to different levels

of testing.

Slide 45
Advantages of V-Model

• Testing activities like planning, test designing happens

well before coding
coding.
• Saves ample amount of time and since the testing
team is involved early in SDLC Process

• Develops a very good understanding of the project at

the very beginning

Slide 46
 Limitations of V Model
• One of the assumption made in V Model is that the execution
of tests of different types cannot happen until the entire
product is built
B t for
But f a given
i product,
d t
The different units and components can be in different
stages
t off evolution
l ti
That is, one unit could be still under development where as
another
th unit
it is
i ready
d for
f componentt testing
t ti
• V Model fails to explicitly address this parallelism

Slide 47
Quality Fundamentals

Slide 48
Topics
• Definitions of Quality

• Views of Quality Gurus

• Shewhart’s PDCA or Deming’s

g Wheel

• Quality Assurance vs. Quality Control

• Testing, Verification and Validation (V & V)

Slide 49
Quality : Definition
“degree of excellence “
-Oxford
Oxford English Dictionary definition

used synonymously with words - luxurious, up

market exclusive,
market, exclusive prestigious etc.,
etc
Subjective and difficult to measure!
Quality is meeting the requirements expected of
software, consistently and predictably.

Slide 50
View of the Quality Gurus
Crosby’s View: Conformance with requirements; Zero defects - right
the first time
Feigenbaum’s View: Setting quality standards, Action when
standards are not meet and continuous improvement of quality
standards
Deming’s View: SPC /SQC Control Charts used for cause removal
Deming Cycle – Repeatedly (Plan-Do-Check-Act).
Juran’s View: Fitness for the purpose. Quality is a result of intention
and
d actions,
ti I di t
Indicates th need
the d for
f ‘R
‘Requirements
i t Specs
S andd
process’
Ishikawa s View: Quality is beyond the quality of product;
Ishikawa’s
EVERYONE contributes to the quality of output
Slide 51
Quality Perspective
Phil Crosby’s defines Quality from the
“Producer’s” perspective, while Deming and
Juran define Quality from the End-customer’s
perspective.

Slide 52
Process Approach
Focuses upon defining, implementing, reviewing
and continually improving the processes in an
organization towards the aim of achieving higher
customer satisfaction and productivity.

Slide 53
Continual Improvement
Focus on Continual Improvement is a fundamental
principle
i i l off quality
lit managementt

Approach
pp oac to
o co
continuous
uous improvement
po e e iss bes
best
illustrated using the PDCA cycle, which was
developed in the 1930s by Dr.
Dr Shewhart of the Bell
System

Slide 54
Deming’s Wheel or PDCA

Act

DEMING Plan
Check
CYCLE

Do

Slide 55
Quality : Assurance & Control
QC is an activity that verifies whether or not the
product produced meets requirements and
standards

QA is
i an activity
ti it that
th t establishes
t bli h and
d evaluates
l t theth
processes that produce the products

Slide 56
QA versus QC
• Concentrates on the process • Concentrates on specific products
of producing the products
• Defect-Prevention based • Detection based
• Usually done throughout the y done after the p
• Usually product is
life cycle. built.
• Process oriented • Product oriented
• This is usually a staff function. • This is usually a line function.
• Organization level • Producers Responsibility
• Phase building activity • End phase activity
• Ex: Reviews and audits • Ex: Software testing

Slide 57
ISO 8402 Definitions
Quality
The totality of characteristics of an entity (product or service) that
bear on its ability to satisfy stated or implied needs.

Q alit Assurance
Quality Ass rance
All those planned and systematic actions necessary to provide
adequate confidence that a product or service will satisfy given
requirements for quality.

Quality Control
The operational techniques and activities that are used to fulfill
requirements for quality.

Slide 58
Verification and Validation
Quality Control activities are of two types,
verification
ifi ti andd validation
lid ti

IIncludes
l d technical
t h i l review,
i i
inspection,
ti walk-through,
lk th h
code review and program Testing

Slide 59
V&V
Verification is the process of evaluating the system or component to
determine whether the products of a given phase satisfy the
conditions imposed at the start of that phase.

Verification activities focus upon ensuring that the product is being

built right

Validation is the process of evaluating the system or component to

determine whether it satisfies requirements.

Validation activities focus upon ensuring that the right product is

built

Slide 60
Exercise - 1
Answer the following questions:
1. Q
Quality can be measured throughout the software
f
engineering process.
True (b) False

2. Cost of Quality includes

(a) Preventive Cost (b) Appraisal Cost (c) Failure Cost
(d) All of the above

Slide 61
Exercise - 2
3.Quality policy reflects the management’s commitment to
quality.
quality
(a) True (b) False

4. Every ISO 9000 certified organization should have a quality

policy.
(a) True (b) False

5. Which activity establishes and evaluates the

processes that produce the products

((a)) Qualityy Control ((b)) Qualityy Assurance

Slide 62
Exercise - 3
6. Match the following:

Quality Assurance Product Oriented

Quality control Top Management

PDCA Process Oriented

Q lit Policy
Quality P li D i
Deming

Quality Management Management Function

Slide 63
Exercises
1. Assume that you are working in the C-DAC Company. Your
firm has received a project from the Ministry of Defense,
Defense
Govt. of India. The defense ministry has decided to go in for
a new missile that is driven by software
software.
This is a foremost & matchless kind of missile that the
government is planning to develop.
develop In this case,
case which SDLC
model will be more appropriate? Why?

Slide 64
Exercises
2. Till now you are working on a legacy system in which you
were following "Waterfall Model".
Model" Now you are about to do
testing for a web-based system. How testing should go on in
this situation? State your opinions,
opinions views and approaches
and justify them.

Slide 65
Exercises
3. Consider a Commercial project with clear SRS which
should be completed within one month. Which is the best
development life cycle model you prefer? Why?

4. Consider a project where the user does not know exactly

what the software is supposed to do.
do You have to develop
the software as per the said SRS and enhancements might
be there in the future.
future Which life cycle model you prefer?
Why?

Slide 66
Exercises
5. Consider a project where the core of the requirements is known.
You have to develop the software within time and cost.
cost Which life
cycle you prefer? Why?
6 Consider a project where high risk is involved to develop.
6. develop Which
life cycle you prefer to develop this kind of project? Why?

Slide 67
ANY QUESTIONS?

Slide 68