Agile V-Model

Foundation: V-Model

The V-model is a systems development lifecycle which has verification and validation "built in". It is often used for development of mission critical systems, e.g. in automotive, aviation, energy and military applications. It also tends to be used in hardware-centric domains. The V-model - not surprisingly - is using a v-shaped visual representation, where the left side of the "V" represents the decomposition of requirements, as well as the creation of system specifications ("definition and decomposition"). The right side of the "V" represents the integration and testing of components. Moving up on the right side, testing usually starts with the basic verification (e.g. unit tests, then integration tests), followed by validation (e.g. user acceptance tests).

When applying the V-model to AIoT, it needs to take different dimensions into consideration, usually including hardware, software, AI and networking. In addition to the standard verification tests (unit tests, integration tests) and validation tests (user acceptance and usability tests), the V-model for AIoT also needs to address interoperability testing, performance testing, scalability testing and reliability testing. The highly distributed nature of AIoT systems of will pose specific challenges here.

Test automation is key to ensure a high level of test efficiency and test coverage. On the software-side, there are many tools and techniques available to support this. In the AI-world, these kinds of tools and techniques are only just beginning to emerge, which makes it likely that a more custom approach will be required. In the embedded and hardware world, simulation techniques like Hardware-in-the-Loop (HIL), Software-in-the-Loop (SIL) and Model-in-the-Loop (MIL) are well established. However, most AIoT products will also require testing of the actual physical product, and how it performs in the field in different types of environments. This again will be a challenge, and some ingenuity will be required to automate testing of physical products wherever possible.

Agile V-Model

Ignite AIoT is trying to strike a good balance between the agile software world and the less agile world of often safety-critical, complex and large(r)-scale AIoT product development with hardware and potentially even manufacturing elements to it. Therefore it is important to understand how an agile method works well together with a V+V-centric approach like the V-model. The logical consequence is the Agile V-model. Combining agile development with the V-model is no contradiction. They both can work very well together, as shown in the figure below:

• Agile methods use story maps including epics, themes and backlogs for logical decomposition. This maps well to the left side of the V
• Continuous Integration / Continous Test / Continuous Delivery are inherently agile methods, which map well to the right side of the V
• The key assumption is that the V-model is not used like one large waterfall approach. Instead, the Agile V-model must ensure that the sprints themselves will become Vs according to the V-model

There are two options to implement the latter:

• Each sprint becomes a complete V, including development and integration / test
• The agile schedule introduces the concept of dedicated integration sprints.
• One V becomes 2 sprints: One development sprint, one integration sprint
• There are pros and cons to both approaches
• Complexity and scale of the project will surely play a role in determining the best setup

Ignite AIoT is assuming in the following that the Agile V-model will be applied.

Example: ACME Robot Vacuum

Story Map

Component Architecture

User Story

Mapping User Story to Components and Feature Team

Sprint Planning

Verification & Validation

Agile V-Model and AIoT

Taking everything together that was discussed so far for IoT and AI, as well as Agile V-Model, and combining it with the product organization discussion from the chapter on Product Organization, the complete picture looks like in the diagram below: The AIoT workstreams are synchronized by applying the Agile V-model accross all AIoT workstreams. Development and integration sprints alternate (or are integrated into single sprints), in order to ensure that at the end of each agile V-sprint, a potentially shippable increment is achieved (although in reality this will not be achievable for the hardware components - some ingenious approach still has to be applied here).

Agile V-Model, AIoT, and SOP

Finally, this discussion should conclude by mentioning the probably biggest differentiator between a "normal" cloud project and an AIoT project: The Start of Production, or SOP. This is the point in time when the mass production of the smart, connected products is starting, and they are leaving the factory to be deployed in the field. Any required changes to the hardware configuration of the product will now be extremely difficult to be achieved (usually involving costly product recalls, which nobody wants). In a world where manufacturers want to utilize the AIoT to constantly stay in contact with their products after they have reached the customer, and provide the customer with new digital services and applications - rolled out via OTA - it becomes extremely important to understand that the V&V process does not stop with the SOP - at least not for anything that is software. And with software defined vehicles, software defined robots and software defined everything, this is fast becoming the new normal.