Meshing agile and plan-driven development in safety-critical software: a case study

Abstract

Organizations developing safety-critical software are increasingly seeking to create better practices by meshing agile and plan-driven development processes. Significant differences between the agile and the plan-driven processes make meshing difficult, and very little empirical evidence on using agile processes for safety-critical software development exists. There are four areas of concern, in particular, for meshing the development of safetycritical software concerning: documentation, requirements, life cycle and testing. We report on a case study of a pharmaceutical organization in which a Scrum process was implemented to support agile software development in a plan-driven safety-critical project. The purpose was to answer the following research question: For safety-critical software, what can a software team do to mesh agile and plan-driven processes effectively? The main contribution of the paper is an elaborated understanding of meshing in the four areas of concern and how the conditions for safety-critical software influence them. We discuss how meshing within the four areas of concern is a contribution to existing research.

Goals and challenges in hybrid software development approaches

“…This means to be adaptable to requirement changes or changes in the technology choices. One means to reach this goal is to have an iterative development 48,52 . Iterations enable companies to get constant feedback from the customer and stakeholders and plan for new or changing requirements.…”

“…The most often goal that is mentioned is the meeting of safety, security, and regulatory requirements . The means that is most often described to meet this goal is an up‐front requirements analysis 44,50‐52 . Also, an up‐front architecture design is used as a means 47,48 .…”

“…Similar to the description of more effort up‐front is also the use of a testing phase at the end of the project described 42 . Also, a up‐front hazard analysis is described to support the meeting of safety requirements 52 . Further, the use of the V‐Mode 4 and the PM 65 is mentioned.…”

“…It is important to react fast to requirement changes in order to not lose momentum 59 . The difficulty is that often a high effort is needed to change high‐level requirements or specifications 50,52,59 . Also, the analysis of the impact of changes requires time and effort 59,75 .…”

“…Projects need often both up‐front and continuous requirements engineering. The challenge here is to decide how much effort should be invested for the up‐front requirements analysis and the level of detail in which requirements are elicited 52 . Too little effort, in the beginning, can lead to requirements on a too high level that are not really understood and not sufficient enough 52 .…”