Introduction to Verification and Validation

Introduction

During and after the implementation process, the program being developed must be checked to ensure that it needs its specification and the functionality expected by the user paying for software. Verification and validation is the name to these checking and analysis. Verification and validation starts with requirement review and continue to design, review and code inspection to product testing. Verification and validation is not the same thing. Validation focuses on " Are we building the right product?" and verification focuses on " Are we building the product right?".(wikipedia)

These definitions tell us that the role of verification involves checking that the software confirms to its specification.(Sommerville SE_book) We should check that it meet its specified functional and non-functional requirements.The aim of validation is to insure that the software system meets the customer’s expectation. It goes beyond checking that the system confirms to its specification to showing that the software does what the customer expects it to do.(documents.mx) The expectation of the system user and the current marketing
environment for the software system are:

1. Software Function: The level of confidence required for software depends on how it can handle critical data or critical situations.
2. User Expectation: It is a sad reflection on the software industry that many users have low expectation of their software and are not surprised when it fails during use.
3. Environment Marketing: When a system is marketed, the seller of the system must take into account Competitions programs, the price those customers are willing to pay for the system and required schedule for delivering that system.(Sommerville SE_book)

Within the verification and validation process, there are two complementary methods used for software system checking and analysis. They are:

1. Software Inspection:Software inspection analyzes and checks system representation such as the Requirement document, design program diagrams, and the program source code. We can use inspection at all the system software development process.
2. Software Testing: Software testing involves running and implementation of the software with test data. We examine the output of the software, its operational behavior to check out that it performing as the user requirement.

Verification and Validation Planning

Verification and validation is an expensive process and more than half of the system development budget may be spent on verification and validation process. Careful planning is needed to get most out of inspection and testing and to control the cost of the verification and validation process.

System verification and validation planning start early in the development process. The models shows that test plan should be derived from the system specification and design. This model also breaks down system verification and validation into number of stage.(slideshare) Each stage is driven by tests that have been defined to check the conformance of the program with its design and specification. As part of the verification and validation planning process, we should decide on balance between static and dynamic approach to verification and validation, draw up standards and procedures for software inspection and testing, establish check list to drive program inspection and define software test plan. The effort devoted to inspection and testing depends on types of system being developed and organizational expertise with program inspection. As a general rule, the more critical system, the more effect should be developed to verification and validation.

The test plan is concerned with establishing standards for the testing process and helping managers to allocate resources and estimate testing schedules. As well as setting out testing schedule and procedures, the test plans define the hardware and software resources that are required for testing. This is useful for manager who is responsible for ensuring that these resources are available to the testing team. (Sommerville SE_book)The structure component of software test plan is:

1. The testing process: A description of major phases of testing process.
2. Requirement Traceability: Users are most interested in the system meeting its requirements and the testing should be planned so that all requirements are individually tested.(Sommerville SE_book)
3. Tested items: The product of the software processes that are to be tested should be specified.
4. Testing schedule: An overall testing schedule and resource allocation for this schedule in linked to the more general project development schedule.(Sommerville SE_book)
5. Test recording procedure: It is not enough simply to run test. The result of the test must be systematically recorded. It must be possible to audit testing process to check that it has been carried out correctly.(Sommerville SE_book)
6. Hardware and Software Requirement: This section should set out the hardware and software tools required or estimated for testing process.
7. Constraint: Constraint affecting the testing process such as staff shortage should be anticipated in this section.

Software inspection

Software inspection is a static verification and validation process in which a software system is reviewed to find errors, omissions and anomalies. Generally, inspection focus on source code but any readable representation of the software such as its requirements specification or design model can be inspected. When we inspect a system, we use knowledge of system, its application domain, design model and the programming to discover error. There are three major advantages of inspection over testing:

1. During testing errors can hide other errors once one error is discovered, we can never be sure if other output anomalies are due to new errors or side errors of original errors. But inspection is static process we do not have to be connected with interaction between errors. Consequently, a single inspection can discover many errors in the system.
2. In a complete version of system can be inspected without additional cost. If the program is incomplete, then we need to develop specialized test harness to test the part of that program.
3. As well as searching for program defect and inspection can consider broader quality attribute of a program such as compliance with standards, portability, and maintainability.

Several studies and experiments that have demonstrate that inspections are more effective for defect discovering than program testing.

Program Inspection Process

