There is a belief amongst many that functional safety standards mandate the V-model, and that other approaches (including Agile) are incompatible with a safety culture. Others take the view that such an approach is impractical in an era when the rate of change of technology and requirements, and the demand for software, are all rising exponentially.
As with most such confrontations, there is perhaps truth on both sides here. Functional safety traditionalists will point at the impressive track record of standards that largely follow the same mantra of requirements first, requirements central, requirements always.
On the other hand, it is a fact that functional safety standards pay little more than lip service to the idea that software can be an intellectual modelling clay; a medium to try, fail, improve, and hone ideas that are malleable and interactive in a way that the writing of requirements can never hope to match. Agile development supports that principle much more closely.
This paper will explore the background to this dilemma. It will and consider the objectives and outcomes specified by the standards, and whether the V-model is a necessary requisite for conformance.
It will assess how other methodologies fit within a safety lifecycle and explore the alternative ways of fulfilling those required objectives and outcomes, and whether such alternative approaches are compatible with a safety culture.