Embedded Office Blog

Embedded Market, Basics, Functional Safety, Embedded Security

Portfolio Projects

Do it right: AGILE Development in Safety Projects

by Embedded Office (comments: 0)

Introduction

Agile's streamlined processes tend to accelerate development and add business value, but require careful consideration in projects when safety is critical. In this post, we review some specific detail, including management and development pointers to help get the project balance right and meet the necessary standards.

Business value through ongoing validation

Firstly, under Agile, one of the top priorities is customer satisfaction through the early and continuous delivery of new software. In safety-critical development contexts, however, this guiding aim takes on a special meaning: early releases must still be safe, apart from being able to add value. A validation process is necessary, therefore, to analyse and evaluate the possible risks and hazards. Ideally, this assessment should be ongoing, although it does not have to be automated. In fact, active human intervention may well be desirable.

Flexible architecture and planning for changes

Secondly, Agile methodologies welcome change – even when updated requirements arrive late during the development process. In such cases, the need to alter specifications may sit uneasily with developers who are finalising and testing code modules. Nonetheless, Agile is about harnessing the power for change and converting it into a competitive advantage for internal and external customers. Notably, in development environments, safety demands should not delay sensible changes that also provide business benefit – though there is an obvious condition that they must not compromise integrity, performance or personal security. To bring this about, planning and control need to be thorough and system architecture flexible.

Timescales

Regarding typical software development cycle durations, Agile environments might strive for periods between two weeks and two months, with a preference for the shorter timescale. In contrast, and following the principles to which we alluded above, periodic releases in safety-critical projects must not reduce standards.

Commitment to safety

Team members must be highly familiar with and fully committed to safety principles. To meet this responsibility, they will need sufficient tools and resources. Teams must be motivated with the necessary support and technical environment they need, then allowed to get the job done.

Safety information can be shared in face-to-face meetings and given a proper place in project meetings. Mentioning the subject briefly or only in assessment reports is unlikely to be sufficient. The ultimate measure of working software and progress includes software that is both safe to use and meets specifications.

Sustainable pace

Technical excellence and good design are as important with safety-critical applications as they are with any other software. The pace of development, therefore, should be constant but sustainable over time. Common sense dictates that exhausted staff constitute a risk to safety standards. It is no more advisable for overworked engineers to design critical systems or work on intricate projects than it is for fatigued workers to operate hazardous machinery.

In addition to limiting normal working hours, therefore, staff turnover due to burnout also needs to be minimal, or preferably zero. Just like any other development activity, staffing needs ought to be properly resourced.

Simplicity

Simplicity usually adds to safety margins by reducing unnecessary complications. Accordingly, teams should be free to design safety features, although they may not change the underlying obligations. An appointed person is responsible for safety matters and has a final vote, with independent validation if necessary.

In addition to regular self-appraisal and fine-tuning of work behaviour, the responses to safety requirements and the attainment of corresponding goals are suitable and relevant metrics for inclusion in regular reports.

Safe ways of working

Safety specialists will want to make sure that developed solutions are stable, that they function correctly and, above all, do not respond erratically. Intermittent glitches, defects and failures could mean inconvenience or disaster, with financial and human consequences apart from damage to corporate reputation.

The authors of prominent Polish research (published by the Department of Computer Science in the Krakow-based University of Science and Technology) investigated the topic of safe working under Agile. As detailed in the online Computer Science Journal in 2012, their initial study assessed the risks of hybrid systems from a software engineer’s perspective. In essence, hybrid solutions employ a balanced approach that blends Agile methodology with disciplined assurance techniques and careful risk mitigation. For instance, software engineers might use pair programming methods with peer validation while automated tools deliver substantial time savings by generating documentation automatically from source code.

Some four years later in 2016, the duo monitored another team of junior software engineers using Agile in safety-critical project work. Their ensuing analytical report mentioned that:

  • Agile methodologies are best viewed as a complementary tool when planning driven practices, instead of as a replacement for safety structures.

  • Thorough identification of requirements and acceptance testing are vital.

  • Contact with domain experts and potential users is also essential.

  • Safety assurance procedures should be incremental and carried out in parallel with iterations in development.

Incrementality requirements can be achieved through pipelined iterations. In practice, this means distinguishing minor iterations from major ones, with extended safety acceptance testing at the end of major cycles.

Although Agile does generally require system properties to be incremental, this may not always be feasible in projects where safety is paramount.

Safety and regulatory considerations

Where business staff and developers work together, the team will also need to include members who are responsible for safety assurance. Routine assessments and the analysis of risks and hazards then become part of the team effort, although specialised and independent professionals should continue to oversee testing and inspections as necessary.

Furthermore, regulatory requirements might well supersede the practice of involving customers or other groups of stakeholders. This is especially the case when external certification bodies and inspections play supervisory or enforcement roles.

SUMMARY

Although it may not be possible to replace the standard V-model entirely in lifecycle management, Agile represents a valuable business tool. Used correctly, the methodology can maintain the quality and effectiveness of systems under development. The practical points we have considered here have special relevance when deploying Agile methodologies within safety-critical projects.

Although it is clear that Agile delivers clear business benefits, particularly from the users’ or business points of view, various additional refinements are essential to assure maximum safety, avoid unnecessary inconvenience and prevent failure(s). Efficient planning and good coding practices help to avoid negative outcomes; they also ensure the highest standards of safety with the minimum likelihood of troubling glitches, intermittent faults and systemic defects or accidents. Finally, proper attention is necessary to ensure organisational compliance with professional verification and inspection standards, as well as regulatory requirements.

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.