heaven or hell the marriage between iec 61508 and …€¦ · the marriage between iec 61508 and...
TRANSCRIPT
Heaven or Hell
The marriage between
IEC 61508 and Scrum
Tor Stålhane, NTNU
Even Andre Karlsson, Addalot
Agile development of safety-critical software
We present two approaches to using an agile approach to the development of safety critical software.
• T. Stålhane, IDI / NTNU, present SafeScrum’s point of view
• E.A. Karlsson, Addalot, present an alternative more agile view
In the end we hope to have some points of discussion or agreement
SafeScrum
Tor Stålhane
NTNU
SafeScrum – the what’s and why’s
The top concerns of SafeScrum:
1. Comply with IEC 61508
2. Few changes to SafeScrum. Affect only the
software part – separation of concerns
3. Stay true to the most important agile
principles:
a) As little documentation as possible
b) Improve project communications
c) Embrace changes
Development process
The SafeScrum
domain
SafeScrum – Separation of concerns
The SafeScrum model
for IEC 61508
Environment
description
RAMS
validation Scrum
Backlog
SSRS
Phases 1 – 4
Operation
Phase 14
Modifications
Phase 15
Parts of Annex
A.1 – A.7B.1 – B.3
B.7 – B.9
New safety
requirements
High level
plans
Parts of Annex
A and B
Why separation of concerns
Separation of concerns in order to
• Keep the changes to the standard-defined
development process as small as possible
• Let the software developers focus on what
they are good at – producing high quality code
Add-ons to Scrum
Why do we need the add-ons
The add-ons are used to be compliant with the
IEC 61508.
• Maintain traceability of safety requirements:
– Separate functional requirements and safety
requirements
– Add a trace activity in each sprint
• Perform a RAMS validation after each sprint
Challenge – change impact analysis
To quote an anonymous developer:
“After the first increment, all the rest is
maintenance”.
We thus need
• To consider change impact analysis
throughout development
• A more complex SafeScrum model
Change Impact analysis and the product backlog
Functional and
RAMS validation
Function
product backlog
Safety
product backlog
Sprint and
validation
results
Change
Impact
Analysis
Changes to
the SSRS
Change rejected
Changes to SW
env. and HW
Changes to safety
req’s and complex
functional req’s
Changes due
to anomalies
from test
1
3
2
How do we handle the challenge
Our main concerns:
• IEC 61508 has strict requirements on change
management that need to be met
• Agile development is about embracing change
We cannot put so many restrictions on change
that we kill agility
Changes to consider
Need to consider changes
• to existing safety requirements
• that will influence code that directly or indirectly belongs to a safety
requirement.
These changes can be categorized into two classes:
• Simple changes. The developer categorizes the change as simple,
perform a CIA and document why he has made this decision
• Not-simple changes. Those that concern safety requirements
– Use trace information to see what parts of the code will be
affected
– Check the code for potential impact on safety in a code review
– Make a decision – change or not – and write a report.
Conclusion -1
IEC 61508 in an agile setting is a large topic and
include components of
Heaven – an agile way of working
Hell – a lot of rules and regulations, depending
on the SIL
Even-André Karlsson
Incremental development and Safety
© Addalot Consulting AB - All rights reserved
Prove that you have done
what is needed
Ensure that the system is
safe; safety req => solution
Ensure that no SW errors
are introduced
High level activities
� 3-7 Hazard analysis and risk assessment
� 3-8 Functional safety concept
� 4-6 Specification of the technical safety requirements
� 4-7 System design
� 4-8 Item integration and testing
� 4-9 Safety validation
� 4-10 Functional safety assessment
� 4-11 Release for production
� 6-6 Specification of software safety requirements
� 6-7 Software architectural design
� 6-8 Software unit design and implementation
� 6-9 Software unit testing
� 6-10 Software integration and testing
� 6-11 Verification of software safety requirements
16
© Addalot Consulting AB - All rights reserved
Possible safety increments/sprints
1. Safety concept (20% into dev)=> Safety requirements added to back-log
2. Defensive software design (50% into dev)
3. Safety test on sw level (60% into dev)
4. Safety verification and validation (70% into dev)
5. Review previous safety activities (80% into dev)
6. Final safety increment
Assuming 14 two weeks sprints = 28 weeks:
X X 1 X X X 2 X 3 X 4 5 X 6
6 of 14 sprints are safety focused. In addition there are safety requirements to be implemented
17
© Addalot Consulting AB - All rights reserved 18
© Addalot Consulting AB - All rights reserved
Concept activities
� 3.5 Item definition
- We assume that enough is known about the “item” after the first two functional sprints. If this changes, we have to redo/complement some of the other activities.
� 3.6 Initiation of the safety lifecycle
- It should already be clear if this is development from scratch or modifications. This presentation only discuss development from scratch, but could perhaps be applicable for modifications as well.
� 3.7 Hazard analysis and risk assessment
- One of the main activities of the first safety sprint
- 7.4.2 Situation analysis and hazard identification
- 7.4.3 Classification of hazardous events (severity, probability, controllability => ASIL)
- 7.4.4 Determination of ASIL and safety goals
- 7.4.5 Verification
� 3.8 Functional safety concept
- Another main activity of the first safety sprint
- This results in a set of “functional” safety requirements that can be implemented in sprints
19
© Addalot Consulting AB - All rights reserved
Defensive software design increment (1)
20
Note 1f will require much more work, and has to be planned up front as separate
sprints
© Addalot Consulting AB - All rights reserved
Defensive software design increment (2)
21
© Addalot Consulting AB - All rights reserved
Software safety test increment
22
© Addalot Consulting AB - All rights reserved
Conclusion
Each sprint is completed with defined exit criteria
1. Hazard analysis to determine functional safety requirements=> Hazard analysis and functional safety requirements added to backlog
2. Functional safety requirements are implemented in sprints with ”normal testing”=> Normal design, but with required safety documentation
3. ”Defensive software design” is done in separate sprint=> Analysis and documentation of ”defensive software design”
4. Additional safety testing=> Analysis and documentation of ”safety testing”
5. Safety validation is summarized in last increment=> Safety case
23
© Addalot Consulting AB - All rights reserved
Advantages of a focused incremental approach
� Focus the whole team on safety activities
� Able to bring in experts to help out
- Early sprints, experts on
- FMEA, FMECA on a high level
- FTA
- Later sprints, experts on
- Defensive programming
- Safety Testing, e.g. boundary testing, error injection
� Ensure that the safety activities are done
� Implementing the functional safety requirements in sprints will improve the ”automatic” traceability
24
Where do we go
from here
Tor Stålhane,
NTNU
Even Andre Karlsson, Addalot
Where do we differ – 1
Planning
• SafeScrum – planning is kept outside
SafeScrum. Reduces the impact on the
development process defined by the standard
• Addalot - planning is done as part of the
sprints. Involves the whole sprint team in the
process from the start
Where do we differ – 2
Process
• SafeScrum– Only the software development part is influenced
– Safety experts and domain experts are brougth in when needed
• Addalot– The whole development process is made agile
– We assume that enough is learned about the system in the first two sprints to do the safety analysis
– Focused use of safety experts – designated sprints
Where do we differ – 3 Safety concerns
• SafeScrum
– safety requirements are kept in a separate backlog but otherwise treated as other requirements
– RAMS (Reliability, Availability, Maintainability and Safety) validation added at the end of each sprint
• Addalot
– safety concerns are handled in designated sprints
– safety requirements are treated as other requirements
Summing up
Addalot:
We make the whole development process agile
NTNU / SINTEF:
We interfere as little as possible with the
process defined by the applicable standard
This is our challenge!
Questions? Comments?