C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....decisions, they can be used to compare, for instance, the productivity of different techniques or technologies. Function Point Analysis (FPA) is a functional measurement technique. It is used extensively in the MIS domain to support productivity analysis and estimation models ( 1] 2, 3] 4] [5], 1996; 6] Kitchenham, 1991) It seems to capture well the specific functional characteristics of MIS software. However, FPA has been criticized as not being applicable to all types of software ( 7] Galea, 1995; 8] 9] Ince, 1991; 5] 10] 11] Ince (1991) for instance, describes the ....

....analysis and estimation models ( 1] 2, 3] 4] 5] 1996; 6] Kitchenham, 1991) It seems to capture well the specific functional characteristics of MIS software. However, FPA has been criticized as not being applicable to all types of software ( 7] Galea, 1995; 8] 9] Ince, 1991; [5]; 10] 11] Ince (1991) for instance, describes the Function Point (FP) scope issue as follows: A problem with the function point approach is that it assumes a limited band of application types: typically, large filebased systems produced by agencies such as banks, building societies and ....

[Article contains additional citation context not shown here]

C. Jones, Applied software measurement - Assuring productivity and quality. New York, NY: McGraw-Hill Inc., 1991.

....of evaluating and predicting some aspects of the production process like the effort, the cost and the productivity of software development. There are two main approaches to measuring software size: a posterior approach as LOC [8] and a priori approach as the methods based on software functionality [1, 2, 3, 4, 16, 20, 23, 26]. LOC is the simplest and the earliest method used to measure software size, it is very useful, but it also has been the object of many criticisms [4, 10] on how to define a line of code and how to deal with different types of programming languages. The methods of a priori approach get more and ....

.... account the complexity in an objective way [23] Therefore, the FPA is not likely applicable to all types of software [2] Some attempts were made to adapt FPA to software types that are complex in data manipulation as real time software in order to objectively estimate the software complexity [1, 2, 16, 20, 23, 26]. Among these, Mark II Function Point Method [23] proposed an approach to calibrate objectively the complexity, but it requires history data for calibrating. So, it may be difficult to apply it to an application type with no history data. Some other extensions deal with the special characteristics ....

[Article contains additional citation context not shown here]

Jones C., Applied software measurement -- Assuring productivity and quality, New York, McGraw-Hill Inc, 1991.

....manipulations. On the one hand, in measuring functional size, the COSMIC FFP size model does not take into account the data manipulations. On the other hand, data manipulation is a sub process transforming one data item into another one; it can be interpreted as related to algorithm complexity [16] or to a part of processing complexity [6] It is worth noting that often little is known from the specifications document about how the algorithm manipulates input to produce output. Some aspects of algorithms can be: Different cases determined by the value of input output from the ....

Jones C., Applied software measurement -- Assuring productivity and quality, New York, McGraw-Hill Inc, 1991.

....and its functionality is presented. Finally, in section 5, apart from the papers conclusion, future goals and open problems are discussed. 2 Using Surveys for Perceived Software Quality Assessment CESM is a soft measurement collection tool. As soft measures are defined measures of what Jones [3] calls soft data . Such data are related to areas in which human opinions must be evaluated and, since human opinions vary, absolute precision cannot be achieved for soft data. In respect to Stevens [4] measures scales, soft measurements are initially in ordinal scale but, as it will be shown in ....

Jones C. Applied Software Measurement: Assuring Productivity and Quality . McGraw Hill. 1991.

....such soft measures are presented. Additionally, in this section, this paper presents how these soft measures are performed within the overall measurement approach and the adopted quality methodology. 2. SOFT AND HARD MEASUREMENTS Internal software measures, also called hard measures , JON, 91] are measures of things that can be quantified with little or no subjectivity. For the hard data elements, high accuracy is both possible and desirable. Internal software measures are very frequently used in almost all software quality assurance programmes. External software measures of user ....

