SOFTWARE DEVELOPMENT MODELS
WATERFALL MODEL
The waterfall model is a project management methodology based on a sequential design process.
Much like waterfall filling lower level pools, phases in the waterfall model flow from one to another.
A simple Waterfall model has 6 phases:
The customer provides the feedback on the new software for the project team to look into. The project team do two additional testing in the live environment, to verify acceptable deployment.
ADVANTAGES
- Easy to understand.
- Easy to manage.
- Fewer production issues.
- Better budget management.
DISADVANTAGES
- Not flexible.
- Doesn’t handle unexpected risks well.
- Not a good model for complex or long term projects.
- Difficult to capture all requirements upfront.
In the olden days, the Waterfall model was used to develop enterprise applications like Customer Relationship Management (CRM) systems, Human Resource Management Systems (HRMS), Supply Chain Management Systems, Inventory Management Systems, Point of Sales (POS) systems for retail chains, etc.
The major drawback of waterfall model, is we move to the next step only when the previous one is finished and there is no chance of going back if something is found wrong in later stages.
V-MODEL
In software development, the V model represents a development process that may be considered on an extension of the waterfall model, and is an example of more general V-Model. Instead of moving down linearly, the process steps are bent upwards after the coding phase, to form the typical V shape.
V-Model is used for small projects where project requirements are clear. Simple and easy to understand and use. This model focuses on verification and validation activities early in the life cycle thereby enhancing the probability of building an error-free and good quality product.
V-Model provides means of testing of software at each step in reverse manner.
Verification and Validation
To understand the V model, let’s first understand what is verification and validation in software.
Verification: Verification is a static analysis technique. In this technique, testing is done without executing the code. Examples include — Reviews, Inspection, and walkthrough.
Validation: Validation is a dynamic analysis technique where testing is done by executing the code. Examples include functional and non-functional testing techniques.
To further understand the V model, let’s look at the figure below:
Left-Hand Side
As said earlier, left-hand side activities are development activities. Normally we feel, what testing can we do in the development phase, but this is the beauty of this model which demonstrates that testing can be done in all phases of development activities as well.
Requirement analysis: In this phase, the requirements are collected, analyzed, and studied. How the system is implemented, is not important but, what the system is supposed to do, is important. Brainstorming sessions/walkthroughs, interviews are done to have the objectives clear.
- Verification activities: Requirements reviews.
- Validation activities: Creation of UAT (User acceptance test) test cases
- Artifacts produced: Requirements understanding document, UAT test cases.
System requirements /High-level design: In this phase, the high-level design of the software is built. The team studies and investigates how the requirements could be implemented. The technical feasibility of the requirements is also studied. The team also comes up with the modules that would be created/ dependencies, Hardware/software needs
- Verification activities: Design reviews
- Validation activities: Creation of System test plan and cases, Creation of traceability metrics
- Artifacts produced: System test cases, Feasibility reports, System test plan, Hardware-software requirements, and modules to be created, etc.
Architectural design: In this phase, based on the high-level design, software architecture is created. The modules, their relationships, and dependencies, architectural diagrams, database tables, technology details are all finalized in this phase.
- Verification activities: Design reviews
- Validation activities: Integration test plan and test cases.
- Artifacts produced: Design documents, Integration test plan and test cases, Database table designs etc.
Module design/Low-level Design: In this phase, every module of the software components are designed individually. Methods, classes, interfaces, data types, etc are all finalized in this phase.
- Verification activities: Design reviews
- Validation activities: Creation and review of unit test cases.
- Artifacts produced: Unit test cases,
Implementation / Code: In this phase, the actual coding is done.
- Verification activities: Code review, test cases review
- Validation activities: Creation of functional test cases.
- Artifacts produced: test cases, review checklist.
Right Hand Side
The right-hand side demonstrates the testing activities or the Validation Phase. We will start at the bottom.
Unit Testing: In this phase, all the unit test cases, created in the Low-level design phase are executed.
*Unit testing is a white box testing technique, where a piece of code is written which invokes a method (or any other piece of code) to test whether the code snippet is giving the expected output or not. This testing is performed by the development team. In case of any anomaly, defects are logged and tracked.
Artifacts produced: Unit test execution results
Integration Testing: In this phase, the integration test cases are executed which were created in the Architectural design phase. In case of any anomalies, defects are logged and tracked.
*Integration Testing: Integration testing is a technique where the unit tested modules are integrated and tested whether the integrated modules are rendering the expected results. In simpler words, It validates whether the components of the application work together as expected.
Artifacts produced: Integration test results.
Systems testing: In this phase all the system test cases, functional test cases, and nonfunctional test cases are executed. In other words, the actual and full fledge testing of the application takes place here. Defects are logged and tracked for its closure. Progress reporting is also a major part of this phase. The traceability metrics are updated to check the coverage and risk mitigated.
Artifacts produced: Test results, Test logs, defect report, test summary report, and updated traceability matrices.
User Acceptance Testing: Acceptance testing is related to business requirements testing. Here testing is done to validate that the business requirements are met in the user environment. Compatibility testing and sometimes non-functional testing (Load, stress, and volume) testing are also done in this phase.
Artifacts produced: UAT results, Updated Business coverage matrices.
At every stage, test plans and test cases are created to verify and validate the product according to the requirement of that stage.
For Ex. In the requirement gathering stage, the test team prepares all the test cases in correspondence to the requirements. Later, when the product is developed and is ready for testing, test cases of this stage verify the software against its validity towards requirement at this stage.
This makes both verification and validation go in parallel.
This model is also known as the “Verification and Validation Model”.
V-Shaped Strengths:
Which phase is more emphasized when using a V-shaped Model?
- Emphasized planning for verification and validation of the product in the early stages of product development.
- Each deliverable must be testable — More emphasis laid on the testing phase.
Easy to use?
Yes, It is easy to use and handle.
V-Shaped Weaknesses:
- V-Model cannot handle concurrent events.
- It cannot easily handle dynamic changes in requirements.
- It does not contain risk analysis activities.
When to use V-Model?
Excellent choice for:
- System requiring high reliability. Ex: Hospital patient control applications.
- All requirements are known upfront.
- When it can be modified to handle changing requirements beyond the analysis phase.
- Solution and Technology are known.
The drawback of V-Model is that it is 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 required documents have to be updated.
DIFFERENCE BETWEEN WATERFALL MODEL AND V-MODEL
Conclusion
We have seen two very important models of software development models. Waterfall Model and V Model and their definition, phases, uses, advantages, disadvantages, and drawbacks. I also gave a brief about the differences between both the models and how V-Model is a modification of the Waterfall Model. Whatever I discussed is not the only knowledge you should have but I suggest you study their applications online and try to differentiate the models on your known to have a better understanding of these two models. And also try on your own so that you can easily choose a model which would be suitable for the given requirements.
