Norman E. Fenton. Software Metrics: A Rigorous Approach. Chapman and Hall, London, 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....for example, safety applies to all components of an auto pilot system on an aircraft. Each quality viewpoint therefore has a defined time in the life cycle when it applies, and at this particular time, specifies the parts of the system affected by it. Table 2 shows a set of possible metrics [19, 11, 15] for assessing product quality compliance. It should be stressed that the quality requirements are given for demonstration purposes only and are in no way generic for all systems. The table though could feasibly be used as a starting point to develop specific quality viewpoints, reusing some of ....

....is reverse traceable to this viewpoint according to the rules of VOCAL. Therefore bi directionality for item 5 is retained with the functionality concerning cash withdrawal. 2. Quality Requirements Viewpoints Group, assess the results of user evaluation. Evaluation assessment requires measurement [11]. Measurement is provided by quality metrics to evaluate the users aspect of product quality, quantifying the evaluation. Important quality aspects to consider (to be made inter traceable) from the operational user validation viewpoint are, performance and usability assessment. Note that ....

FENTON, N. E.: "Software Metrics, A Rigorous Approach" (Chapman & Hall, 1991)

....analyze the quality of these metrics. What is a valid metrics, or even a valid measurement method How do you validate a measurement method Various authors have attempted to address these questions, but usually from different points of view (mathematical, practical, etc. in the past few years [2, 4, 8, 9, 11, 18]. For example, Schneidewind proposes a metrics validation methodology based on six validity criteria [18] while other authors [4, 8] postulate that a measurement method is valid if it can be shown that it gives a proper numerical characterization of some attributes. Nevertheless, this ....

....authors have attempted to address these questions, but usually from different points of view (mathematical, practical, etc. in the past few years [2, 4, 8, 9, 11, 18] For example, Schneidewind proposes a metrics validation methodology based on six validity criteria [18] while other authors [4, 8] postulate that a measurement method is valid if it can be shown that it gives a proper numerical characterization of some attributes. Nevertheless, this definition is far from being unanimously accepted, and Fenton remarks that there is an implicit assumption in the software community that ....

[Article contains additional citation context not shown here]

N. Fenton "Software Metrics : A Rigorous Approach", Chapman & Hall, 1991.

....shown to be e ective for the speci c transformation based problem of automatic parallelisation [45, 46, 66, 67] so there is reason to hope that they will be applicable to more general software engineering problems. Fitness functions on programs are nothing more than code level software metrics [20, 52]. A metaheuristic approach to program transformation therefore provides a mechanism to combine program transformation rules with software metrics. The metric is used to guide the search, while the possible solutions that can be found are bounded by the set of transformations chosen. The existing ....

Fenton, N. E. Software Metrics: A Rigorous Approach. Chapman and Hall, 1990.

....or planned for release B or C. The prioritisations are performed on a ratio scale and normalised to a relative value in the range between 0 and 1. Thus, it is possible to subtract the cost from the value, getting a resulting priority, which is marked by the black arrows in the bar chart [5]. The bars are sorted on their resulting priority from top down. Thus the bar chart shows the ideal order in which requirements should be implemented if only customer value and development costs were to be considered. Some of the requirements were not identified in release A, but turned out to be ....

Fenton, N.E., Software Metrics - A Rigorous Approach, Chapman & Hall, 1994.

....shown to be effective for the specific transformation based problem of automatic parallelisation [45, 46, 66, 67] so there is reason to hope that they will be applicable to more general software engineering problems. Fitness functions on programs are nothing more than code level software metrics [20, 52]. A metaheuristic approach to program transformation therefore provides a mechanism to combine program transformation rules with software metrics. The metric is used to guide the search, while the possible solutions that can be found are bounded by the set of transformations chosen. The existing ....

FENTON, N. E. Software Metrics: A Rigorous Approach. Chapman and Hall, 1990.

....teaching and research at universities in Colorado for the purpose of economic development. guidelines of scientific measurement principles as applied to software [BBF90] Attributes of reuse measurement are internal product attributes related to properties of particular software document [Fen91]. In the tool design, we stress flexibility, so that users can tailor their metric use to their own goals. Our aim is to identify a suite of metrics for primitive reuse attributes. These are attributes that are clearly components of the level of reuse. We do not attempt to combine these ....

.... the primitive metrics and must be defined very carefully [MGBB90] Thus we focus on developing primitive reuse metrics which can later be used (or combined) to satisfy specific goals and questions of software developers [BS88] 2 Background Conte [CDS86] Boehm [Boe81] Bailey [BB81] and Fenton [Fen91] describe reuse measures that are based on comparisons between the length or size of reused code and the size of newly written code in particular software products. The purpose of Conte s reuse measure is estimating coding effort. Boehm and Bailey use the size of reused code to adjust cost ....

[Article contains additional citation context not shown here]

N. Fenton. Software Metrics A Rigorous Approach. Chapman & Hall, London, 1991.

....software system depend on factors such as the nature of the product and the skill level of the users. As a result, the characterizations of software quality differ among the case studies. In order to express commonality, we must necessarily adopt a fairly general view of software quality. Fenton [Fen91] identifies, for example, reliability, maintainability,andusability as principal attributes for which measurement is useful. He also describes a define your own quality model approach that allows the end user and the software engineer to agree on the important quality attributes for a ....

....military (3) other (11) unpublished (20) published (2) student (10) 7) academic (15) professional Figure 1: Sources of case study data In our analysis, we examine case study conclusions with a focus on the impact of rapid prototyping on software quality. Using Fenton s approach [Fen91] quality is characterized according to external and internal attributes. External attributes refer to the interface between the system and external entities such as the 3 not stated (2) failure (29) success Figure 2: Reported prototyping success failure users and the programmers. External ....

N. Fenton. Software Metrics - A Rigorous Approach. Chapman and Hall, 1991. 12

....Problems There are several examples of software development projects that turn into great disasters. In Chapter 1, some figures were quoted to indicate the effect of problems in the development projects. A first overview of these problems suggests that they fall into three main categories (Fenton, 1991, p. 7) Cost. Developing software is expensive, particularly when maintenance is included in the consideration. Much of the cost can be attributed to non productive activities such as rework and fixing problems. Productivity. There is a certain backlog of work within software development. ....

....of software development for which the concept of quality has a meaning. This will not only include physical objects, but also other concepts, e.g. services and models. 2.3. 1 Entities Software development can be considered as comprised by three basic entities: Products, processes and resources (Fenton, 1991; Basili, 1994b; Reynolds, 1994) These three basic entities of software engineering are depicted in Figure 1 together with four typical views present within software development. Products include the software, its specification, documentation, user manual and related information. This category ....

[Article contains additional citation context not shown here]

Norman Fenton. Software Metrics: A Rigorous Approach. Chapman & Hall, London, 1991.

....of FPMM and FPPM with which to measure it; they are not the topic of this paper. Two things are intrinsic to the problem: the top left quadrant, and the inherent complexity of the problem (Fenton calls inherent complexity a third dimension of size, along with functionality and physical size [9]) Everything else is related to the product that solves the problem. Inherent complexity is only one of the usual GSC s it means is the calculation hard or easy. In its aim to adjust for inherent complexity, the current VAF casts a far broader net; Jones [16] limits the adjustment much more ....

Fenton, N.E. Software Metrics: a Rigorous Approach. Chapman and Hall, London, 1991.

....the whole software life cycle, maintainability has become one of the software product quality characteristics [21] that software development organisations are more concerned about. Maintainability is not restricted to code, it is an attribute of the different software products we hope to maintain [15], like, for example, class diagrams. However, we are aware that maintainability is an external quality attribute that can only be measured late in the OOIS life cycle. Therefore, it is necessary to have early indicators of such qualities based, for example, on the structural properties of class ....

....that maintainability is an external quality attribute that can only be measured late in the OOIS life cycle. Therefore, it is necessary to have early indicators of such qualities based, for example, on the structural properties of class diagrams [5] Most of the existing literature on OO measures [15], 20] 25] 37] is related to measures, which can only be applied once a software product is completed or nearly complete. These provide information too late to lead us in building quality OOIS. So after a thorough review of some of the existing OO measures, applicable to class diagrams at ....

