1 .SDLCv1 - Ibm (1) .0

Learning & Knowledge Education - India
Software
Development
Life
Cycle
Table of Contents
Topic
Slide Number
What is SDLC
Overview of Life Cycle
SDLC Phase
7-8
Roles associated with SDLC Phases
SDLC with simple entry and exit gates
10
WaterFall Model
11-16
Spiral, Incremental Models
17
Incremental Model
18-22
Spiral Model
23-30
RAD
31-35
SDLC
Table of Contents
Topic
Slide Number
Evolutionary Model
36-41
V-Model
42-46
Agile SDLC
47-48
Extreme programming
49-52
FDD
53
DSDM
54-56
Adaptive SDLC
57-58
Tailored SDLC
59
Exercises
60-61
SDLC
Table of Contents
Topic
Slide Number
SDLC Phases
Planning
Analysis
Design
Build
Test
Quality Assurance
Summary
Exercise
SDLC
64
65-67
68-71
72-76
77--81
82-84
85-90
91-93
94
What is SDLC
The systems development life cycle (SDLC)
is a conceptual
model
used in project management
that describes the stages involved
in an information system development project,
from an initial feasibility
study
through maintenance of the completed application.
SDLC
Overview of SDLC Life Cycle

The life-cycle models have changed over time to reflect the changes in
customer group problems, perceptions of quality, and technologies
available.
Generally they have been described as development life cycles, but

some of them include or may be adapted to maintenance activities.
In some of the models we will see that these are performed once and in
others some or all the steps are repeated or broken down into sub
steps.
SDLC
SDLC Phases
Planning and Control
Input:
This Phase will produce a high-level
Identified Business Need
overview document of the proposed
project. It will contain information
Deliverables:
relating to the projects requirements
Project Charter
and will enable the formalization and
definition of the scope of the project .
Input:
This Phase of the SDLC is required to
understand and document the users'
needs for the system.
Requirement
Analysis
Project Charter
Deliverables:
Detailed System Analysis
This Phase of the SDLC continues from

the Detailed Requirement Analysis and
describes how the proposed system will
be built.
Design
Input:
Detailed System
Analysis
Deliverables:
Detailed System design
SDLC
SDLC Phases
Input:
This Phase addresses the
preparation and establishment
of the technical environment
for development.
Build
Detailed System Design

Deliverables:
System Build
Developer Guidelines
Application Forms and Reports

This Phase of the SDLC is to
prepare for and carry out the
implementation of the
developed system through
user and acceptance testing to
a full production system
Test
Input:
System Build
Deliverables:
User procedures
Test Plan
SDLC
Roles associated with various phases in SDLC

Planning & Control
Project Manager
Quality Reviewer
Lead Analyst
Business Requirement
Analyst
Lead Designer
System Analyst
Requirement Analysis
Architect
Designer
Design
SDLC
Lead Developer
Developer
Build
Lead Tester
System Tester
Integration Tester
Test
SDLC with simple entry, exit quality gates
10
SDLC
Waterfall Model
Requirement
Analysis
Design
Build
Test
11
SDLC
Big Bang Waterfall Model

A project may be run with a "big bang" approach.
All the work is delivered at one time;
At the start of the SDLC we can make a clear statement of what we
need.
Customer: "These are our requirements.

Manager: "I will need three analysts for 6 weeks, then five
designers for 10 weeks, then 15 programmers for 10 weeks, then
five testers for 6 weeks."
After the requirements sign-off, measurers, customers, and
supporters do not become involved again until testing.
12
SDLC
Phased Waterfall Model

In a project that has a "phased" approach, the work is grouped into
separate chunks and delivered at intervals perhaps by different teams.
The whole of a sector is delivered together as one project.

It is possible to divide a waterfall style into phases, which run in parallel,
provided that the work can be divided into distinct chunks, each being
smaller, more manageable miniprojects with its own team.
13
SDLC
Waterfall Strengths??
Ease of Use: Easy or difficult ?
Easy to understand, easy to use
Provides structure to inexperienced staff
Clarity on Milestones: Clear or not?

well understood
Importance is given to quality or schedule?

