Case Study 1: Lines of Code: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 //MQQAM01 JOB (5,,55,5),’DEDENE’ /* PASSWORD HIEPHIEP //STEP EXEC PASCAL //PAS.SYSIN DD * ***************** * PROGREM * * STARTS HERE * ***************** PROGRAM COUTNER(INPUT,OUTPUT); * TYPE DEFINITIONS TYPE ROW = ARRAY[1..30] OF INTEGER; * DECLARATION OF VARIABLES VAR QUEUE : ROW; I,J,X : INTEGER; ****************** * THIS PGM PUTS * * SUM IN ARRAY * ****************** BEGIN READ(I);READ(J); FOR X:= 1 TO 30 DO BEGIN QUEUE[X]:= I + J; END; END. /* Case Study 1: Lines of Code


Case Study 1: Lines of Code: Case Study 1: Lines of Code NO standard definition after 50 yrs of literature  cocomo ? Very implementation dependent Paradox: penalisation of contemporary development tools ! Can be used at most within one programming environment with the same group of people...as a 'relative' volume measure... The number of program logic instructions The number of program logic instructions and data definitions (definition of many IBM studies) The number of program instructions including data definitions and comments (COCOMO definition) The number of program instructions including data definitions and comments, but also the commands needed to compile and run the program The number of physical lines in the program.


Cost per Lines of Code Paradox: Cost per L.O.C. paradox... Cost per Lines of Code Paradox Suppose 10000 L.O.C. Assembler Effort: 15 PersonMonths à 5000 $ Total cost is 75 000 $ Suppose same project in XYZ2000 with 2000 L.O.C. Total effort: 7 PersonMonths Total cost is 35 000 $ Assembler =andgt; 666 L.O.C./PM =andgt; 7.50 $/L.O.C. XYZ200 =andgt; 286 L.O.C./PM =andgt; 17.50 $/L.O.C.


Cost per Defect Paradox: Cost per Defect Paradox Suppose in Assembler-project a test reveals 100 errors, at 0.1 PM correction time per error + 1 PM integration tests Suppose in XYZ2000-project a test reveals 10 errors, at 0.5 PM correction time per error + 0.5 PM integration tests Assembler =andgt; 55000 $/100 errors = 550 $ /error XYZ2000 =andgt; 27500 $/10 errors = 2750 $ /error Cost per defect paradox...


Case Study 2: Function Points: Case Study 2: Function Points Functional Size Measurement (FSM) is a method for measuring the functional size of software ISO/IEC/JTC1/SC7 Standard #14143 definition 'Functional Size: a size of software derived by quantifying the functional user requirements'… Needed to measure size independently of language, tools, technique or technology. 'Size' = functions delivered to the user derived in terms understood by the user derived without reference to effort methods used physical or technical components


Are the problems solved ?: Are the problems solved ? Suppose Assembler/XYZ2000 project is 50 FP =andgt; productivity : 3.3 FP/PM for Assembler =andgt; productivity : 7.14 FP/PM for XYZ2000 =andgt; Assembler costs: 1500 $/FP =andgt; XYZ2000 costs: 700 $/FP


Function Points: Function Points


Function Points: Function Points Functional Size Measurement (FSM) is a method for measuring the functional size of software ISO/IEC/JTC1/SC7 Standard #14143 definition 'Functional Size: a size of software derived by quantifying the functional user requirements'… Needed to measure size independently of language, tools, technique or technology. 'Size' = functions delivered to the user derived in terms understood by the user derived without reference to effort methods used physical or technical components


Function Points : Function Points developed first by Allan J. Albrecht in the mid 1970s and was an attempt to overcome difficulties associated with lines of code as a measure of software size, and to assist in developing a mechanism to predict effort associated with software development. The method was first published in 1979, then later in 1983. In 1984 Albrecht refined the method. Since 1986, when the International Function Point User Group (IFPUG) was set up, several versions of the Function Point Counting Practices Manual have been published by IFPUG.


FPA: Growth & Acceptance: FPA: Growth andamp; Acceptance Indicated by the growth of the International Function Point User Group (IFPUG): from 100 members in 1987 to nearly 600 members in 1997. conference attendance has grown from 125 in 1988 to over 300 by 1997. IFPUG members are from North America, but Function Point analysis growth outside North America is strong. Affiliate organizations in Italy, France, Germany, Austria, India, The Netherlands, Australia, Japan, and several other countries. Example of Manual: Longstreet, David.  Function Point Training and Analysis Manual.  andlt;http://www.SoftwareMetrics.Com/freemanual.htmandgt;. 


