Sdlc & Models

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

•

Debug

•

Re-structure

•

Code Analyzers

•

Testing Methodology

•

Effective use of tools

Tools

Education

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

•

After system testing

•

Often performed outside of project life-cycle

•

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

When Input

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.