SOFTWARE DEVELOPMENT LIFE CYCLE

• There are a number of different models for software development

lifecycles.
• One thing which all models have in common is that at some point in the
lifecycle, software has to be tested.
• This session outlines some of the more commonly used SDLCs, with
particular emphasis on the testing activities in each model.
• Traditionally, the models used for the software development lifecycle
progress through a number of well defined phases.
• They are:
• Requirements
• Design
• Coding
• Testing
• Installation, Operation and maintenance

SDLC models Advantages & disadvantages

Advantages of Waterfall Model

1. Clear project objectives.
2. Stable project requirements.

3. Progress of system is measurable.

4. Strict sign-off requirements.

Disadvantages of Waterfall Model

1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes

Advantages of Spiral Model

1. Avoidance of Risk is enhanced.
2. Strong approval and documentation control.
3. Implementation has priority over functionality.
4. Additional Functionality can be added at a later date.

Disadvantages of Spiral Model

1. Highly customized limiting re-usability
2. Applied differently for each application
3. Risk of not meeting budget or schedule
4. Possibility to end up implemented as the Waterfall framework

Advantages of Prototype model

1. Strong Dialogue between users and developers
2. Missing functionality can be identified easily
3. Confusing or difficult functions can be identified
4. Requirements validation, Quick implementation of, incomplete, but
functional, application
5. May generate specifications for a production application
6. Environment to resolve unclear objectives
7. Encourages innovation and flexible designs

Disadvantages of Prototype model

1. Contract may be awarded without rigorous evaluation of Prototype
2. Identifying non-functional elements difficult to document
3. Incomplete application may cause application not to be used as the
full system was designed
4. Incomplete or inadequate problem analysis
5. Client may be unknowledgeable
6. Approval process and requirement is not strict
7. Requirements may frequently change significantly

Software Development Life Cycle

Objectives
This tutorial consists of:
•Principles and Concepts of Software Development.
•What is software ?
•What are software characteristics ?
•What are the phases of software development and building test efforts
into every phase at critical points.
•Models of Software Development Life Cycle (SDLC).
•Understand the importance of adopting a life cycle approach to testing
process.

What is Software
Software is:
•Instructions (computer programs) which when executed, provide desired function
and performance.
•Data structures that help the program to adequately manipulate information.
•Documents that describe the operation and use of the programs.
Principles and Concept of Testing
What are software characteristics?
•Software is logical unlike hardware, which is physical (contains chips, circuit
boards, power supplies etc.,) Hence its characteristics are entirely different.
•Software is developed and not manufactured.
•Software does not “wear out” …as do hardware components, from dust, abuse,
temperature and other environmental factors. Hence its failure curve is
idealized.
•Although industry is moving towards component-based assembly, most systems
continue to be custom built.
•A software component should be built such that it can be reused in many
different programs.

Software Development Life Cycle

What is the 'software life cycle'?
•Various activities which are undertaken when developing software.
•The life cycle begins when an application is first conceived and ends with the
formal validation of the software against requirements.
•It includes aspects such as initial concept, requirements analysis, functional
design, internal design, documentation planning, test planning, coding, document
preparation, integration, testing, maintenance, updates, retesting, phase-out, and
other aspects.

Software Development Life Cycle

•There are a number of different models for software development lifecycles.
•One thing which all models have in common, is that at some point in the
lifecycle, software has to be tested.
•This session outlines some of the more commonly used SDLCs, with particular
emphasis on the testing activities in each model.
•Traditionally, the models used for the software development lifecycle progress
through a number of well defined phases.
•They are:
–Requirements
–Design
–Coding
–Testing
–Installation, Operation and maintenance

Software Development Life Cycle

What are the four components of the Software Development Process?
•a. Plan
•b. Do
•c. Check
•d. Act
Phases of SDLC
Phases of SDLC
Problems in Software development process
What are common problems in the software development
process?

–Poor requirements
–Unrealistic Schedule
–Inadequate testing
–Features
–Miscommunication
Solutions
What are common solutions to software development problems?

–Solid requirements
–Realistic Schedules
–Adequate testing –
–Stick to initial requirements as much as possible
–Communication
Life Cycle Testing
•Life Cycle Testing means perform testing in parallel with systems development.
•While the system being developed, a test plan and test conditions are developed
and executed.
•At predetermined points during the life cycle, the system is tested to ensure that
it is being developed properly and the defects are detected at the earliest possible
points of the life cycle.

