Tomoko Matsumura

Defect Data Analysis Based on Extended Association Rule Mining

This paper describes an empirical study to reveal rules associated with defect correction effort. We defined defect correction effort as a quantitative (ratio scale) variable, and extended conventional (nominal scale based) association rule mining to directly handle such quantitative variables. An extended rule describes the statistical characteristic of a ratio or interval scale variable in the consequent part of the rule by its mean value and standard deviation so that conditions producing distinctive statistics can be discovered As an analysis target, we collected various attributes of about 1,200 defects found in a typical medium-scale, multi-vendor (distance development) information system development project in Japan. Our findings based on extracted rules include: (l)Defects detected in coding/unit testing were easily corrected (less than 7% of mean effort) when they are related to data output or validation of input data. (2)Nevertheless, they sometimes required much more effort (lift of standard deviation was 5.845) in case of low reproducibility, (i)Defects introduced in coding/unit testing often required large correction effort (mean was 12.596 staff-hours and standard deviation was 25.716) when they were related to data handing. From these findings, we confirmed that we need to pay attention to types of defects having large mean effort as well as those having large standard deviation of effort since such defects sometimes cause excess effort.

Proposal of a Complete Life Cycle In-Process Measurement Model Based on Evaluation of an In-Process Measurement Experiment Using a Standardized Requirement Definition Process

This poster reports on a solution to ERP project cost estimation and on results from its first experimental application.

Modeling Software Project Monitoring with Stakeholders

Recently, software size becomes larger, and consequently, not only a software developer but also a software purchaser suffers considerable losses by software project failure. So avoiding project failure is also important for purchasers. Project monitoring with a purchaser and a developer (stakeholders) is expected for the purchaser to suppress risk of project failure. It is performed by sharing software metrics during the project for the purchaser to grasp the status of the project. Although there are some software measurement models, they cannot describe two kinds of metrics which are used to monitor projects with stakeholders. One metric is to indicate project goal achievement after finishing project. The other one is to measure to progress toward the goal. In addition, the models cannot represent countermeasures when symptoms of project failure are found. We propose the model for project monitoring with stakeholders. The model is based on the measurement information model defined by ISO/IEC 15939, and added stakeholder’s goal, key goal indicator (KGI), key performance indicator (KPI), corrective action, and check timing. With our model, project monitoring with stakeholders can be described more rigorously.

A method for detecting faulty code violating implicit coding rules

In the field of legacy software maintenance, there unexpectedly arise a large number of implicit coding rules --- which are seldom written down in specification documents or design documents --- as software becomes more complicated than it used be. Since not all the members in a maintenance team realize each of implicit coding rules, a maintainer who is not aware of a rule often violates the rule while doing various maintenance activities such as adding new functionality and repairing faults. The problem here is not only such a violation causes injection of a new fault into software but also this violation will be repeated again and again in the future by different maintainers. Indeed, we found that 32.7% of faults of certain legacy software were due to such violations.This paper proposes a method for detecting code fragments that violate implicit coding rules. In the method, an expert maintainer firstly investigates the causes, situations, and code fragments of each fault described in bug reports; and, identifies implicit coding rules as much as possible. Then, code patterns violating the rules (which we call bug code patterns) are described in a pattern description language. Finally, potential faulty code fragments are extracted by a pattern matching technique.

Standardizing the software tag in japan for transparency of development

In this paper, we describe the Software Tag which makes software development visible to software purchasers (users). A software tag is a partial set of empirical data about a software development project shared between the purchaser and developer. The purchaser uses the software tag to evaluate the software project, allowing them to recognize the quality level of the processes and products involved. With Japanese government support, we have successfully standardized the software tag named Software Tag Standard 1.0, and have developed various associated tools for tag data collection and visualization. For its initial evaluation, the software tag has been applied to several projects. This paper also presents various activities aimed at promoting the use of the software tag in Japan and the world.

An Empirical Study of Process and Product Metrics Based on In-process Measurements of a Standardized Requirements Definition Phase

This paper focuses on in-process project measurement in the requirements definition phase based on progress with standardization of this phase. The authors have verified the utility of in-process project measurement in a real mid-scale multi-vendor distributed project. This trial was successful, but limited to a part of the total development process. The project measurement target was limited to later processes such as the coding and testing phases where the output products were easy to acquire. The requirements definition phase where process and product were not standardized was difficult to measure. However, a newly provided governmental process guideline standardizes the process and product for the requirements definition phase, and the authors had an opportunity to measure such a requirements definition effort. This paper presents an empirical study of in-process project measurement in the standardized requirements definition phase, verifies the usefulness of this measurement for project management, and reveals the possibility of creating a new software metrics field using these measurements.