Catherine Stringfellow

An Empirical Method for Selecting Software Reliability Growth Models

Estimating remaining defects (or failures) in software can help test managers make release decisions during testing. Several methods exist to estimate defect content, among them a variety of software reliability growth models (SRGMs). SRGMs have underlying assumptions that are often violated in practice, but empirical evidence has shown that many are quite robust despite these assumption violations. The problem is that, because of assumption violations, it is often difficult to know which models to apply in practice. We present an empirical method for selecting SRGMs to make release decisions. The method provides guidelines on how to select among the SRGMs to decide on the best model to use as failures are reported during the test phase. The method applies various SRGMs iteratively during system test. They are fitted to weekly cumulative failure data and used to estimate the expected remaining number of failures in software after release. If the SRGMs pass proposed criteria, they may then be used to make release decisions. The method is applied in a case study using defect reports from system testing of three releases of a large medical record system to determine how well it predicts the expected total number of failures.

Comparison of software architecture reverse engineering methods

Abstract Problems related to interactions between components is a sign of problems with the software architecture of the system and are often costly to fix. Thus it is very desirable to identify potential architectural problems and track them across releases to see whether some relationships between components are repeatedly change-prone. This paper shows a study of combining two technologies for software architecture: architecture recovery and change dependency analysis based on version control information. More specifically, it describes a reverse engineering method to derive a change architecture from Revision Control System (RCS) change history. It compares this method to other reverse engineering methods used to derive software architectures using other types of data. These techniques are illustrated in a case study on a large commercial system consisting of over 800 KLOC of C, C++, and microcode. The results show identifiable problems with a subset of the components and relationships between them, indicating systemic problems with the underlying architecture.

Deriving a Fault Architecture to Guide Testing

Defect analysis of software components can be used to guide testing, with the goal of focusing on parts of the software that were fault-prone in earlier releases or earlier life cycle phases, such as development. We replicate a study that adapted a reverse architecting technique using defect reports to derive fault architectures. A fault architecture determines and visualizes components that are fault-prone in their relationships with other components, as well as those that are locally fault-prone. Our case study uses defect data from three releases of a large medical record system to identify relationships among system components, based on whether they are involved in the same defect report.We investigate measures that assess the fault-proneness of components and component relationships. Component relationships are used to derive a fault architecture. The resulting fault architecture indicates what the most fault-prone relationships are in a release. We also apply the technique in a new way. Not only do we derive fault architectures for each release, we derive fault architectures for the development, system test and post release phases within each release. Comparing across releases, makes it possible to see whether some components are repeatedly in fault-prone relationships. Comparing across phases, makes it possible to see whether development fault architectures can be used to identify those parts of the software that need to be tested more. We validate our predictions using system test data from the same release. We also use the development and system test fault architectures to identify fault-prone components after release, and validate our predictions using post release data.

On effective use of reliability models and defect data in software development

In software technology today, several development methodologies such as extreme programming and open source development increasingly use feedback from customer testing. This makes the customer defect data become more readily available. This paper proposes an effective use of reliability models and defect data to help managers make software release decisions by applying a strategy for selecting a suitable reliability model, which best fits the customer defect data as testing progresses. We validate the proposed approach in an empirical study using a dataset of defect reports obtained from testing of three releases of a large medical system. The paper describes detailed results of our experiments and concludes with suggested guidelines on the usage of reliability models and defect data.

A Conceptual Graphs Framework for Teaching UML Model-Based Requirements Acquisition

Students that first learn multiple-viewed requirements modeling with UML diagrams tend to create incomplete and inconsistent models. Complex requirements and numerous modeling elements in UML often overwhelm students and make it hard for them to even notice such flaws in the models. Useful feedback can help students revise their UML models to be more complete. In this paper, we introduce a novel approach of teaching UML modeling and requirements acquisition. A knowledge-based framework is proposed to help reveal incompleteness and inconsistency in a set of models developed by students. This approach can drive the process of acquiring requirements for each UML model. The proposed framework is based on a central knowledge representation, the conceptual graphs.

Network centric improvements to resource caching

Network bandwidth is a precious commodity in the information age. One would be hard-pressed to cite an example of an industry, hobby, or effort that could not benefit, in some way, from a communication network. The ability to minimize the allocation time for communication channels within a network is one of the primary concerns of the network administrator. Network resource caching is one technique that may be used to reduce channel allocation time. Therefore, improvements to the standard cache management algorithms are an important component of achieving this goal. This study demonstrates the potential benefit of the time distance indexing factor (TDIF) cache replacement algorithm over a traditional technique, least recently used (LRU), in reducing communication channel allocation time. The benefit of this technique translates into an increase in the effective bandwidth of the network.

Using sequence diagrams to document Web elements' unknown behavior

Software engineers depend on analysis and design methods that take into consideration users requirements and computing resources on the processing site. With many new network applications being developed based on web browser user interfaces, software engineers have become more dependent on knowledge of network operations. Web caching is an existing mechanism that seeks to improve users response time, but their existence and functionality are usually transparent to those not directly working with the network infrastructure. In this paper, a new method that uses UML sequence diagrams to perform requirements analysis on web applications is proposed, whereby the web application is designed in such a way to avoid the actions taken by hidden resources, such as web caches, becoming, then, independent of the uncertainty of the caching mechanisms for dynamic contents.