Life Cycle testing Concept

•Life cycle testing involves continuous testing of the system during the
development process.
•At the predetermined points, the results of the development process are
inspected to determine the correctness of the implementation.
•These inspections identify the defects at the earliest possible points.
•Test early and prevent defect migration.

Life Cycle testing-Role of Testers

Concept Phase
•Evaluate Concept Document,
•Learn as much as possible about the product and project
•Analyze Hardware/software Requirements,
•Strategic Planning
Requirement Phase
•Analyze the Requirements
•Verify the Requirements using the review methods.
•Prepare Test Plan
•Identify and develop requirement based test cases

Life Cycle testing-Role of Testers

Design Phase,
•Analyze design specifications
•Verify design specifications
•Identify and develop Function based test cases
•Begin performing Usability Tests
Coding Phase
•Analyze the code
•Verify the code
•Code Coverage
•Unit test
Life Cycle testing-Role of Testers
Integration & Test Phase
•Integration Test
•Function Test
•System Test
•Performance Test
•Review user manuals
Operation/Maintenance Phase
•Monitor Acceptance Test
•Develop new validation tests for confirming problems

SDLC
Software is developed based on specific process models, which are chosen
–Based on the nature of the project, methods and tools to be used.
–Controls and deliverables required.
Few of the models are:
–Waterfall Model
–V – Model
–Spiral Model
–Progressive Development Life Cycle
–Iterative Life Cycle models
Sequential SDLC models
•The sequential phases are usually represented by a V or waterfall diagram.
•There are many variations of V and waterfall lifecycle models, introducing
different phases to the lifecycle and creating different boundaries between
phases.

Water Fall Method

In this model the application is developed as a series of sequential steps.
Here the project is broken into series of increments, each of which delivers
a portion of the functionality of the overall project.

Water Fall Method

•Describes a process of stepwise refinement.
•Takes a static view of requirements.
•Unrealistic separation of specification from design.
•Very rigid, doesn’t accommodate prototyping, reuse, etc.
•Advantages/Disadvantages:
–Most-widely used process model.
–Controls schedules,budgets & documentation.
–Tends to favor well-understood system aspects over poorly understood system
components.
–Does not detect development areas behind schedule early in the life cycle
stages.
V-Model
–The V-model is an internationally recognized development standard for IT
systems.
–It uniformly and bindingly lays down what has to be done, how the tasks are to
be performed and what is to be used to carry this out.
–This model is based on observation of respective tests at each phase of
development.
V-Model

•G VV
V Model

V-Model Testing
Spiral Model
Progressive SDLC model
Progressive SDLC model
•Progressive model used for reasons, such as volatility of requirements, or a need
for an interim system with reduced functionality when long timescales are
involved.
•Solution to form a compromise between timescales and functionality, providing
"interim" deliveries of software, with reduced functionality, but serving as a
stepping stones towards the fully functional software.
•Stepping stone approach as a means of reducing risk.
•Each individual phase of development follows its own SDLC,typically using a V or
waterfall model. The actual number of phases will depend upon the development.

Progressive SDLC model

•Each delivery of software to pass acceptance testing to verify the software fulfils
the relevant parts of the overall requirements.
•The testing and integration of each phase requires time and effort.
•Hence,increase in the number of development phases actually becomes counter
productive.
•Consequently,increased cost and timescale, which will have to be weighed
carefully against the need for an early solution.

Iterative model
•An Iterative lifecycle model does not attempt to start with a full specification of
requirements.
•Development begins by specifying and implementing just part of the software,
which is then reviewed in order to identify further requirements.
•Above process repeated, producing a new version of the software for each cycle
of the model.
•Consists of repeating the following four phases in sequence.
–Requirements phase-Requirements are gathered and analyzed.

Iterative model
–Design phase-Solution to meet the requirements is designed. May be a new
design or an extension of an earlier design.
–Implementation and Test phase-Software coded, integrated and tested.
–Review phase-Software evaluated, current requirements reviewed and
changes and additions to requirements proposed
Decision as to software produced by the cycle will be discarded, or kept as
a starting point for the next cycle
Key to successful is rigorous validation of requirements and verification
(including testing).
Iterative model
Maintenance phase
•Successfully developed software eventually becomes part of a product and enter
a maintenance phase.
•During Maintenance phase software undergoes modification to correct errors
and to comply with changes to requirements.
•Like initial development, modifications also follow a development lifecycle, but
not necessarily using the same lifecycle model as the initial development.
•Throughout maintenance phase, software tests have to be repeated, modified
and extended.