Jones, C, `Applied Software Measurement: Assuring Productivity and Quality', McGraw Hill, isbn: 0-07-032813-7, 1991.

.... as demonstrated by the many estimation models that have included this measure as a key parameter [1, 2] As a measure of software size though, the source code measure carries some inherent limitations, and this has been recognized by software engineering practitioners and researchers alike [3]. Among the practitioners, Allan Albrecht was the first to propose, over 20 years ago, a new way of quantifying software size based on the user s view of the software [4] Albrecht s 1979 method, now referred to as the IFPUG method, is still used today and provides useful results in many ....

....to as the IFPUG method, is still used today and provides useful results in many organizations, but it also has some limitations and these have been well documented over the past 15 years. One of these limitations is the difficulty of applying such a method outside the MIS domain, as documented by [3, 5, 6, 7, 9, 10, 11, 12, 13, 14]. In 1996, the industry sponsored the development of an IFPUG extension for real time and embedded software, which was put into the public domain under the name of Full Function Points [8, 15, 16] This extension enjoyed fair recognition, notably within the telecommunications industry and the ....

C. Jones, Applied software measurement - Assuring productivity and quality, 2 nd Edition. New York, NY: McGraw-Hill Inc., 1996.

.... software emerged 20 years ago from the empirical results gathered on a sample of MIS applications [7] As it gained wider practitioner acceptance in the 80s, the methods then available have been regularly criticized, notably for their inability to correctly measure the size of real time software [8, 9, 10, 11, 12, 13, 14, 15, 16]. Although many alternatives have been proposed, from the mid 80s to the mid 90s to address this problem, none of them seemed to have gained sufficient recognition from practitioners to be used on a regular basis across a large number of organizations and in many countries. Version 1.0 of Full ....

Jones C., Applied Software Measurement -- Assuring Productivity and Quality, McGrawHill, 1991, 493 pages.

....Instead, the unit we used for measuring detector size was the number of executable statements added to or modified in (ESAM) a program to implement the sensor or detector. The definition of executable statement was used as provided in the Source Code Counting Rules described by Jones [72] and as implemented by Metre [85] For example, the detector shown in the right side of Figure 3.1 has an ESAM count of 2 because the if statement and the call to log alert( each count as 1 executable statement. As a measure of the fragmentation of each detector s implementation, we used the ....

Capers Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, New York, New York, 1991.

....and reasons for the improvements as based on the findings. This paper discusses the evaluation of all projects performed during 4 years. Description of faults The measurement method for the description of faults uses categorisation of fault types. Categorisation is based on the ideas of Jones [13], and each root cause is determined by studying the final report and complementary discussions to clarify the context. I have also looked at IEEE Standards [14] regarding fault classification, but I decided early on that this classification uses too many categories. Often (in fact much too often) ....

.... 23 , n system design 21 , n requirements analysis 18 , n project planning and estimations 11 , n test planning 5 , n configuration management 3 , n delivery and acceptance 2 , and n others (which are usually difficult to categorise) 17 . Compared to Jones s result, [13], the percentage of errors with source cause requirements analysis is high, and the value for the source implementation is low. The value for implementation is also low if you compare with Boehm s result [15] The categorisation leads, however, to the conclusion that my thoughts about areas ....

[Article contains additional citation context not shown here]

C. Jones, "Applied Software Measurement: Assuring Productivity and Quality", 2nd edition, McGraw Hill, 1996

....the implementation of a prototype of the system. In particular, requirements analysis was conducted with the support of our requirements engineering environment Circe [2, 5] We selected four information content measures to use as F (t) namely functional score F f (measured in feature points [6]) behavioural complexity F b (measured by counting decision points) static complexity F s (measured by counting the number of entities, relationships and attributes) and document size F d (measured by counting the number of atomic requirements) The measures were automatically computed by ....

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, New York, N.Y., 1991.

.... extensively, as demonstrated by the many estimation models that include this measure as a key parameter [1, 2] As a measure of software size though, the source code measure carries some inherent limitations, and this has been recognized by software engineering practitioners and researchers alike [3]. Among the practitioners, Allan Albrecht was the first to propose, over 20 years ago, a new way of quantifying software size based on the user s view of the software [4] Albrecht s 1979 method, now referred to as the IFPUG method, is still used today and provides useful results in many ....

....to as the IFPUG method, is still used today and provides useful results in many organizations, but it also has some limitations and these have been well documented over the past 15 years. One of these limitations is the difficulty of applying such a method outside the MIS domain, as documented by [3, 5, 6, 7, 9, 10, 11, 12, 13, 14]. In 1996, the industry sponsored the development of an IFPUG extension for real time and embedded software, which was put into the public domain under the name of Full Function Points [8, 15, 16] Building on the strengths of this work and with the support of the industry, the Common Software ....

C. Jones, Applied software measurement - Assuring productivity and quality, 2 nd Edition. New York, NY: McGraw-Hill Inc., 1996.

....renovation. 4 1.1 The size of the legacy problem It is tempting to assume that we might be able to deal with legacy systems by just throwing them away. However, the sheer volume of legacy software running worldwide prohibits such an approach. If we take a look at some indicators provided by [15], we see that the total volume of all software world wide is 7 10 9 function points. The majority of software is written in old, inflexible languages. For example, 30 is written in COBOL, which corresponds to 2 2 10 11 statements. For mainframe applications, 80 of the software is written ....

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

....when it comes back it is broke. Harry Sneed mentioned during his keynote for the fourth Working Conference on Reverse Engineering that he experienced this phenomenon in an off shore outsourced Year 2000 conversion. On the other hand, outsourcing can be quite effective, for instance, a recent study [25] reports that outsourcing averages about twice the productivity of in house development in New England banking applications. In [15] a key to success for off shore outsourcing reengineering projects appeared to be intensive communication. Note that our approach also included intensive ....

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

....(for example, function points[BK91] Dre89] ffl Source Lines of Code (SLOC) The total lines of code in the product source files. ffl Reused Source Lines of Code (RSI) The total lines not written but included in the source files. RSI includes only completely unmodified reused software units[Jon91]. ffl Source Instructions Reused By Others (SIRBO) The total lines of code other products reuse from your product. ffl Software Development Cost: A historical average required for estimating reuse cost avoidance. ffl Software Development Error Rate: A historical average required for ....

Capers Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

....of the software industry. System size is measured in KLOC. Because the data set contains multiple programming languages, we adjusted each project s KLOC value to obtain a comparable size measure. To calculate the adjusted KLOC for each project we used the language levels proposed by Jones [20]. It was decided to exclude 6 projects from the analysis, because these projects were enhancements rather than new projects. Missing data is a common attribute of software engineering data [5] 16] In our case, only 90 projects had values for all the variables used in the current analysis. We will ....

Jones, C. Applied Software Measurement: Assuring Productivity and Quality, (2 nd Ed.), Mc-Graw-Hill, NY, USA, (1996).

....[93] a rate of 0.16 pages per hour in this study versus 0.5 to 1.5 or more pages for a conventional review. Others cite substantially higher rates (e.g. Jones presents a range of 12 to 50 pages per hour depending on the type of specification and whether the time is in preparation or meetings [Jones 91] This result is not especially discouraging, considering that the specification involved extensive formal notation and an inexperience modeler, this was the first real problem the modeler analyzed. In addition, these techniques have been shown to identify errors that have eluded detection by ....

Jones, C. Applied Software Measurement: Assuring Productivity and Quality. New York: McGraw-Hill, 1991.

.... need to be calibrate, i.e. all estimation techniques require recalibration to local environments; dynamic evolution environment, i.e. software projects live in not statictic 38075 Moreover, project schedules and costs are considered to be important quality factors according to Capers Jones [13] in his attempt to provide a precise definition of quality: software quality means being on time, within budget, and meeting user needs . As a consequence, considerable research attention is now directed at gaining a better understanding of the software development process as well as constructing ....

....we convert the total Function Point size to a size in KDSI (thousands of Delivered Source Instructions) for an implementation in a specific language by using an expansion factor for that language (C. Jones has published a conversion table from Function Points to lines of code in selected language [13]) This is done for those models that require KDSI as input size (COCOMO, TUCOMO, COPMO and PUTNAM) Function Points have been chosen as software size metrics because they are attractive for sizing systems written in fourth generation languages since other measures (such as lines of code) are ....

C. Jones, Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991

....analysis tools Many source code analysis tools exist, each with its own requirements for the grammars it contains. A very rudimentary grammar will do for a function point counting tool based on backfiring, that is, estimating the number of function points by counting logical source lines of code [61]. For a tool that provides rapid insight into the call structure of an entire system, it is only necessary to parse those parts of a system that contribute to the information that constitutes the call structure. For the McCabe complexity metric [82] we need to parse a little bit more, but not as ....

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGrawHill, second edition, 1996.

.... the existence of IFPUG has not prevented the emergence of variants and extensions outside its influence, nor has it been seen to be responsive in taking into account, and integrating, the various concepts underlying proposals to address some of its weaknesses, as highlighted by researchers ( 14] [9], 15] 1] 13] with the exception of questions related to the reliability and consistency of the counting process across counters [10,11] In 1994 IFPUG recognized the importance of the ISO (International Organization for Standardization) label for increasing its penetration into the ....

C. Jones, "Applied Software Measurement: Assuring Productivity and Quality", Software Engineering Series, McGraw-Hill, Inc, 1991.

....is created. Supporters claim that function point analysis is superior to lines of code metrics for productivity analysis. Capers Jones asserts that [Function Point metrics] have substantially replaced the older lines of code metric for purposes of economic and productivity analysis. [42] 24 Since the introduction of this metric, numerous refinements have been introduced, and in 1986, the International Function Point Users Group was formed to enhance the technique s use. Despite advances in function point analysis, subjective judgments remain a difficulty. Five early goals were ....

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, New York, 2 edition, 1996. 154

.... if LOC is the size metric, then the characteristics of a LOC of a final software product can be defined in no less than eleven different ways (Jones 1986) Once defined, the unit of the metric (e.g. lines of code) expresses a different magnitude of functionality due to the programming language (Jones 1991). The development environment must conform to a standard counting practice and use an adjustment factor to normalize the effects of alternative programming languages. Another example of changing counting standards is the difference between release 3.0 and release 4.0 of the International Function ....

....function points are then converted to LOC using a language expansion factor. The resulting LOC is then used in a product size based model to produce the effort and schedule estimate. Jones has maintained a function point to LOC conversion table that could support Arifoglu s approach (Jones 1986; Jones 1991; Jones 1996) Though this approach has promise, Arifoglu does not report empirical evidence to support the method. Symons (1988, 1991) re defined the function point technique to estimate systems that will use a database management system called Mark II Function Point Analysis (Mk II FPA) Again, ....

Jones, Capers. 1991. Applied software measurement: Assuring productivity and quality.

.... and improving estimation accuracy in mostly large software projects, which is hardly applicable for small medium enterprises (SMEs) In general, there is little progress in obtaining and keeping control over evolving software processes by exploitingtechnologies from software measurement [Fen91] Cap91] or experience reuse synthesis [BCR94b] BR91] 3 Evolution Framework 3.1 Conceptual framework We distinguish between a changing real world where managerial and technical activities are taking place, and a modeled world where the human perceptions and constraints of the real world is ....

Jones Capers. Applied Software Measurement: Assuring Productivity and Quality. Software Engineering Series. McGraw-Hill, 1991.

.... long proclaimed ineffectiveness of software development projects to maintain their schedule, cost, and quality, continues to plague most development projects [4, 8] It is estimated that over half of all software development projects are considered a failure with respect to their cost and schedule [6]. Extensive effort is now being made by many software companies to mature their development processes by attempting to follow the ranking of the Software Engineering Institute s (SEI) Capability Maturity Model, conforming to the ISO 9000 standard, or by following internal improvement policies. ....

Capers Jones, Applied Software Measurement: Assuring Productivity and Quality, McGraw-Hill, New York, 1991.

....are often late, over budget and of low quality. A recent world wide survey revealed that less than half of all development projects meet their goals for cost and schedule [Roberts92] Capers Jones found that fifty percent of the time we overshoot our schedules by more than sixty percent [Jones91]. An enormous number of claims such as these exist in the literature. In fact, it seems as if any paper concerning software development begins with new statistics proclaiming the same old problems of missed deadlines. Reducing the time to produce software benefits not only the customer, but also ....

C. Jones, Applied Software Measurement: Assuring Productivity and Quality, McGraw-Hill, New York, 1991. 36

....projects are far more complex due to number of persons, number of software components and required amount of management involved. In general, there is little progress in obtaining and keeping control over evolving software processes by exploiting technologies from software measurement [Fen91] Jon91] or from experience reuse synthesis [BCR94b] BR91] Indeed, most project management tools are of limited practical value, due to the accumulated effect of process changes during project execution. Thus, EPOS attempts to integrate process and project support in managing changes during ....

Capers Jones. Applied Software Measurement: Assuring Productivity and Quality. Software Engineering Series. McGraw-Hill, 1991.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

No context found.

Jones, C. (1991). Applied Software Measurement: Assuring Productivity and Quality. McGraw Hill.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, 1991.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, second edition, 1996.

No context found.

Capers Jones, Applied Software Measurement: Assuring Productivity and Quality, McGraw-Hill, Inc., New York, NY (1991).

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, second edition, 1996.

No context found.

Jones, C., "Applied Software Measurement - Assuring Productivity and Quality, McGrawHill, New York, 1991, 493 pages.

No context found.

Jones, C., "Applied Software Measurement - Assuring Productivity and Quality, McGraw-Hill, New York, 1991, 493 pages.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, second edition, 1996.

No context found.

C. Jones, Applied software measurement - Assuring productivity and quality, 2 nd Edition. New York, NY: McGraw-Hill Inc., 1996.

No context found.

Jones, C, `Applied Software Measurement: Assuring Productivity and Quality', McGraw Hill, isbn: 0-07-032813-7, 1991 Software Technology Journal, Butterworth Publications, Vol. 39, Issue 6, pp. 417-424, June 1997.

No context found.

C. Jones. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill, second edition, 1996.

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