Abstract
In order to develop a better understanding of the application of Scrum to IEC61508 certifiable software, we assessed the standard to see how Scrum could conform. Each section of part 3 of the standard was assigned one of the categories: (1) "OK" - no modification needed to Scrum or IEC61508, (2) "?" - need to be discussed, (3) "Not OK" - need adaptation of Scrum Based on our assessment we proposed the Safe Scrum where the main idea is separation of concerns. Everything that is not part of the software development process is kept outside Scrum and will thus not be influenced by our choice of paradigm. In Safe Scrum, all requirements are split into safety critical requirements and other requirements and inserted into separate product backlogs. We then did a new assessment where we took the Safe Scrum into consideration. We found 15 issues where we need changes in order to make the process acceptable to Scrum and the safety assessors: how to structure development, plan for validating safety, create, review, select, design and ensure safety, write requirements for module testing, and test and evaluate the outputs from the safety lifecycle The first part of our model consists of the IEC61508 steps of developing the environment description and the SSRS phases 1-4. These initial steps result in the initial requirements of the system that is to be developed and is the key input to the second part of the model - the Safe Scrum process. Using an iterative and incremental approach means that the project can be continuously re-planned based on recent product experience. Between the iterations, experience can be used to re-prioritize the product backlogs. This makes the process flexible. When the sprints are completed, a final RAMS validation will be done. Since most of the system has been incrementally validated during the sprints, we expect the final RAMS validation to be less extensive than when using other development paradigms. This will also help us to reduce the time and cost needed for certification.