CUNY CSC 79000 - Evaluation of Safety Critical Software

Unformatted text preview:

Evaluation of Safety Critical Software by D. Parnas, A. J. van Schouwen, and P. KwanPresentation OutlineIntroductionWhy is software a special concern?Why is software used?How are software controllers like other controllers?How are software controllers different from other controllers?Software Testing ConcernsSoftware Reviewability ConcernsWhat Reviews are neededWhat documentation is required to review functional requirements?What documentation is required to review software structure?What documentation is required to review module’s internal design?What documentation is required to review the code?What documentation is required to review the test plan review?Reviewing relationships between these documentsWhy is configuration management essential for rigorous reviewsModular StructureReliability Assessments for Safety-Critical SoftwareWhat should be measuring?The finite state machine model of programsUse of hypothesis testingHypothesis testing exampleReliability estimates of programsConclusionsUncovered IssuesSoftware Crisis ExamplesEvaluation of Safety Critical Softwareby D. Parnas, A. J. van Schouwen, and P. KwanPresented by:Hatem HalaouiPresentation OutlinePaperIntroductionWhy is software used?Software controllers and other controllersSoftware concernsModular StructureReliability Assessment for Safety-critical softwareConclusionsUncovered issuesStatistical software crisis information due to bad software engineeringIntroductionThe failure of programmable computer applications could be life threatening. Computers now have safety-critical functions.To reduce application failures these questions need some answers: what standards must a software product satisfy?What documentation is needed?How much testing is needed?How should software be structured?Why is software a special concern?Many tragedies were caused by software failures.Software systems do not work well until they have been used and have failed repeatedlySoftware products may fail in their first use because situations that were anticipated by the programmers were also overlooked by the test plannersThe use of randomly generated data reduces the likelihood of shared oversightWhy is software used?Software makes it practical to build more logic into the system. They can distinguish a large number of situations and provide suitable outputs.Logic implemented in software is easier to change than that implemented in hardwareSoftware provide more information in more suitable formHow are software controllers like other controllers?Similar to other controllers (hardware), software controllers has the following properties:1. Inputs can be described as mathematical functions2. Outputs can be described as mathematical functions of the inputs3. Values of the variables can also be described as mathematical function of the controller output4. Relations between variables can be describedHow are software controllers different from other controllers?Complexity: Programs need more precise documentation which might fill a book case programs need much more time (years ) before being trustedError Sensitivity: software is much more sensitive to small errors.Hard to test: Huge number of testing cases in softwarewhat about points between the testing pointsCorrelated failures:Assumptions for hardware design are invalid for software: like assuming that a hardware failures are not strongly correlated In contrast to hardware, duplicating software components does not imply higher reliability Lack of professional standardsNo professional software engineersNo agreement on the skills and knowledge that a software engineer should haveSoftware Testing ConcernsWe cannot test software for correctness: large number of statesIt is difficult to make accurate predictions of software reliability and availabilityIt is not practical to measure the trustworthiness of software: a software is trustworthy if the probability of having a potentially catastrophic flaw is acceptably low.There is a role for testing: some scientist argue that one should test rather than spending this time review and does mathematical verificationsThere is a need for an independent validation agency: it is difficult to test one’s own design in an unbiased waySoftware Reviewability ConcernsWhy is the reviewability concern for software?Before, there were not too much care about software, its documentation, and its trustworthinessNow, much more software controllers in big equipments and industryReviews are very important to increase the correctness of softwareEngineers are required to do documentationsWhat Reviews are neededReview for the correct intended functionReview for maintainable, understandable, well documented structure.Review each module to verify the algorithm and date structure design are consistent with the specified behaviorReview the code for consistency with the algorithm and data structure design. Review test adequacy: was the testing sufficient to provide sound confidence in the software functioning.What documentation is required to review functional requirements?Should be done by engineers and scientists who understand the situation to be monitored and devices to be controlled.The functional requirement can be stated by giving three mathematical functions:1. The required values of the controlled variables in terms of values of the relevant observable environmental parameters2. The computer inputs in terms of those observable environmental variables3. The values of the controlled environmental variables in terms of the computer outputThis can be given as a set of tables and formulaeWhat documentation is required to review software structure?Documents that describe the breakdown of the program into modules (each module is a unit which could be a set of programs).The purpose of this review is to make sure that:1. The structure allow independent development and change2. All programs need are included once and only once3. Module interfaces are defined4. Modules are compatible to each other and meet the requirementsThree types of documents are needed:1. Requirements and specifications2. Informal document describing responsibilities of each module3. Module specification (black box description)What documentation is required to review module’s internal design?Design documentation which include description


View Full Document
Download Evaluation of Safety Critical Software
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Evaluation of Safety Critical Software and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Evaluation of Safety Critical Software 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?