Program inspections are reviews whose objective is to detect program defect. The notation of a formalized inspection process was developed by IBM in 1970s. The key difference between program inspection and other types of quality review is that the specific goal of inspection is to find program defects rather than consider design issue. Defects may be logical errors anomalies in the code that might indicate an error condition. By contrast, other types of review may be more concerned with schedule, cost, progress against define milestone or assessing whether the software is likely to meet organizational goal. The program inspection is a formal process.

That is carried out by a team. The team members systematically analyze the code and point out the possible defect.

During an inspection a check list of common programming errors are often used to focus the discussion. The inspection team is modulator responsible for inspection panning. This involves selecting an inspection team, organizing a meeting room and ensuring that the material to be inspected and its specification are complete.(issuu)

The program is to be inspected is presented to be inspected team during the review stage when another code describes what program is intended to do. This is followed by a period of individual preparation. Each inspection team member studies the specification and program and looks for defect in the code.(Sommerville SE_book)

During the inspection, the program author should make change to the code to correct identified defect. The time needed for an inspection and amount of code that can be covered depends on the experience of inspection team, programming language and application domain.

Inspection checks:The left side repreentsfault classes and right side represents inspection check.

Data fault:

• Are all program variable initialized before their use?
• Should the upper bound of array be equal to the size of the array? Or size-1?
• Is there any possibility of buffer flow?

Control Fault:

• For each conditional statement is the condition correct?
• Is each loop contains terminating value?
• Are compound statement correctly bracketed?
• Is case statement, are all possible cases accounted?
• Is a break is required after each case in case statement has it been Included?

Input/ output fault:

• Are all input variable used?
• Are all output variable assigned a value before they are outputted-putted.

Interface fault:

• Do all function and method call have the correct no of Parameters?
• Do formal and actual parameters types match?
• Are all parameter in the high order?

Storage mgt fault:

• If linked structure is modified, have all links been correctly Reassigned(coursehero)
• If dynamic storage is used has space been allocated?(coursehero)

Clean room Software Development

Clean room software development is a software development philosophy that uses formal method to support software inspection. (stupidsid) The clean room approach to software development is based on five key strategies:

1. Formal specification: The software to be developed is formally specified. A state transition model that shows system response to the input/ output is used to express the specification.(Sommerville SE_book)
2. Incremental Development: The software is partition into increments that are developed and validated separately using clean room process. These increments are specified with customer requirement at an early stage in the process.
3. Structured Programming: Only a limited number of control and data abstraction construct are used. The program development process of step wise refinement of the specification. The aim is to systematically transform the specification to create the program code.(coursehero)
4. Static Verification: The developed software is statically verified by using various software inspection techniques.
5. Statistical Testing of the system:The integrated software increments are tested statistically determines its reliability. These statistical tests are based on operational profile which is developed in parallel with the system specification.(coursehero)

There are three teams involved when the clean room process is used for the large software development.

1. The significance team: The significance team is responsible for developing and maintaining the system specification. This team produces customer-oriented specification and the mathematical specification for verification. In some cases, when the specification team also takes responsibility for development.
2. The development Team:This team has the responsibility of developing and verifying the software. The software is not executed during the development process. A structured formal approach to verification based on inspection of code supplemented with correctness argument is used.(Sommerville SE_book)
3. The certification team: This team is responsible for developing a set of statistical test to exercise the software after it has been developed. These tests are based on formal specification. (Sommerville SE_book)

The approach to incremental development in the clean room process is to deliver critical customer functionality is early increments. Less importance system functions are included in later increments. The customer has the opportunity to try these critical increments before the whole system has been delivered. If requirements problems are discovered, the customer feedback this information to the development team and request a new version of increments.

Reference:

• Sommerville, Ian. Software engineering. eight edition. Newyork: pearson, 2007.
• csitnepal. .
• csitprogram. <https://books.google.com.np/books?id=CDWRq0B9e5kC&pg=PA5&lpg=PA5&dq=+Software+Software+is+computer+programs+and+associated+documentation.&source=bl&ots=fuFOT7wYOS&sig=0tkbWoER8gf7RxbScRjIQc7W_d0&hl=en&sa=X&redir_esc=y#v=onepage&q=Software Software is%>.
• csitprogram. .
• documents.mx. <http://documents.mx/documents/verification-and-validationppt.html>.
• slideshare. <http://www.slideshare.net/sangeeswaran/software-testing-objectivetypes>.
• wikipedia. <https://en.wikipedia.org/wiki/Software_verification_and_validation>.