V model final

14
AHEAD TEAM 1 A H E A D T E A M © c o p y r i g h t 2 0 1 3 ShravanKumar Sowmya Alekhya Saisuhas Reddy(TL) Anusha

description

 

Transcript of V model final

Page 1: V model final

AHEAD TEAM

1

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

ShravanKumar Sowmya Alekhya Saisuhas Reddy(TL) Anusha

Page 2: V model final

V – MODEL (SOFTWARE DEVELOPMENT)

2

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 3: V model final

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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 4: V model final

• 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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 5: V model final

STEPS IN V-SHAPED MODEL

Quality is guaranteed at each project stage.

5

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 6: V model final

ENTRY AND EXIT CRITERIA

Entry CriteriaSet 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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 7: V model final

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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 8: V model final

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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 9: V model final

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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 10: V model final

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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 11: V model final

• 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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 12: V model final

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

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 13: V model final

13

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13

Page 14: V model final

14

AH

EA

D T

EA

M ©

cop

yrigh

t 20

13