Park Robert, Software Size Measurement: A Framework for Counting Source Statements, Technical report, Software Engineering Institute, 1992.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....products and the projects that produce these products. The SEI SW CMM defines the following types of metrics: Product size . Development effort . Development schedule (or duration) Product quality . Product performance Several SEI technical reports describe these metrics in detail [3] [4], 5] and [6] The exception is product performance, which has no descriptive report. John Baumert s report, reference [3] does provide some references to other sources. Our organization s Software Engineering Process Group (SEPG) established a metrics program that met the SEI criteria for ....

Park, Robert E., "Software Size Measurement: A Framework for Counting Source Statements", SEI Technical Report CMU/SEI-92-TR-20, September 1992.

....A more detailed evaluation based on application results is given in Chapter 6. 8.1 Code size and complexity Figure 34 shows a breakdown of the code size for each of the Java packages in the Sandstorm implementation. The number of classes, methods, and non commenting source statements (NCSS) [109] are shown. The latter is a better indication of code size than source code lines, which vary greatly with indentation and coding style. The figure shows that Sandstorm is relatively small, with a total of only 10299 NCSS. The bulk of the complexity lies in the NBIO primitives and Dennis Chi ....

R. Park. Software size measurement: A framework for counting source statements. Technical Report CMU/SEI-92-TR-020, Carnegie-Mellon Software Engineering Institute, September 1992.

....Size EM BSF i i i = 1 5 1 17 Eq. 4.2 where, A = Baseline multiplicative calibration constant B = Baseline Exponential calibration constant, set at 1.01 for the 1997 calibration. 67 Size = Size of the software project measured in terms of kSLOC (thousands of Source Lines of Code [Park, 1992] or Function Points [IFPUG, 1994] and Programming Language. SF = Scale Factor EM = Effort Multiplier The five scale factors and 17 effort multipliers of the COCOMO II Post Architecture model are shown in table 4.1. All these twenty two variables are measured qualitatively by selecting a rating ....

.... on a data collection form (Appendix B) A question asked very frequently is the definition of software size, i.e. what defines a line of source code or a Function Point (FP) Appendix B in the Model Definition Manual [CSE, 1997] defines a logical line of code using the framework described in [Park, 1992] and [IFPUG, 1994] gives details on the counting rules of FPs. In spite of the definitions, the data collected to date exhibits local variations caused by differing interpretations of the counting rules. Another parameter that has different definitions within different organizations is effort i.e. ....

[Article contains additional citation context not shown here]

Park, 1992 - "Software Size Measurement: A Framework for Counting Source Statements," Park, CMU-SEI-92-TR-20, Software Engineering Institute, Pittsburg, PA, 1992.

....expressed in Person Month (PM) which is the amount of time one person spends for the project in one calendar month. The key inputs for the base model are the Size of the developing software project, a constant A, and a scale factor B. COCOMO uses Object Points [Banker 92] Source Lines of Code [Park 92] and Unadjusted Function Points [IFPUG 94] with modifiers for reuse, adaptation, and software breakage. The multiplicative constant, A, captures the linear effects of effort as the project size increases. It is also used to calibrate the model for a better fit. EQ 2.9) The B in EQ 2.9 is the ....

.... in the COCOMO II database is recorded from a data collection form asking questions regarding size, effort, schedule, 5 scale factors, 17 effort multipliers and quality information of the completed projects [USC CSE 99] For the size input to the PostArchitecture model, Source Lines Of Code (SLOC) Park 92] or Unadjusted Function Points (UFP) IFPUG 94] can be used as a counting method. Also, the size input can be adjusted for breakage effects, adaptation, and reuse with the modifiers: the percentage of design modified (DM) the percentage of code modified (CM) the percentage of modification to ....

Robert E. Park, "Software Size Measurement: A Framework for Counting Source Statements", CMU/SEI-92-TR-20, Carnegie Mellon University, Pittsburgh, PA, 1992.

....Working Group. These drafts were distributed for industry and government review in the fall of 1991. We have now extended that work, guided by the comments we have received; and our results are presented in three framework documents that are being published concurrently with this report [Park 92] Goethert 92] Florac 92] These documents provide methods for clearly communicating measurement results. They include measurement definitions; checklists for constructing alternative definitions and data specifications; instructions for using the checklists to collect, record, and report ....

....a basic set of software measures for use with DoD software systems. These recommendations are based on checklists, forms, and operational practices that are presented and discussed more completely in three framework reports: Software Size Measurement: A Framework for Counting Source Statements [Park 92] Software Effort Schedule Measurement: A Framework for Counting Staff Hours and Reporting Schedule Information [Goethert 92] Software Quality Measurement: A Framework for Counting Problems and Defects [Florac 92] The framework reports should be used as references when implementing the ....

[Article contains additional citation context not shown here]

