EN 
DE A proven agile development process for safety projects
Author: Frank Poignée, infoteam Software AG
Contribution – Embedded Software Engineering Congress 2017
Agile software development aims to make the development process more flexible and streamlined than traditional approaches like the V-model. Can agile methods also be used effectively in the development of safety-related systems while simultaneously meeting all the requirements of IEC 61508 for the development process?
motivation
Software development has evolved continuously over the last 50 years. For several years now, Agile and Scrum methodologies have been emerging, and more and more development teams are working on this basis. Agile methods are particularly well-suited for responding to changing requirements, and projects developed using agile methods have a significantly higher probability of being completed successfully.
Can we work more effectively for our customers in the area of safety and security by using agile methods?
What does Agile actually mean?
The literature cites February 2001 as a milestone, the year in which the Agile Manifesto [/1/] was formulated. The statements in this Agile Manifesto directly relate to values that are also highly valued in development with regard to functional safety – only these are found on the RIGHT-HAND PAGE and are considered „less important“ in Agile (see Figure 1, PDF: Statements from the Agile Manifesto).
This is particularly noticeable in the areas of process, documentation, and planning!
Does agile development truly function without the values on the right side of the equation? Does this lead to smoother project operations and ultimately greater customer satisfaction? And if so, doesn't this already contradict the requirements of IEC 61508 regarding the development process, thus hindering the use of agile methods in functional safety development?
In fact, even an agile team doesn't work without a process – so from a safety point of view, it doesn't look quite so frightening.
Where are the differences in the process models?
Let's take Scrum as an example of an agile methodology. Scrum's approach is to work empirically, incrementally, and iteratively, and it's based on the experience that many development projects are simply too complex to be captured in a comprehensive plan; a significant portion of the requirements and solutions are unclear at the outset. This ambiguity can be eliminated by creating intermediate results, which then allow for the more efficient identification of missing requirements and solution techniques than through an abstract clarification phase.
The V-model, also known as the waterfall model in software development, is found in functional safety standards. This is a linear, non-iterative process model organized into successive project phases. As with a waterfall, phase results always become binding requirements for the next phase. Each phase has predefined start and end points with clearly defined deliverables and is executed only once.
At least in theory! In reality, even a safety project has "late requirements", and therefore it's essential to master things like iterations in the project phases.
IEC 61508 doesn't actually mandate the V-model as the development process! It's simply easier to demonstrate compliance with the standard's goals and requirements using the V-model. Tailoring the development process is permitted, and often the motivation for specifying the V-model as the methodology in project descriptions is merely convenience. This saves the development team the otherwise necessary proof that all goals and requirements are met in the lifecycle phases according to the standard.
Is there an agile V-model?
If we consider the right side of the "continuous" V-model – which deals with testing – this can be addressed "in parallel" with the left side of the development process. One way to adopt something from the agile world here is to view the implementation and testing/verification phases in such a way that they are approached like an agile project (see Figure 2)., PDF(e.g., „Agile“ V-model).
Why only from the Implementation phase onwards? We initially adhere to the V-model to define requirements and document a system design, as risk considerations are of paramount importance in these two steps – and these can be carried out more efficiently in a „static“ process than in a (highly) dynamic design that we obtain when changes to the requirements occur.
However, if we present this "agile V-model" to a proponent of agile models, they will rightly shake their head and say: That's not agile, but "only" iterative, what we're doing here! We've overlooked an important aspect, namely the dynamic nature of requirements, which is precisely one of the advantages of the agile approach. In our model, on the other hand, we define EXACTLY ONE set of requirements that we use during the iterations, but we don't change them (see Figure 3)., PDF: „Iterative“ V-model).
Or perhaps a "Safety Scrum" process?
Let's take a different approach: Perhaps defining a secure Scrum process is more promising.
At first glance, this doesn't seem so difficult: we "only" perform a new "Safety Analysis" activity for each sprint, then the actual sprint follows, which is then completed with an additional "Safety Validation" activity (see Figure 4)., PDF: Safety Scrum).
However, it's only that simple in theory. In reality, this results in two – or even three, if we include the certification exams – overlapping process models for development.
Firstly, there is the safety analysis, which involves considering the risks. During backlog grooming, entries are defined in the product backlog that specify the safety requirements for the system.
During sprint planning, a safety analysis must be carried out again, because the entries included in the sprint backlog create new risks in the system that must be considered – after all, we are changing a previously existing system state and must cover the connection to system risks through change impact analyses!
A safety analysis must also take place during the final sprint review.
Looking at the validation aspect in relation to the Scrum process model, we also have to define entries during "backlog grooming" that need to be considered and usually carried out or checked during the final sprint review.
The certification exams also provide tasks that need to be added to the product backlog and then implemented – addressed in the daily scrum, sprint review, and sprint retrospective. This safety assessment should be conducted continuously and in parallel throughout the development process so that the resulting feedback can be incorporated as early as possible.
The Safety Assessment is therefore essentially its own Scrum, which is carried out in parallel with the development and has its own safety-related activities and roles, such as Assessment Owner, Assessment Backlog.
The question remains whether this approach will actually deliver the advantages originally mentioned in the motivation regarding flexibility and being "leaner than classic process models".
Scrum, mentioned here as an example, is just one of several alternative agile methodologies. All of them retain characteristics that proponents of agile methods wish to preserve, but which are diametrically opposed to the requirements of functional safety standards or can only be implemented very inefficiently when safety aspects are considered.
Or perhaps "just" a V-model with iterations?
The approach of bringing something from the agile world into the safety process, and thus "at least somewhat improving" the development process, is actually not that difficult. If you take a closer look at the "maintenance and support" phase of the process, you'll find an iterative approach already in place: change management. It's a legitimate and standards-compliant approach to implement this change management process even while development is still ongoing and incomplete. An additional motivation for this is that we not only create at least an approximation of an agile approach, but also simultaneously train our development team in the process that the team will have to follow even after acceptance/handover/certification.
Conclusion
In fact, we will find it difficult to find EXACTLY ONE process model that represents the right solution for ALL projects!
Successfully completed real-world software projects have shown that the answer to the question "Agility in safety projects – is that possible?" can indeed be "yes".
However, it is not the case that ALL tasks can be BETTER handled using agile methods!
Sources
[/1/] https://agilemanifesto.org/iso/de/manifesto.html
Our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.
Training & coaching on the other topics in our portfolio can be found here. here.
Quality, Safety & Security – Expertise
Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
