V Model | Software Verification. Software Validation....
Information & Understanding. | Software Validation.
The V shaped software validation lifecycle model is a variant of the Waterfall model to software validation with an emphasis on both verification and validation of the end product. The critical aspect of the V shaped model is that the testing of the product is planned in parallel with a corresponding phase of development.Phases of the V Model:
Software Validation. Information & Understanding >>>
i) Development of the user requirements specification.
ii) Development of the functional specification.
iii) Hardware design specification.
iv) Software design specification.
v) Software module design specification.
vi) Coding.
vii) Application software production.
viii) Testing.
ix) Software module test specification.
x) Software integration test specification.
xi) Hardware acceptance test specification.
xii) System acceptance test specification.
Looking at these is some more detail:
User Requirements Specification (URS).
This describes what the equipment or system is supposed to do, and as such is normally written by the product manufacturer. An initial version of the URS may be included with the Invitation To Tender (ITT) sent to potential suppliers. This version should include all essential requirements (musts), and if possible a prioritised set of desirable Requirements (wants).Functional Specification.
The Functional Specification is a description of the product to be supplied in terms of the functions it will perform and facilities required to meet the user requirements as defined in the URS. The Functional Specification should be written in such a way that it is understood by both supplier and customer. This document is the controlling specification, against which the system will be tested.Hardware Design Specification.
The Hardware Design Specification is a description of the hardware on which the software resides and how it is to be connected to any existing system or plant equipment.Software Design Specification.
The Software Design Specification is a description of the software components and sub-systems to be provided as part of the product. If there is only one module the Design Specification should contain enough information to enable the code to be produced. In this case the module design specification, test specification and integration test specification are not required.Software Module Design Specification.
For each software sub-system (module) identified in the Software Design Specification, a Software Module Design Specification should be produced. The Software Module Design Specification should contain enough information to enable coding of the module to proceed.Coding.
Coding consists of the actual writing of the code for the program. The programmer has a continuous cycle of writing and testing. The programmers testing is a part of writing the code, not validating it. The programmer’s testing IS NOT the testing used for validation.Application Software Production.
The following should be considered in each implementation activity:– Where possible, appropriate implementation methodologies and tools should be used to formalize the production process. The use of these methods and tools should be documented.
– Rules and conventions such as programming rules, programming languages, consistent naming conventions, coding and commentary rules should be formally specified and observed.
Testing.
Testing includes, tests of each module:– Groups of modules
– The whole program
The testing will finally include the system as it will be used. Testing may show flaws in the code, design and / or the requirements.
Software Module Test Specification.
For each Software Module Design Specification, an associated Software Module Test Specification should be produced. The Software Module tests to be carried out should ensure that the software module meets its specification.Software Integration Test Specification.
The Software Integration Test Specification defines those tests which demonstrate that all software modules communicate with each other correctly and that the software system meets its design specification. A Software Integration Test Specification should be produced where more than one software module has been produced.Hardware Acceptance Test Specification.
The Hardware Acceptance Test Specification details those tests to be carried out on the hardware described in the Hardware Design Specification. These tests should ensure that the hardware to be supplied meets its specification and integrates correctly with any existing computer hardware or plant equipment.System Acceptance Test Specification.
The System Acceptance Test Specification is a description of those tests to be carried out to permit acceptance of the system by the user. Typically it should address system functionality, system performance, critical parameters and operating procedures.V-shaped model strengths.
Places an emphasis on the planning of the verification and validation of the product in the early stages of product development.Each deliverable can be testable.
Project management can track progress by milestones.
Easy to use.
V-shaped model weaknesses.
Does not easily handle concurrent events.Does not handle iterations or phases.
Does not easily handle dynamic changes in requirements.
Does not contain risk analysis activities.
When to use the V-shaped model.
Is very applicable when applied to systems requiring high reliability, e.g. in a medical device application such as hospital patient control applications.However, all requirements should be known up-front and the technology needs to be well understood.
When it can be modified to handle changing requirements beyond the analysis phase.
When there is a requirement for verification of requirements and design specifications.
Throughout the Validation process you need to consider.
How do you trace the specifications through every stage of the life cycle?Is there a traceability matrix?
Are all of the specifications mapped?
Has control flow diagram and data flow diagram analyses been done to assure that the requirement specifications are complete?
Information & Understanding. | Software Validation.
- Agile Development. Extreme Programming. Spiral Validation. Etc..
- Software Validation explained in an easy to understand, visual, format.
- Use to inform yourself on the Validation of Software.
- Information & Understanding >>>
General Principles of Software Validation (FDA)
Guidance of standalone software in the Medical Device Industry. MEDDEV 2.1/6
ISO/IEC 12207 Systems & Software Engineering – Software Life Cycle Processes