WIXLIB

LIST OF TABLESTable 1 Software Size Measurement Methods Based on “Functionality” Metric .12Table 2 Parts of ISO/IEC 14143: Information Technology - Software Measurement Functional Size .13Table 3 Criteria for the Classification of Software Size Measurement Methods .22Table 4 BFC Types of Methods Based on “Functionality” Metrics.25Table 5 Main Differences between IFPUG FPA, Mk II FPA and COSMIC FFP Methods .32Table 6 Forms of Processing Logic Performed by BFC Types of FSM Methods.44Table 7 Characteristics by Field of Application .46Table 8 Forms of Processing Logic and Software Functionality Types .47Table 9 The Naming Convention used in Case Study 2 and Case Study 3 .70Table 10 Size Estimates of the Subsystems of the Case Project by Mk II FPA.74Table 11 Size Estimation of Module A1 by COSMIC FFP.76Table 12 Size Estimation of Module A1 by IFPUG FPA .76Table 13 Taxonomy for Defining Software Projects .77Table 14 Elements of the EFPA Method .78Table 15 EFPA Size Estimates for Consecutive Stages .79Table 16 Size Estimates by EFPA at Consecutive Stages and the Relative Errors with respectto Mk II FPA Estimate .81Table 17 Efforts Utilized for the Life Cycle Processes of Project-1 .87Table 18 Case Study 2.1 Mk II FPA Size Measurement Details .88Table 19 Case Study 2.1 COSMIC FFP Size Measurement Details.88Table 20 The Productivity Rates (Code & Unit Test Effort / Functional Size) of theSubsystems of Case Study 2.1 .89Table 21 The Productivity Rates (Development Effort/Functional Size) of Case Study2.1.89Table 22 The Productivity Rates (Code & Unit Test Effort / SLOC) of Case Study 2.1.89Table 23 The Productivity (Development Effort / SLOC) Values of Case Study 2.1 .90Table 24 The Ratio of Functional Size (Mk II FP & Cfsu) to SLOC Values of Case Study2.1.90Table 25 Efforts Utilized for the Life Cycle Processes of Case Study 2.2.92Table 26 Case Study 2.2 Mk II FPA Size Measurement Details .93Table 27 Case Study 2.2 COSMIC FFP Size Measurement Details .93xii

Table 28 The Productivity Rates (Code & Unit Test Effort/Funct. Size) of Case Study 2.2 .94Table 29 The Productivity Rates (Development Effort/Functional Size) of Case Study2.2.94Table 30 The Productivity (Code & Unit Test Effort / SLOC) Values of Case Study 2.2 .94Table 31 The Productivity (Development Effort / SLOC) Values of Case Study 2.2 .95Table 32 The Ratio of Functional Size (Mk II FP & Cfsu) to SLOC Values of Case Study2.2.95Table 33 Efforts Utilized for the Life Cycle Processes of Case Study 2.3.96Table 34 Case Study 2.3 Mk II FPA Size Measurement Details .97Table 35 Case Study 2.3 COSMIC FFP Size Measurement Details .98Table 36 The Productivity (Code & Unit Test Effort / Functional Size) Rates of Project-3 .98Table 37 The Productivity (Effort / Functional Size) Values of Case Study 2.3.98Table 38 SLOC Values of Case Study 2.3 .99Table 39 Case Study-2 Mk II FPA Size Measurement Details . 100Table 40 Case Study-2 COSMIC FFP Size Measurement Details . 101Table 41 The Efforts Utilized for Functional Size Measurement in Case Study 2 . 107Table 42 Case Study 3.1 ARCHI-DIM FSM Size Measurement Details . 109Table 43 SLOC Values of Project-1 . 111Table 44 Case Study 3.2 ARCHI-DIM FSM Size Measurement Details . 113Table 45 SLOC Values of Project-3 . 114Table 46 The Code and Unit Test Effort Values of Project-3 . 114Table 47 Case Study 3.3 ARCHI-DIM FSM Size Measurement Details . 115Table 48 The Productivity (Code & Unit Test Effort / Functional Size) Rates of Project-3116Table 49 Mapping BFC Types of Mk II FPA and COSMIC FFP to the Constituent Parts ofARCHI-DIM FSM BFCs . 118Table 50 Summary of the Base Counts obtained by Mk II FPA, COSMIC FFP and ARCHI-DIMFSM . 119Table 51 The Functional Sizes (Mk II FP, Cfsu and ADfsu) and SLOC Values of theSubsystems of Project-1. 122Table 52 The Ratios of the Functional Sizes and SLOC Values of the Subsystems of Project-1. 123Table 53 The Ratio of SLOC to Functional Size of the Subsystems of Project-1 . 124Table 54 The Functional Sizes of the Subsystems of Project-1 Obtained by Mk II FPA,COSMIC FFP with respect to ARCHI-DIM FSM Dimensions . 125Table 55 The Ratios of SLOC to Functional Size (Mk II FP and Cfsu) of the Subsystems ofProject-1 . 126xiii