[Article contains additional citation context not shown here]

Fenton, N. and Pfleeger, S., Software Metrics: A Rigorous Approach. 2 . edition. London, Chapman & Hall, (1997).

....DTDs are enumerated. Applications that can use the metrics are shown in section 5. Section 6 provides two detailed examples. In section 7, we give a conclusion. 2 Related work Many publications and results on software metrics are available. A general overview of that research eld is given in [Fen91]. An extensive collection of articles dealing with software metrics is available in [Dum02] Horst Zuse Supported by the German ResearchAssociation (DFG) He 1768 7 1 1 and Katrin Drabe collected and classi ed more that 1600 di erent metrics in the (ZDMIS measure information system) ....

Norman E. Fenton. Software Metrics { A Rigorous Approach. Chapman & Hall, London, 1991. 14

....96] The term complexity deserves a special attention. In table 1 we have cited control flow complexity as a product internal attribute and many authors call this simply complexity. For other authors instead complexity is a very high level term that comprehends nearly all aspects of software. Fenton 91] distinguishes three kinds of complexities: computational, psychological and representational. We will concentrate only on the psychological one that is complexity as perceived by man. This kind of complexity comprehends structural complexity, programmer characteristics and problem complexity. ....

N. Fenton, Software Metrics: A Rigorous Approach, Chapman and Hall, London, 1991

