/start exch def /rotval exch def /mode exch def findfont /infont exch def /printme exch def

www.utdallas.edu/~chung/, www.inf.puc-rio.br/~julio Abstract. 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.

Software metrics as a subject area is over 30 years old, but it has barely penetrated into mainstream software engineering. A key reason for this is that most software metrics activities have not addressed their most important requirement: to provide information to support quantitative managerial decision-making during the software lifecycle. Good support for decision-making implies support for risk assessment and reduction. Yet traditional metrics approaches, often driven by regression-based models for cost estimation and defects prediction, provide little support for managers wishing to use measurement to analyse and minimise risk. The future for software metrics lies in using relatively simple existing metrics to build management decision-support tools that combine different aspects of software development and testing and enable managers to make many kinds of predictions, assessments and trade-offs during the software life-cycle. Our recommended approach is to handle the key factors...

Conventional software engineering tends to focus on a small part of the software life cycle: the design and implementation of a product. The bulk of the lifetime cost is in the maintenance phase, where one must live with the product previously developed. Presently, we have little theory and fewer tools to help us manage the maintenance activity. We contend that a fundamental cause of the difficulty is the failure to preserve design information. This results from an over preoccupation with the synthesis and maintenance of code. We offer an alternative paradigm: . make the design the central focus of the construction process---get code as a byproduct; . make the design the central focus of the maintenance process---preserve revised designs and get code as a byproduct. A transformational scheme for accomplishing this is presented. We call it the Design Maintenance System. The programming roles change radically from coding instances for ill-defined specifications to specifiers of func...

/start exch def /rotval exch def /mode exch def findfont /infont exch def /printme exch def

The analysis and measurement of current levels of software reuse are necessary to monitor improvements. This paper provides a framework for the derivation of measures of software reuse and introduces several de#nitions, attributes, and abstractions of potentially measurable reuse properties. The framework is applied to the problem of measuring reuse in object oriented systems which support #leveraged" reuse through inheritance. I describe the importance of the perspective of the observer when analyzing, measuring, and pro#ling reuse. Three perspectives are examined: the server perspective, the client perspective, and the system perspective. Candidate reuse metrics are proposed from each perspective. 1 Introduction Research on formal aspects of software measurement tends to focus on properties of measures, measurement theory, measurement scales, and requirements for predictive measures. This paper reports on the practical application of techniques developed in formal studies of softwar...

Construct validity is about the question, how we know that we're measuring the attribute that we think we're measuring? This is discussed in formal, theoretical ways in the computing literature (in terms of the representational theory of measurement) but rarely in simpler ways that foster application by practitioners. Construct validity starts with a thorough analysis of the construct, the attribute we are attempting to measure. In the IEEE Standard 1061, direct measures need not be validated. "Direct" measurement of an attribute involves a metric that depends only on the value of the attribute, but few or no software engineering attributes or tasks are so simple that measures of them can be direct. Thus, all metrics should be validated. The paper continues with a framework for evaluating proposed metrics, and applies it to two uses of bug counts. Bug counts capture only a small part of the meaning of the attributes they are being used to measure. Multidimensional analyses of attributes appear promising as a means of capturing the quality of the attribute in question. Analysis fragments run throughout the paper, illustrating the breakdown of an attribute or task of interest into sub-attributes for grouped study.

We describe the application of model checking tools to analyze a real-time software challenge in the design of Lucent Technologies' 5ESS telephone switching system. We use two tools: COSPAN for checking real-time properties, and TPWB for checking probabilistic specifications. We report on the feedback given by the tools, and based on our experience, discuss the advantages and the limitations of the approach used.

Software engineering researchers have long been interested in where and why bugs occur in code, and in predicting where they might turn up next. Historical bug-occurence data has been key to this research. Bug tracking systems, and code version histories, record when, how and by whom bugs were fixed; from these sources, datasets that relate file changes to bug fixes can be extracted. These historical datasets can be used to test hypotheses concerning processes of bug introduction, and also to build statistical bug prediction models. Unfortunately, processes and humans are imperfect, and only a fraction of bug fixes are actually labelled in source code version histories, and thus become available for study in the extracted datasets. The question naturally arises, are the bug fixes recorded in these historical datasets a fair representation of the full population of bug fixes? In this paper, we investigate historical data from several software projects, and find strong evidence of systematic bias. We then investigate the potential effects of “unfair, imbalanced” datasets on the performance of prediction techniques. We draw the lesson that bias is a critical problem that threatens both the effectiveness of processes that rely on biased datasets to build prediction models and the generalizability of hypotheses tested on biased data 1.

this report is to review and summarize the empirical evidence thus far on the costs and benefits of SPI. The intention is that this review would be utilized to support the business case for initiating and continuing SPI programs, to aid in the selection amongst the alternative improvement paradigms, to make more accurate estimates of the costs and benefits of such efforts, and to help set and manage the expectations of technical staff and management. The need for such a review is supported by the results of two recent surveys that were conducted by the SEI. The first survey was administered to individuals at the National SEPG Conference in 1993 and at an SPI tutorial during the Software Engineering Symposium in 1993 [25]. The respondents represented organizations that had mature SPI programs. More than seventy percent stated that they need information on the benefits of SPI (by choosing the "very high" or "high" response category in terms of characterizing their needs), which was also ranked as the highest need of the respondents. This indicates a need for consolidation of the evidence on the benefits of SPI. The second survey solicited information from organizations that had conducted software process assessments between 1992 and 1993 [26]. The results indicate that 77% of the respondents "Strongly Agree" or "Agree" that SPI has taken longer than expected and 68% stated that SPI has cost more than expected. This indicates a need for information to help estimate the costs of SPI and to set and manage expectations from SPI. Two general paradigms to SPI have emerged, as described by Card [10]. The first is the analytic paradigm. This is characterized as relying on "quantitative evidence to determine where improvements are needed and whether an improvement initiative has b...