; Hand this in to: ece849-staff+hw@ece.cmu.edu ; Required Readings @article{Fagan86, author = "Fagan, M.E.", title = "Advances in software inspections", journal = "IEEE Transactions on Software Engineering SE-12,", year = "1986", pages = "744-51", number = "7", abstract = "Software inspection is a method of static testing to verify that software meets its requirements. It engages the developers and others in a formal process of investigation that usually detects more defects in the product-and at lower cost-than does machine testing. Studies and experiences are presented which enhance the use of the inspection process and improve its contribution to development of defect-free software on time and at lower cost. Examples of benefits are cited followed by descriptions of the inspection process and some methods of obtaining the enhanced results. Users of the method report very significant improvements in quality that are accompanied by lower development costs and greatly reduced maintenance efforts. Excellent results have been obtained by small and large organizations in all aspects of new development as well as in maintenance. There is some evidence that developers who participate in the inspection of their own product actually create fewer defects in subsequent work. Because inspections formalize the development process, productivity-enhancing and quality-enhancing tools can be adopted more easily and rapidly", url = "http://www.ece.cmu.edu/~ece849/papers/fagan86_sw_inspections.pdf", studentname = "", summary = "", contribution1 ="", contribution2 ="", contribution3 ="", contribution4 ="", contribution5 ="", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @article{Umansky01, author = "Umansky", title = "Studs and Dud", journal = "The Washington Monthly", year = "2001", abstract = " In Afghanistan, the Navy has weapons that work. So why don't the Army and Air Force?", url = "http://www.washingtonmonthly.com/features/2001/0112.umansky.html", studentname = "", summary = "", contribution1 ="", contribution2 ="", contribution3 ="", contribution4 ="", contribution5 ="", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @article{Buus97, author = "Buus, H. ; McLees, R. ; Orgun, M. ; Pasztor, E. ; Schultz, L.", title = "777 flight controls validation process", journal = "IEEE Transactions on Aerospace and Electronic Systems 33,", year = "1997", pages = "656-66", number = "2", abstract = "The validation process used in support of certification of the Boeing 777 full fly-by-wire Primary Flight Control System (PFCS) and Autopilot Flight Director System (AFDS) is summarized. This process includes development of the system and component level requirements, ensuring the requirements are correct and complete, and ensuring the integrated systems and airplane comply with the system and airplane level requirements. Validation methods, traceability, problem tracking, and organizational management of the process are described", url = "http://ieeexplore.ieee.org/iel4/7/12850/00588385.pdf", studentname = "", summary = "", contribution1 ="", contribution2 ="", contribution3 ="", contribution4 ="", contribution5 ="", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } ; NOTE: This is a "how we did it" case study paper, without too much on "why". So don't waste breath on saying they didn't talk about "why". Just read the paper to get a feel for all the stuff that has to go into a real x-by-wire system. @Conference{ yeh98_777_fbw, author = "Yeh, Y.C.; ", title = "Design considerations in Boeing 777 fly-by-wire computers", journal = "HASE 1998", year = "1998", abstract = "The new technologies in flight control avionics systems selected for teh Boeing 777 airplane program consist of the following: Fly-By-Wire (FBW), ARINC 629 Data Bus, and Deferred Maintenance. The FBW must meet extremely high levels of fractional integrity and availability. The heart of the FBW concept is the use of triple redundancy for all hardware resources: computing system, airplane electrical power, hydraulic power and communication paths. The multiple redundant hardware are required to meet the numerical safety requirements. Hardware redundancy can be relied upon only if hardware faults can be contained; fail-passive electronics are necessary building blocks for the FBW systems. In addition, FBW computer architecture must consider other fault tolerance issues: generic errors, common mode faults, near-coincidence faults and dissimilarity.", url = "http://ieeexplore.ieee.org/iel4/5939/15811/00731596.pdf", studentname = "", summary = "", contribution1 ="", contribution2 ="", contribution3 ="", contribution4 ="", contribution5 ="", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } ; Supplemental Readings @Conference{Crary99, author = "Crary, K. ; Harper, R. ; Lee, P. ; Pfenning, F. ", title = "Automated techniques for provably safe mobile code", inbook = "Proceedings DARPA Information Survivability Conference and Exposition. DISCEX'00", year = "1999", pages = "406-19", volume = "1", abstract = "We present a general framework for provably safe mobile code. It relies on a formal definition of a safety policy and explicit evidence for compliance with this policy which is attached to a binary. Concrete realizations of this framework are proof-carrying code (PCC), where the evidence for safety is a formal proof generated by a certifying compiler and typed assembly language (TAL), where the evidence for safety is given via type annotations propagated throughout the compilation process in typed intermediate languages. Validity of the evidence is established via a small trusted type checker either directly on the binary or indirectly on proof representations in a logical framework (LF)", url = "http://ieeexplore.ieee.org/iel5/6658/17862/00825043.pdf?isNumber=17862&prod=IEEE+CNF&arnumber=825043&arSt=406&ared=419+vol.1&arAuthor=Crary%2C+K.%3B+Harper%2C+R.%3B+Lee%2C+P.%3B+Pfenning%2C+F.%3B", studentname = "", summary = "", contribution1 = "", contribution2 = "", contribution3 = "", contribution4 = "", contribution5 = "", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @article{Fagan76, author = "Fagan, M.E.", title = "Design and code inspections to reduce errors in program development", journal = "IBM Systems Journal 15,", year = "1976", pages = "182-211", number = "3", abstract = "Substantial net improvements in programming quality and productivity have been obtained through the use of formal inspections of design and of code. Improvements are made possible by a systematic and efficient design and code verification process, with well-defined roles for inspection participants. The manner in which inspection data is categorized and made suitable for process analysis is an important factor in attaining the improvements. It is shown that by using inspection results, a mechanism for initial error reduction followed by ever-improving error rates can be achieved", url = "http://www.ece.cmu.edu/~ece749/papers/fagan76_inspections.pdf", studentname = "", summary = "", contribution1 = "", contribution2 = "", contribution3 = "", contribution4 = "", contribution5 = "", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @Conference{Goddard93, author = "Goddard, P.L. ", title = "Validating the safety of embedded real-time control systems using FMEA", inbook = "Annual Reliability and Maintainability Symposium. 1993 Proceedings ", year = "1993", pages = "227-30", abstract = "Traditional failure modes and effects analysis techniques have been adapted and extended to include assessment of software failures. The resulting technique is used to assess the safety of embedded real-time control systems designed for use in automotive applications. The use of FMEA techniques in assessing the software safety of those controllers has allowed analysis of the effects of a more comprehensive set of potential failures, including data corruption, than is practical using other software safety analysis techniques. The ability to assess the results of data corruption has proven to be crucial in providing feedback to design teams about the potential safety risks of the designs analyzed", url = "http://ieeexplore.ieee.org/iel3/1050/7344/00296851.pdf", studentname = "", summary = "", contribution1 = "", contribution2 = "", contribution3 = "", contribution4 = "", contribution5 = "", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @article{Musa93, author = "Musa, J.D.", title = "Operational profiles in software-reliability engineering", journal = "IEEE Software 10,", year = "1993", pages = "14-32", number = "2", abstract = "A systematic approach to organizing the process of determining the operational profile for guiding software development is presented. The operational profile is a quantitative characterization of how a system will be used that shows how to increase productivity and reliability and speed development by allocating development resources to function on the basis of use. Using an operational profile to guide testing ensures that if testing is terminated and the software is shipped because of schedule constraints, the most-used operations will have received the most testing and the reliability level will be the maximum that is practically achievable for the given test time. For guiding regression testing, it efficiently allocates test cases in accordance with use, so the faults most likely to be found, of those introduced by changes, are the ones that have the most effect on reliability", url = "http://ieeexplore.ieee.org/iel1/52/5191/00199724.pdf", studentname = "", summary = "", contribution1 = "", contribution2 = "", contribution3 = "", contribution4 = "", contribution5 = "", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @article{Whittaker00, author = "Whittaker, J.A.", title = "What is software testing? And why is it so hard?", journal = "IEEE Software 17,", year = "2000", pages = "70-9", number = "1", abstract = "The author sheds some light on why testing today's software products is so challenging, and he identifies several solid approaches that all testers should be able to thoughtfully apply. The effective tester has a rich toolkit of fundamental testing techniques, understands how the product will be used in its operating environment, and has a nose for where subtle bugs might lurk in the product and a bag of tricks for flushing them out. The methods described can help testers provide a sensible answer to the question of what they really mean when they say they have finished testing a software system", url = "http://ieeexplore.ieee.org/iel5/52/17783/00819971.pdf", studentname = "", summary = "", contribution1 = "", contribution2 = "", contribution3 = "", contribution4 = "", contribution5 = "", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @article{Zhu97, author = "Hong Zhu ; Hall, P.A.V. ; May, J.H.R.", title = "Software unit test coverage and adequacy", journal = "ACM Computing Surveys 29,", year = "1997", pages = "366-427", number = "4", abstract = "Objective measurement of test quality is one of the key issues in software testing. It has been a major research focus for the last two decades. Many test criteria have been proposed and studied for this purpose. Various kinds of rationales have been presented in support of one criterion or another. We survey the research work in this area. The notion of adequacy criteria is examined together with its role in software dynamic testing. A review of criteria classification is followed by a summary of the methods for comparison and assessment of criteria", url = "http://doi.acm.org/10.1145/267580.267590", studentname = "", summary = "", contribution1 = "", contribution2 = "", contribution3 = "", contribution4 = "", contribution5 = "", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", } @article{Weinberg84, author = "Weinberg, G.M. ; Freedman, D.P.", title = "Reviews, walkthroughs, and inspections", journal = "IEEE Transactions on Software Engineering SE-10,", year = "1984", pages = "68-72", number = "1", abstract = "Historic origins and future trends of formal and informal technical reviews are discussed. Formal technical reviews supply the quality measurement to the cost effectiveness equation in a project management system. There are several unique formal technical review procedures, each applicable to particular types of technical material and to the particular mix of the review committee. All formal technical reviews produce reports on the overall quality for project management, and specific technical information for the producers. These reports also serve as an historic account of the systems development process", url = "http://www.ece.cmu.edu/~ece749/papers/weinberg84_inspections.pdf", studentname = "", summary = "", contribution1 = "", contribution2 = "", contribution3 = "", contribution4 = "", contribution5 = "", weakness1 = "", weakness2 = "", weakness3 = "", weakness4 = "", weakness5 = "", interesting = "high/med/low", opinions = "", }