Table 56 Efforts Utilized for Functional Size Measurement by MkII FPA, COSMIC FFP andARCHI-DIM FSM. 129Table 57 The Correlation between Functional Size and Effort . 143Table 58 The Ratio of SLOC to Functional Size (Cfsu) . 144Table 59 The Ratio of SLOC (SmallTalk) to Functional Size (IFPUG FP). 145Table 60 The Ratio of SLOC (C ) to Functional Size (IFPUG FP) . 146Table 61 The Ratio of SLOC (Cobol) to Functional Size (IFPUG FP). 147Table 62 The Ratio of SLOC (C) to Functional Size (IFPUG FP). 148xiv

LIST OF FIGURESFigure 1 FSM Process of IFPUG FPA, Mk II FPA and COSMIC FFP.29Figure 2. ARCHI-DIM Measurement Process .50Figure 3. ARCHI-DIM Software Model.57Figure 4 Case Study Method .68Figure 5 Requirements Analysis Life Cycle .72xv

LIST OF ACRONYMS / ABBREVIATIONS3-DADfsuARCHI-DIM FSMASSET- SMFURGLGUIHTMLIICASEIDEFIFPUGIIU: Three-Dimensional: ARCHI-DIM FSM functional size unit: Architectural Dimensions Based FSM Method: Analytical Software Size Estimation Technique – Real-Time: Base Functional Component: Business Process Modeling: Collision Avoidance Subsystem: Cosmic Functional Size Unit: Commented Lines of Code: Constructive Cost Model: Component Object Points: Common Software Measurement International Consortium: Commercial Off-The Shelf: Data Element Type: Data Function: Data Flow Diagram: Delivered Source Instructions: Entry: Early and Quick: Extended Event Driven Process Chain: Early Function Points: Early Function Point Analysis: External Input: External Interface File: External Output: Elementary Process: External Inquiry: Entity - Relationship: Executable Statements: Functions: Fonksiyonel Büyüklük Ölçme: Full Function Points: The Finnish Software Metrics Association: Functional Primitive: Function Point: Function Point Analysis: Functional Size Measurement: Functional User Requirement: Granularity Level: Graphical User Interface: Hyper Text Markup Language: Input: Integrated Computer Aided Software Engineering: Integrated Computer Aided Manufacturing (I-CAM) Definition: International Function Point Users Group: Instance Interaction Unitxvi

ILFISBSGISOLDLOCLTmMDIUMFmFMISMK II AWUKSMAUMLUUCPUUCWVAFWXXML: Internal Logical File: International Software Benchmarking Standards Group: International Standards Organization: Logical Data Group: Lines of Code: Logical Transaction: meter: Master Detail Interaction Unit: Macrofunction: Microfunction: Management Information System: Mark II Function Point Analysis: Non-Commented Lines of Code: The Netherlands Function Point Users Group: The Netherlands Software Metrics Users Association: Average Number of Children per Base Class: Output: Object Oriented: Object Oriented Method Function Points: Object Oriented Function Points: Object Points: Processing Entity: Population Interaction Unit: Predictive Object Points: Read: Resolution Advisory: Record Element Type: Request for Proposal: Software Engineering Laboratory in Applied Metrics: Standard Generalized Markup Language: Source Lines of Code: Statistical Object Model: Software Productivity Research: Software Requirements Specification: Software Sizing Model: Standard Deviation: Software Capability Maturity Model: Traffic Collision Avoidance Subsystem: Transactional Function: Unadjusted Actor Weight: United Kingdom Software Metrics Association: Unified Modeling Language: Unadjusted Use Case Points: Unadjusted Use Case Weights: Value Adjustment Factor: Write: Exit: Extensible Markup Languagexvii

CHAPTERCHAPTER I1 INTRODUCTIONSoftware Engineering requires measuring the attributes of software to be able todescribe, prescribe, and predict. Tom De Marco states, “If you can’t measure it, you can’tmanage it”. That is, we need to estimate how much software to build, just as we need todetermine the weight and volume of an engineering product as part of the planningprocess.Estimation errors are essential cause of poor management which usually results inrunaway projects that spiral out of control (Glass, 2002). Whatever these projects produceis frequently behind schedule and over budget, and most often they fail to produce anyproduct at all. According to the Standish Group CHAOS report of 2003:-5% of software projects are terminated before they produce anything,-66% are considered to have failed,-Of those that do complete the average cost blowout is 43%,-The lost dollar value for USA projects in 2002 is estimated at US 38 billion withanother US 17 billion in cost overruns.The question of what causes runaway projects arises frequently in the softwareengineering field. One of the major causes of runaway projects is considered to beimmature measurement / estimation.All prior software effort and cost estimation research is based on the suppositionthat size is a primary predictor. One of the significant challenges of software engineeringremains to be reliable sizing of software. By estimating software size, it is possible toestimate development effort, which enables to estimate cost. Therefore, the primarymetric that must be identified is the one that infers size attribute.1

