Software maintainers use the traces of field failures to understand and diagnose faulty functions that cause the system to fail. Despite their usefulness, traces from the field can be quite overwhelming, especially for software systems with a vast client base. In the execution of realistic applications, many of them being millions of lines of code, there are just too many traces that are generated. In addition, traces are known to be extraordinarily large, which further complicates matters. Fortunately, not all field failures are caused by new faults. In fact, previous studies showed that 50% to 90% of field failures are due to previously known faults. In this paper, we propose a machine learning approach that automatically detects recurring faulty functions in the traces of new field failures. We achieve our goal by training decision trees on earlier resolved traces of system failures from the current and prior releases of the system. When applied to a large industrial system with 20 million lines of code and 200,000 functions, our approach was able to detect recurring faulty functions in the traces of field failures with an accuracy of 90%, to even 97% in some cases.

Diabetes currently ranks among the highest threats to human life given the increase in the number of diagnosed cases worldwide. This sudden increase has been linked to changes in human lifestyle since the majority of cases diagnosed are that of type 2 diabetes. Mobile health (m-health) technologies are being implemented in all areas of the health industry to aid patients in their pursuit of healthier lives. The society chosen for our study has a population predominately of African descent and is in crisis, as it possesses one of the highest rates of diabetes and amputation worldwide. Work was therefore conducted to promote proactive behaviour among members of the society by placing relevant technology in their hands to take control of their health. The purpose was to determine if the development of an m-health application would influence people diagnosed with diabetes to adopt healthier lifestyles, and reduce the impact of the disease on this part of the African diaspora. A mobile application was developed based on a preliminary study of m-health application availability and people's attitudes towards mobile applications. People who had diabetes or caretakers of people with diabetes tested the mobile application over a two-week period. Average participation among all users was low but notably there were a few persons who used the application frequently. The frequent users were compliant with the expected behaviours of a diabetes patient. The other participants used the application infrequently and generally had bad health regimes.

Literature indicates that 20% of a program's code is responsible for 80% of the faults, and 50-90% of the field failures are rediscoveries of previous faults. Despite this, identification of faulty code can consume 30-40% time of error correction. Previous fault-discovery techniques focusing on field failures either require many pass-fail traces, discover only crashing failures, or identify faulty "files" (which are of large granularity) as origin of the source code. In our earlier work (the F007 approach), we identify faulty "functions" (which are of small granularity) in a field trace by using earlier resolved traces of the same release, which limits it to the known faulty functions. This paper overcomes this limitation by proposing a new "strategy" to identify new and old faulty functions using F007. This strategy uses failed traces of mutants (artificial faults) and failed traces of prior releases to identify faulty functions in the traces of succeeding release. Our results on two UNIX utilities (i.e., Flex and Gzip) show that faulty functions in the traces of the majority (60-85%) of failures of a new software release can be identified by reviewing only 20% of the code. If compared against prior techniques then this is a notable improvement in terms of contextual knowledge required and accuracy in the discovery of finer-grain fault origin.

Certain software defects require corrective changes repeatedly in a few components of the system. One type of such defects spans multiple components of the system, and we call such defects pervasive multiple-component defects (PMCDs). In this paper, we describe an empirical study of six releases of a large legacy software system (of approx. size 20 million physical lines of code) to analyze PMCDs with respect to: (1) the complexity of fixing such defects and (2) the persistence of defect-prone components across phases and releases. The overall hypothesis in this study is that PMCDs inflict a greater negative impact than do other defects on defect-correction efficacy. Our findings show that the average number of changes required for fixing PMCDs is 20-30 times as much as the average for all defects. Also, over 80% of PMCD-contained defect-prone components still remain defect-prone in successive phases or releases. These findings support the overall hypothesis strongly. We compare our results, where possible, to those of other researchers and discuss the implications on maintenance processes and tools.

This paper proposes an automatic technique to reduce the time spent in detection of the fault origin from field traces, by discovering hidden patterns in the traces.

In this paper, we overview a new approach to comparing execution traces. Such comparison can be useful for purposes such as improving test coverage and profiling system's users. In our approach, traces are compressed into different levels of compaction and are then compared iteratively from highest to lowest levels, rejecting dissimilar traces in the process and eventually leaving residual, similar traces. These residual traces form an important feedback for improvement or analysis goals. The preliminary results show that the approach is scalable for industrial use.

This paper discusses the Pareto principle as it relates to the distribution of software defects in code. We look at evidence in the context of both the software test team, and users of the software. We also investigate two related principles. The first principle is that the distribution of defects in code relates to the distribution of complexity in code. The second principle is that how we define complexity relates to the distribution of defects in code. We present this work as an empirical study of three general hypotheses investigated for large production-level software; we show that the essence of the principle holds, while precise percentages do not.

Operational profiles are a quantification of usage patterns for a software application. These profiles are used to measure software reliability by testing the software in a manner that represents actual use. The current definition of an operational profile states that it is the set of operations available in the application, and the operations probabilities of occurrence in customer usage scenarios. This definition is too limited. In most industrial applications, focusing on operations alone does not offer adequate representation of the use of software. The limited definition of operational profiles can restrict their applicability and hence software reliability analysis for many software development organizations. This paper describes a formal and practical extension of the current definition of operational profiles to increase their applicability.