In the first part of the blog, we have considered the principles of agile development and the functional safety development. Based on these principles, I want to debate possible areas of conflict in this blog, if you want develop agile in functional safety projects. As well, I want to give an idea about the opportunities that may arise from this innovative approach. Read more
I’m convinced that agile development is an mean to achieve an more efficient software development process. However, it is also in discussion whether its possible to development in accordance with the functional safety standards if you use agile development methods. As a motivation for this blog, the following questions served me:
- Do you use agile development methods and you have upcoming functional safety projects? Under which conditions does this work?
- Do you develop safety-critical embedded systems in industries such as: railway, aeronautics, automotive, medical technology and automation technology? Is it possible to use agile development methods in such an environment?
In the first part of this blog, I consider the respective poles (agile development and functional safety development) for themselves. In the second part, I will discuss, what you should consider, if you have to bring these very different worlds together. Read more
In the last 10 years, the term “Functional Safety” has found its way into many development departments. This goes along with the increasing popularity of electronic systems. For mechanical devices and systems, there are decades of experience, how to design and build it, so that there is no danger for the user and the environment because of the function of these systems and devices. For example, there are provisions, which mechanical protection devices must be installed, so that an operator of a saw can’t push his fingers into the blade.
The dangers that may result from the function of electronic systems are usually not immediately to see and recognize. Nevertheless, they are naturally present. Read more
When I reflect the current state of requirements engineering, then I recognize the following:
- There are a number of good tools for documenting requirements
- There are good and established methods for creating natural language requirements
- There are still relatively few standardized methods to properly handle recurring categories of requirements