Works well when quality is more important than cost or
schedule
14
SDLC
Waterfall Deficiencies
Can new requirements be taken into consideration during the development
phase?
All requirements must be known upfront.
Can deliverables be subjected to change?

Deliverables created for each phase are considered frozen inhibits
flexibility.
Can the customer preview the system during the development phase?
Little opportunity for customer to preview the system (until it may be too
late)
15
SDLC
When to use the Waterfall Model

Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
16
SDLC
Spiral, Incremental Model

There is a large family of incremental and iterative models that were
developed from the 1980s onwards as a response to the problems of the
waterfall model.
These include increments in mini waterfalls and in iterative or spiral

models, as well as evolutionary models.
17
SDLC
Incremental Model Model

Release 3
Release 2
Test
Test
Release 1
Test
Build
Build
Build
Increment 2
Design
Design
Requirement
Requirement
Requirement
Analysis
Analysis
Analysis
Design
18
SDLC
Each release
delivers an
operational product
Incremental SDLC Model
Construct a partial implementation

of a total system
Then slowly add increased

functionality
The incremental model prioritizes

requirements of the system and
then implements them in groups.
Each subsequent release of the
system adds function to the

previous release, until all designed
functionality has been
implemented.
19
SDLC
Incremental Model Strengths ??

What are developed first?
Develop high-risk or major functions first
What does each release deliver?

Each release delivers an operational product
Can Customers use each build?

Customer can respond to each build
Is there any time constraint in product delivery?

Initial product delivery is faster
20
SDLC
Incremental Model Weaknesses ??

What is required early in this model?
Requires early definition of a complete and fully functional
system to allow for the definition of increments
How does this model deal with the cost of the complete system?
Total cost of the complete system is high.
21
SDLC
When to use the Incremental Model

Risk, funding, schedule, program complexity, or need for early realization of
benefits.
Most of the requirements are known up-front but are expected to evolve
over time
A need to get basic functionality to the market early

On projects which have lengthy development schedules
On a project with new technology
22
SDLC
Spiral Model
23
SDLC
Spiral Quadrant- Plan

Plan next phase
Typical activities
Develop project plan
Develop configuration management plan
Develop a test plan
Develop an installation plan
24
SDLC
Spiral Quadrant -Determine goal

Determine objectives, alternatives and constraints
Objectives: functionality, performance, hardware/software interface,
critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract, etc.
Constraints: cost, schedule, interface, etc.
25
SDLC
Spiral Quadrant- Risk Analysis

