V model Over view (Software Engineering)
Download as PPTX, PDF3 likes776 views
The V-model is a software development lifecycle framework where each phase of development (requirements, design, implementation, testing) has a corresponding testing phase that validates the product. The V-model is suited for projects with clearly defined requirements and available technical resources, as each phase must be completed before moving to the next. Key phases include requirements analysis, system design, module design and coding, unit testing, integration testing, system testing, and user acceptance testing.
V model Over view (Software Engineering)
- 2. What is V model When to use V model Pictorial Description Phases of V-Model Merits Demerits
- 3. V- model means Verification and Validation model. V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase starts. Testing of the product is planned in parallel with a corresponding phase of development.
- 4. The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed. The V-Shaped model should be chosen when sample technical resources are available with needed technical expertise.
- 5. There are two phases Verification Phase Validation Phase
- 7. Requirements Analysis: the first step in the verification process, the requirements of the system are collected by analyzing the needs of the user. System design: In this phase system engineers analyze and understand the business of the proposed system by studying the user requirements document.
- 8. Architecture design The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in the particular phase.
- 9. Module design The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo-code: 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.
- 10. This is at the bottom of the V-Shape model. Module design is converted into code by developers.
- 11. Unit testing In the V-Model, Unit Test Plans (UTPs) are developed during module design phase. These UTPs are executed to eliminate bugs at code level or unit level. A unit is the smallest entity which can independently exist, e.g. a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/units.
- 12. Integration testing Integration Test Plans are developed during the Architectural Design Phase. These tests verify that units created and tested independently can coexist and communicate among themselves. System testing System Tests Plans are developed during System Design Phase. Unlike Unit and Integration Test Plans, System Test Plans are composed by client's business team. System Test ensures that expectations from application developed are met.
- 13. User acceptance testing User Acceptance Test (UAT) Plans are developed during the Requirements Analysis phase. Test Plans are composed by business users. UAT is performed in a user environment that resembles the production environment, using realistic data.
- 14. Simple and easy to use. Testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model. Proactive defect tracking – that is defects are found at early stage. Avoids the downward flow of the defects. Works well for small projects where requirements are easily understood.
- 15. Very rigid and least flexible. Software is developed during the implementation phase, so no early prototypes of the software are produced. If any changes happen in midway, then the test documents along with requirement documents has to be updated.