CSC/ECE 517 Fall 2012/ch2a 2w4 sa

From PG_Wiki
Jump to: navigation, search

V - Model

Contents

Introduction

The V-model of the Systems Engineering Process.

The V-model also called as Verification and Validation model is a software development process which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the testing cycle.

In the diagram, the left arm corresponds to the development phases in the traditional waterfall model and the right to the test phases. Each development activity carried out by the development team has its corresponding validation activity done by the testing team.

From Waterfall to V-Model[1]

Every phase or stage in the waterfall model needs to be completed and signed off before the next phase can start, this rigidity affects the flexibility in iterating back and forth between the stages of development with the result being a poor quality system. The V-Model prevents this by explicitly connecting the development and testing stages.

Objectives

The V-Model facilitates the planning and realization of projects. The following are the objectives to be achieved during system development:

Verification phase

V-Model in detail.

Verification ensures that, the software is being built correctly. The ISTQB defines Verification as: “Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.

The first part of the definition is the same as for Validation, but the second part is the key. This states that “specified requirements have been fulfilled“. The V-model diagram arrows shows that each produced product is checked against the products or documents that were used to drive the development. This ensures that all aspects have been met. A key problem is ensuring that the user requirements are adequately verified against the customer needs. The Business Case is only likely to contain high level functionality, and not the detail about processes that are essential for determining what is required.

Requirements Analysis

Requirements analysis encompasses those tasks that determine the conditions specified by the stakeholders for the product. Its activities are concerned with eliciting, analyzing, documenting, validating and managing system requirements. The requirements have to be documentable, actionable, measurable, testable, traceable, related to the business needs and should include details sufficient for system design.

Requirements analysis includes three types of activities:

Requirements analysis is a long process during which many changes can occur over that time period. Technology changes, business requirements changes with many other things, so it is important that the stakeholders are in constant touch with the developers to ensure that they understand the new improved system. It is the responsibility of the analyst to gather information from the customer. System prototypes[5] should be developed to demonstrate a working model to the stakeholders. Analysts employ a combination of various methods to establish the exact requirements of the stakeholders, so that the system developed meets the customer’s needs. The information regarding the product requirements can be classified as: Customer, Architectural, Structural, Behavioral, Functional, Non-functional, Performance, Design, Derived, and Allocated Requirements.

System Design

This design process defines the architecture, components, modules, interfaces, and data required by a system to meet the mentioned system requirements. We can say that design is an act of taking the marketing information and creating the products to be manufactured. So, systems design is the process of defining and developing systems specified by the user.

Architecture Design

The design of computer and software architecture can be referred to as high-level design. The architecture selected should realize the list of modules, brief functionality of each module, the interface relationships between the modules, dependencies, database tables, architecture diagrams, technology details etc.

Integration testing design is carried out in this phase.

Module Design

The module design phase is a low-level design. The designed system is broken up into smaller units and each of them is explained to the programmer. The low level design document will contain a detailed functional logic of the module:

Unit test design is developed in this stage.

Validation phase

Importance of Early Testing

Studies show that catching a fault early in the development stages before the system is released is more cost effective and it takes less resources to fix the system when compared to fixing it after its release. We must also take into account the reputation of the organisation, the cost associated with missing functionality, so in fact the true cost for fixing the system is much higher.

In the waterfall model[7] errors were found very late in the cycle because testing began at the end of the project. In the V-Model testing begins as early as possible. Prior to testing, the testing team works on various activities in parallel to the development activity which helps to get the test deliverable on time which includes creation of test cases, preparation of test strategies, test planning and test scripting.

Testing Types Matched to Development Stages

The first noticeable point of the V-Model is that the Test stage of the Waterfall model is bent upwards to make it a “V”. This stage is now separated out into the various types of testing. So this first step visually points out that there is more than one type of testing to consider for system development and like the development steps they build on one another, and have different objectives. The next important part of the “V” is to match each type of testing against the development stage it matches e.g. we have Component Design matched against Component Testing. This means that the testing stage does not start when the Construct Component stage has ended. Instead when each development stage starts, the testing for that stage also starts.

Unit testing

Unit testing, tests the low level design i.e. units. A unit is a basic module of the application on which testing is carried out, it may be an individual function or a procedure. These tests are created by the developers (white box testing) to verify the internal logic code. Input data are passed to the unit to test every case of execution.

Integration testing

Integration testing tests high level design i.e. components and their interfaces. In Integration testing the basic units will be tested together to check the interaction between them and finds errors in the interfaces. This is generally a black box testing method. Integration testing is performed by program team leaders.

System testing

Once the entire system has been developed, it then has to be tested against the system specifications to validate if it provides the required features. In short, system testing is about checking the system as a whole. System testing involves a number of special types of tests to see if all the functional and nonfunctional requirements have been met. System testing is performed by system testers. Reasons for carrying out a system test even after the unit and integration test

Acceptance testing

The major purpose of Acceptance Testing is to validate or confirm that the system meets the business requirements and gives an assurance before it is delivered to the end user. This phase is for testing the software in the real world by the end user to determine whether to accept the system or not.

Release testing

This testing phase answers important questions such as

Advantages

Disadvantages

Conclusion

Testing in the development process is critical[8]. The earlier a fault is found, the cheaper it is to fix. The V model extends testing to the beginning of the life-cycle. The explicit recognition of testing in the V-model makes it very useful in planning and executing information system development. The V-Model has evolved over time and supports flexibility and agility throughout the development process. Static testing techniques[9], such as inspections and walkthroughs, can be used to find faults in the functional specification, as well as defining test cases that are subsequently executed in system testing.

References

  1. http://www.coleyconsulting.co.uk/from-waterfall-to-v-model.htm
  2. http://en.wikipedia.org/wiki/Requirements_elicitation
  3. http://en.wikipedia.org/wiki/Requirements_analysis
  4. http://www.dubuquecounty.org/Recorder/RealEstate/RecordingRequirements/tabid/169/Default.aspx
  5. http://www.umsl.edu/~sauterv/analysis/prototyping/proto.html
  6. http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
  7. http://www.etestinghub.com/waterfall.php
  8. http://www.i-techzone.com/why-testing-is-important-in-software-development
  9. http://www.codentest.com/manualStatic.php

Further Suggested Reading

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox