Showing papers on "Software technical review published in 1995"
TL;DR: It is concluded that the benefits of inspections are often overstated and the costs (especially for large software development projects) are understated.
Abstract: For two decades, software inspections have proven effective for detecting defects in software. We have reviewed the different ways software inspections are done, created a taxonomy of inspection methods, and examined claims about the cost effectiveness of different methods. We detect a disturbing pattern in the evaluation of inspection methods. Although there is universal agreement on the effectiveness of software inspection, their economics are uncertain. Our examination of several empirical studies leads us to conclude that the benefits of inspections are often overstated and the costs (especially for large software development projects) are understated. Furthermore, some of the most influential studies establishing these costs and benefits are 20 years old now, which leads us to question their relevance to today's software development processes. Extensive work is needed to determine exactly how, why, and when software inspections work, and whether some defect detection techniques might be more cost effective than others. We ask some questions about measuring the effectiveness of software inspections and determining how much they really cost when their effect on the rest of the development process is considered. Finding answers to these questions will enable us to improve the efficiency of software development.
58 citations
TL;DR: The aim of this literature review is to outline the context of theory in designing educational software for vocational education and training, and to give an account of the significance of the "key ingredients" which constitute best practice.
Abstract: The aim of this literature review is to outline the context of theory in designing educational software for vocational education and training, and to give an account of the significance of the "key ingredients" which constitute best practice.
20 citations
TL;DR: Analysis of the analysis of the data collected suggest that many interacting technical and nontechnical factors come into play in software development, specifically those related to roles managers played with their people, subcontractors, and customers.
17 citations
TL;DR: Using this process, breadth and depth of subject coverage, clarity of presentation, quality of construction, and ease of use are being assessed by content and technical experts.
6 citations
TL;DR: Results from a survey of practitioners are presented that indicate a lack of information interchange exists and that the use of formal techniques is limited, indicative of poor life-cycle practices and that more rigorous methodologies are required.
Abstract: This paper integrates the premise that current software level practices within the aerospace industry are weak and that there is a lack of rigour in both technical and managerial areas. Results from a survey of practitioners are presented that indicate a lack of information interchange exists and that the use of formal techniques is limited. The paper proposes that this is indicative of poor life-cycle practices and that more rigorous methodologies, ones that integrate formal methods with quality practices, are required. A two-level model is proposed to address the issue.
5 citations
TL;DR: The authors examine other fields of engineering to obtain an indication as to how, in an action of negligence, the civil courts might measure the competence and behaviour of software engineers in producing safety-related software.
Abstract: If a software failure leads to injury or death, legal liability may fall on manufacturers, designers and software engineers. Allegations of negligence may result, and a demonstration of competence is likely to be important in a defence of such allegations. In the absence of authoritative case law, the authors examine other fields of engineering to obtain an indication as to how, in an action of negligence, the civil courts might measure the competence and behaviour of software engineers in producing safety-related software. The authors consider the implications of standards and codes of practice, responsibilities of client and contractor, budgetary implications, the status of experts, and the distinction between pioneering design and negligent behaviour. This paper is, however, intended for an engineering readership and legal detail is kept to a minimum. >
4 citations
04 Jan 1995
TL;DR: From observations gathered during a study of large software development projects, it was concluded that the software engineering technology (SET) transfer process is plagued with problems involving learning, technical communication, and negotiation.
Abstract: From observations gathered during a study of large software development projects, it was concluded that the software engineering technology (SET) transfer process is plagued with problems involving learning, technical communication, and negotiation. The underlying causes of these problems are discussed. The observations presented here attempted to help facilitate the MCC Software Technology program technology transfer of advanced software development technology, which mostly failed. Technology transfer was a major goal and risk of the MCC Software Technology program. >
3 citations
TL;DR: The lack of common guidelines for software development becomes a formidable obstacle as discussed by the authors as trade barriers in Europe and North America come down, and the lack of Common Guidelines for Software Development becomes an obstacle.
Abstract: As trade barriers in Europe and North America come down, the lack of common guidelines for software development becomes a formidable obstacle. ISO-9000 standards are internationally recognized and accepted. ISO-9000-3 in the series applies guidelines to the software industry. As purchasers of software, corporate IS departments need to understand these standards and their possible impact on the quality of software.
3 citations
05 Nov 1995
TL;DR: In this article, the authors highlight MIL-STD-498 as the new way of developing software, and examine its application on a governmentsponsored real-time guidance, navigation, and control project underway at the Draper Laboratory.
Abstract: In his June 29, 1994 memo, Secretary of Defense Perry challenged Dod agencies (and Industry) to move to greater use of performance and commercial specifications and standards, and shelved a host of military standards, including those related to software. After an intense lobbying effort by the Dod and Industry, the DoD approved the use of MIL-STD-498 for two years; assuming, a non-Government software standard would replace it in that time frame. The U.S. Navy and Air Force have issued waivers permitting MIL-STD-498 to be invoked on contracts. The Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Association (EIA) are working together to create a nonGovernment software standard. Because MIL-STD498 is new and being applied on selected projects, there is no published information on its practical use. This paper briefly: (1) highlights MIL-STD-498 as the new way of developing software; (2) examines MIL-STD-498's application on a governmentsponsored real-time guidance, navigation, and control project underway at the Draper Laboratory; and (3) reviews the effort to create non-Government software Standards.
2 citations
01 Sep 1995
1 citations
TL;DR: The Design Browser is a combination of an artificial intelligence paradigm known as case-based reasoning and a conceptual framework that presents developers a unified structure through which to understand, compare, and contrast related design experience.
01 Nov 1995
TL;DR: This report relates, in detail, the vendor assessment steps to the planning audits proposed in NUREG/CR-6101 and the correspondence of the vendor assessors to the design factor categories of NUREg/ CR-6294 is discussed.
Abstract: Several previous studies performed for the Nuclear Regulatory Commission by Lawrence Livermore National Laboratory have focused on characteristics of software development processes that are important for the development of high-integrity software. These include software reliability (NUREG/CR-6101, Lawrence) and software design factors (NUREG/CR-6294, Lawrence and Preckshot and Ploof and Preckshot). Ploof and Preckshot has been included as Appendix B of this report. In addition, recent analyses of standards important to the development of software for the safety systems of nuclear power plants have indicated the importance of the understanding and use of a complete framework of standards in the development of such software (Scott et. al.). Finally, Preckshot (Appendix A) addressed the assessment of software development processes used by software vendors. The latter work defined a set of steps to be followed in conducting vendor assessments. This report relates, in detail, the vendor assessment steps to the planning audits proposed in NUREG/CR-6101. The correspondence of the vendor assessment steps to the design factor categories of NUREG/CR-6294 is also discussed.