EN 
DE Agile development methods for safety-critical software
Authors: Ingo Nickles, VectorSoftware, Martin Heininger, HEICON
Contribution – Embedded Software Engineering Congress 2015
The Agile Manifesto addresses points in software development projects that many experienced project managers readily agree with. Agile methods originated in IT software development. At first glance, different aspects seem to take precedence in the development of safety-critical embedded systems/software. Are there ways to bridge these two worlds? To compare them, the underlying principles are analyzed, and appropriate conclusions are drawn.
Let's first take a look at the original text of the Agile Manifesto (see Figure 1, PDFThe core principle of the Agile Manifesto is to place the customer's needs at the absolute center. Things that don't directly serve customer value are given a lower priority. Comprehensive documentation, for example, offers less customer value than working software. The same applies to the other three points of the manifesto.
Another aspect can be seen in the following principle: "Build projects around motivated individuals. Give them the environment and support they need, and trust that they will complete the task."„
This is where the often-discussed self-organizing teams come into play. Furthermore, motivated and high-performing teams are a prerequisite.
Furthermore, the following principles suggest that the founders of the Agile Manifesto had smaller projects in mind:
„"Deliver working software regularly within a few weeks or months, and prefer the shorter timeframe."“
„"The most efficient and effective method of conveying information to and within a development team is through face-to-face conversation."“
- Customer needs are the focus
- motivated and high-performing development teams as well as
- typically smaller projects
These are, in summary, the three most important elements on which the Agile Manifesto is based.
Principles of developing safety-critical, embedded systems/software
Now let's look at the development process for projects in the field of functional safety. This term refers to the development of safety-critical, embedded systems. What are the key points here? For software development, the following observation is central to the activities:
There is no method that guarantees error-free software development! A single error can endanger human lives!
This realization presents a dilemma. There is no development methodology for industrial projects that can guarantee error-free software. Rather, several processes and methods have emerged over the last few decades that can minimize the number of errors. A milestone in this development was certainly the introduction of the DO-178 standard for civil aviation projects in the 1980s. Comparing the functional safety standards of various industries today, it becomes clear that some fundamental, cross-industry processes have become established in software development. These processes reduce the software error rate to a very low, socially acceptable level.
The main contents are here:
- Requirements documented in writing
- Proof of correct (error-free) implementation through very comprehensive verification methods (focus on testing, but also review and analysis)
- Verification of the verification
- Proof of deterministic software behavior (=> worst-case scenarios)
- Questioning the quality of testing and requirements, e.g., by demonstrating structural coverage
Written documentation of all work results, the four-eyes principle, and the establishment of comprehensive transparency are, in summary, the essential elements on which software development in functional safety is based. In functional safety projects of the highest criticality level, pure software coding often accounts for only 201,003,000 of the total project effort. 801,003,000 of the effort is spent on validation, verification, and documentation.
As shown in the following diagram (see Figure 2, PDFAs illustrated, these activities were not the focus of the Agile Manifesto.
conclusion
If one wants to carry out FuSi projects using agile development methods, the following potential areas of conflict arise (see Figure 3, PDFThe secret to success lies in analyzing the points mentioned above and drawing the appropriate conclusions for your own project. How can you actively resolve these conflicting principles?
The first point (Requirements / User Stories) requires consideration of functional safety requirements, meaning a database containing the requirements must be maintained. The user stories become documented requirements, meaning they are incorporated into sprint planning in the form of user stories. The product backlog then contains the requirements from the database. A customer-oriented prioritization of the implementation is carried out. Unclear, high-priority requirements are thus clarified promptly. Active customer involvement in the project also ensures rapid feedback on the requirements and the implementation.
The tests must meet the formal requirements of the relevant functional safety standard. However, if they are used as a criterion for the "Definition of Done," they can even improve agile projects.
In particularly safety-critical projects (SIL3, SIL4, ASIL C, ASIL D), it can generally make sense, due to the large verification effort, to manage one of the agile teams as a dedicated verification team. This ensures the necessary independence, and the extensive scope of the tests (every error must be found) is adequately addressed in terms of personnel.
The strong interaction between hardware, mechanical, and software development in embedded projects must, of course, be taken into account. However, this has no consequences for the individual work of the agile software teams. It is the product owner's responsibility to ensure the exchange of information between hardware and mechanical development.
The same applies when the start of production and similar deadlines define a clear framework for the development of embedded systems. However, this framework is usually broad enough to allow the autonomous decision-making of agile teams to be fully exercised within it.
Conclusion
In functional safety (FuSi) projects, written documentation of work results and the four-eyes principle are fixed points that cannot be argued away. How else can one prove, at the latest in the event of damage (when product liability law applies and the relevant functional safety standard must be demonstrated), that development was carried out in accordance with the current state of the art?
On the other hand, the key strengths of agile development are its short planning cycles and strong communication among team members. The challenge now is to extend these agile principles beyond pure software architecture and coding activities to include validation, verification, and documentation. This is the key to the successful agile development of functional safety (FuSi) projects.
The customer focus promoted in agile projects and the use of high-performing and motivated teams are essential success criteria for all projects. The application of agile methods to large-scale projects goes beyond the considerations presented here and was therefore not examined in detail.
Agile & Scrum – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Agile & Scrum.
Training & coaching on the other topics in our portfolio can be found here. here.
Agile & Scrum – Expertise
Valuable expertise on the topic of Agile & Scrum is available here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
