slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
V – Model (Software Development) PowerPoint Presentation
Download Presentation
V – Model (Software Development)

Loading in 2 Seconds...

play fullscreen
1 / 14

V – Model (Software Development) - PowerPoint PPT Presentation


  • 224 Views
  • Uploaded on

V. V – Model (Software Development). By: Jaya Gupta Asnani. The V-Shaped Model. V-Model evolved from waterfall Model. Each phase must be completed before the next phase begins.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'V – Model (Software Development)' - brooks


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

V

V – Model (Software Development)

By: Jaya Gupta Asnani

slide2

The V-Shaped Model

  • V-Model evolved from waterfall Model.
  • Each phase must be completed before the next phase begins.
  • Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape.
  • Testing is emphasized in this model more than in the waterfall model.
  • It is a structured approach to testing.
  • Brings high quality into the development of our products.
slide3

Steps in the V-Shaped Model

Quality is guaranteed at each project stage.

slide4

Stage Containment

  • This term is used to identify problems existing in the product being developed before proceeding to the following stage.
  • More errors than defects.
  • Cost and effort for fixing problems is minimized.

Defect Origin

Detailed Design

Component Test

Assembly Test

Analyze

Design

Prod Test

Deploy

Defect Discovered

Detailed Design

Component Test

Assembly Test

Analyze

Design

Prod Test

Deploy

With Stage Containment

slide5

Without Stage Containment

  • More defects than errors.
  • Fixes become more expensive and difficult.

Defect Origin

Detailed Design

Component Test

Assembly Test

Analyze

Design

Prod Test

Deploy

Defect Discovered

Detailed Design

Component Test

Assembly Test

Analyze

Design

Prod Test

Deploy

slide6

Without Stage Containment

Defect Origin

Detailed Design

Component Test

Assembly Test

Analyze

Design

Prod Test

Deploy

Defect Discovered

Detailed Design

Component Test

Assembly Test

Analyze

Design

Prod Test

Deploy

Worst Case!

slide7

Entry and Exit Criteria

  • Entry Criteria
    • The Term Entry Criteria refers tot the input conditions required from the previous processes to support a specific stage.
  • Exit Criteria
    • The term Exit Criteria refers to the output conditions required by a specific process to determine its thoroughness and correct completion.
    • The Exit Criteria for one stage can constitute part of the Entry Criteria for the following stage.
slide9

Unit testing

  • The most ‘micro’ scale of Testing
  • A unit = smallest testable software component
    • Objects and methods
    • Procedures / functions
  • Performed by Programmer
    • A tester can help.
    • Requires detailed knowledge of the internal program design and code.
  • The units are tested in isolation.
  • Ensures the component is working according to the detailed design/build specifications of the module.
  • Not to be confused with debugging.
  • Also known as component, module, or program testing.
slide10

Integration Testing

  • Testing of more than one (tested) unit together to determine if they function correctly.
  • Focus on interfaces
    • Communication between units
  • It is done using the integration test design prepared during the architecture design phase.
  • Helps assembling incrementally a whole system, ensuring the correct ‘flow’ of data from the first through the final component.
  • Done by developers/designers and testers in collaboration
  • Also called Interface Testing or Assembly Testing.
slide11

System testing

  • Testing the system as a whole - Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
  • Ensures that system meets all functional and business requirements.
  • Focus
    • Verifying that specifications are met
    • Validating that the system can be used for the intended purpose
  • The system test design is derived from the system design documents and is used in this phase.
  • It can involve a number of specialized types of tests to check performance, stress, documentation etc. Sometimes testing is automated using testing tools.
  • Done by Independent testing group
slide12

Acceptance testing

  • To determine whether a system satisfies its acceptance criteria and business requirements or not.
  • Similar to System testing in that the whole system is checked, but the important difference is the change in focus.
  • Done by real business users.
  • It enables the customer to determine whether to accept the system or not.
  • Also called as Beta Testing, Application Testing or End User Testing.
  • Approach
    • Should be performed in real operating environment .
    • Customer should be able to perform any test based on their business processes.
    • Final Customer sign-off.
slide13

Benefits of V-Model

  • Faults are prevented and it stops fault multiplication.
  • Avoids the downward flow of defect.
  • Lower defect Resolution cost due to earlier detection.
  • Improved quality and reliability.
  • Reduction in the amount of Re-work.
  • Improved Risk Management
  • Validation and Verification at each level of stage containment
  • Allows testers to be active in the project early in the project’s lifecycle. They develop critical knowledge about the system.