IP flows have heavy-tailed packet and byte size distributions. This make them poor candidates for uniform sampling---i.e. selecting 1 in N flows---since omission or inclusion of a large flow can have a large effect on estimated total traffic. Flows selected in this manner are thus unsuitable for use in usage sensitive billing. We propose instead using a size-dependent sampling scheme which gives priority to the larger contributions to customer usage. This turns the heavy tails to our advantage; we can obtain accurate estimates of customer usage from a relatively small number of important samples. The sampling scheme allows us to control error when charging is sensitive to estimated usage only above a given base level. A refinement allows us to strictly limit the chance that a customers estimated usage will exceed their actual usage. Furthermore, we show that a secondary goal, that of controlling the rate at which samples are produced, can be fulfilled provided the billing cycle is sufficiently long. All these claims are supported by experiments on flow traces gathered from a commercial network.

Abstract not found

“precision ” and “accuracy ” were used in a qualitative manner to characterize measurements. These terms appeared in many American Society for Testing Materials (ASTM) standards long before any common agreement or understanding had been reached as to their meanings and consequences. Circa 1950, individuals and organizations began concerted efforts to right this situation. Churchill Eisenhart was drawn to this issue as it related to calibrations, which he called refined measurement methods. As Chief of the Statistical Engineering Laboratory (SEL), Applied Mathematics Division, he set out to put the concepts of accuracy and precision on a solid statistical basis for NBS scientists and metrologists. His paper on the subject, published in 1961 [1], was to become the preeminent publication on the subject. With impeccable scholarship and commitment to detail, Eisenhart synthesized his own work [2] and the writings of statistical theorists and practitioners, Walter Shewhart [3], Edwards Deming, Raymond Birge [4], and R. B. Murphy [5], into concepts of quality control that could be applied to measurement processes. Three basic concepts in the paper were immediately accepted by metrologists at NBS, namely: (1) a measurement process requires statistical control; (2) statistical control implies control of both reproducibility and repeatability; and (3) a measurement result requires an associated statement of uncertainty that includes any possible source of bias. In this paper, for the first time, measurements themselves were described as a process whose output can be controlled using statistical techniques. Eisenhart reinforced the conclusion, probably first drawn by Murphy [5], that “Incapability of control implies that the results of measurement are not to be trusted as an indication of the physical property at hand—in short, we are not in any verifiable sense measuring anything”—when he says, “a measurement operation must have attained what is known in industrial quality control language as a state of statistical control... before it can be regarded in any logical sense as measuring anything at all.” Eisenhart’s paper, coupled with work by other SEL statisticians, had a lasting and profound effect on

Abstract — Humans (individually, on teams, and in organizations) can follow simple processes to increase their probability of success. Many authors, both technical and nontechnical, have described processes for doing various things like designing a system, attaining business excellence, and solving personal and professional problems. The amazing similarities in these diverse processes suggest that there is a general process that might be closely related to human thinking. This general process was abstracted into the SIMILAR Process. This paper shows how the SIMILAR Process was used to help redescribe the Requirements Discovery Process and System Design Process. Index Terms—Design methodology, human thinking, modeling, problem solving, process description, requirements, standards, systems engineering.

1. A brief history of adaptive testing. 2. Computer-adaptive testing (CAT)- how it works. (a) Dichotomous items.

Companies that engage in multi-site, multi-project software development continually face the problem of how to understand and improve their software development capabilities. We have def'med and applied a goal-oriented process that enables such a company to assess the strengths and weaknesses of those capabilities. Our goals are to help a) to decrease the time and cost to develop software, b)to decrease the time needed to make changes to existing software, c) to improve software quality, d) to attract and retain a talented engineering staff, and e) to facilitate more predictable management of software projects. In response to the variety of product requirements, market needs, and development environments, we selected a goal-oriented process, rather than a criteria -oriented process, to advance our strategy and ensure relevance of the results. We describe the design of the process, discuss results achieved, and present vulnerabilities of the methodology. The process includes both interviews with projects ' personnel and analysis of change data. Several common issues have emerged from the assessments across multiple projects, enabling strategic investments in software technology. Teams report satisfaction with the outcome in that they act on the recommendations, ask for additional future assessments, and recommend the process to sibling organizations.

In recent years, a growing number of software organizations have begun to focus on applying the concepts of statistical process control (SPC) to the software process, usually as part of an improvement program based on the Software CMM. There are a number of technical challenges to the successful use of these statistical techniques, primarily centered on the issues associated with high variation between individual software professionals. A growing number of organizations, however, are demonstrating that SPC techniques can be applied to the software process, even if questions remain on the specific processes, measures, and statistical techniques that will provide significant business value. This paper illustrates the application of the XmR control chart to the Personal Software Process. SM Introduction During the last decade, the focus of software process improvement has been on fundamental project management and organizational learning issues. In recent years, more mature organizati...

Standardization in software engineering plays an important role for integrating, regulating, and optimizing existing best practices and fundamental theories in software development and organization. An idiom says that one can "gain new knowledge by reviewing the past." This chapter reviews current software engineering and software quality related standards and the history of their development. Usability and open issues in applications of the major software engineering standards are discussed. Future trends and research topics considered significant and worthy of being explored are suggested in this chapter.

IP flows have heavy-tailed packet and byte size distributions. This make them poor candidates for uniform sampling---i.e. selecting # in # flows---since omission or inclusion of a large flow can have a large effect on estimated total traffic. Flows selected in this manner are thus unsuitable for use in usage sensitive billing. We propose instead using a size-dependent sampling scheme which gives priority to the larger contributions to customer usage. This turns the heavy tails to our advantage; we can obtain accurate estimates of customer usage from a relatively small number of important samples. The sampling scheme allows us to control error when charging is sensitive to estimated usage only above a given base level. A refinement allows us to strictly limit the chance that a customers estimated usage will exceed their actual usage. Furthermore, we show that a secondary goal, that of controlling the rate at which samples are produced, can be fulfilled provided the billing cycle is sufficiently long. All these claims are supported by experiments on flow traces gathered from a commercial network. I.

Abstract. The development of software products and systems generally requires collaboration of many individuals, groups, and organizations that form an ecosystem of interdependent stakeholders. The way the interests and expectations of such stakeholders are communicated is critical for whether they are heard, hence whether the stakeholders are successful in influencing future solutions to meet their needs. This paper proposes a model based on negotiation and network theory for analyzing and designing flow of requirements through a software ecosystem. The approach supports requirements engineering process engineers and managers in taking strategic decisions for resolving communication bottlenecks, increasing overall requirements engineering productivity, and consciously assigning power to stakeholders.