Embedded Office Blog

Embedded Market, Basics, Functional Safety, Embedded Security

Portfolio Projects

AGILE Software Development and Safety: Two Worlds?

by Embedded Office (comments: 0)


In project teams and boardrooms throughout the world of IT, decision makers are already well aware of the value that Agile methodologies can add to a business. The dual attractions of satisfied customers and reduced time spent on conventional specify–build–test–implement iterations speak for themselves. However, what of safety-critical systems? Might Agile’s streamlined and accelerated processes affect the ability to get product releases right and, consequently, compromise standards? Is there a limit to how lean and finely tuned organisations, IT operations and development processes can become? Here, we discuss the possible answers to these topical and crucial questions and whether, in essence, agility and safety are two mutually exclusive or incompatible worlds.

Business benefits

As a forward-thinking and customer-focused methodology, Agile ensures that it is the business units and project goals that drive the software development processes. At the same time, its innovation and customer focus tend to cultivate an environment that delivers timely results that meet or exceed expectations. Additionally, the methods allow the limitation of core investment before more extensive rollouts, i.e. scaling. The newer and more flexible techniques mitigate the risks (or the consequences) of failure, while a shared, common platform serves to unify and speed up code development.

Getting it right

However, there are some key considerations to factor into the equation. When considering whether to adopt Agile, the most important factors are the nature and objectives of the task. Projects vary and may include elements of analytics, robotics, AI (artificial intelligence) or device control. In the case of mission-critical work, safety is paramount. Automated infrastructure and transport systems, for instance, demand that the solution works correctly, is stable and does not behave erratically. Otherwise, glitches or failures could give rise to a host of undesirable and potentially costly outcomes, ranging from inconvenience to disaster. In addition to preventing injuries and fatalities as well as financial loss, there is also the corporate reputation to consider.

When analysing the challenge(s) of applying Agile practices to projects where safety is critical, one might turn to Polish research published by the Department of Computer Science in the Krakow-based University of Science and Technology. In April 2012, this eminent technical authority disseminated a study in their online Computer Science Journal, which investigated the subject in considerable depth. Its authors, Janusz Górski and Katarzyna Łukasiewicz, assessed the risks of hybrid ways of working and reported in detail from a software engineer’s perspective.

Case studies

The Polish study concluded that there was a growing body of evidence in support of the theory that incorporating Agile methods into safety-critical projects was not merely feasible but also potentially profitable. The authors cite various examples and case studies, some which were well documented by those involved and others that, unfortunately, lacked corroborative detail.

Some specific examples listed by the Polish researchers started from as early as 2003 when Alleman et al. incorporated Agile in an FDA (US Food and Drug Administration) regulated project to respond to rapid market changes, variations in production requirements and a driving need to reduce costs. At the time, the company employed a software engineering consultancy that used Agile+ to improve its processes and achieve the required financial goals, while still complying with FDA safety assurance requirements.

Regulatory considerations

In a later example, Paige et al. got to grips with the key challenges that are inherent to formulating a hybrid approach. Citing concerns about communication, documentation and customer participation, the group also considered multiple-domain engineering and testing – as well as incrementality. Although Agile requires system properties to be incremental, this is often not feasible in those systems where safety is all-important. Additionally, regulatory requirements might well supersede the Agile practice of involving customers (or other groups of stakeholders), as external certification bodies and inspections play supervisory or enforcement roles.

There were other flies in the ointment. Black box testing and incrementality are both crucial to Agile development but may be difficult to reconcile with safety requirements, which require time-consuming white-box and acceptance testing to satisfy the said certification bodies. Put another way, an incremental approach to development (specified under Agile) could well impede safety preparations and certification procedures, where all of the risks and corresponding measures have to be evaluated and addressed in advance.

A hybrid solution

Having considered all these factors, the detailed solutions centred on balancing an Agile approach with risk mitigation and disciplined assurance techniques, in an attempt to combine the best of both worlds.

In particular, suggestions included:

  • Pair programming working methods for software engineers.

  • Introducing risk management techniques.

  • Using automated tools to generate documentation from source code.

  • Dealing with incrementality by pipelined iterations, i.e. minor and major iterations with acceptance tests at the end of major cycles.


The above points were put to the test on a project to develop an Integrated Altitude Data Display System (IADDS) for aircraft, where the new approach led to some interesting findings. Although the Agile practices employed were not designed explicitly with safety systems in mind, it was still possible to adapt them for use in such a development environment. Notably, however, neither project engineers and management nor the report's authors envisaged that the most safety-critical software (termed level A software under DO-178B assurance standards) could move in its entirety to the newly invented process. Nonetheless, they added that the experience of adapting Agile methodologies to the mission-critical IADDS project had been valuable. The experts also commented on a continued need to improve the guidelines for such software development projects so that they were more comprehensive, yet easier to follow.

Today, experienced engineers point to how safety standards describe the V-model for development process – and for good reasons. In summary, although it may not be possible to replace the V-model entirely, both development philosophies could be used in parallel to complement each other and, therefore, improve the quality and effectiveness of safety systems under development.


In this analysis, we have considered the case for and the previous form of obtaining significant benefits by introducing Agile methodologies within safety-critical projects. While it is possible to increase the agility of development processes, we have also seen that it is necessary to consider some of the potential pitfalls with care. In particular, compliance with regulations is of particular importance to ensure the correct delivery of safe, functional and glitch-free systems. In the next blog post, we will look at some specific measures and how to combine agility with safety awareness as gainfully as possible.

Go back

Update Notification

For an automatic notification on new blog articles, just register your EMail address.

We are the Blogger:

Andrea Dorn

After my study of industrial engineering I worked at an engineering service provider. As team leader and sales representative, I was responsible for customers from aviation and mechanical engineering. I am part of the Embedded Office team since 2010. Here I am responsible for the Sales and Marketing activities. I love being outside for hiking, riding or walking no matter the weather.

Fridolin Kolb

I have more than 20 years experience in developing safety critical software as developer and project manager in medical, aerospace and automotive industries. I am always keen on finding a solution for any problem. The statement “This won’t never work”, will never work for me. In my spare time You can find me playing the traverse flute in our local music association, spending time with my family, or in a session as member of our local council and member of the local church council. So obviously I am lacking the ability to say “No” to any challenge ;-).

Michael Hillmann

I have been working for 20 years in safety critical software development. Discussing and solving challenges with customers and colleagues excites me again and again. In my spare time I can be found while hiking, spending time with my family, having a sauna with friends - or simply reading a good book.

Wolfgang Engelhard

I’m a functional safety engineer with over 10 years of experience in software development. I’m most concerned with creating accurate documentation for safety critical software, but lately found joy in destruction of software (meaning I’m testing). Spare time activities range from biking to mentoring a local robotics group of young kids.

Matthias Riegel

Since finishing my master in computer science (focus on Embedded Systems and IT-Security), I’ve been working at Embedded Office. Before that, I worked with databases, and learned many unusual languages (like lisp, clojure, smalltalk, io, prolog, …). In my spare time I’m often on my bike, at the lathe or watching my bees.