History: History


FPA – General Outline: FPA – General Outline mapping phase measurement phase Description of the SW to be measured FPA Software model funtional size of the SW model FPA Functional size model FPA Rules andamp; Procedures FPA Measurement Manual


General outline: General outline Mapping phase Measurement phase FPA functional size model/ FPA Software model


FPA Functional Size model: Stored Data Internal File/ Stored Data External File INPUT OUTPUT INQUIRY FPA Functional Size model + Adjustment Transaction/ Elementary Process


Definitions*: Definitions* External Inputs (EI) - is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files. The data can be either control information or business information. If the data is control information it does not have to maintain an internal logical file. * Source : David Longstreet's FP manual, www.SoftwareMetrics.Com


Definitions: Definitions External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications. These reports and files are created from information contained in one or more internal logical files and external interface files.


Definitions: Definitions External Inquiry (EQ) - an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files. The input process does not update or maintain any FTR’s (Internal Logical Files or External Interface Files) and the output side does not contain derived data.


Definitions: Definitions Internal Logical Files (ILF) - a user identifiable group of logically related data that resides entirely within the application boundary and is maintained through External Inputs. External Interface Files (EIF) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application boundary and is maintained by another applications external inputs. The external interface file is an internal logical file for another application.


Definitions: Definitions Record Element Type (RET): A RET is user recognizable sub group of data elements within an ILF or an EIF. File Type Referenced (FTR): A FTR is a file type referenced by a transaction. An FTR must also be an internal logical file or external interface file. Data Element Type (DET): A DET is a unique user recognizable, non-recursive (non-repetitive) field.


Definitions: Definitions


External Input Function PointsInquiry Function Points: 1 - 4 5 - 15 andgt; 15 0 - 1 2 andgt; 2 Simple Simple Simple Average Average Average Complex Complex Complex # input fields = DET # files used = FTR External Input Function Points Inquiry Function Points


External Output Function Points: 1 - 5 6 - 19 andgt; 19 0 - 1 2or 3 andgt; 3 Simple Simple Simple Average Average Average Complex Complex Complex # output fields = DET # files used = FTR External Output Function Points


Internal File Function PointsExternal File Function Points: 1 - 19 20 - 50 andgt; 50 1 2 - 5 andgt; 6 Simple Simple Simple Average Average Average Complex Complex Complex # fields = DET # record types = RET Internal File Function Points External File Function Points


Unadjusted Function Points (= Function Count): Input Output Inquiry Internal File External File Simple Average Complex 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 Unadjusted Function Points (= Function Count)


Net Function Points (= Function Points): Influence factor = 0.65 + 0.01 * S Fi Fi = 0,1,...,5 i=1 14 Net Function Points (= Function Points) = Unadjusted Function Points * Influence factor


Slide26: No special performance requirements were stated by the user. Performance and design requirements were stated and reviewed but no special actions were required. Response time or throughput is critical during peak hours. No special design for CPU utilization was required. Processing deadline is for the next business day. Response time or throughput is critical during all business hours. No special design for CPU utilization was required. Processing deadline requirements with interfacing systems are constraining. In addition, stated user performance requirements are stringent enough to require performance analysis tasks in the design phase. In addition, performance analysis tools were used in the design, development, and/or implementation phases to meet the stated user performance requirements. 0 1 2 3 4 5 PERFORMANCE: Descriptions To Determine Degree of Influence


ASSIGNMENT: ASSIGNMENT Download andamp; view FPLive.Exe Read Chapters 1, 2 andamp; 4 of Thomas Fetcke’s report (print is included in Coursenotes) Solve former exam question Cfr. Toledo for assignment details.


Function Point Exercise…: Simplified FP-Calculator Application Title: _________________________ FUNCTION POINTS COUNT x WEIGHT TOTAL # INPUT FP: # OUTPUT FP: # INQUIRIES: # DATA FILES: # INTERFACES: ______ ______ ______ ______ ______ x 4 = x 5 = x 4 = x 10 = x 7 = ______ ______ ______ ______ ______ Function Count : Influence Factor : Function Points : ______ ______ ______ PRINT REPORT? ____ SAVE REPORT? ____ NEW FORM ? ______ Function Point Exercise…


Function Point Exercise…: 1. There is one input panel 2. There is one output panel, equal to the input panel. 3. The application can print a report. 4. The report can be saved on a file. 5. There are NO couplings with other applications. 6. The operations are simple. 7. The application will be developed in VisualBasic Calculate the Function count, Influence factor and Function points for this application. Function Point Exercise…


