Essentially a software system's utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.

/pdf/on-non-functional-requirements-in-software-engineering-3a6a23qlo6.pdf

On Non-Functional Requirements in Software Engineering

Like other sciences and engineering disciplines, software engineering requires a cycle of model building, experimentation, and learning. Experiments are valuable tools for all software engineers who are involved in evaluating and choosing between different methods, techniques, languages and tools. The purpose of Experimentation in Software Engineering is to introduce students, teachers, researchers, and practitioners to empirical studies in software engineering, using controlled experiments. The introduction to experimentation is provided through a process perspective, and the focus is on the steps that we have to go through to perform an experiment. The book is divided into three parts. The first part provides a background of theories and methods used in experimentation. Part II then devotes one chapter to each of the five experiment steps: scoping, planning, execution, analysis, and result presentation. Part III completes the presentation with two examples. Assignments and statistical material are provided in appendixes. Overall the book provides indispensable information regarding empirical studies in particular for experiments, but also for case studies, systematic literature reviews, and surveys. It is a revision of the authors book, which was published in 2000. In addition, substantial new material, e.g. concerning systematic literature reviews and case study research, is introduced. The book is self-contained and it is suitable as a course book in undergraduate or graduate studies where the need for empirical studies in software engineering is stressed. Exercises and assignments are included to combine the more theoretical material with practical aspects. Researchers will also benefit from the book, learning more about how to conduct empirical studies, and likewise practitioners may use it as a cookbook when evaluating new methods or techniques before implementing them in their organization.

Experimentation in Software Engineering

This paper presents the results of a study in which we empirically investigated the suite of object-oriented (OO) design metrics introduced in (Chidamber and Kemerer, 1994). More specifically, our goal is to assess these metrics as predictors of fault-prone classes and, therefore, determine whether they can be used as early quality indicators. This study is complementary to the work described in (Li and Henry, 1993) where the same suite of metrics had been used to assess frequencies of maintenance changes to classes. To perform our validation accurately, we collected data on the development of eight medium-sized information management systems based on identical requirements. All eight projects were developed using a sequential life cycle model, a well-known OO analysis/design method and the C++ programming language. Based on empirical and quantitative analysis, the advantages and drawbacks of these OO metrics are discussed. Several of Chidamber and Kemerer's OO metrics appear to be useful to predict class fault-proneness during the early phases of the life-cycle. Also, on our data set, they are better predictors than "traditional" code metrics, which can only be collected at a later phase of the software development processes.

/pdf/a-validation-of-object-oriented-design-metrics-as-quality-16egyd4zw9.pdf

A validation of object-oriented design metrics as quality indicators

As with any engineering discipline, software development requires a measurement mechanism for feedback and evaluation. Measurement is a mechanism for creating a corporate memory and an aid in answering a variety of questions associated with the enactment of any software process. It helps support project planning (e.g., How much will a new project cost?); it allows us to determine the strengths and weaknesses of the current processes and products (e.g., What is the frequency of certain types of errors?); it provides a rationale for adopting/refining techniques (e.g., What is the impact of the technique XX on the productivity of the projects?); it allows us to evaluate the quality of specific processes and products (e.g., What is the defect density in a specific system after deployment?). Measurement also helps, during the course of a project, to assess its progress, to take corrective action based on this assessment, and to evaluate the impact of such action.

/pdf/the-goal-question-metric-approach-2clwv1qd79.pdf

The Goal Question Metric Approach

Many organizations want to predict the number of defects (faults) in software systems, before they are deployed, to gauge the likely delivered quality and maintenance effort. To help in this numerous software metrics and statistical models have been developed, with a correspondingly large literature. We provide a critical review of this literature and the state-of-the-art. Most of the wide range of prediction models use size and complexity metrics to predict defects. Others are based on testing data, the "quality" of the development process, or take a multivariate approach. The authors of the models have often made heroic contributions to a subject otherwise bereft of empirical studies. However, there are a number of serious theoretical and practical problems in many studies. The models are weak because of their inability to cope with the, as yet, unknown relationship between defects and failures. There are fundamental statistical and data quality problems that undermine model validity. More significantly many prediction models tend to model only part of the underlying problem and seriously misspecify it. To illustrate these points the Goldilock's Conjecture, that there is an optimum module size, is used to show the considerable problems inherent in current defect prediction approaches. Careful and considered analysis of past and new results shows that the conjecture lacks support and that some models are misleading. We recommend holistic models for software defect prediction, using Bayesian belief networks, as alternative approaches to the single-issue models used at present. We also argue for research into a theory of "software decomposition" in order to test hypotheses about defect introduction and help construct a better science of software engineering.

