Chapter 5 Software effort estimation part 2 NET

Chapter 5: Software effort estimation- part 2 NET 481: Project Management Afnan Albahli S

Topics to be covered S Difficulties of Estimation S Where are estimates done? S Problems of over- and under- estimate S Estimation techniques 2 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Albrecht Function Point Analysis S FP is A top-down method S Devised by Allan Albrecht during his work for IBM S Why FP To be able to quantify the functional size of programs independently of the programming language used 3 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Albrecht Function Point Analysis (cont’d S The basis of FP analysis is that n Information System consists of five major that are of components or external user types or functions benefit to the user S Transaction functions S External input types • Input transactions that update internal computer files S External output types • (Are transactions where data is output to the user rinted report) S External inquiry types • Are transactions initiated by the user which provide information but not update the internal files • The user details required inputs some information that directs the system to the 4

Albrecht Function Point Analysis (cont’d S Data functions S Logical internal file types S The standing files used by the system S File here refers to a group of data items accessed together S It may be made up of one or more record types S External interface file types S Allow for output and input that may pass to and from other computer systems S Files shared between applications would also be counted here 5

Albrecht Function Point Analysis (cont’d S The FP approach 1 dentify each external user type in your application (2 etermine the complexity of each user type igh verage or low 3 Peach = of score for of each external user type ultiply the weight complexity by the count of each external user type that has that complexity 4. = FP count ummation of all the FP scores. FP count indicates the size of the information processing 6 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

User Type Complexity S For the original function points defined by Albrecht he complexity (of the components xternal user types as ntuitively decided S (Now there is a group called FPUG nternational FP user group have put rules governing the complexity and how it isssessed S The Albrecht FP is often refereed to as the IFPUG FP method 7

IFPUG File Type Complexity 8

IFPUG File Type Complexity (cont’d S The boundaries shown in this table show the complexity level for the logical internal files is decided on S There are similar tables for external inputs and outputs S (Record Type is also called Record Element Type ET S (Data Type is also called Data Element 9 Type ET

Function Points Mark II S Developed by Charles Symons in 1991 S method (It is not a replacement to the Albrecht method he IFPUG S processing FP Mark II as Albrecht FPs measures the information size in FPs 10 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

Function Points Mark II (cont’d S The idea of FP Mark II n information system contains transactions which have the basic structure shown below 11

Function Points Mark II (cont’d S (FP = i umber of input data element types (+ We umber of entity types referenced ( Wo umber of output data element types S proportions Wi e o are weightings derived by asking developers the of effort code dealing spentwith in previous projects developing the ü Inputs ü Accessing and modifying stored data ü Processing outputs 12

Function Points Mark II (cont’d S The proportions of effort are then normalized into ratios or weightings which add up to 2. 5 S equivalents 2 as adopted to produce FP counts similar to the Albrecht S Industry averages for the weights , Wi. 58 e. 66 o. 26 hey add up to 2. 5 = 13

Example 14

Answer ü (FP = i umber of input data element types (+ ( We umber of entity types referenced Wo umber of output data element types ü = , Wi. 58 e. 66 o. 26 ü number of input data element types = 3 (Invoice number, Date received, Cash received) ü number of entity types referenced = 2 (Invoice and Cashreceipt) ü number of output data element types = 1(error message) ü FP = (0. 58*3) + (1. 66*2) + (0. 26*1) = 5. 32 15 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

COSMIC Full Function points S COSMIC FFPs stands for Common Software Measurement Consortium Full Function Points. S or This approach is developed to measure the sizes of real-time embedded systems S In COSMIC method he system architecture is decomposednto a hierarchy of software layers 16 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

COSMIC Full Function points (cont’d) They define 4 ata groups that a software component can deal with: S Entries (. effected by sub-processes that moves the data group into the SW component in question from a user outside its oundary S Exits (. effected from the by SWsub-processes that moves the data group component into a user outside its boundary S Reads (. data movements that move data groups from a persistent ( storage B o the SW component S Writes (. data movements that move data groups from the SW component to a persistent storage 17

COSMIC Full Function points (cont’d) S the Thefour overall FFP is derived by simply summing the counts of groups all together S The method doesn’t take account of any processing of the data groups once they are moved into the software omponent S It is not recommended for systems that include complex mathematical algorithms 18

COCOMO II S It is a parametric productivity model S It is developed by Barry Boehm in the late 1970 s S COCOMO is short for COnstructive COst Model. S It refers to a group of models S The basic model was built around the following equation S Effort (size)k S 152 , The effort is measured in person-months (pm onsisting of units of hours S instructions (The size is measured in dsi housands of delivered source code of S c and k are constants 19 orking

COCOMO II (cont’d) S The first step is to derive an estimate the system size in terms of kdsi S C and k constants values depend on classifying the system in Boehm’s terms as either ü Organic mode or ü Embedded mode or ü Semi-detached mode 20 SPM (5 e) Software effort estimation© The Mc. Graw-Hill Companies, 2009

COCOMO II (cont’d) S Organic mode S Small team S Small system S Interface requirements flexible S In-house software development S Examples Systems such as payroll nventory 21

COCOMO II (cont’d) S Embedded mode S Product has to operate within very tight constraints S the project team is large S development environment consists of many complex interfaces S Changes are very costly S Examples eal-time systems such as those for air traffic control TMs r weapon systems 22

COCOMO II (cont’d) S Semi-detached mode S Combined elements from the two above modes or haracteristics that come in between S Examples Systems such as compilers atabase systems nd editors 23

COCOMO II (cont’d) S c and k values 24

COCOMO II (cont’d) S COCOMO II takes into account that there is a wider range ofrocess models in use than before S COCOMO II is designed to accommodate the fact thatstimates will be needed at different stages of the system lifeycle S COCOMO II has models for three different stages S Application composition S Early design S Post Architecture 25