An interesting discussion: whether agile methods are best suited for critical systems or not? The lack of formal documentation of agile methods is a drawback. I too believe in the absence of upfront planning and formal documentation is important to ensure traceability. That is the only way to ensure that the system is complying with the standards and regulations.
Apart from documentation, refactoring is also an issue with agile methods. A refactored code might invalidate a previously accepted certification. This would lead to additional rework. And since agile methods welcome changes at any change so upfront planning is not easy to be carried out. The iterative methods are considerably better at creating software with fewer flaws in less time than waterfall approach. However, regulatory standards forbid developers from releasing software to a live environment without been fully tested.
A new study supports that agile methods are not only feasible for safety-critical systems but probably profitable as well. Paige (2008) carried out a study for the development of critical systems using agile methods, where he analyzed the agile elements and processes. The key conclusion was that agile methods can be used for the critical systems by not replacing them with the plan-driven methodologies but instead by using them in suitable tasks. Gary (2012) is of the view that agile methods can be used for the open source critical systems as these approaches are synergistic with the security codes. Using agile, the process handling and software development can be carried out with strength. Ge et al. (2010) believe agile methods could be used for critical systems development but they are not directly suitable for the regulations. They came up with the idea of upfront design that would at the minimum give detailed information on risk analysis before the beginning of the agile process. Also, the iterations need to include information on the safety of the released products. Larger products can follow a modular approach where each of them is dependent on one another.
Mwadulo (2016) believes “The low adoption of agile methods for safety critical systems development is as a result of developers of these systems being too conservative and wanting to use the traditional methods because they have been tested and they are familiar with. This cannot be entirely blamed on them given the fact that the consequence of failure of such systems can be catastrophic. There is also the reason of an organization not wanting to make its internal operations public and as such would want to use a method that they already know. Also agile practices such as minimal documentation, refactoring of code, upfront planning and iterative release of project contradicts safety requirement standards of safety critical systems.” In critical system development, the main focus is on the safety whereas in agile methods the emphasis is on the quality thus, there is no contradiction.
References:
Gary et al. (2012) Agile methods for open source safety critical software. Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3142956/ (Accessed: 13 September 2017)
Ge, X., Paige, R. F., and McDermid, J. A. (2010). ‘An iterative approach for development of safety-critical software and safety arguments’, In Proceedings of the 2010 Agile Conference, AGILE ’10, pp. 35–43.
Mwadulo, M.W. (2016) ‘Suitability of Agile Methods for Safety-Critical Systems Development: A Survey of Literature’, International Journal of Computer Applications Technology and Research, 5(7), pp. 465 – 471.
Paige R. et al (2008) ‘Towards Agile Engineering of High Integrity Systems’, Proc. of 27th International Conference on Computer Safety, Reliability and Security (SAFECOMP).
