The "V" model is a software development process (also applicable to the development of hardware) that can be considered an extension of the cascade model.
Instead of going down in a linear manner, the process steps, after the step of encoding, are bent upward to form the typical shape of a V. The V-model illustrates the relationships between each phase of the life cycle of development and testing phase associated with it. The horizontal axis represents the time or the completeness of the project (from left to right); the vertical axis the level of abstraction (lower level of abstraction at the bottom, higher abstraction level at the top).
The descending branch (left) of the macro-V is the "definition phase", that is the macro phase of conception and design; the vertex of the V rapprenta the implementation phase (writing) of the Code; the ascending branch (right) of the V represents the macro-phase testing and integration.
The V-model provides for the possibility that there are feedback (from right to left) between the stages of testing / integration and the identification phase at the same level. Such feedback constitute the corrections and changes to be applied as a negative result of the testing and integration phases.
Descrizione delle fasi
The model includes four phases of definition (design), an implementation phase and 4 phases of testing/ integration:
In the analysis of requirements phase, which constitutes the first step in the translation process, the system requirements are gathered by analyzing the user's needs. This phase deals with determining what the ideal system should accomplish, but is not concerned to determine how the software will be designed and will be implemented. In this phase, users are interviewed and a document called "user requirements specification" is generated.
There are several methods to collect user requirements: interviews, questionnaires, document analysis, observation, prototyping to lose, use cases, and static and dynamic schemes elaborated together with the users.
The System Design phase is the phase in which systems engineers, studying the specific user requirements, analyze and understand the tasks of the proposed system. If the analysis shows that any of the requirements is not feasible, the user is informed of the problem, and a solution is found and shared, and the requirements document is modified accordingly.
In this phase, the specification of the software requirements is drawn up. It will be used as architectural plan for the development phase. This document usually contains the general organization of the system, the menu structure, data structures, etc .; It may also contain examples of operating scenarios, examples of windows and reports for a better understanding of the system. In this phase other technical documentation as the entity diagrams and the data dictionary will be produced. In this phase we are finally prepared the specifications for the system test.
The phase of the hardware and software design is often called high-level design; the reference point in selecting the software architecture should be to achieve all that is necessary to define the list of modules, the functionality of each module in short, their interface relationships, dependencies, the tables of the databases, the architectural diagrams and details about the technology to use.
In this phase, the integration tests are designed.
The phase of the module design can also be referred to as low-level design. The designed system is divided into very small units, called modules; each of them is specified so that the programmer can immediately begin coding.
The specification of program, or of low-level design document, will contain: the detailed functional description of the module written in pseudocode; the database tables with all the elements, including their type and size; all interface details with the full addresses of the API; all of the problems of dependencies; the list of error messages; all input and output module.
In this phase the design of the unit tests is performed.
In this phase we proceed to encoding, or to the implementation of the modules.
The "unit tests" are a method by which individual units of source code are tested to determine if they are suitable for use. The unit is the smallest testable part of an application; usually in procedural programming the unit is a single function or procedure.
The "unit tests" are created by programmers and are usually madeby tests of type "white box". The purpose is to test the internal logic of the code testing each possible branch within the function (a concept known as the coverage testing). To facilitate this process often uses static analysis tools, through which all the variations of the input data are passed on to test every possible case function.
The integration tests can be divided into two different classes:
- SW integration: the modules are tested together to detect errors in the interfaces and interaction between integrated components. The tests are usually of the type "black box" since the code is not directly controlled for finding errors.
- Integration HW / SW: the architectural requirements that describe the interaction of the SW with its HW platform below are verified. Also in this case the tests are usually of the type "black box".
The System testing is testing performed on a complete and integrated system and is designed to assess the compliance of the system with the specified requirements. The system testing is a test to "black box" and, as such, requires no knowledge of the internal design of the code or its logic.
As a rule, system testing takes as input all software components, "integrated" with each other, that have passed integration testing, and the entire embedded software with all applicable hardware systems.
User acceptance testing
The acceptance testing is the testing phase used to determine whether a system meets the requirements specified in the analysis of the requirements phase. The design of the acceptance test is derived from the User Requirements document. This is the phase used by the client to determine whether to accept the system.
In summary, the acceptance testing;
- helps to determine whether a system meets the acceptance criteria;
- enables the customer to determine whether to accept the system, or not;
- allows you to test the software in the "real world" of users.
The model "V" in the safety life cycle of SW
The "V" development model, applied to the security of the software life cycle, looks slightly different than the standard model. This is due to the fact that the rules relating to functional safety define two life cycles, one for the system, and one for the software. The two life cycles, however, are closely interrelated and interdependent; This shows the concern of the standard, which want that hardware and software are fully integrated with each other, and, in fact, the software is thought as a component somewhat special of the system.
The main differences between the two "V" models are the following:
- In the model applied to the safety lifecycle phases of analysis of the requirements and system design are lacking. This is due to the fact that the phases of design and planning are carried out at the system level as they are closely related to the safety analysis (for example hazard & risk analysis).
- In the model applied to the safety life cycle the first phase is the definition of the security requirements of the SW. These requirements are derived from system security requirements, and thus descend from the safety analysis relating to the system in its entirety.
- In complex projects and large the architecture specification phase can be divided into two phase: the first deals to decompose the software into its main components, the second deals with decomposing the software further up to the identification of individual modules that realize each component. The first of these two phase is still considered to be related to the architecture specification, while the second is called "software design system" and should not be confused with the phase of "design system" of the standard model.
- The model applied to the safety life cycle, beyond the normal validation activity (testing), provides for a series of verification activities. These activities have the purpose of controlling the consistency of what is produced in each phase with the safety requirements. Validation and verification (the so-called V & V) are considered among the main activities that are intended to ensure the integrity of the safety of the system under construction.