Conference Paper

Experiences Using Defect Checklists in Software Engineering Education.

Conference: Proceedings of the ISCA 18th International Conference on Computer Applications in Industry and Engineering, November 9-11, 2005, Sheraton Moana Surfrider, Honolulu, Hawaii, USA
Source: DBLP

ABSTRACT There are numerous challenges in teaching software engineering courses, as such courses typically cover multiple technical, managerial and social topics. Within software engineering, software quality assurance (SQA) is a complex area to teach, because it involves aspects from all these three types of topics. Given the complexity of the area and the limited amount of time available to teach a software engineering course educators need to ask the question "How can we effectively teach some of the most important SQA issues and techniques, highlighting the critical relationship between quality and the time and cost of software development?". Here, we present a survey of the literature on checklists and our experiences using defect checklists in software engineering classes at both graduate and undergraduate levels. The study involves 11 teams, who used the checklists to collect defect data on technical deliverables, in both internal (peer) reviews and external (instructor) reviews. Using an iterative waterfall model, students were required to correct the defects discovered in internal and external reviews; the purpose of this was to reinforce the relationship between the quality of the deliverables and the time and effort required for correcting defects. The defect data are analyzed with respect to five conjectures; the strengths and limitations of the approach are discussed using the results. Improvements to the approach and alternatives are suggested, which could aid educators in teaching this important area of software engineering.

0 Bookmarks
 · 
87 Views
  • [Show abstract] [Hide abstract]
    ABSTRACT: Successful management of any process requires planning, measurement, and control. In programming development, these requirements translate into defining the programming process in terms of a series of operations, each operation having its own exit criteria. Next there must be some means of measuring completeness of the product at any point of its development by inspections or testing. And finally, the measured data must be used for controlling the process. This approach is not only conceptually interesting, but has been applied successfully in several programming projects embracing systems and applications programming, both large and small. It has not been found to “get in the way” of programming, but has instead enabled higher predictability than other means, and the use of inspections has improved productivity and product quality. The purpose of this paper is to explain the planning, measurement, and control functions as they are affected by inspections in programming terms.
    Ibm Systems Journal 02/1999; · 1.29 Impact Factor
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: This paper presents a process framework and a preliminary checklist for software cost management. While most textbooks and research papers on cost estimation look mainly at the "estimation" phase, our framework and checklist includes the phases relevant to estimation: "preparation", "estimation", "application", and "learning". We believe that cost estimation processes and checklists should support these phases to enable high estimation accuracy. The checklist we suggest is based on checklists from a number of sources, e.g., a handbook in forecasting and checklists present in several Norwegian software companies, it needs, however, to be extended through feedback from other researchers and software practitioners. There is also a need for a provision of conditions for meaningful use of the checklist issues and descriptions of the strength and sources of evidence in favor of the checklist issues. The present version of the checklist should therefore be seen as preliminary and we want to get feedback from the conference participants and other readers of this paper for further improvements.
    Quality Software, 2003. Proceedings. Third International Conference on; 12/2003
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Software requirements specifications (SRS) are usually validated by inspections, in which several reviewers read all or part of the specification and search for defects. We hypothesize that different methods for conducting these searches may have significantly different rates of success. Using a controlled experiment, we show that a scenario-based detection method, in which each reviewer executes a specific procedure to discover a particular class of defects has a higher defect detection rate than either ad hoc or checklist methods. We describe the design, execution and analysis of the experiment so others may reproduce it and test our results for different kinds of software developments and different populations of software engineers
    Software Engineering, 1994. Proceedings. ICSE-16., 16th International Conference on; 06/1994

Full-text

View
0 Downloads
Available from