There are two models that are commonly used in the development process: the v model & agile.
I will take a deeper look into the v-model in this article.
V-Model
Every project you build will need a plan, and the V-model is one of the classic plans in the testing and development process. It constantly passes between its two phases, validation and varification.
Although this model started as a graphical representation of the software development life cycle the V-Model is now used in more engineering disciplines, including mechanical engineering, electrical design, and systems engineering.
At its core, the V-Model is a systematic method that emphasizes the importance of testing and validation at each stage of development. Unlike traditional linear approaches, where testing occurs only after the completion of the entire design phase, the V-Model incorporates testing and validation activities in parallel with development, thereby reducing the risk of costly errors and delays.
The V-Model consists of two main phases: the left side of the “V” represents the development phase, while the right side signifies the testing and validation phase. Let’s start with a deeper look into the verification stages!
Development Phase
1. Requirements Analysis:
In this early stage of the project, the problems need to be well stated and defined. Here you will find out what the customer wants, what the regulations are, which standards you need to follow, and what the project constraints are going to be.
2. System Design:
Here is where we take pen to paper and start drawing out the architecture of our system.
The way I see it is that we have a solution to each problem stated in the requirements phase, and here in the system design phase we are just finding interfaces to fit the solutions into.
Simply put, finding out how the puzzel pieces fit together.
3. Subsystem Design:
Now we need to dive deeper into the images on the puzzel pieces. We need to start looking into the details.
Here is what needs to be considered:
- funtionality – what will it do
- performance – how well will it do it
- reliability – how long will it do it
- manufacturability – can we make it
4. Component Design
Here we as the development team look at the individual components for our project. We will look at:
- materials
- tollerances
- environment
- lifecycle management
- safety
Additionally, we will start with the fun parts: prototyping and simulation. This is used to varify the design concepts.
5. Implementation:
Finally we start on the product. We will start the construction/fabrication of the product.
The development team will start seeing a lot more of the manufaturing team in the factory. Engineers are netorious for their bad communication skills, but communication with the manufactring team is crutial for this phase – to ensure a smooth process.
On the right side of the “V,” the focus shifts towards testing and validation activities – testing- mirroring the steps taken during the development process. Here is what the validation phases look like.
Testing phase
1. Unit Testing
Unit testing is the testing counterpart to component or module design phase.
Unit testing is vital to ensuring that each base component and all of the new features of our system work alone – in isolation.
We will create test cases that are based on the or requirement and specifications. All possible scenarios and uses need to be covered by these tests.
2. Subsystem Testing:
In the test counterpart to the subsystem design, we need to test the interface compatibility between our components.
The subsystems are tested together to ensure that the components communicate and interact with each other exactly as intended. Additionally, they need to meet our predefined performance criteria.
3. System Testing:
We now move onto testing the entire system more practically. We will take the system into the wild – test how it works in real world conditions.
Additionally, we need to ensure that our system functions and is reliable in complience with our requirements.
4. Acceptance Testing:
After all of the other tests pass with flying colours, we move on to the acceptance testing. This just means we take our system to the customer and ensure that it follows the regulatory compience.
If the regulatory authorities and customer are happy with our product, we have passed this test aswell.
Final Thoughts
No product is ever finished. Everything can be improved upon. I highly recomend leaning into the continuous improvement of the V-Module design. It is an easy to use linear approach to the product development process. The V-Model can be used for both software development and hardware development.