Maintenance phase
•Effort to revise and repeat tests consequently forms a major part of the overall
costs of developing and maintaining software.
•Regression testing used for repetition of earlier successful tests to make sure
that changes to software have not introduced side effects.

Summary and Conclusion

•Irrespective of lifecycle model used for software development, software has to be
tested.
•Efficiency and quality are best served by testing software as early in the lifecycle
as practical, with full regression testing whenever changes are made.
•Such practices become even more critical with progressive development and
iterative lifecycle models
•Regression testing is a major part of software maintenance.
•The ease with which tests can be repeated has a major influence on the cost of
maintaining software.

•A common mistake in the management of software development is to start by

badly managing a development within a V or waterfall lifecycle model, which then
degenerates into an uncontrolled iterative model. This is another situation which
we have all seen causing a software development to go wrong.

Thank you

S U N D A Y, N O V E M B E R 2 1 , 2 0 0 4
SDLC models Advantages & disadvantages
SDLC models Advantages & disadvantages

Advantages of Waterfall Model

1. Clear project objectives.
2. Stable project requirements.
3. Progress of system is measurable.
4. Strict sign-off requirements.

Disadvantages of Waterfall Model

1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes

Advantages of Spiral Model

1. Avoidance of Risk is enhanced.
2. Strong approval and documentation control.
3. Implementation has priority over functionality.
4. Additional Functionality can be added at a later date.

Disadvantages of Spiral Model

1. Highly customized limiting re-usability
2. Applied differently for each application
3. Risk of not meeting budget or schedule
4. Possibility to end up implemented as the Waterfall framework

Advantages of Prototype model

1. Strong Dialogue between users and developers
2. Missing functionality can be identified easily
3. Confusing or difficult functions can be identified
4. Requirements validation, Quick implementation of, incomplete, but
functional, application
5. May generate specifications for a production application
6. Environment to resolve unclear objectives
7. Encourages innovation and flexible designs

Disadvantages of Prototype model

1. Contract may be awarded without rigorous evaluation of Prototype
2. Identifying non-functional elements difficult to document
3. Incomplete application may cause application not to be used as the
full system was designed
4. Incomplete or inadequate problem analysis
5. Client may be unknowledgeable
6. Approval process and requirement is not strict
7. Requirements may frequently change significantly
• Software Test Life Cycle
• Objectives
• This tutorial consists of:
• The software testing life cycle
• The various activities involved in the testing process.
•
• STLC
• Software testing is a comprehensive activity, as there are numerous types
of software requiring specific testing techniques.
• To manage testing successfully, apart from technological skill, one needs
management system to handle large number of entities, their internal
relationships, testing process and personnel for testing and managing
other stake holders in software development.
• Cost of building and correcting defects may far exceed the cost of
detecting the defects.The method to reduce cost of defects is locate
defects early.
• This involves beginning testing early during the requirement phase and
continuing testing thru’ out the life cycle.
• Testing Process
• Testing process
• The test development life cycle contains the following
components/steps:
• System study-Assess development plan and status
• Collect SFS/SRS
• Develop Test plan
• Building strategies-How to test?
• Design test cases
• Tests specifications
• Execute tests
• Evaluate tests
• Evaluate results
•
•
• Testing process
• Acceptance test
• Report test results
• Evaluate test effectiveness
• Document results(defect reports, summary reports)
• Collect matrix
• Testing strategy
• Building Strategies/SW Testing Strategy
• A strategy for SW testing integrates SW test case design methods into a
well-planned series of steps that result in the successful construction of
SW.
• Testing begins at the module level and works outward toward the
integration of the entire computer-based system.
• Different testing techniques are appropriate at different points in time.
• Testing and debugging are different activities, but debugging must be
accommodated in any testing strategy.
•
• Test specification
• Test case specifications is developed from the test plan and are the second
phase of the test development life cycle.
• Test specification explains "how" to implement the test cases described in
the test plan.
• Each test specification should contain the following items:
• Case No
• Title
• Program Name
• Author
• Date
• Background(Objectives, Assumptions, References, Success Criteria)
• Expected Error(s)
• Reference(s)
Data
• Script
• Test Documentation
• Test documentation is a required tool for managing and maintaining the
testing process.
• Documents produced by testers should answer the following questions:
• What to test? Test Plan
• How to test? Test Specification
• What are the results? Test Results Analysis
• Test Evaluation
• The Test Results Analysis or Evaluation Report is an analysis of the results
of running tests.
• The results analysis provide management and the development team with
a readout of the product quality.
• Using defects for Process improvement.
• The following sections should be included in the results analysis:
• Management Summary
• Test Results Analysis
• Test Logs/Traces
•
•
•
• Why Testing process
•
• Operability- It operates cleanly
• Observability- The results are easy to see
• Controllability- Processing can be controlled
• Decomposability- Testing can be targeted
• Simplicity- No complex architecture and logic
• Stability- Few changes are requested during testing
• Understandability – Test design is well understood
• Thank you
• .
Integration Testing