Park, Robert E. et al. Software Size Measurement: A Framework for Counting Source Statements (CMU/SEI-92-TR-20). Pittsburgh, Pa: Software Engineering Institute, Carnegie Mellon University, September 1992.

....result from the software process. Quality of the products produced. For more information on these measures and how they can be defined to help an organization measure its benefits, refer to [Goethert 92] for measuring resources expended and the amount of calendar time to execute the process, Park 92] and [IFPUG 90] for measuring the size of software products, and [Florac 92] for measuring the quality of products produced. Information about measures related to the CMM is provided in [Baumert 92] A set of core measures is recommended in [Carleton 92] Business value. Often the result of most ....

Park, Robert E. Software Size Measurement: A Framework for Counting Source Statements (CMU/SEI-92-TR-20, ADA258304). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1992.

....directly from the CVS repository or have been computed from this data. Some of these can also be directly seen on the data model presented above (see Fig. 1) The first metric to be used is the number of lines of code (LOC) added to a file. The definition of this often disputed metric LOC [11] [16] is taken from the CVS repository and therefore includes all types of lines of code, e.g. also commentaries. In addition, any LOC changed is counted as one line of code added and one line of code deleted. The grand total of LOC added was 6 300 000 for the whole project and all programmers. The ....

R.E. Park, "Software size measurement: A framework for counting source statements," Technical Report CMU/SEI-92-TR-20, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1992.

....The Software Engineering Institute (SEI) has developed this checklist as part of a system of definition checklists, report forms and supplemental forms to support measurement 1 . significant module interfaces specified, significant risks eliminated. COCOMO Reference Manual 7 definitions [Park 1992] [Goethert et al. 1992] Figure 1 1 shows a portion of the definition checklist as it is being applied to support the development of the COCOMOII model. Each checkmark in the Includes column identifies a particular statement type or attribute included in the definition, and viceversa for the ....

....usage, delivery, functionality, replications and development status. There are also clarifications for language specific statements for ADA, C, C , CMS 2, COBOL, FORTRAN, JOVIAL and Pascal. Some changes were made to the line of code definition that departs from the default definition provided in [Park 1992]. These changes eliminate categories of software, which are generally small sources of project effort. Not included in the definition are commercial off the shelf software (COTS) government furnished software (GFS) other products, language support libraries and operating systems, or other ....

Park R. (1992), "Software Size Measurement: A Framework for Counting Source Statements," CMU/SEI-92-TR-20, Software Engineering Institute, Pittsburgh, PA.

....(SEI) definition checklist for a logical source statement is used in defining the line of code measure. The Software Engineering Institute (SEI) has developed this checklist as part of a system of definition checklists, report forms and supplemental forms to support measurement definitions [Park 1992, Goethert et al. 1992] Figure 5 shows a portion of the definition checklist as it is being applied to support the development of the COCOMO II model. Each checkmark in the Includes column identifies a particular statement type or attribute included in the definition, and vice versa for the ....

....and development status. There are also clarifications for language specific statements for ADA, C, C , CMS 2, COBOL, FORTRAN, JOVIAL and Pascal. The complete checklist is in Appendix B. Some changes were made to the line of code definition that depart from the default definition provided in [Park 1992]. These changes eliminate categories of software which are generally small sources of project effort. Not included in the definition are commercial off the shelf software (COTS) government furnished software (GFS) other products, language support libraries and operating systems, or other ....

Park R. (1992), "Software Size Measurement: A Framework for Counting Source Statements." CMU/SEI-92-TR-20, Software Engineering Institute, Pittsburgh, PA.

....of code measurement is the fact that it is difficult to estimate the number of lines of code that will be needed from the information available at the requirements or design phase of the project. This metric over emphasizes the coding stage of the software development. The report by Robert Park [25] presents guidelines for defining and reporting the lines of code. Two important factors that the report takes into account are: ffl Communication: if someone else uses the measurement, what will it mean to the other person, and ffl Repeatability : if another person measures the same software, ....

....person, and ffl Repeatability : if another person measures the same software, will he get the same value. IEEE standard 1045 [19] provides terms and definitions to arrive at a measure of software productivity. It however, does not resolve ambiguities in source code size measurements. Park s report [25] provides guidelines to record and report size measurements that are well suited for our case. Lines of code measurement falls under two categories, namely physical lines of code and logical lines of code. Physical lines of code give an idea of the physical size of the software, while logical ....

[Article contains additional citation context not shown here]

Park, R. E. Software Size Measurement: A Framework for Counting Source Statements. Tech. Rep. CMU/SEI-92-TR-20, Software Engineering Institute, Carnegie Mellon University, 1992.

