V model final


Published on

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • AHEAD TEAM © copyright 2013
  • AHEAD TEAM © copyright 2013
  • AHEAD TEAM © copyright 2013 AHEAD TEAM © copyright 2013
  • V model final

    1. 1. AHEAD TEAM 1 AHEADTEAM©copyright2013  ShravanKumar  Sowmya  Alekhya  Saisuhas Reddy(TL)  Anusha
    2. 2. V – MODEL (SOFTWARE DEVELOPMENT) 2 AHEADTEAM©copyright2013
    3. 3. HISTORY OF V-MODEL  Defined by the late Paul Rook in 1980’s.  To improve the efficiency and effectiveness of software development.  Accepted in Europe and UK as an alternative to Waterfall model. 3 AHEADTEAM©copyright2013
    4. 4. • Evolved from waterfall Model. • Completion of each phase before the next phase begins. •Instead of moving in a linear way, process steps are bent upwards. • Emphasizing on testing is more when compared with the waterfall model. • Structured approach to testing. • High quality development of products can be guaranteed. THE V SHAPED MODEL 4 AHEADTEAM©copyright2013
    5. 5. STEPS IN V-SHAPED MODEL Quality is guaranteed at each project stage. 5 AHEADTEAM©copyright2013
    6. 6. ENTRY AND EXIT CRITERIA Entry Criteria Set of generic and specific conditions for permitting a process to go forward with a defined task. 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. 6 AHEADTEAM©copyright2013
    7. 7. Unit testing  The most ‘micro’ scale of Testing 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. 7 AHEADTEAM©copyright2013
    8. 8. Integration Testing  Testing of more than one (tested) unit together to determine if they function correctly. 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. 8 AHEADTEAM©copyright2013
    9. 9. 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 9 AHEADTEAM©copyright2013
    10. 10. 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. 10 AHEADTEAM©copyright2013
    11. 11. • Fault multiplication can be reduced. • Improved quality and reliability. • Reduction in the amount of Re-work. • Improved Risk Management • Validation and Verification at each level of stage containment • Developing critical knowledge and confidence in the initial stages. BENEFITS 11 AHEADTEAM©copyright2013
    12. 12. DISADVANTAGES  Lot of money and resources are required.  Very rigid and less flexible.  Suitable for long term / large projects.  Ignorance of any of the test phases may lead to poor quality.  No software prototype available.  Any modifications, then the test documents along with requirement documents has to be updated. 12 AHEADTEAM©copyright2013
    13. 13. 13 AHEADTEAM©copyright2013
    14. 14. 14 AHEADTEAM©copyright2013