Results 1 - 10
of
63
Software size measurement: A framework for counting source statements
, 1992
"... /start exch def /rotval exch def /mode exch def findfont /infont exch def /printme exch def ..."
Abstract
-
Cited by 63 (2 self)
- Add to MetaCart
/start exch def /rotval exch def /mode exch def findfont /infont exch def /printme exch def
Non-functional requirements in software engineering
, 1999
"... 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 em ..."
Abstract
-
Cited by 59 (6 self)
- Add to MetaCart
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: Roadmap
, 2000
"... 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 de ..."
Abstract
-
Cited by 43 (0 self)
- Add to MetaCart
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...
Software Change Through Design Maintenance
, 1997
"... 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 to ..."
Abstract
-
Cited by 28 (1 self)
- Add to MetaCart
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...
Software Quality Measurement: A Framework for Counting Problems and Defects
, 1992
"... /start exch def /rotval exch def /mode exch def findfont /infont exch def /printme exch def ..."
Abstract
-
Cited by 27 (5 self)
- Add to MetaCart
/start exch def /rotval exch def /mode exch def findfont /infont exch def /printme exch def
Deriving Measures of Software Reuse in Object Oriented Systems
- Formal Aspects of Measurement. (Proc. BCS-FACS Workshop on Formal Aspects of Measurement
, 1992
"... 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 fra ..."
Abstract
-
Cited by 24 (7 self)
- Add to MetaCart
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...
Software Engineering Metrics: What Do They Measure and How Do We Know?
- In METRICS 2004. IEEE CS
, 2004
"... 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 applicat ..."
Abstract
-
Cited by 21 (1 self)
- Add to MetaCart
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.
Model Checking of Real-Time Systems: A Telecommunications Application
- IN PROCEEDINGS OF THE 19TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING
, 1997
"... 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 feedba ..."
Abstract
-
Cited by 17 (1 self)
- Add to MetaCart
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.
Fair and Balanced? Bias in bug-fix Datasets
- in European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE
, 2009
"... 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 ..."
Abstract
-
Cited by 17 (6 self)
- Add to MetaCart
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.
Costs and Benefits of Software Process Improvement
, 1997
"... 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, ..."
Abstract
-
Cited by 13 (8 self)
- Add to MetaCart
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...