....comparable size measurement across COCOMO 2.0 participants and users, standard counting rules are necessary. A consistent definition for size within projects is a prerequisite for project planning and control, and a consistent definition across projects is a prerequisite for process improvement [Park 1992]. The COCOMO 2.0 model has adopted counting rules that have been formulated by wide com 10 munity participation or standardization efforts. The source lines of code metrics are based on the Software Engineering Institute source statement definition checklist [Park 1992] The function point ....

....for process improvement [Park 1992] The COCOMO 2.0 model has adopted counting rules that have been formulated by wide com 10 munity participation or standardization efforts. The source lines of code metrics are based on the Software Engineering Institute source statement definition checklist [Park 1992]. The function point metrics are based on the International Function Point User Group (IFPUG) Guidelines and applications of function point calculation [IFPUG 1994] Behrens 1983] Kunkler 1985] 4.2.1 Lines of Code Counting Rules In COCOMO 2.0, the logical source statement has been chosen as ....

[Article contains additional citation context not shown here]

Park R. (1992), "Software Size Measurement: A Framework for Counting Source Statements." CMU/SEI-92-TR-20, Software Engineering Institute, Pittsburgh, PA.

....and FFRDC organizations. The initial COCOMO II Post Architecture model had the following form: # # Effort A Size EM SF i i # # # # # # # # 1 01 1 17 1 5 . 1) where, A = Multiplicative Constant Size = Size of the software project measured in terms of KSLOC (thousands of Source Lines of Code [12], Function Points [9] or Object Points [1] SF = Scale Factor EM = Effort Multiplier [refer to 2, 3 for further explanation of COCOMO 81 and COCOMO II respectively] Equation 1 can be linearized by taking logarithms as follows: ln( ln( ln( ln( ln( ln( ln( PM Size SF Size SF Size ....

Park R. et al, "Software Size Measurement: A Framework for Counting Source Statements", CMUSEI -92-TR-20, Software Engineering Institute, Pittsburg, PA, 1992.

....comparable size measurement across COCOMO 2.0 participants and users, standard counting rules are necessary. A consistent definition for size within projects is a prerequisite for project planning and control, and a consistent definition across projects is a prerequisite for process improvement [Park 1992]. The COCOMO 2.0 model has adopted counting rules that have been formulated by wide community participation or standardization efforts. The source lines of code metrics are based on the Software Engineering Institute source statement definition checklist [Park 1992] The function point metrics are ....

....for process improvement [Park 1992] The COCOMO 2.0 model has adopted counting rules that have been formulated by wide community participation or standardization efforts. The source lines of code metrics are based on the Software Engineering Institute source statement definition checklist [Park 1992]. The function point metrics are based on the International Function Point User Group (IFPUG) Guidelines and applications of function point calculation [IFPUG 1994] Behrens 1983] Kunkler 1985] Annals of Software Engineering DRAFT 2.1 10 4.2.1 Lines of Code Counting Rules In COCOMO 2.0, the ....

[Article contains additional citation context not shown here]

Park R. (1992), "Software Size Measurement: A Framework for Counting Source Statements." CMU/SEI-92-TR-20, Software Engineering Institute, Pittsburgh, PA.

....it was checked for completeness and consistency. Incomplete or inconsistent data points were dropped from the calibration dataset. A frequent question is what defines a line of source code. Appendix B in the Model Definition Manual [6] defines a logical line of code using a framework described in [10]. However the data collected to date has exhibited local variations in interpretation of counting rules, which is one of the reasons that local calibration produces more accurate model results. Local calibration results are discussed later in this paper. The data collected included the actual ....

Park. R., "Software Size Measurement: A Framework for Counting Source Statements," CMU/SEI-92-TR-20, Software Engineering Institute, Pittsburgh, Pa., 1992.

....Software management depends upon managers to collect accurate data of the software development process and on the production of accurate models upon which to use that data. Lines of code is still the most widely used measure for cost and error analysis, even though it is known to be inaccurate [8]. However, since it is not known until the completion of a project, its use as a predictive measure is not reliable. What are needed are more accurate models of the software development process. Current models are developed according to broad categories, such as waterfall development, spiral ....

R. E. Park. Software size measurement: A framework for counting source statments. Technical Report 92-TR-20, Software Engineering Institute, Carnegie Mello University, Pittsburgh, PA, September 1992.

No context found.

Park Robert, Software Size Measurement: A Framework for Counting Source Statements, Technical report, Software Engineering Institute, 1992.

No context found.

Park Robert, Software Size Measurement: A Framework for Counting Source Statements, Technical report, Software Engineering Institute, 1992.

No context found.

Park92- "Software Size Measurement: A Framework for Counting Source Statements", R.M. Park et al, CMU-SEI-92-TR-20, Software Engineering Institute, Pittsburg, PA, 1992.

No context found.

Park, R. (1992), "Software Size Measurement: A Framework for Counting Source Statements, CMU/SEI-92-TR-20, Software Engineering Institute, Pittsburgh, PA.

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