Nok Viravan

This paper documents the design of an experiment to test a debugging oracle assistant. A debugging oracle is responsible for judging correctness of program parts or program states. A programmer usually acts as a debugging oracle. The goal of a debugging oracle assistant is to improve the programmer’s speed and accuracy. Factors that complicate our design process include: (1) programmer variability, (2) interaction between programmers and programs, (3) interaction between programs and faults, (4) possible confounding experimental factors, (5) any learning effect from the assistance, (6) any learning effect from the program, and (7) the lack of experienced programmers for our experimental studies. This paper explains the rationale behind our design. It explains why the above factors can make other choices, such as a Latin square design, produce misleading results. It questions the validity of the so-called within-subjects factorial design when the experimental factors exclude programm...

A debugging oracle is a decision maker during a debugging process. Three major decisions during typical debugging sessions are on the identities, the locations, and the repairs of faults. A programmer usually acts as a debugging oracle. Our research objective is to help him in his decision-making process with a debugging oracle assistant. To enhance our understanding of both the debugging oracle and the debugging oracle assistant, we studied how 14 expert programmers debug a C program with over 4300 executable lines of code including real faults of omission. Four different forms of debugging oracle assistance were tested. The outcome of the studies provides insight to programmers’ needs and the forms of assistants which fulfill them. We find that information alone does not improve debugging performance. The two assistants that helped programmers make more accurate decisions on faults observed when programmers needed help and provided unsolicited and customized assistance for each pr...

This dissertation presents a new debugging assistant called a Debugging Critic. As an alternative to an automated debugging oracle, the debugging critic evaluates hypotheses about fault locations. If it cannot confirm that the code at the hypothesized location contains a fault, it formulates an alternative hypothesis about the location of a faulty statement or the location of omitted statements. The debugging critic derives knowledge of possible locations of a fault that manifested itself under a given test case from failure symptoms. It derives information about failure symptoms from programmers' replies to its questions. Therefore, it can operate without a line-by-line specification and a knowledge base of faults. A prototype of our debugging critic has been implemented as an extension of an existing debugger, Spyder. An experiment with Spyder shows that programmers debug two to four times faster on the average with the debugging critic than without it. Ninety-two percent of t...

This paper documents the design of an experiment to test a debugging oracle assistant. A debugging oracle is responsible for judging correctness of program parts or program states. A programmer usually acts as a debugging oracle. The goal of a debugging oracle assistant is to improve the programmer’s speed and accuracy. Factors that complicate our design process include: (1) programmer variability, (2) interaction between programmers and programs, (3) interaction between programs and faults, (4) possible confounding experimental factors, (5) any learning effect from the assistance, (6) any learning effect from the program, and (7) the lack of experienced programmers for our experimental studies. This paper explains the rationale behind our design. It explains why the above factors can make other choices, such as aLatin square design, produce misleading results. It questions the validity of the so-called within-subjects factorial design when the experimental factors exclude programme...

This paper documents the design of an experiment to test a debugging oracle assistant. A debugging oracle is responsible for judging correctness of program parts or program states. A programmer usually acts as a debugging oracle. The goal of a debugging oracle assistant is to improve the programmer's speed and accuracy. Factors that complicate our design process include: (1) programmer

Summary form only given, as follows. Boehm's spiral model is currently gaining popularity over the traditional waterfall software development model. The spiral model is a risk-driven approach. The process steps are determined by the need to resolve the high-risk situations-ones that have greatest chance to ruin the project. This approach contrasts with traditional document-driven approach where the process step is determined by the type of document that has to be submitted. Over a period of two years, the author applied the spiral model approach in the requirements analysis phase for four projects. These projects were with different sectors of the Thai government. The author was the head of the requirement analysis team for three projects and was responsible for quality assurance in one project. The author's experience reveals factors that foster the spiral approach's success in requirement analysis as well as factors that inhibit its effectiveness. Some of these factors include the Thai culture, governmental regulations, the educational background of the requirement engineers, the governmental employees' understanding of requirements analysis, terms in the contract, etc. The experience also reveals the risks in conducting software requirements analysis in a country that endures shortages of software engineers

Locating bugs is one of the most time-consuming tasks in debugging. Though external resources, such as explicit knowledge bases or formal specifications, can reduce the debugging time, this information either may not be readily available or may be too limited for real-world software. So in general, most debuggers try to reduce the time by providing analysis tools for the programmer to reduce the search space for bugs and to guess at the bug type, location, or both. We review the current state-of-the-art in debugging and point out three shortcomings that deserve more attention. First, the programmer has to perform the analysis and keep track of the results himself while he tries to locate faults. Second, the programmer needs (but lacks) automated decision support to help him evaluate program behavior as he tries to reduce the search space for bugs. Third, the debuggers that support fault location guessing do not point out the statements most likely to be faulty. Our objective is to r...