The document outlines the Software Development Life Cycle (SDLC) including its phases, models (such as Waterfall, Spiral, and V-Model), and the importance of quality assurance in software development. It emphasizes the need for structured processes to ensure high-quality software that meets customer expectations while addressing the potential risks and challenges associated with various SDLC models. The content also covers aspects of requirements specification, design, coding, testing, implementation, and maintenance.

1. Quality Assurance /
Software Testing Training
SDLC

2. Page 2Classification: Restricted
Agenda
• SDLC and Quality Standard
• What is SDLC and Stages
• Phases of SDLC
• SDLC Models

3. Page 3Classification: Restricted
• What is SDLC and Stages
• SDLC Models
• Waterfall Model
• V-Model
• Spiral Model
• Agile Model and Testing
• Quality Standard
• ISO(9001,14001,27001)
• SEI-CMMI
-- Level 1 – Performed
-- Level 2 – Managed
-- Level 3 – Defined
-- Level 4 -Quantitatively Managed
-- Level 5-Optimizing
• IEEE
• Class Assignment
Module 2 – SDLC and Quality Standard

4. Page 4Classification: Restricted
What is SDLC and Stages
Software Development Life Cycle(SDLC)
SDLC, Software Development Life Cycle is a process used by software
industry to design, develop and test high quality software. The SDLC aims
to produce a high quality software that meets or exceeds customer
expectations, reaches completion within times and cost estimates
The software development life cycle (SDLC) is a framework defining tasks
performed at each step in the software development process.

5. Page 5Classification: Restricted
Phases of SDLC
•
• Requirement Specification and
• Analysis
• Design
• Coding
• Testing
• Implementation
• Maintenance

6. Page 6Classification: Restricted
6

7. Page 7Classification: Restricted
Requirement
Specification
and Analysis
User Requirement
Specification (USR)
Software
Requirement
Specification (SRS)

8. Page 8Classification: Restricted
Design
The output of SRS is the input of design phase.
Two types of design -
High Level Design (HLD)
Low Level Design (LLD)
.

9. Page 9Classification: Restricted
• High Level Design (HLD)
• List of modules and a brief description of each module.
• Brief functionality of each module.
• Interface relationship among modules.
• Dependencies between modules (if A exists, B exists etc).
• Database tables identified along with key elements.
• Overall architecture diagrams along with technology details.
• Low Level Design(LLD)
• Detailed functional logic of the module, in pseudo code.
• Database tables, with all elements, including their type and
size.
• All interface details.
• All dependency issues
• Error message listings
• Complete input and outputs for a module.

10. Page 10Classification: Restricted
Coding
Developers use the LLD document and write the code in the
programming language specified.
Testing
The testing process involves development of a test plan,
executing the plan and documenting the test results.
Implementation
Installation of the product in its operational environment.

11. Page 11Classification: Restricted
Maintenance
After the software is released and the client starts using the software,
maintenance phase is started.
3 things happen - Bug fixing, Upgrade, Enhancement
Bug fixing – bugs arrived due to some untested scenarios.
Upgrade – Upgrading the application to the newer versions of the
Software
Enhancement - Adding some new features into the existing software.

12. Page 12Classification: Restricted
SDLC Models
Waterfall Model
Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall" approach,
the whole process of software development is divided into separate
phases.
In Waterfall model, typically, the outcome of one phase acts as the input
for the next phase sequentially.

13. Page 13Classification: Restricted

14. Page 14Classification: Restricted
• System is well documented.
• Phases correspond with project management phases.
• Cost and schedule estimates may be lower and more
accurate.
• Details can be addressed with more engineering effort if
software is large or complex.
Waterfall Approach - Advantages

15. Page 15Classification: Restricted
• All risks must be dealt with in a single software development effort.
• Because the model is sequential, there is only local feedback at the
transition between phases.
• A working product is not available until late in the project.
• Progress and success are not observable until the later stages. If a mistake
or deficiency exists in the documentation of earlier phases, it may not be
discovered until the product is delivered.
• Corrections must often wait for the maintenance phase.
Application
The Waterfall model can be successfully used when requirements are well
understood in the beginning and are not expected to change or evolve over
the life of the project. Project risks should be relatively low.
Waterfall Approach - Disadvantages

16. Page 16Classification: Restricted
Spiral Model
The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.
• Identification: This phase starts with gathering the business requirements in the
baseline spiral. In the subsequent spirals as the product matures, identification of
system requirements, subsystem requirements and unit requirements are all done
in this phase.
• Design: Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design and
final design in the subsequent spirals.
• Construct or Build: Construct phase refers to production of the actual software
product at every spiral. In the baseline spiral when the product is just thought of
and the design is being developed a POC (Proof of Concept) is developed in this
phase to get customer feedback.
• Then in the subsequent spirals with higher clarity on requirements and design
details a working model of the software called build is produced with a version
number. These builds are sent to customer for feedback.
• Evaluation and Risk Analysis :Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage
and cost overrun. After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.

17. Page 17Classification: Restricted

18. Page 18Classification: Restricted
V-Model
Under V-Model, the corresponding testing phase of the development phase
is planned in parallel. So there are Verification phases on one side of the .V.
and Validation phases on the other side. Coding phase joins the two sides
of the V-Model.

19. Page 19Classification: Restricted
Big Bang Model
• Big bang model comprises of focusing all the possible resources in software
development and coding, with very little or no planning. The requirements
are understood and implemented as they come. Any changes required may
or may not need to revamp the complete software.
• This model is ideal for small projects with one or two developers working
together and is also useful for academic or practice projects. It.s an ideal
model for the product where requirements are not well understood and
the final release date is not given
Pros
Cons
•This is a very simple model
•Little or no planning required
•Easy to manage
•Very few resources required
•Gives flexibility to developers
•Is a good learning aid for new comers or
students
•Very High risk and uncertainty.
•Not a good model for complex and object-
oriented projects.
•Poor model for long and ongoing projects.
•Can turn out to be very expensive if
requirements are misunderstood

20. Page 20Classification: Restricted
Question?

21. Page 21Classification: Restricted
Thank You