Introduction to V-Model
3 Levels of V-Model:
The standardization concept of the German Federal Authorities pursues this objective by regulations on three levels:
- Software Lifecycle Process Model.
- Methods to be used.
- Tool Requirements.
Submodels of V-Model:
The V-Model is structured into functional parts, called submodels. These four submodels are closely integrated and mutually influence one another by exchange of products/results. These submodels are as below:
- Project management (PM): plans, controls and informs the SD, QA and CM submodels.
- Software/System development (SD): develops the system or the software.
- Quality Assurance (QA): specifies quality requirements, test cases and criteria, and examines the products and the compliance with the standards.
- Configuration Management (CM): administrates the products generated.
Software Development Submodel – [ Also known as the traditional V-Model ]
Conventional V-Model represents the development process in the form of a V shape. The right side of the V represents the testing where the systems is validated against the specifications defined on the left side. The meeting point of the V represents the actual development.
Use of V-Model in ABAP Development Lifecycle:
Generally in implementation Projects, ABAP development cycle will be somewhat :
Application Design – High Level design – quite functional – contains functional test cases or guidelines for test cases – Review of AD – Review comments implemented till sign off by the stake holders ( client side / consultant side )
Detail Design Detail Level design – quite technical as well – Man-hours required is estimated and mentioned – contains functional & technical unit test cases – Review of DD – Review comments implemented till sign off by the stake holders ( client side / consultant side )
Development – Coding by the developers as per the detail design –
Unit Testing – is done in Development Server by the developer to ensure that program works as per the detail design – add / implement test case results – transport request details & documentation in detail design – Evidence is attached. Code Review to ensure that coding is as per the coding standards ( performance related as well ) – Also check the test cases and verify – Review comments implemented till sign-off by the stake holders. Before Application testing the realted chunk of work is transported to QA Server.
Application Testing / Integration Testing – This is to ensure that programs work along with other components, that might get affected. e.g. Even the Invoice process should be tested if a change is made in the interface related with a PO creation / change. The test cases or created separately ( more functional in nature and considers dependency of components ). Before implementation of the release, the complete product needs to be tested to ensure that it can bear the maximum load of a production environment.
Product Testing / Load Testing – is performed with huge datasets to check if system / product can handle production scenario in terms of memory and performance.
Final Implementation in Production.
Support – Any further problems will be solved as Bug-fix or and enhancments will be carried out as a part of change request.