Various approaches to software size estimation are developed and applied indifferent phases of the development life cycle during the last 3 decades. The size ofsoftware can be estimated by classifying different types of externally observable features,and then by counting the occurrences of those features. Examples for these features maybe inputs and outputs from a software component. Each estimation method countsdifferent types of features in a different way. There might also be differences in themethods due to different application domains (MIS, real-time, control, etc.) which havedifferent features that should be considered.Among the various size estimation methods, the ones based on “functionality” arewidely-used due to their earlier applicability during the software life cycle. After thedescription of the original method based on “functionality to be delivered to the users” byAlbrecht (1979), variations of these methods have been developed. During the 1980s and1990s, several authors have suggested new Function Point counting techniques thatintended to improve the original Function Point Analysis (FPA) or extend its field ofapplication from business application software to real-time and algorithmic software(Symons, 2001).In 1996, the International Standards Organization (ISO) started a working group(ISO/IEC JTC1 SC7 WG12) to establish common principles of the methods based on“functionality”. They first published the first part of this standard (ISO/IEC 14143-1,1998), which defines the fundamental concepts of Functional Size Measurement (FSM) suchas “Functional Size”, “Base Functional Components (BFC)”, “BFC Types”, the FSM methodcharacteristics and requirements that should be met by a candidate method to beconformant to this standard. The standard promoted the consistent interpretation of FSMprinciples. After that, IEEE Std. 14143.1 (2000), which is an adoption of ISO/IEC 141431:1998, was published.Four more parts of ISO/IEC 14143, which are ISO/IEC 14143-2 (2002) - Conformityevaluation of software size measurement methods to ISO/IEC 14143-1:1998; ISO/IEC TR14143-3 (2003) - Verification of FSM methods; ISO/IEC TR 14143-4 (2002) - FSM Referencemodel and ISO/IEC TR 14143-5 (2004) - Determination of functional domains for use withFSM, were published in the following years.Being conformant to ISO/IEC 14143-1 (1998), detailed descriptions of four FSMmethods which are IFPUG Function Point Analysis (ISO/IEC 20926, 2003), Mark II FunctionPoint Analysis (ISO/IEC 20968, 2002), COSMIC Full Function Points (ISO/IEC 19761, 2003)2

and NESMA Function Point Analysis (ISO/IEC 24570, 2003) have been recently published asISO standards.Although it has gone a long way, FSM is still considered as “immature” andcriticized because of the general difficulty of the measurement process and theimmaturity of the measurement science for software engineering (Hughes, 2000; Fenton,1994; Fenton, 1996). The results of the literature review showed that there still existsignificant improvement opportunities for the existing FSM methods related to theirconceptual and theoretical basis, convertibility of functional sizes obtained by differentmethods, estimation early in the life cycle, suitability of methods for different applicationdomains, and validation and rigor which are available in other engineering disciplines.1.1Scope of the Thesis StudyThis thesis study aims to explore the improvement opportunities of FSM methodsand based on the findings, suggest some improvements and develop a new FSM method bymaking improvements on two of the most challenging improvement opportunities, whichare on the conceptual and theoretical basis of FSM and extension of the applicationdomain suitability.The research objectives of this thesis study are:-to examine the conceptual and theoretical differences between FSM methods,-to explore the applicability of FSM methods to measure the size of the projectsof different functional domain types,-to explore the applicability of size estimation methods at different phases ofthe software development life cycle,1.2-to bring into light the improvement opportunities related to FSM methods,-to make some improvement suggestions and-to develop a new FSM method based on the improvement suggestions.Research StrategyIn order to assist to meet the research objectives of this thesis study, weperformed empirical studies on FSM methods. There are several ways of doing empiricalresearch in software engineering, which may include formal experiments, surveys and case3

studies. We used case study as a research strategy in this thesis study, as we have nocontrol over behavioral events and we are examining contemporary events.Three case studies are conducted as part of this thesis study. The first case studyis a single-case study which was conducted to explore the applicability of four estimationmethods at different phases of the software development life cycle.The second case study is a multiple-case study which involves three differentcases. In this multiple case study, our objective is to explore the applicability of FSMmethods to measure the size of the projects of different functional domain types, examinethe

July 2005, 300 pages This thesis study aims to examine the conceptual and theoretical differences of Functional Size Measurement (FSM) methods, to identify the improvement opportunities of these methods and to develop a new FSM method. A comprehensive literature review is performed and two multiple-case studies are conducted as a research strategy.