Software Guidance for DS 00-56 Issue 3

John McDermid

2

ContentsIntroduction and Objectives

Overview of MoD/Dstl work

Available Standards and Guidance

MoD Requirements

Representing Guidance

Legacy and COTS

Developing Guidance

21

Feedback 1Feedback reflects consensus items

More detail recorded

Who is the guidance intended for?Four possibilities

DevelopersDesk officers in IPTsISAsRegulators

ConsensusPrimary guidance is for desk officers in IPTsThis will have some value for the other communities, e.g. setting

expectations for developers

22

Feedback 2Principle underlying IDS 00-56 Issue 3 “as civil as

possible, only as military as necessary” Question

For software, is civil (level of evidence) sufficient?Consensus

Military systems are more demanding, hence we have to look at more demanding forms of evidence

Levels of criticalityNB 56 Issue 3 Part 2 has High, Medium, LowConsensus, need to distinguish

Safety criticalSafety relatedNot safety related (none)May also need strong arguments supporting non-interference

23

Feedback 3Question about how guidance should be represented

ConsensusExample safety case patterns, with evidence typesNeed to be multiple examples, to avoid risk of examples becoming

the default

Also produced some illustrative examplesTop level argument

ProductProcessContinuous independent assessment

Specific issuesFreedom from run-time failuresSatisfaction of functional and safety requirements

24

Feedback 4Discussion of legacy and COTS

As 56 Issue is goal-based, approach still appliesConsensus – need

Guidance on data collection for “proven in service” argumentsGuidance on making arguments comprising “direct” evidence and

service data – especially on what is ALARPLegal guidance on grandfather rights, and how access to data, IP

etc. impacts argument, especially ALARP

Development of guidanceNeeds MoD and industry working together

Industry group excluding MoD possible, but less valuable

Ideally a task for the SSEI