Evaluate alternatives, identify and resolve risks
Study alternatives relative to objectives and constraints
Identify risks (lack of experience, new technology, tight schedules,
poor process, etc.
Resolve risks (evaluate if money could be lost by continuing system
development
26
SDLC
Spiral Quadrant - Develop and Test

Develop next-level product
Typical activities:
Create a design
Review design
Develop code
Inspect code
Test product
27
SDLC
Spiral Model Strengths??

What is developed first?
Critical high-risk functions are developed first .
This model provides early indication of insurmountable risks,
without much cost.
How does the user benefit?

Users can be closely tied to all lifecycle steps.
Users see the system early because of rapid prototyping tools.
Early and frequent feedback from users.
28
SDLC
Spiral Model Weaknesses??

What is the impact of using Spiral Model fro small or low risk
Projects?
Time spent for evaluating risks too large for small or low-risk
projects
Time spent planning, resetting objectives, doing risk analysis
and prototyping may be excessive
Can Spiral Model be considered Simple?

The model is complex
Expertise is required in which area?

Risk assessment expertise is required
29
SDLC
When to use Spiral Model
30
When creation of a prototype is appropriate
Users are unsure of their needs
When costs and risk evaluation is important

For medium to high-risk projects
Long-term project commitment unwise because of potential changes to
economic priorities
Requirements are complex
New product line
Significant changes are expected (research and exploration)
SDLC
Rapid Application Model (RAD)

Rapid Application Development (RAD) is a software development
methodology that focuses on building applications in a very short
amount of time.
It was originally intended to describe a process of development that

involves application prototyping and iterative development .
31
SDLC
Core Elements of RAD

Prototyping/Demo
Iterative Development
Time Boxing
RAD tools (Erwin, CASE tools, Rational Rose, Visio)
32
SDLC
RAD Strengths??
What mainly gets reduced by using RAD model?
Reduced cycle time and improved productivity with fewer
people -means lower costs
How does customer involvement in the SDLC cycle help?

Customer is involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction and
business needs.
33
SDLC
RAD Weaknesses??
What is the risk associated with this model?
Due to time boxing, where features are pushed off to later
versions in favor of delivering an application in a short time
frame, RAD may produce applications that are less full
featured than traditionally developed applications.
What is the drawback of customer being involved in the

development cycle?
Developers and customers must be committed to rapid-fire
activities in an abbreviated time frame.
34
SDLC
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
35
SDLC
Evolutionary Model
We can see that the incremental, iterative, and spiral models all still
suffer from the problem of the length of time from the start of the SDLC
to delivery of software for use by the customers.
The evolutionary model was developed, because it helps to break down

the software into chunks that can be delivered earlier to the customer;
this means that the real-life problem is at least partly resolved more
quickly.
36
SDLC
Structured Evolutionary Prototyping Model

Developers build a prototype during the requirements phase
Prototype is evaluated by end users
Users give corrective feedback
Developers further refine the prototype
When the user is satisfied, the prototype code is brought up to the
standards needed for a final product.
37
SDLC
Structured Evolutionary Prototyping Steps
A preliminary project plan is developed

An partial high-level paper model is created
The model is source for a partial requirements specification
A prototype is built with basic and critical attributes
The designer builds
the database
user interface
algorithmic functions
The designer demonstrates the prototype, the user evaluates for

problems and suggests improvements.
This loop continues until the user is satisfied
38
SDLC
Structured Evolutionary Prototyping Strengths

How does Evolutionary Prototyping Help Customers and Developers?
Customers can see the system requirements as they are being
gathered
Developers learn from customers
How are new requirements dealt with?

Unexpected requirements accommodated
Allows for flexible design and development
How can additional needed functionality be identified?

Interaction with the prototype stimulates awareness of additional
needed functionality
39
SDLC
Structured Evolutionary Prototyping Weaknesses

What is risk involved with this model?
Overall maintainability may be overlooked.
Process may continue forever.
40
SDLC
V Model
Production and Maintenance
Requirement
System and Acceptance
Analysis
Test
High level Design
Integration Test
Low level Design
Unit & In Test
Build
41
SDLC
When to use
Structured Evolutionary 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.
42
SDLC
V-Shaped Steps
Project and Requirements Planning
allocate resources
Production, operation and
maintenance provide for

enhancement and corrections
System and acceptance testing
check the entire software system in

its environment
Product Requirements and
Specification Analysis complete

specification of the software system
Integration and Testing check that

modules interconnect correctly
Architecture or High-Level Design
defines how software functions fulfill

the design
Detailed Design develop
algorithms for each architectural

component
43
SDLC
Unit testing check that each

module acts as expected
Coding transform algorithms into

software
V-Shaped Strengths??
Which phase is more emphasized when using V Shaped Model?
Emphasize planning for verification and validation of the
product in early stages of product development
Each deliverable must be testable More Emphasis laid on the
Testing phase.
Ease of use?
Easy to use
44
SDLC
V-Shaped Weaknesses
Can V model handle concurrent events?
Does not easily handle concurrent events
Can V model handle dynamic changes in requirements?

Does not easily handle dynamic changes in requirements
Does V model contain risk analysis activities?

Does not contain risk analysis activities
45
SDLC
When to use the V-Shaped 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
46
SDLC
Agile SDLC
Speed up or bypass one or more life cycle phases
Usually less formal and reduced scope
Used for time-critical applications
Web application deveopment
Used in organizations that employ disciplined methods
47
SDLC
Few(out of 12) of the Agile Manifesto Principles
Welcome changing requirements, even late in development
Deliver working software quickly
48
The best architectures, requirements and designs emerge from selforganizing teams
. The most efficient and effective method of conveying information to
and within a development team is face-to-face communication
Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout
the project
Working software is the primary measure of progress.
SDLC
Agile Characteristics
Mostly agile practices are adaptive
Charactised by XP,scrum,lean s/w dev,Feature driven
devopement,crystal methodologies
Focus on collobarative deveopment rather than process

Less documentation
Customers/stakeholders, actively shape and guide the
complete evolution and end of the software product
service.
49
SDLC
Some Agile Methods
50
Adaptive Software Development (ASD)
Feature Driven Development (FDD)
User stories(an agile technique to capture product functionality)
Crystal Clear
Dynamic Software Development Method (DSDM)
Rapid Application Development (RAD)
Scrum
Extreme Programming (XP)
Rational Unify Process (RUP)
SDLC
Extreme Programming - XP
For small-to-medium-sized teams developing software with vague or
rapidly changing requirements
Coding is the key activity throughout a software project
Communication among teammates is done with code

Life cycle and behavior of complex objects defined in test cases again
in code
51
SDLC
XP Practices (1-6)
52
1.
Planning game determine scope of the next release by combining

business priorities and technical estimates
2.
Small releases put a simple system into production, then release new
versions in very short cycle
3.
Metaphor all development is guided by a simple shared story of how the

whole system works
4.
Simple design system is designed as simply as possible (extra

complexity removed as soon as found)
5.
Testing programmers continuously write unit tests; customers write tests

for features
6.
Refactoring programmers continuously restructure the system without

changing its behavior to remove duplication and simplify
SDLC
XP Practices (7 12)
53
7.
Pair-programming -- all production code is written with two programmers

at one machine
8.
Collective ownership anyone can change any code anywhere in the

system at any time.
9.
Continuous integration integrate and build the system many times a day
every time a task is completed.
10.
11.
40-hour week work no more than 40 hours a week as a rule
12.
Coding standards programmers write all code in accordance with rules

emphasizing communication through the code
On-site customer a user is on the team and available full-time to answer

questions
SDLC
XP is extreme because
Common sense practices taken to extreme levels
If code reviews are good, review code all the time (pair programming)
If testing is good, everybody will test all the time
If simplicity is good, keep the system in the simplest design that supports its
current functionality. (simplest thing that works)
If design is good, everybody will design daily (refactoring)

If architecture is important, everybody will work at defining and refining the
architecture (metaphor)
If integration testing is important, build and integrate test several times a day
(continuous integration)
If short iterations are good, make iterations really, really short (hours rather
than weeks)
54
SDLC
Feature Driven Design (FDD)

Five FDD process activities
1.
Develop an overall model Produce class and sequence diagrams from chief
architect meeting with domain experts and developers.
2.
Build a features list Identify all the features that support requirements. The
features are functionally decomposed into Business Activities steps within Subject
Areas.
Features are functions that can be developed in two weeks and expressed in
client terms with the template: <action> <result> <object>
3.
4.
5.
55
i.e. Calculate the total of a sale

Plan by feature -- the development staff plans the development sequence of
features
Design by feature -- the team produces sequence diagrams for the selected features
Build by feature the team writes and tests the code
SDLC
Dynamic Systems Development Method (DSDM)

Applies a framework for RAD and short time frames
Paradigm is the 80/20 rule

majority of the requirements can be delivered in a relatively short
amount of time.
56
SDLC
DSDM Principles
1.
2.
3.
4.
5.
6.
7.
8.
9.
57
Active user involvement imperative (Ambassador users)

DSDM teams empowered to make decisions
Focus on frequent product delivery
Product acceptance is fitness for business purpose
Iterative and incremental development - to converge on a solution
Requirements initially agreed at a high level
All changes made during development are reversible
Testing is integrated throughout the life cycle
Collaborative and co-operative approach among all stakeholders
essential
SDLC
DSDM Lifecycle
Feasibility study
Business study prioritized requirements
Functional model iteration
risk analysis
Time-box plan
Design and build iteration
Implementation
58
SDLC
Adaptive SDLC
Combines RAD with software engineering best practices
Project initiation
Adaptive cycle planning
Concurrent component engineering
Quality review
Final QA and release
59
SDLC
Adaptive Steps
1.
2.
3.
4.
5.
6.
7.
8.
60
Project initialization determine intent of project

Determine the project time-box (estimation duration of the project)
Determine the optimal number of cycles and the time-box for each
Write an objective statement for each cycle
Assign primary components to each cycle
Develop a project task list
Review the success of a cycle
Plan the next cycle
SDLC
Tailored SDLC Models

Any one model does not fit all projects
If there is nothing that fits a particular project, pick a model that comes
close and modify it for your needs.
Project should consider risk but complete spiral too much start with
spiral & pare it done
Project delivered in increments but there are serious reliability issues

combine incremental model with the V-shaped model
Each team must pick or customize a SDLC model to fit its project
61
SDLC
Limitations of Agile Principles

Poor documentation
Communication gap between Client and Developers
Improper Requirement Gathering and Tracking
Un synchronized code base
Live Demos and Technical reviews
No support for critical applications
Limited support for large software systems
Scalability & Transparency
62
SDLC
When to use Agile

Projects with aggressive deadlines, a high degree of
complexity, and a high degree of novelty (uniqueness) to
them
63
SDLC
Exercise
1. What are the key elements of the SDLC?
2. We involve the users in new project requests, but they complain that we
ask for too much information that they do not have or know. We don't
want to become too bureaucratic, but we need more complete
information and not half filled out forms. How can we effectively and
affordably fix or improve things
3. During a conversation with a colleague in another business unit, she
advised that they are moving away from flowcharts in favor of text
based instructions in table format. I asked what drove this decision. The
answer was that the users of the process found it easier to read a table
format instead of a flow diagram. Isn't there a risk in missing or getting
the process workflows wrong if you don't use a proper flowcharting tool?
64
SDLC
Exercise (contd.)
Cite the difference between the Waterfall, Spiral and VModel
Cite an example where a V Model would be preferable then the
Waterfall or Spiral Model
65
SDLC
SDLC Phases
The System Development Life Cycle (SDLC) is intended to provide a set
of guidelines for the successful completion of application development
projects. The SDLC consists of six distinct Phases .
Each Phase contains one or more individual deliverables associated with

the Phase. These deliverables are themselves described in separate
standards documents.
68
SDLC
Planning
Purpose:
This Phase of the SDLC is required to determine the feasibility of a
particular project proceeding, or not.
This Phase will produce a high-level overview document of the
proposed project.
Prerequisites:
Deliverables:
69
SDLC
Identified Business Need

Project Charter
Planning (Contd.)
Responsibility
Executive Management --Deliverable Approval
Project Manager --Assist as required
Development TeamNone
Business Analyst --Assist as required
User Team --Requirement Input
Quality Assurance --Standards QA
70
SDLC
Planning
Milestone:
Project Approval. A project must not proceed to the next Phase
without the appropriate authorization and approval.
71
SDLC
Planning
Additional Activities:
Depending on the specific requirements of the system project, certain
activities may need to be performed, after the completion and approval
of the Project Charter, but before the next Phase of the SDLC. These
are:
Selection of Development Team;
Selection and appointment of a qualified Project Manager;
Secured and allocated resources (funds, people, technology)
72
SDLC
Analysis
Purpose:
This Phase of the SDLC is required to understand and document the
users' needs for the system.
This Phase will document, in significantly more detail than the Project
Statement, the scope, business objectives and requirements of the
current/proposed system.
The emphasis throughout this Phase is on what the system will do.
During analysis and specification, the technical aspects and
constraints should be considered, but should not be influenced by
implementation characteristics. The technical aspects of the system
are addressed in the Design Phase.
73
SDLC
Analysis
Prerequisites:
Project Statement Approved.
Deliverables:
Detailed System Analysis.
74
SDLC
Analysis
Responsibility
Executive Management
--Monitor Progress
Project Sponsor
--Support the Process
Analyst
75
--Major Contributor
User Team
--Significant contribution
QA
-Analysis QA
SDLC
Analysis
Milestone:
Detailed System Analysis -- Approval and Sign-off
A project must not proceed to the next Phase without appropriate
deliverable approval and Sign-off.
Activity:
The Project Manager is responsible for producing the deliverables
associated with the Detailed System Analysis. However, the Project
Manager usually delegates this to the Business Analyst.
76
SDLC
Design
Purpose:
This Phase of the SDLC continues from the Detailed System Analysis
and describes how the proposed system will be built.
The Design is specific to the technical environment that the system will
operate in and the tools used in building the system. The results of this
Phase significantly impact the Build and Implementation Phases of the
system.
77
SDLC
Design
Prerequisites:
Detailed System Analysis -- Signed-off
Deliverables:
Detailed System Design.
78
SDLC
Design
Responsibility
Executive Management --Monitor Progress
Project Manager
Development Team
79
SDLC
--Quality Assurance
--Major Contributor
Design
Milestone:
Detailed System Design -- Approval and Sign-off.A project must not
proceed to the next Phase without appropriate deliverable approval
and Sign-off.
Activity:
associated with the Detailed System Design. However, the Project
Manager usually delegates responsibility for some or all of these
deliverables to the Development Team.
80
SDLC
Build
Build Application is the third
activity in the Application work
stream. Using the analysis and
design deliverables from the
previous two stages, you will
produce the detailed design, then
build and test the application
components.
81
SDLC
Build
This Phase of the SDLC deals with the development, unit testing and
integration testing of the application modules, screens and reports. In
addition, this Phase addresses the preparation and establishment of the
technical environment for development, testing and training of user
representatives.
This Phase is usually carried out in parallel with the development of user
procedures and user documentation from the Implementation Phase.
Both of these will be required for module testing, upon the completion of
the Build Phase.
82
SDLC
Build
Prerequisites:
Detailed System Design -- Signed-off.
Deliverables:
System Build.
Developer Guidelines.
Application Forms and Reports.
83
SDLC
Build
Responsibilities
Executive Management -- Monitor Progress
Development Team -- Major Contributor
84
SDLC
Build
Milestone:
System Build -- Approval and Sign-off.
Some activities in this Phase may be conducted in parallel with
activities of the Module Testing Phase.
85
SDLC
Test
Using the deliverables (integrated components from the previous
stages), this stage prepares and executes assembly, product,
performance and UAT of the application components.
This Phase of the SDLC is to prepare for and carry out the
implementation of the developed system through user and acceptance
testing to a full production system.
86
SDLC
Test
Prerequisites:
System Build -- Sign-off.
Deliverables:
87
User Procedures
On-Line Help
Test Plan
User Training Plan.
Application Migration Plan.
Implementation Plan
.Internet Deployment Plan (as appropriate)
.Production Sign-off.
SDLC
Test
associated with the Implementation Phase. However, the Project
Manager usually delegates responsibility for some or all of these
deliverables to the Development Team.
The Project Manager will provide initial Quality Assurance of the

deliverables prior to review by QA team.
88
SDLC
Quality Assurance
Quality Assurance
The Quality Assurance (QA) role is the role responsible for
guaranteeing a level of quality for the end client, and to help the
software development team to identify problems early in the process.
It is not surprising that people in this role are often known as "testers".
Of course, the role is more than just testing. It's about contributing to
the quality of the final product .
89
SDLC
Quality Assurance Role

The quality assurance (QA) role is one that is focused on creating a
quality deliverable.
In other words, it is the responsibility of the QA role to make sure that

the software development process doesn't sacrifice quality in the name
of completed objectives.
90
SDLC

The QA role works with the Functional Analyst (FA) and the Solutions
Architect (SA) to convert the requirements and design documents into a

set of testing cases and scripts, which can be used to verify that the
system meets the client needs.
This collection of test cases and scripts are collectively referred to as a

test plan. The test plan document itself is often simple providing an
overview of each of the test cases.
The testing cases and scripts are also used to validate that there are no
unexplained errors in the system
91
SDLC

The test plan is approved by the Subject Matter Experts (SMEs) and
represents the criteria to reach a project closing.
If the test cases and scripts in the test plan are the agreed upon
acceptance criteria for a project then all that is necessary is for project
closure is to demonstrate that all of the testing cases and scripts have
been executed successfully with passing results.
92
SDLC

What is a Test Case
A test case is a general-purpose statement that maps to one or more
requirements and design points. It is the overall item being tested. It
may be a specific usability feature, or a technical feature that was
supposed to be implemented as a part of the project
Test scripts fit into the test cases by validating that case. Test scripts
are step-by-step instructions on what to do, what to look for, and what
should happen. While the test cases can be created with nearly no
input from the architecture or design, the test scripts are specific to
how the problem was solved by the software development team and
therefore they require an understanding of not only the requirements,
but also the architecture, design, and detailed design.
93
SDLC

The quality assurance role is split into three parts:
First
The role creates test cases and scripts.
Second
The role executes or supervises the execution of those test cases and
scripts.
Third
The role facilitates or performs random testing of all components to
ensure that there's not a random bug haunting the system.
94
SDLC
Summary
SDLC models are tools that allow the development team to correctly follow the
SDLC steps to create software that meets a business need.
The SDLC models have evolved as new technology and new research have
addressed weaknesses of older models. Ideas have been borrowed and adapted
between the various models.
The Various types of Models are:

Waterfall
Spiral
Incremental
Evolutionary
RAD
V Model
95
SDLC
Summary
The Different Phases of SDLC are
Planning
Analysis
Design
Build
Test
Quality the degree to which the software satisfies stated and implied
requirements
Absence of system crashes

Correspondence between the software and the users expectations
Performance to specified requirements
96
SDLC
Summary
Quality must be controlled because it lowers production speed,
increases maintenance costs and can adversely affect business
97
SDLC
Exercise
1. How many test cases can you write for a login page scenario?
2. Knowledge Buzz library has a huge collection of books and has
branches all over India. Lending of Books , membership creation,
withdrawal of membership, etc is done manually at present. Knowledge
Buzz requires a software which could be accessed by any of the
clients in India, membership should be created online or manual,
scanning of books be done online, booking of books should be done
online, withdrawal of membership should be done online.
98
Define a proper SDLC for the above mentioned application
SDLC

1 .SDLCv1 - Ibm (1) .0

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1 .SDLCv1 - Ibm (1) .0

Enviado por

Direitos autorais:

Formatos disponíveis

Learning & Knowledge Education - India

Learning & Knowledge Education - India

Overview of Life Cycle

Roles associated with SDLC Phases

SDLC with simple entry and exit gates

Spiral, Incremental Models

Learning & Knowledge Education - India

Learning & Knowledge Education - India

Learning & Knowledge Education - India

through maintenance of the completed application.

Learning & Knowledge Education - India

Overview of SDLC Life Cycle

Generally they have been described as development life cycles, but

Learning & Knowledge Education - India

This Phase of the SDLC continues from

Learning & Knowledge Education - India

Detailed System Design

Application Forms and Reports

Learning & Knowledge Education - India

Roles associated with various phases in SDLC

Learning & Knowledge Education - India

SDLC with simple entry, exit quality gates

Learning & Knowledge Education - India

Learning & Knowledge Education - India

Big Bang Waterfall Model

Customer: "These are our requirements.

Learning & Knowledge Education - India

Phased Waterfall Model

separate chunks and delivered at intervals perhaps by different teams.

The whole of a sector is delivered together as one project.

Learning & Knowledge Education - India

Clarity on Milestones: Clear or not?

Importance is given to quality or schedule?

Learning & Knowledge Education - India

All requirements must be known upfront.

Can deliverables be subjected to change?

Learning & Knowledge Education - India

When to use the Waterfall Model

Learning & Knowledge Education - India

Spiral, Incremental Model

These include increments in mini waterfalls and in iterative or spiral

Learning & Knowledge Education - India

Incremental Model Model

Planning and Control

Learning & Knowledge Education - India

Incremental SDLC Model

Construct a partial implementation

Then slowly add increased

The incremental model prioritizes

Each subsequent release of the

system adds function to the

Learning & Knowledge Education - India

Incremental Model Strengths ??

What does each release deliver?

Can Customers use each build?

Is there any time constraint in product delivery?

Learning & Knowledge Education - India

Incremental Model Weaknesses ??

Learning & Knowledge Education - India

When to use the Incremental Model

A need to get basic functionality to the market early

Learning & Knowledge Education - India

Learning & Knowledge Education - India