Is there an agile V-model?

Figure 2: Exemplary 'agile' V-model, which provides the requirements and design in a classic 'static' way and interprets and integrates the implementation and testing in an agile way.

© Infoteam Software

When looking at the classic V-model (see Figure 2 in red), it is noticeable that the left-hand side (development) can be approached in parallel with the right-hand side (testing). One way of doing this is to approach both the 'implementation' and 'test/review' phases in the same way as an agile project. But why only from the implementation phase?

Figure 3: Simplified illustration: For the 'iterative' V-model, the requirements packages are created once at the beginning, which later serve as the basis for the individual iteration steps.

© Infoteam Software

The reason for this lies in the risk assessment, which plays a major role in the two previous steps. A 'static' process is therefore the more efficient method for defining the requirements and documenting a system design compared to a (highly) dynamic design, which would be the consequence of changes to the requirements.

Advocates of agile models rightly shake their heads at such an 'agile V-model' and argue that such an approach is not agile, but 'only' iterative. This is because this model ignores an elementary part: the dynamics within the requirements, which is precisely one of the advantages of the agile approach. The 'agile V-model', on the other hand, only defines requirements once as an unchangeable basis for subsequent iterations (Figure 3).

Figure 4: Exemplary model for a safety scrum process: The actual sprint is encapsulated by the activities of safety analysis at the beginning and safety validation at the end.

© Infoteam Software

Given this fact, it might be logical to define a secure Scrum process. This does not look so difficult at first: For each sprint, a new 'safety analysis' activity must first be carried out, followed by the actual sprint and, with 'safety validation', an additional activity as a conclusion (Figure 4).

However, it is only that simple in theory, as this actually results in two overlapping process models for development - and even three if the certification test is taken into account: On the one hand, there is the 'safety analysis', i.e. the consideration of risks. During backlog grooming, entries are created in the product backlog that define the safety requirements for the system. A safety analysis must also be carried out during sprint planning. The reason for this is the entries transferred to the sprint backlog. They create new risks in the system that need to be considered, as the previously created system status is changed and therefore the reference to system risks must be checked by means of change-impact analyses. Finally, a safety analysis must also be carried out in the final sprint review.

In the validation part, entries must also be made in relation to the Scrum process model during 'backlog grooming', which must then be observed and usually carried out or checked during the final sprint review. Similarly, the certification checks also provide tasks that need to be entered into the product backlog and then implemented - i.e. addressed in the daily scrum, the sprint review and the sprint retrospective. This safety assessment should be carried out continuously and in parallel throughout the entire development process so that the resulting feedback can be taken into account as early as possible.

The safety assessment is therefore an independent Scrum process that runs parallel to development and has its own safety-related activities and roles - such as 'assessment owner' and 'assessment backlog'. In view of this necessary approach, the question is justified as to whether a safety scrum process actually fulfills the original motivation of agile development methods in terms of flexibility and "leaner than classic process models".

Incidentally, the Scrum mentioned here as an example is only one of several agile process models. What all models have in common, however, is that they have characteristics that representatives of agile methods would like to have preserved, but which are diametrically opposed to the requirements of functional safety standards or can only be applied with little efficiency in safety projects.

The approach of adopting at least partial aspects from the agile world into the safety process and thus making the development process somewhat more variable and optimized within the scope of possibilities is actually not that difficult. In the 'maintenance and care' process phase, for example, there has always been an iterative approach: 'change management'. A legitimate and standard-compliant approach is to internalize and implement this change management process while development is still ongoing and not yet completed.

Solution: V-model with iterations?

On the one hand, this creates an approximation to agile procedures. On the other hand, such an approach also trains the development teams for the process that they have to live after acceptance/handover/certification.

In summary, it can be said: In a normatively regulated environment, such as the development of functionally safe software, it is indeed difficult to find a process model that represents the exact right solution for all projects. It is important to have extensive experience in dealing with both the requirements of safety standards and the approach of agile development methods, as not all tasks in functional safety can be handled better and more efficiently using agile methods. Nevertheless, successfully completed software projects show that the answer to the question "Agility in safety projects - is it possible?" can definitely be "Yes!".

Author:
Frank Poignée is Consultant Safety and Chief Engineer at Infoteam Software.