[SystemSafety] Collected stopgap measures
Olwen Morgan
olwen at phaedsys.com
Fri Nov 2 19:37:01 CET 2018
OK. Let's look at this in a slightly different way.
One of the big problems that you see constantly in real-world software
engineering is people *not doing basic sanity checks* on their methods,
tools and products. You can point people at the literature ad nauseam
but they still won't read it.
So, over all the activities in the life cycle, is it possible to come up
with a set of widely agreed checklists that can be followed in order to
avoid gross blunders? (A very good book on the use of checklists is:
Gawande, A., The Checklist Manifesto, Profile, 2011, ISBN-10:
9781846683145, ISBN-13: 978-1846683145).
As a profession, surely we ought to be able to distil into checklists at
least a basic set of rules for avoiding well-known pitfalls ... ?
Olwen
On 02/11/2018 16:22, Jonathan Ostroff wrote:
> I teach a 4th year course on Software Engineering Requirements. This
> is a systems safety list but I assume that documenting requirements is
> important for the production of systems that are safe and fit for
> purpose. There is a large literature and many textbooks that deal with
> software requirements but not so many that address requirements
> engineering for safety critical systems.
>
> To students I recommend:
>
> https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-08-32.pdf
>
> which is a handbook that presents a set of recommended practices on
> how to collect, write, validate, and organize requirements (in the
> aviation domain butI think applicable elsewhere). I would be
> interested in other available teaching resources if they exist.
>
> The course uses TLA+ and PVS for validating specifications (which is
> different from verifying that code satisfies specifications). In the
> course, PVS is used to check that function table specifications are
> complete and disjoint (in line with earlier work by David Parnas in
> the nuclear domain).
> https://wiki.eecs.yorku.ca/course_archive/2018-19/F/4312/start
> Jonathan Ostroff
>
>
>> On Nov 2, 2018, at 10:57 AM, John Howard <john.howard at ieee.org
>> <mailto:john.howard at ieee.org>> wrote:
>>
>> I too am just beginning and would find something like this useful.
>> Just for a point of reference. I am currently taking a "Software
>> Systems Engineering" class towards my Masters in Systems Engineering,
>> and here are some notes I captures from our one and only lesson on
>> V&V for Safety Critical Software.
>>
>> I'd be interested to know what the experts on this list think of this
>> (how complete is it?).
>>
>> Also, does anyone know of good courses that teach this stuff?
>>
>>
>> V&V Methods for Software in Safety Critical Systems
>>
>> Static Analysis
>>
>> -Formal methods (Mathematical Proof)
>> oNeed specialized notations, and can be very expensive
>> oMay be able achieve same level of rigor without such expensive methods
>> -Model Checking
>> oUse a state machine model of the system
>> oValuable for concurrent systems
>> oTools today are practical for small to medium systems
>> -Automated static analysis
>> oTools which analyze source code
>> oCode as a supplement to but not a replacement for code inspections
>> oCan add your own rules and for enforcing coding styles
>>
>> oValuable for identifying specific security issues
>>
>> Reliability Testing
>>
>> -Four validation activities:
>> oEstablish the operational profile for the system
>> §Identify classes of system inputs and the probability that these
>> inputs will occur in normal use
>> oConstruct test data reflecting this operational profile
>> oTest the system and observe the number of failures and the times of
>> these failures
>>
>> oCompute the reliability after a statistically significant number of
>> failures have been observed
>>
>> Security Testing
>>
>> -Experience Based validation testing (against known attacks)
>> -Tiger-teams (a form of experience based testing)
>> -Tool based validation testing (experience is embodied in the tools
>> themselves)
>> -Formal verification
>>
>> -Static analysis can be used to supplement security testing
>>
>> Process assurance
>>
>> -Dependability is assured because the processes which ensure
>> dependability are followed throughout software development.
>> oDo we have the right process?
>> oAre we doing the process right?
>> -Generated a lot of documentary evidence
>> -Examples include:
>> oCreation of a hazard monitoring and logging system that traces
>> hazards through analysis, testing, and V&V
>> oAppointment of project safety engineers that have explicit
>> responsibility for the safety of the system
>> oExtensive use of safety reviews
>>
>> oCreation of a safety certification system where safety critical
>> components are formally verified
>>
>> oDetailed Configuration Management
>>
>>
>>
>>
>>
>> On Thu, Nov 1, 2018 at 1:37 PM Tim Schürmann
>> <tschuerm at techfak.uni-bielefeld.de
>> <mailto:tschuerm at techfak.uni-bielefeld.de>> wrote:
>>
>> From the viewpoint of somebody still in the beginning:
>>
>> I wold love to have something like this.
>>
>> May it even be just a list of references, papers, "does and don't
>> does"
>> or alike..
>>
>> Kind regards
>>
>> Tim
>>
>>
>> On 01.11.2018 16:34, Olwen Morgan wrote:
>> >
>> > One thing that I sense (maybe wrongly?) from recent traffic is
>> that a
>> > goodly few of us use our own favourite techniques to help plug the
>> > holes in weak development practices. Cut-down structured and OO
>> > methods seem to be a case in point. I'm sure there are others.
>> >
>> > Might there be some benefit in gathering here the tricks that
>> many of
>> > us may have used when faced with inadequate processes. Call me
>> > simple-minded (many have called me worse) but I'm wondering if
>> there
>> > would be value in what might be called a "Software Process
>> Cookbook"
>> > of "Software Process Checklists" for high-integrity developments.
>> >
>> > True, I'd prefer something direct, technical and possibly
>> rather dry
>> > but I'm thinking here about an appealing format. I'm wondering if
>> > something like a cookbook or "for Dummies" format would appeal to
>> > people who would otherwise never go near the sources that they
>> need to
>> > be accessing to help them do the job better.
>> >
>> >
>> > Just a thought,
>> >
>> > Olwen
>> >
>> >
>> > _______________________________________________
>> > The System Safety Mailing List
>> > systemsafety at TechFak.Uni-Bielefeld.DE
>> <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
>> > Manage your subscription:
>> >
>> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
>>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>> <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
>> Manage your subscription:
>> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
>>
>>
>>
>> --
>> John Howard
>> Sr. Systems Engineer
>> Robotic Research LLC <https://www.roboticresearch.com/>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>> <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
>> Manage your subscription:
>> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181102/e0cc5bd7/attachment-0001.html>
More information about the systemsafety
mailing list