[SystemSafety] Collected stopgap measures
Steve Tockey
Steve.Tockey at construx.com
Fri Nov 2 21:31:11 CET 2018
I first started using Software Inspections in about 1985 and have had overwhelming success on many projects ever since. So I have included a number of checklists to support inspections of semantic models, design models, etc. in my new book. Here is the list of available checklists:
Chapter 3, Fundamental principles
----------------------------------------------
Overall quality criteria for work products (line 652)
Quality criteria for naming (line 656)
Chapter 4, Functional and non-functional requirements
-------------------------------------------------------------------------
Quality criteria for requirements (line 598)
Chapter 6, Partitioning systems into domains
-----------------------------------------------------------
Quality criteria for domain partitioning (line 259)
Chapter 7, Use case diagrams: scope and context
-----------------------------------------------------------------
Quality criteria for use cases (line 786)
Quality criteria for consistency between use cases and (sub-) domain partitioning (line 791)
Chapter 8, Class models: policies to enforce
---------------------------------------------------------
Quality criteria for class models (line 1373)
Quality criteria for class model to use case consistency (line 1397)
Chapter 9, Interaction diagrams: process at a mid-level
------------------------------------------------------------------------
Quality criteria for interaction diagrams (line 575)
Quality criteria for consistency between interaction diagrams and use cases (line 580)
Quality criteria for consistency between interaction diagrams and class models (line 585)
Chapter 10, State models: process at a fine-grained level
---------------------------------------------------------------------------
Quality criteria for state models (line 1131)
Quality criteria for consistency between state and class models (line 1136)
Quality criteria for consistency between state models and interaction diagrams (line 1141)
Chapter 11, Partitioning domains into subdomains
------------------------------------------------------------------
Quality criteria for subdomain partitioning (line 296)
Chapter 14, Designing interfaces: specifying real-world interaction
---------------------------------------------------------------------------------------
Quality criteria for overall interface design (line 794)
Quality criteria for general usability (line 799)
Quality criteria for user interfaces (line 803)
Quality criteria for APIs
Chapter 15, High-level design: classes and operations
----------------------------------------------------------------------
Quality criteria for high-level design (line 906)
Chapter 16: High-level design: contracts and signatures
-------------------------------------------------------------------------
Quality criteria for designing contracts and signatures (line 1733)
Chapter 17, Detailed design and code
-------------------------------------------------
Quality criteria for detailed design and code (line 1117)
Chapter 18, Formal disciplines of design and code
------------------------------------------------------------------
Quality criteria for Programming by intent (line 1416)
Quality criteria for Assertions (line 1420)
Quality criteria for Software proofs of correctness (line 1424)
Chapter 19, Optimization
---------------------------------
Quality criteria for design and code optimization (line 1491)
Chapter 20, Model compilation
-----------------------------------------
Quality criteria for open model compilation (line 1418)
Chapter 21, Advanced open model compilation
--------------------------------------------------------------
Quality criteria for optimizing an open model compiler (line 954)
Quality criteria for a new open model compiler on an existing interpreter (line 959)
Quality criteria for a new production rule interpreter (line 963)
Chapter 23, Estimation
------------------------------
Quality criteria for estimates and estimation (line 967)
Chapter 24, Development and maintenance processes
-----------------------------------------------------------------------
Quality criteria for lifecycle / process selection (line 753)
The good news is that all of these checklists are available for you to use if you see fit. The book manuscript is available on DropBox at:
https://www.dropbox.com/sh/jjjwmr3cpt4wgfc/AACSFjYD2p3PvcFzwFlb3S9Qa?dl=0
Your feedback on any of these checklists would definitely be appreciated. The bad news might be that these checklists are customized and tailored to the model-based approach in the book.
Cheers,
— steve
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of Olwen Morgan <olwen at phaedsys.com<mailto:olwen at phaedsys.com>>
Date: Friday, November 2, 2018 at 11:37 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] Collected stopgap measures
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)
o Need specialized notations, and can be very expensive
o May be able achieve same level of rigor without such expensive methods
- Model Checking
o Use a state machine model of the system
o Valuable for concurrent systems
o Tools today are practical for small to medium systems
- Automated static analysis
o Tools which analyze source code
o Code as a supplement to but not a replacement for code inspections
o Can add your own rules and for enforcing coding styles
o Valuable for identifying specific security issues
Reliability Testing
- Four validation activities:
o Establish the operational profile for the system
• Identify classes of system inputs and the probability that these inputs will occur in normal use
o Construct test data reflecting this operational profile
o Test the system and observe the number of failures and the times of these failures
o Compute 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.
o Do we have the right process?
o Are we doing the process right?
- Generated a lot of documentary evidence
- Examples include:
o Creation of a hazard monitoring and logging system that traces hazards through analysis, testing, and V&V
o Appointment of project safety engineers that have explicit responsibility for the safety of the system
o Extensive use of safety reviews
o Creation of a safety certification system where safety critical components are formally verified
o Detailed 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<mailto: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/3ff68482/attachment-0001.html>
More information about the systemsafety
mailing list