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 OutlinePaperIntroductionWhy is software used?Software controllers and other controllersSoftware concernsModular StructureReliability Assessment for Safety-critical softwareConclusionsUncovered issuesStatistical software crisis information due to bad software engineeringIntroductionThe 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 repeatedlySoftware products may fail in their first use because situations that were anticipated by the programmers were also overlooked by the test plannersThe 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 hardwareSoftware 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 trustedError Sensitivity: software is much more sensitive to small errors.Hard to test: Huge number of testing cases in softwarewhat about points between the testing pointsCorrelated 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 standardsNo professional software engineersNo agreement on the skills and knowledge that a software engineer should haveSoftware Testing ConcernsWe cannot test software for correctness: large number of statesIt is difficult to make accurate predictions of software reliability and availabilityIt 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 verificationsThere is a need for an independent validation agency: it is difficult to test one’s own design in an unbiased waySoftware Reviewability ConcernsWhy is the reviewability concern for software?Before, there were not too much care about software, its documentation, and its trustworthinessNow, much more software controllers in big equipments and industryReviews are very important to increase the correctness of softwareEngineers are required to do documentationsWhat Reviews are neededReview for the correct intended functionReview for maintainable, understandable, well documented structure.Review each module to verify the algorithm and date structure design are consistent with the specified behaviorReview 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 outputThis 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 requirementsThree 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