Function Point Excercise solution: 1. EI: Registration of Data (Input panel). 0 files (FTR), 7 fields to input (DETs) =andgt; simple 2. EO: (Calculation of results Output panel, equal to the input panel. 0 files (FTR), 7 fields output (DETs) =andgt; simple EO: The application can print a report. 0 files (FTR), 14 fields output (DETs) =andgt; simple EO: The report can be saved in a file. 1 file (FTR), 14 fields output (DETs)=andgt; simple 3. Q: No Queries 4. ILF: 1 File 6 DETs, 1 RET =andgt; Simple 5. ELF: There are NO couplings with other applications. Function Count = 1x3 + 3x4 + 1x7 = 22 Function Point Excercise solution


Function Point Excercise solution: · F1: Reliable Backup andamp; Recovery · F2: Use of Data Communication · F3: Use of Distributed Computing · F4: Performance · F5: Realisation in heavily used configuration · F6: On-line data entry · F7: User Friendliness The operations are simple andamp; The application will be developed in VisualBasic Influence factor = 0.65 + 10 * 0.01 = 0.75 2 0 0 0 2 0 0 = 10 Function Points = 22 x 0.75 = 16.5 Function Point Excercise solution 0 0 0 1 0 2 3


Translation FP => LOC: Macro-assembler ANSI COBOL 74 (~= Fortran 77) Pascal (~= 3GL default) PL/I ADA Basic AI Shell Statistical language OO-language Program generator Query language Spreadsheet LOC/FP 213 105 91 80 71 64 49 32 29 16 13 6 Capers Jones Translation FP =andgt; LOC


FP exercice 2: FP exercice 2 owns Stored at 1 1 * * ASSIGNMENT: read chapters 1-4 of Thomas Fetcke's report


Transactions: Transactions Add Customer Change Customer Delete Customer Receive payment Deposit Item Retrieve Item Add Place Change Place Data Delete Place Print Customer item list Print Bill Print stored Item List Query Customer Query Customer's items Query Places Query Stored Items External Inputs External Outputs External Inquiries


Slide35: Add Customer Name Address Error Message Add Cancel Delete Customer Name Error Message Delete Cancel 1 2a 3 2b


Slide36: Retrieve Item Owner Descr. Error Message Add Cancel 4 5 6


Slide37: 7 9 8a 8b


Slide38: Customer ABC Computers Item Value Storage Date Monitor 17' 500€ 2000-06-12 Monitor 19' 1000€ 2000-10-31 2 1500€ ABC Computers Brussels Storage Fees 400€ Items currently stored : 2 10a 10b 11a 11b


Slide39: Stored Items Item Pallets Storage Place Paper A4 2 A22 Monitor 17' 2 A21 Monitor 19' 2 A21 Books 1 B15 4 Customer ABC Computers Item Pallets Value Storage Date Monitor 17' 2 500€ 2000-06-12 Monitor 19' 2 1000€ 2000-10-31 12 13 14a 14b


Slide40: Location: A21 Space: 6 Item Pallets Monitor 17' 2 Monitor 19' 2 16a 16b 15


Variations in counting: examples: Variations in counting: examples External Input: IFPUG 4.0: count updated DETs in ILF IFPUG 4.1: count DETs that cross boundary External Output: IFPUG 4.0: count output only IFPUG 4.1: Count input andamp; output DET across boundary Inquiries IFPUG 4.0: distinguishes between input andamp; output side of inquiry IFPUG 4.1: combines all elements that cross the boundary


FP Counting results: FP Counting results IFPUG 4.0 IFPUG 4.1 Add Customer 4 1 3 3 1 3 Change Customer 5 2 4 4 2 3 Delete Customer 4 2 3 2 2 3 Receive payment 2 1 3 3 1 3 Deposit Item 7 3 6 6 3 6 Retrieve Item 8 2 4 3 2 3 Add Place 3 1 3 3 1 3 Change Place Data 4 2 3 3 2 3 Delete Place 3 2 3 2 2 3 Print Customer item list 6 2 5 7 2 5 Print Bill 4 2 4 5 2 4 Print stored Item List 4 1 4 4 1 4 Query Customer 2 1/3 1 3 4 1 3 Query Customer's items 2 1/5 2 3 6 2 4 Query Places 2 1/2 1 3 3 1 3 Query Stored Items 2 1/4 2 3 5 2 3 57 56


Function Point Discussion: Function Point Discussion What does FPA Measure ? Albrecht: 'the functionality of a software-system from a users point of view, using the specifications as a model of the system' However ... Functions are classified according to complexity to establish complexity use size measures What is the empirical relation ? functional size: amount of fucntionality delivered to the user, making abstraction of everything that should be transparant to the user


Function Point Relation System: Function Point Relation System Empirical Relation System A FS B : A smaller in functional size than B Implicit assumption: FS is a weak order: transitive and strongly complete (any pair of systems can be compared) Formal Relation System Set of Real numbers (discontinuities !): R,' A FS B iff FP(A)  FP(B)


Invalidating FP is easy ...: Invalidating FP is easy ... System A 1 ILF, 1RET, 50DET =andgt; simple = 7 pts 1 EI, 1FTR, 50DET =andgt; average = 4 pts 1 EO, 1FTR, 50DET =andgt; average = 5 pts FP (A) = 16 System B 1 ILF, 1RET, 51DET =andgt; average = 10 pts 1 EI, 1FTR, 51 DET =andgt; average = 4 pts 1 EO, 1FTR, 5 DET =andgt; simple = 4 pts FP (B) = 18


Function Points & Scales: Function Points andamp; Scales In function point analysis, each type of function (input, output, inquiry, file) is first assigned a 'complexity' weighting (simple, average, complex), suggesting that functional size is measured on an ordinal scale. Next, a specific number of function points are allocated to each function depending on its type and complexity weighting. Within each set of functions belonging to a same type, the allocation of integer values to functions qualifies as an admissible transformation of scale.


Function Points & Scales (ctd.): Function Points andamp; Scales (ctd.) The higher the complexity weighting, the more function points are allocated. For instance, input functions get 3 function points if they are simple, 4 function points if they are of average complexity, and 6 function points if they are complex. Hence, within the class of input functions, one ordinal scale (simple, average, complex) is homomorphically transformed into another ordinal scale (3, 4, 6). Next, the function points assigned to all individual functions are summed to arrive at the 'unadjusted function point count' for the entire system. This operation is not meaningful given the ordinal scale type of the homomorphisms (one per function type) that allocate function point values to functions.


Function Points and meaningfulness: Suppose SX and SY are software systems. The set of functions of SX is {Fa, Fb, Fc}. The set of functions of SY is {Fd, Fe}. Suppose further that all functions belong to the same type, e.g., they are input functions (which cannot occur in reality of course as at least one file in the system is needed). The number of function points assigned to the functions is: FP(Fa) = 3 FP(Fb) = 3 FP(Fc) = 3 FP(Fd) = 4 FP(Fe) = 4 Then, the unadjusted function point counts for SX and SY are UFPC(SX) = 9 UFPC(SY) = 8. Function Points and meaningfulness


Function Points and meaningfulness: If it is our intent to use UFPC as an ordinal scale, then we must conclude that the functional size of SX is greater than that of SY. However, for this statement to be meaningful, it must hold under all admissible transformations of the ordinal scale. An example of such a transformation is: (3) = 4 (4) = 8 (6) = 10 The corresponding values for SX and SY are now UFPC(SX) = 4 + 4 + 4 = 12 UFPC(SY) = 8 + 8 = 16. Now, we would conclude that the functional size of SX is smaller than that of SY, which is just the opposite result as above. Clearly, the summation of ordinal measurements is not meaningful. Hence, UFPC cannot be validated as an ordinal measure of functional size. (Summation requires interval scale type) Function Points and meaningfulness


Function Points & Scales: Function Points andamp; Scales classification of transactions as EI, EO,EI : nominal scale DET, RET, FTR: Ratio scale (absolute) DET, RET andamp; FTR mapping to intervals = transformation of scale from ratio to ordinal ! loss of information !! Determination of Complexity complexity is not ordinal: not strongly complete half-order scale (Zuse): not every pair of elements are related


External Input Function PointsInquiry Function Points: 1 - 4 5 - 15 andgt; 15 0 - 1 2 andgt; 2 Simple Simple Simple Average Average Average Complex Complex Complex # input fields # files used External Input Function Points Inquiry Function Points


External Input Function PointsInquiry Function Points: 1 - 4 5 - 15 andgt; 15 0 - 1 2 andgt; 2 Simple Simple Simple Average Average Average Complex Complex Complex # input fields # files used External Input Function Points Inquiry Function Points


FP Influence Factor and Scales: FP Influence Factor and Scales Influence rating (none - essential) ORDINAL SCALE Influence value (0 - 5) ORDINAL SCALE (transformation rating to value is admissible) Adding the values (N) requires INTERVAL SCALE WRONG ( + is not allowed) Calculating AF = 0.65 + N / 100 requires RATIO SCALE WRONG (/ is not allowed)