Are you involved in the development of safety-related systems? Are you a software safety engineer, or a software engineer with responsibility for safety?
You are? Fabulous news! Do you have time for a quick chat? You do? Brilliant – please get in touch!
Actually, regardless of whether your status matches any of the above, if you have an interest in better supporting the safety of software, then please do sit comfortably, and I’ll begin, as it where (fear not, it isn’t that long…).
OK, to the pachyderm in the building first…
Yes, we know software is an entity and it is neither safe nor unsafe (*insert yawn emoji at your pleasure*)…and yes …by software safety assurance we DO mean the contribution software makes to assuring a safe state…and yes, we know – that is a system property (*insert another yawn emoji*).
Right, now the be-trunked pachyderm is suitably dealt with, to the matter in hand…
Firstly, the things we can (I hope) all agree on. Forgive the abbreviated and bulleted form, but you don’t have long for your tea break):
- In design, safety is argued to be achieved through the identification of hazards and the mitigation of said hazards
- Required mitigations are often expressed as safety requirements
- Safety requirements are to be carefully managed (elicited and further derived) as the level of design granularity increases…down to the software boundary and beyond
- Such an approach is consistent for both product- and process-based assurance processes
- Such an approach is consistent whether it is a traditional ‘waterfall’ or ‘agile’ development lifecycle
- One cannot possibly know all safety requirements up-front at the beginning of a project
- Whilst not volatile, safety requirements are not static, and they do evolve
- Safety requirements should be SMART.
So why on earth are we so poor when it comes to managing software safety requirements? Or ARE we as poor as we think we are when it comes to software safety requirements? We do believe that the state of good practice hasn’t transferred completely to the state of practice yet, so we want to establish whether that is the case, and why.
We suggest that there are many potential impediments to the adoption of best practice for software safety assurance (through the careful management of software safety requirements), and we predict that some impediments will be of a socio-technical nature. However, whilst we have many predictions and theories as to the existence and causes of impediments, we want firstly to understand and identify those that are preventing best practice for software safety assurance throughout the system design lifecycle.
Then, and only then will we seek to understand whether software safety assurance guidance and/or assurance practices need to change – proposing mitigation research areas that will help in their mitigation.
We’ve created a model of the stages of software safety assurance, which we ever-so-cleverly call our 3D model:
- As Desired
- As Described
- As Done
(You see…? 3 x Ds…genius)
There are actually 10 inter-relationships at play here – but we’ll reveal more of that imminently (soon to be published). For now, we want to understand the 3rd D better – how software safety assurance is carried out at the keyboard/desk as it where (I did write ‘coal face’ originally, but any form of mining must rightly be left to the data boffins).
Can you spare some time for a quick chat? If you can, we’d be eternally grateful.
What will you and your company get out of all this I hear you ask? Well, once the research concludes later this year you will get…
…Standby for my elevator pitch…although depending how quickly you read, it may end up being a very slow elevator…in a high rise…in Tall Town…
Participation in the empirical research will provide you and your organisation with:
- An easily understandable representation of the safety lifecycle
- An easily understandable representation of the software safety assurance process
- An understanding of how software safety assurance is carried out by those charged with its implementation
This will enable you and your organisation to understand:
- Whether the software safety lifecycle has considered all aspects (who needs what, by when, in what format, to what end)
- The levels of compliance and agreement of organisational practice with any Open Standards
- The relationships between work as desired, described and required
- Whether there are any shortfalls in meeting legislation and/or standards
- Whether there are any nugatory activities that add no safety benefit
- Whether internal processes and open standards are realistic when considering commercial, legislative, and contractual complexities
- Whether resource could be more efficiently redeployed to activities that improve/attain safety
- Whether the workforce experience difficulties in undertaking organisational safety processes
- Whether the workforce is circumventing documented safety processes for the benefit of both safety AND the organisation
- Whether there are any instances of ‘wilful compliance’ (where the workforce carries out work that they know adds no value).
Other organisations involved in the research have also used the provided representations to update internal processes and used them in support of a competency framework and training needs analysis.
…but please don’t worry – this elevator pitch and the outcomes described represent the entire research project. We just want a quick chat…please. Just head to ‘Contact Us’. Speak soon!