CSC/ECE 517 Fall 2012/ch2a 2w4 sa

V - Model

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<ref>http://www.coleyconsulting.co.uk/from-waterfall-to-v-model.htm</ref>

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:

• Minimizing Project Risks: Early recognition of planning deviations and risks improves process management, thus reducing risks.

• Improving Quality: Defined intermediate results can be checked at an early stage. Uniform product contents will improve readability, understandability and verifiability.

• Reduction of Total Cost: The results obtained should be uniform and easily retraced. This reduces the dependency on the supplier and the effort for subsequent activities.

• Effective Communication between all Stakeholders: The miscommunication between user, supplier and developer is reduced.

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:

• Eliciting requirements<ref>http://en.wikipedia.org/wiki/Requirements_elicitation</ref>: Identifying the various types of requirements from various sources i.e. project and business process documentation along with stakeholder interviews.

• Analyzing requirements<ref>http://en.wikipedia.org/wiki/Requirements_analysis</ref>: Determining whether the specified requirements are clear, complete and consistent.

• Recording requirements<ref>http://www.dubuquecounty.org/Recorder/RealEstate/RecordingRequirements/tabid/169/Default.aspx</ref>: Requirements can be documented in normal language documents, use cases, user stories, or system specifications.

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<ref>http://www.umsl.edu/~sauterv/analysis/prototyping/proto.html</ref> 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.

• Softwares that run on generic platforms have enhanced software engineering.

• Object-oriented analysis and design methods<ref>http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design</ref> are widely used for systems design.

• UML is used for modeling software systems and designing high non-software systems and organizations.

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:

• database tables, with all elements, including their type and size

• all interface details with complete API references

• all dependency issues

• error message listings

• complete input and outputs for a 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<ref>http://www.etestinghub.com/waterfall.php</ref> 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

• The previous testings were done against the system specifications. The system test, looks at the system from the perspective of the future user.

• Many of the system functions and characteristics results from the interaction of the modules, and can be tested only at this level.

• Also, keeping in mind that the customer and the end user can be two different groups of people having their own requirements and interests.

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

• Is the software suitable for the end user?

• Has the compatibility with other systems been ensured?

• Is the performance of the software optimized?

Advantages

• Early acceptance criteria is the key advantage, they are performed against a specification of requirements.

• 60 to 70 percent of all faults are in the system before the component construction and test stages start, which is taken care of.

• At an early stage we can feed back to catch a fault before it is built into the system.

• Specifies test requirements and expected results prior to performing the actual tests.

• Defines who is responsible for performing the testing and provides a focus for defining the testing that takes place at each stage.

Disadvantages

• Too simple to reflect the development process.

• Leads project managers to a false sense of security.

• Inflexible and no ability to respond to change.

• Produces inefficient testing methodologies

• The placing of contracts for services is not regulated.

• The organization and execution of operation, maintenance, repair and disposal of the system are not covered by the V-Model.

• The V-Model addresses software development within a project rather than a whole organization.

Conclusion

Testing in the development process is critical<ref>http://www.i-techzone.com/why-testing-is-important-in-software-development</ref>. 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<ref>http://www.codentest.com/manualStatic.php</ref>, 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

<references/>

Further Suggested Reading

• Dual Vee Model - http://en.wikipedia.org/wiki/Dual_Vee_Model

• System Development Lifecycle - http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

• Product Lifecycle Management - http://en.wikipedia.org/wiki/Product_lifecycle_management

• Portal: Software Testing - http://en.wikipedia.org/wiki/Portal:Software_Testing

• IBM RUP - http://en.wikipedia.org/wiki/RUP

• Systems Architecture - http://en.wikipedia.org/wiki/Systems_architecture

• System Analysis - http://en.wikipedia.org/wiki/Systems_analysis

• System Design - http://en.wikipedia.org/wiki/Systems_design