/pdf/a-critique-of-software-defect-prediction-models-50s650jf56.pdf

A critique of software defect prediction models

At last! New experiences and lessons from one of the authors who brought you Software Metrics: Establishing a Company-Wide Program. This exciting book has over 70 charts and graphs from real projects that will help you to manage software projects and process improvements more effectively. Project managers: Learn through practical examples what to measure and track, which will help you more effectively manage your projects throughout the life cycle. Learn how to measure and present progress. Most importantly, learn why you need to measure and how important it is for you to tie your measurements to visible, agreed-upon project goals. People responsible for process improvement: Learn a useful model for understanding organizational limitations. Explore the relationship between tools and the potential for achieving improvements. Examine some of the potential problems you might face and see examples of how some of them have been avoided. Finally, discover how metrics can be rolled up into useful, balanced organizational indicators. This book emphasizes proven practices and results.These include: *Which software development "rules" are supported by measured evidence *How measurement should be tightly linked to organizational strategies *How the metrics that engineers find useful help project managers as well *What people feel about metrics and what approaches you can take to gain their support *How metrics are used to achieve continuous process improvement *Which measures are meaningful for a large organization

Practical Software Metrics for Project Management and Process Improvement

For Grad level courses in software engineering, software development and software metrics. Explains what metrics are and when they are useful. Most detailed study of a metrics program ever done.

Software Metrics: Establishing a Company-Wide Program

Offering a method of improving the way organizations develop software, this guide shows how to plan and develop a core competency in software development Presenting an investment model for software process improvement, it describes methods for sustaining management commitment and generating a environment that will ensure success The book organizes software process improvement into four stages: Plan, Do, Check and Act It then thoroughly reviews the steps to be taken in each stage, showing how to assess current software processes more effectively, and plan and invest to make software development a core competency It also makes recommendations to ensure that management stays committed to process improvement for the future Finally, the book describes specific techniques organizations can use to track, validate and evaluate software process improvements

Successful Software Process Improvement

O~IWUC ~aavcry yourr~ficld. Whik ~~.z~~pr~~~~%bd~ been made in a short time, it has not attained the maturity ofmany other technical ticids. Therefore, ir is useful to try to get ahead by applying analogies from these other fields. One common metaphor is the construction of buildings. We can conveniently draw parallels to methods (drawings and designs), standards (for foundations, framing, components), tools, and a variety of specialized jobs that have developed over thousands of years of trial and error. What spurred such developments? State-of-the-art projects in any field often f&cc new standards. For example, have you ever visited a beautiful old Euro-pean cathedral? It is very enlightening to hear the stories of how the massive towers of some cathedrals only reached their current heights after earlier disastrous collapses.' Nevertheless, these stories are just unfortunate examples in a developing engineering field. Most learning was accomplished on a less dramatic scale. One lesson this analogy teaches is that some of our most important engineering premises are based on rp<-rracular 1:ul1n-cs. When we speak ofsof~twarem,@neeri~~ we should remember such beginnings ofother mature fields. Software trial and error forms the basis for a new developing field. We learn from our mistakes. Successful codification of best practices allows us to move forward without having to repeat the mistakes of others. Just as the masons who built the old cathedrals traveled from one building site to another to exchange good ideas for avoiding problems, we can learn from our defects. At our software conferences, there is often heated debate about how to define " quality. " Some argue that it is " fitness for use. " Others say " satisfying customer needs " or " absence ofdefects. " This article takes the practical stancr that, like other, previous immature fields, it is initially mozt useful to focus improvement efforts on defects. A defect is any flaw in the specification, design or implementation of a product [4]. This article contains results that are supported by quality measurements. The first section looks at examples of proven software best practices. These help us avoid defects or detect them sooner. The examples include the kind of persuasive data needed to establish best practices. The second section gives a defect categorization model that highlights areas for potential improvement for an organization. The best way to accelerate our field's transition to true engineering status is to learn not only from software disasters, but …

Robert B. Grady

Papers

Practical Software Metrics for Project Management and Process Improvement

Software Metrics: Establishing a Company-Wide Program

Successful Software Process Improvement

Practical results from measuring software quality