[SystemSafety] Software Safety Assessment

[SPRIGGS, John J]

With regard to Question 1:  It depends on your viewpoint; you may say it is an obsolete standard, but to me  it may be a well-tried, dependable, standard.  New is not always better.  Some people have to use a particular standard because a law or a Regulator says so; the rest of us choose to use a standard (and, I hope, justify its use in context) because it gives us some benefit to do so.  Just because some standards group up-issued the document does not make the previous version unusable - especially if it is one of those standards groups that have to be seen to be maintaining their stuff regularly...  You need to know what the changes are and check them against your justification - are they just clarifying (or even removing stuff because people have said "there are too many requirements") or are they fixing genuine errors?
Question 2:  I assume that the thing has not been in use for ten years without performance monitoring, incident monitoring, etc., that not only maintains safety, but also in some way validates the original assurance.  But the original claim is immaterial; what did it actually do, i.e. was the risk adequately managed?
... and Question 3: Project B could use the old check list as augmented with lessons learned in the intervening decade (which may be an entirely new checklist if the usage environment has changed too).

John

From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Carl Sandom
Sent: 08 July 2015 10:54
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: [SystemSafety] Software Safety Assessment

Consider the following scenario:

In 2004 Project A software was assessed against a safety standard (let's call it Standard X). Standard X had a very prescriptive list of software safety requirements and a simple checklist was used for assessing SIL1 compliance.

In 2014, Project B began to integrate significant new functionality into Project A. Standard X, which was by 2014 an obsolete standard, was used to assess the significantly smaller software baseline of Project B. Under modern scrutiny, the simple Standard X checklist used for Project A in 2004 was not as explicit as it could have been and it was decided to use an improved checklist for Project B.

A couple of important questions can be raised with this scenario:

1. Is it acceptable to use an obsolete safety standard to assess software?

2. Is the SIL1 claim for 10 year old Project A invalid because the checklist could have been better?

3. If Project B used the old checklist from Project A would that be adequate?

I've been having some interesting discussions with the Project Managers involved, any thoughts?

Regards
Carl

_________________________________

Dr. Carl Sandom CErgHF CEng PhD

Director

iSys Integrity Ltd.

+44 7967 672560

carl at isys-integrity.com<mailto:carl at isys-integrity.com>

www.isys-integrity.com<http://www.isys-integrity.com>

_________________________________

***************************************************************************
If you are not the intended recipient, please notify our Help Desk at Email information.solutions at nats.co.uk
immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose
their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to 
secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses
caused as a result of viruses and it is your responsibility to scan or otherwise check this email
and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd 
(company number 4129270), NATSNAV Ltd (company number: 4164590) 
or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). 
All companies are registered in England and their registered office is at 4000 Parkway, 
Whiteley, Fareham, Hampshire, PO15 7FL.

***************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150708/f5bed8f7/attachment.html>