RE: [sc] life cycle data \ processes for DO-178B level-D



RE: [sc] life cycle data \ processes for DO-178B level-D

From: SPRIGGS, John J <John.SPRIGGS_at_xxxxxx>
Date: Fri, 17 Jun 2011 09:39:00 +0100
Message-ID: <13F38CD629737E4693C3EBD7B481A8B4032D43B1@xxxxxx>
There does seem to be a general confusion between Assurance Standards
(RTCA/DO-178B is a de facto assurance standard) and Development
Standards, such as ISO/IEC 12207:2008.

It is not unusual to see a Customer Requirement that states, "The
software shall be developed to RTCA/DO-178B", or similar.  The Customer
gets upset when you say that you can't do that.  Some would go on to
state that your ISO/IEC 12207:2008 compliant set of development
processes is not good enough; it's RTCA/DO-178B or nothing.


John
-----Original Message-----
From: safety-critical-request@xxxxxx
[mailto:safety-critical-request@xxxxxx] On Behalf Of Dewi Daniels
Sent: 17 June 2011 09:16
To: safety-critical@xxxxxx
Subject: RE: [sc] life cycle data \ processes for DO-178B level-D

Kuper,

The question you should be asking is not, "Which life cycle data /
processes
can be omitted for developing in accordance with DO-178B Level D", but
"Which life cycle data / processes do not need to be provided as part of
the
certification evidence for DO-178B Level D".

You're correct that DO-178B does not require software requirements
standards, software design standards or software code standards to be
provided to the certification authority at Level D.  See Table A-1,
objective 5.  You may still want to have company standards, because they
improve consistency and make the software more maintainable.

DO-178B does require a Software Verification Plan at Level D.  See Table
A-1, objectives 1-4.  DO-178B does not necessarily require a separate
document.  For example, the Software Development Plan and the Software
Verification Plan could be merged, especially at Level D.  See section
11.0.

DO-178C is likely to state that low-level requirements and source code
are
no longer required to be provided as part of the certification evidence
for
Level D (Table A-2, objectives 4-6).  This is because the emphasis at
Level
D is on black box testing of the executable object code against the
high-level requirements.  It is already the case that the objectives
relating to low-level requirements and source code do not apply at Level
D
(Table A-4, objectives 1-12 and Table A-5, objectives 1-7).  This does
not
mean that we advocate omitting low-level requirements and source code,
only
that they do not need to be provided to the certification authority.  It
would be an incredibly foolish organisation that coded in binary
directly
from high-level requirements (and such a process would be prohibitively
expensive)!

I'm concerned that your debate seems to be centred on which life cycle
data
/ processes can be omitted.  When dealing with safety-related software,
even
at Level D, your first question should be, "what do I need to do to
ensure
that my software is safe for its intended purpose" and only second, "how
can
I do this most cost-effectively".  There are many things that you can do
to
improve the efficiency of your software development and verification
processes other than omit data and processes.  For example, you could
use
tools and programming languages that detect errors earlier and more
cheaply.

Yours,

Dewi Daniels | Managing Director | Verocel Limited
Direct Dial +44 1225 718912 | Mobile +44 7968 837742 | Email
ddaniels@xxxxxx

Verocel Limited is a company registered in England and Wales. Company
number: 7407595. Registered office: Grangeside Business Support Centre,
129
Devizes Road, Hilperton, Trowbridge, United Kingdom BA14 7SZ

-----Original Message-----
From: safety-critical-request@xxxxxx
[mailto:safety-critical-request@xxxxxx] On Behalf Of HK
Sent: 17 June 2011 07:30
To: safety-critical@xxxxxx
Subject: [sc] life cycle data \ processes for DO-178B level-D

Hello Everyone,

I have a debate with my colleges, regarding:
Which life cycle data \ processes can be omitted for developing in
accordance with DO-178B level-D ?

for example,  requirements, design and code standards can be omitted -
although they serve as good software development practices.
And what about Software Verification Plan (SVP), Do we need to create as
well ?


Regards,
Kuper

***************************************************************************
If you are not the intended recipient, please notify our Help Desk at Email isproduction@xxxxxx
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 5th Floor,
Brettenham House South, Lancaster Place, London, WC2E 7EN.

***************************************************************************
Received on Fri 17 Jun 2011 - 09:39:04 BST