Agile development is a much better fit with IEC 61508 compliant software development than one might think at first blush.

Agile is not a methodology but rather a set of values and principles stated in the Agile manifesto. These principles are designed to force introspection and reflection to foster development teams that are efficient, self-motivating, self-sustaining, effective and in a state of continuous improvement. These concepts fit well with a proactive safety culture.

So, then the question is:  

How do you implement an Agile system for safety critical software?

Well, that is up to you!

A widely adopted Agile framework for conventional software development is “Scrum”. Scrum is popular because it is a simple and flexible framework when implemented correctly reduces development time and provides transparency into the development process. It is a continuous inspect and adapt framework at multiple levels. The Scrum team is comprised of 3 main roles; Product Owner, Scrum Master and team. Some of the concepts used in Scrum are; Sprints, Product Backlogs, and User Stories. Scrums are implemented in Sprints which are time-bounded development cycles, typically 2 weeks in length, but no more than 4 weeks, which are driven by the product backlog which is simply the prioritized list of customer centric features. A User Story is ultimately a use case for the product that drives features. A Scrum produces fully tested, functional software that implements the features in the backlog.

So how does this apply to safety critical software? Or does it?

One of the main tenets of IEC 61508 is reducing systematic faults. That is accomplished by having a well-defined, documented, predictable, auditable process for software development of safety functions. The rigor of the audit is based on the SIL level (systematic capability) targeted.

IEC 61508 defines a safety lifecycle with 3 main phases; analysis, realization and operation. It starts with a concept and ends with the decommissioning of the safety system and the end of its useful life. Methods are built in for assessing and mitigating risk such as risk assessments, validation testing, configuration management, verification, change management and impact analysis.

Typical implementations of Scrum do not include the rigor required for developing safety critical software. They only address a subset of the required safety development lifecycle. User stories and the backlog are not sufficient to define safety software requirements. There are some “safe Scrum” concepts presented in papers but they fail to consider requirements such as documenting personnel roles and competencies and development tool qualifications.

Software development can be very difficult to define and control. When the Agile concept emerged, it was tempting to indiscriminately jump on board with the notion that it would automatically lead to better quality software, delivered on time.

For safety critical software development, there are other Agile practices that can be tailored to fit within the safety lifecycle.

An example of an Agile practice that can improve safety critical software development is Test Driven Development (TDD). This is the practice of developing module tests prior to the source code. This method forces you to think through your requirements before you write the code and provides a means of verifying that the implementation meets the design requirements.

Another Agile practice that is easily assimilated into the safety lifecycle is continuous integration. This is an iterative code, test, build cycle where functionality is added and verified on each successive build. This minimizes the impact of code bugs since they are tested out early in the development cycle. For this to be effective, it is crucial that these cycles are measured in hours and not days or weeks as in traditional water fall methodology. This method improves the probability of delivering bug free code at each release.

So, if you think that Agile methods can improve your safety critical software process, have at it! But remember, you will still need to be IEC 61508 compliant to have your system certified.

Tagged as:     software     SIL     Scrum     IEC 61508     Anthony Romano     Agile development  

Other Blog Posts By Anthony Romano