An analysis of factors affecting software reliability

A large number of software product metrics have been proposed in software engineering. We use the term metric here to be consistent with prevailing international standards. Product metrics quantitatively characterize some aspect of the structure of a software product, such as a requirements specification, a design, or source code. They are also commonly collectively known as complexity metrics.



While many of these metrics are based on good ideas about what is important to measure in software to capture its complexity, it is still necessary to systematically validate them.



Two types of validation are recognized internal and external. Internal validation is a theoretical exercise that ensures that the metric is a proper numerical characterization of the property it claims to measure. Demonstrating that a metric measures what it purports to measure is a form of theoretical validation. Typically, one defines the properties of the attribute that is to be measured, for example, the properties of module coupling. Then one demonstrates analytically that the product metric satisfies these properties. External validation involves empirically demonstrating that the product nature is associated which is important external metter or an improvement is shown above. Internal and external validation are also commonly referred to as theoretical and empirical validation respectively



This article presents a comprehensive methodology for validating software product metrics. Our focus will be limited to empirical validation.


Keywords:

metrics;
terminology;
validated product metrics;
methodology;
risky components;
model specification;
model building;
code churn

/pdf/methodology-for-validating-software-product-metrics-5fxg059uo7.pdf

Methodology for Validating Software Product Metrics

In today’s business environment, competitive pressures demand the production of reliable software with shorter and shorter release intervals. This is especially so in commercial high-reliability domains such as telecommunications and the aerospace industry. One recipe for success is to increase process capability. There is recent compelling evidence that process capability is positively associated with productivity and quality. (Clark, 1997; El-Emam and Birk, 2000a, 2000b; Flowe and Thordahl, 1994; Goldenson and Herbsleb, 1995; Jones, 1999; Krishnan and Kellner, 1999). Quantitative management of software quality is a hallmark of high-process capability (EI-Emam et al., 1998; Software Engineering Institute, 1995).

/pdf/object-oriented-metrics-a-review-of-theory-and-practice-1beyiouw1p.pdf

Object-oriented metrics: A review of theory and practice

Empirical software engineering can be viewed as a series of actions to obtain knowledge and a better understanding about some aspects of software development, given a set of problem statements in the form of issues, questions or hypotheses. Experience has made us aware of the criticality of integrating the various types of data that are collected and analyzed as well as the criticality of integrating the various types of activities that take place, such as experiment design and the experiment itself. This has led us to develop a Computer-Aided Empirical Software Engineering (CAESE) framework to support the empirical software engineering lifecycle. The paper first presents the CAESE framework that consists of three elements: (1) a process model for the "lifecycle" of empirical software engineering studies, including needs analysis, experiment design, actual experimentation, and analyzing and packaging results; (2) a model that helps empirical software engineers decide how to look at the "world" to be studied in a coherent manner; (3) an architecture, based on which CAESE environments can be built, consisting of tool sets for each phase of the process model, a process management mechanism, and the two types of integration mechanism that are vital for handling multiple types of data: data integration and control integration. Next, the paper describes the Ginger2 environment as an instantiation of our framework. It concludes with reports on case studies using Ginger2, which dealt with a variety of empirical data types including mouse and keystrokes, eye traces, 3D movement, skin resistance level, and videotaped data.

Ginger2: an environment for computer-aided empirical software engineering

The success of information systems development ISD projects depends on the developers who deliver them However, developers face many challenges in bringing an ISD project to successful completion These projects are often large and highly complex, with volatile targets, creating a stressful environment for developers Although prior literature has considered how technical ISD risk factors, such as project size, complexity, and target volatility, affect team-and project-level outcomes, their effects on developers have received limited attention This gap in the literature is problematic for two reasons: 1 the interplay between developers and project characteristics are unaccounted for, resulting in an incomplete picture of ISD; and 2 developer stress has been shown to reduce team performance In this research, we examine the role of empowering leadership in reducing developer stress in ISD We develop a multilevel model of the effect of empowering leadership on the relationship between technical ISD risk factors and developers' role perceptions, and explore the consequences for developers' stress The model was tested in a field study of 350 developers in 73 ISD teams from a large US-based firm Results showed that empowering leadership ameliorated the negative effects of project size and target volatility on role ambiguity as well as the negative effects of project size, complexity, and target volatility on role conflict and stress We also found that empowering leadership reduced role ambiguity, role conflict, and stress directly, and that role ambiguity and role conflict increased stress Project size, complexity, and target volatility were found to increase empowering leadership behaviors We conclude that empowering leadership can be an effective means of helping developers cope with technical ISD risk factors and discuss the implications of our findings for research and practice

The online appendix is available at https://doiorg/101287/isre20170716 

Technical Systems Development Risk Factors: The Role of Empowering Leadership in Lowering Developers' Stress

Fault generation model and mental stress effect analysis

https://link.springer.com/content/pdf/10.1007%2F978-0-387-34869-8_2.pdf

Analysis of fault generation caused by stress during software development

The effects of mental stress on fault-generation are quantitatively determined through a controlled experiment. Two teams develop the same software program under the same conditions, except for mental stress. One team is mentally stressed during the functional design phase, while the other one is not. The degree of stress is measured by two types of metrics: “inner metrics” and “outer metrics”. The inner metrics, which measure the degree of stress, show that the “stressed team” generates more faults than the “nonstressed team”. Among the inner metrics, the “schedule pressure” and “workload” metrics are the most effective for predicting fault generation. Among the outer metrics, the fatigue meter value is related to all inner metrics and is therefore useful for verifying the inner metric values.

Yoshio Arai

Papers

Fault generation model and mental stress effect analysis

Analysis of fault generation caused by stress during software development

Metrics for measuring the effect of mental stress on fault generation during software development