integration testing
Integration tests are performed when new code is added to an
existing code base; for example, when a new function is
added to a set of existing functions. Integration tests measure
whether the new code works -- integrates -- with the existing
code; these tests look for data input and output, correct
handling of variables, etc.
Integration level tests verify proper execution of application components and do not
require that the application under test interface with other applications.
Communication between modules within the sub-system is tested in a controlled and
isolated environment within the project.

Objectives • To technically verify proper interfacing

between modules, and within sub-systems
When • After modules are unit tested
Input • Internal & External Application Design
• Master Test Plan
• Integration Test Plan
Output • Integration Test report
Who • Developers
Methods • White and Black Box techniques
• Problem / Configuration Management
Tools • Debug
• Re-structure
• Code Analyzers
Education • Testing Methodology
• Effective use of tools
 Systems Integration Testing
Systems Integration testing is a test level which verifies the integration of all
applications, including interfaces internal and external to the organization, with their
hardware, software and infrastructure components in a production-like environment.

Objectives • To test the co-existence of products and

applications that are required to perform
together in the production-like operational
environment (hardware, software, network)
• To ensure that the system functions together
with all the components of its environment as
a total system
• To ensure that the system releases can be
deployed in the current environment
When • After system testing
• Often performed outside of project life-cycle
Input • Test Strategy
• Master Test Plan
• Systems Integration Test Plan
Output • Systems Integration Test report
Who • System Testers
Methods • White and Black Box techniques
• Problem / Configuration Management
Tools • Recommended set of tools
Education • Testing Methodology
• Effective use of tools
 Regression Testing
Description
Regression testing verifies that no unwanted changes were introduced to one part of
the system as a result of making changes to another part of the system.
To perform a regression test, the application must be run through the same test
scenario at least twice. The first test is run when your application or a specific part of
your application is responding correctly. Your application's responses to the first test
serve as a base against which you can compare later responses. The second test is run
after you make changes to the application. The application responses are compared
for both executions of the same test cases.
The results of comparison can be used to document and analyze the differences. By
analyzing the differences between two executions of the same test cases, you can
determine if your application's responses have changed unexpectedly.
Regression testing should always be used by the developer during Unit testing and, in
conjunction with a Change Management discipline, will help prevent code changes
being lost or being overwritten by subsequent changes. A last regression test should
be done as the final act of System Testing, once all the function is stabilized and
further changes are not expected.
Objectives
The objectives are to ensure or verify that:
• The test unit or system continues to function correctly after changes have been made
• Later changes do not affect previous system functions

Examples
• Final test a group of changes by executing a regression test run as the last System Test
• Reusing accumulated test cases to re-unit-test a module each time an incremental
change is coded

regression testing
The term "regression testing" can be applied two ways. First,
when a code problem has been fixed, a regression test runs
tests to verify that the defect is in fact fixed; "Imagine finding
an error, fixing it, and repeating the test that exposed the
problem in the first place. This is a regresson test" (Kaner in
Testing Computer Software). Second, regression testing is
the counterpart of integration testing: when new code is
added to existing code, regression testing verifies that the
existing code continues to work correctly, whereas integration
testing verifies that the new code works as expected.
regression testing can describes the process of testing new
code to verify that this new code hasn't broken any old code.