....of transformations applied to the initial model of that problem. So behind each solution there is a problem. However the complexity of the problem differs from the complexity of the solution. Complex solutions may exist for simple problems. In this paper we will use the following definitions: [9] [5] 16] 17] 18] 31] The complexity of a problem is the amount of resources required for an optimal solution of the problem . The complexity of a solution is the amount of resources required for that solution of the problem . In order to evaluate the complexity of a solution several types ....

....of a problem is the amount of resources required for an optimal solution of the problem . The complexity of a solution is the amount of resources required for that solution of the problem . In order to evaluate the complexity of a solution several types of metrics are frequently used: [9] [5] Algorithmic Complexity Is required to reflect the algorithmic complexity in each solution. There are two types of metrics in this class: one is the complexity based on the algorithmic efficiency, the other is the complexity on the structure of the algorithm. Cognitive Complexity Is ....

[Article contains additional citation context not shown here]

Fenton N E: Software Metrics: A Rigorous Approach, Chapman & Hall, 1991.

No context found.

Norman E. Fenton. Software Metrics: A Rigorous Approach. Chapman and Hall, London, 1991.

No context found.

Norman E. Fenton. Software Metrics: A Rigorous Approach. Chapman & Hall, 1991.

No context found.

Norman E. Fenton. Software Metrics: A Rigorous Approach. Chapman and Hall, London, 1991.

No context found.

Fenton, N. E., Software Metrics - A Rigorous Approach, Chapman & Hall, 1991.

No context found.

Fenton, N. E. (1991). Software Metrics A Rigorous Approach. Chapman and Hall.

No context found.

Norman E Fenton, "Software Metrics, A Rigorous Approach", Chapman & Hall, London, 1991, pp 143

No context found.

Fenton, N.E., Software Metrics - A Rigorous Approach, Chapman & Hall, 1994.

No context found.

N. E. Fenton. Software Metrics: A rigorous approach. Chapman & Hall, 1991.

No context found.

Fenton, N. Software Metrics - A Rigorous Approach. First Edition, Chapman & Hall, 1991. 33

No context found.

Norman E. Fenton. Software Metrics { A Rigorous Approach. Chapman & Hall, London, 1991.

No context found.

Fenton, N.E., Software Metrics: A Rigorous Approach, Chapman & Hall, 1992, pp. 337.

No context found.

N. Fenton, Software Metrics - A Rigorous Approach. London: Chapman and Hall, 1991.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC