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.
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.
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.
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.
For an automatic notification on new blog articles, just register your EMail address.