Authors: Ingo Nickles, VectorSoftware, Martin Heininger, HEICON<\/p>\n
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.<\/strong><\/p>\n Let's first take a look at the original text of the Agile Manifesto (see Figure 1,\u00a0PDF<\/a>The 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.<\/p>\n 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."\u201e<\/p>\n This is where the often-discussed self-organizing teams come into play. Furthermore, motivated and high-performing teams are a prerequisite.<\/p>\n Furthermore, the following principles suggest that the founders of the Agile Manifesto had smaller projects in mind:<\/p>\n \u201e"Deliver working software regularly within a few weeks or months, and prefer the shorter timeframe."\u201c<\/p>\n \u201e"The most efficient and effective method of conveying information to and within a development team is through face-to-face conversation."\u201c<\/p>\n These are, in summary, the three most important elements on which the Agile Manifesto is based.<\/p>\n 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:<\/p>\n There is no method that guarantees error-free software development! A single error can endanger human lives!<\/p>\n 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.<\/p>\n The main contents are here:<\/p>\n 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.<\/p>\n As shown in the following diagram (see Figure 2,\u00a0PDF<\/a>As illustrated, these activities were not the focus of the Agile Manifesto.<\/p>\n If one wants to carry out FuSi projects using agile development methods, the following potential areas of conflict arise (see Figure 3,\u00a0PDF<\/a>The 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?<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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?<\/p>\n 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.<\/p>\n 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.<\/p>\n Download the article as a PDF<\/a> Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topic of Agile & Scrum.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise on the topic of Agile & Scrum is available\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\n\n
Principles of developing safety-critical, embedded systems\/software<\/h2>\n
\n
conclusion<\/h2>\n
Conclusion<\/h2>\n
\n<\/strong><\/p>\n
\nAgile & Scrum \u2013 our training & coaching<\/h2>\n
\nAgile & Scrum \u2013 Expertise<\/h2>\n