Software Effort Estimation What makes a successful project

Software Effort Estimation

What makes a successful project? Delivering: Agreed functionality On time At the agreed cost With the required quality 2

Difficulties with Estimation Subjective nature of Estimation Changing Technologies Political implications 3

Estimation Wrong initial estimations ◦ Lead to exceeding deadlines Over estimation Under estimation

Over and under-estimating Parkinson’s Law: ‘Work expands to fill the time available’ Brook’s Law: putting more people on late job make it later An over-estimate is likely to cause project to take longer than it would otherwise 5

Basis for s/w estimation Need historical data Measure of work ◦ Only a code measure ◦ Programmer dependent 6

Software effort estimation techniques • Top-down • Bottom-up

Bottom-up V/S top-down Bottom-up ◦ use when no past project data ◦ identify all tasks that have to be done – so quite time-consuming ◦ use when you have no data about similar past projects Top-down ◦ produce overall estimate based on project cost drivers ◦ based on past project data ◦ divide overall estimate between jobs to be done 8

Bottom-up estimating 1. Break project into small components 2. Stop when you get to what one person can do in one/two weeks 3. Estimate costs for the lowest level activities 4. At each higher level calculate estimate by adding estimates for lower levels 9

Top-down estimates Estimate 100 days Produce overall estimate using effort driver(s) overall project design 30% i. e. 30 days code 30% i. e. 30 days Distribute test 40% i. e. 40 days 10 proportions of overall estimate to components

Function Point Function Count Alan Albrecht while working for IBM, recognized the problem in size measurement in the 1970 s, and developed a technique (which he called Function Point Analysis), which appeared to be a solution to the size measurement problem. 11

Function Count The principle of Albrecht’s function point analysis (FPA) is that a system is decomposed into functional units. § Inputs : information entering the system § Outputs : information leaving the system § Enquiries : requests for instant access to information § Internal logical files : information held within the system § External interface files : information held by other system that is used by the system being analyzed. 12

Function Count The FPA functional units are shown in figure given below: User Inquiries Inputs User ILF Outputs System Other applications EIF ILF: Internal logical files EIF: External interfaces FPAs functional units System 13

Function Count The five functional units are divided in two categories: (i) Data function types § Internal Logical Files (ILF): A user identifiable group of logical related data or control information maintained within the system. § External Interface files (EIF): A user identifiable group of logically related data or control information referenced by the system, but maintained within another system. This means that EIF counted for one system, may be an ILF in another system. 14

Function Count (ii) Transactional function types § External Input (EI): An EI processes data or control information that comes from outside the system. The EI is an elementary process, which is the smallest unit of activity that is meaningful to the end user in the business. § External Output (EO): An EO is an elementary process that generate data or control information to be sent outside the system. § External Inquiry (EQ): An EQ is an elementary process that is made up to an input-output combination that results in data retrieval. 15

Software Project Planning Counting function points Functional Units External Inputs (EI) External Output (EO) External Inquiries (EQ) Internal logical files (ILF) External Interface files (EIF) Weighting factors Low Average High 3 4 6 4 5 7 3 7 5 4 10 7 6 15 10 Table 1 : Functional units with weighting factors 16

Software Project Planning Table 2: UFP calculation table Functional Units External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) External logical Files (ILFs) External Interface Files (EIFs) Count Complexity Low x 3 Average x 4 High x 6 Complexity Totals Functional Unit Totals = = = Low x 4 Average x 5 High x 7 = = = Low x 3 Average x 4 High x 6 = = = Low x 7 Average x 10 High x 15 = = = Low x 5 Average x 7 High x 10 = = = Total Unadjusted Function Point Count 17

Software Project Planning Table 3 : Computing function points. Rate each factor on a scale of 0 to 5. 0 1 No Incidental Influence Number of factors considered ( Fi ) 1. 2. 3. 4. 2 3 4 5 Moderate Average Significant Essential Does the system require reliable backup and recovery ? Is data communication required ? Are there distributed processing functions ? Is performance critical ? 5. Will the system run in an existing heavily utilized operational environment ? 6. Does the system require on line data entry ? 7. Does the on line data entry require the input transaction to be built over multiple screens or operations ? 8. Are the master files updated on line ? 9. Is the inputs, outputs, files, or inquiries complex ? 10. Is the internal processing complex ? 11. Is the code designed to be reusable ? 12. Are conversion and installation included in the design ? 13. Is the system designed for multiple installations in different organizations ? 14. Is the application designed to facilitate change and ease of use by the user ? 18

IFPUG Complexity 19

Software Project Planning Functions points may compute the following important metrics: Productivity = FP / persons-months Quality = Defects / FP Cost = Rupees / FP Documentation = Pages of documentation per FP These metrics are controversial and are not universally acceptable. There are standards issued by the International Functions Point User Group (IFPUG, covering the Albrecht method) and the United Kingdom Function Point User Group (UFPGU, covering the MK 11 method). An ISO standard for function point method is also being developed. 20

Software Project Planning Example: 4. 1 Consider a project with the following functional units: Number of user inputs = 50 Number of user outputs = 40 Number of user enquiries = 35 Number of user files = 06 Number of external interfaces = 04 Assume all complexity adjustment factors and weighting factors are average. Compute the function points for the project. 21

FP Solution We know UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7 = 200 + 140 + 60 + 28 = 628 CAF = (0. 65 + 0. 01 ΣFi) = (0. 65 + 0. 01 (14 x 3)) = 0. 65 + 0. 42 = 1. 07 FP = UFP x CAF = 628 x 1. 07 = 672 22

Function points Mark II Developed by Charles R. Symons ‘Software sizing and estimating - Mk II FPA’, Wiley & Sons, 1991. Work originally for CCTA: ◦ should be compatible with SSADM; mainly used in UK has developed in parallel to IFPUG FPs 23

Function points Mk II #entities accessed #input items #output items For each transaction, count ◦ data items input (Ni) ◦ data items output (No) ◦ entity types accessed (Ne) FP count = Ni * 0. 58 + Ne * 1. 66 + No * 0. 26 24

Productivity = size/effort Or Effort=const 1+(size*const 2) 25

Inputs: 1) Select new sale (control); User action expressed by selection of command [Sale: Receipt_No]. 2) Select product type (business); User choses from categorised drop-down list of pizza related product types [Product: Type_Of_Item]. 3) Select product “name” (business); User choses from a drop-down list of pizza related goods. [Product: Product_Description > Receipt_No & Product_No]. 4) Select number of item (business); Customer may order 3 large margarita pizzas [Item_sale: Quantity_Sold]. 5) Confirm sale (control); This is a recursive menu selection system. Outputs: 1) Error/conformation (control); End of sales data interaction cycle. Entities: 1) Sale; Occurrence of a sale recorded here [Write All data]. 2) Item_sale; Functional relationship to sale entity (List of products for this sales) [Write all data]. 3) Recipe; Required to determine the inventory items to be subtracted from the inventory_item entity [Read all data]. 4) Inventory_item; Required to change the inventory(stock) level for items used [Read Item_No, Write Quantity_In_Stock] (Quantity of Item x - Recipe: Quantity_Used). 5) System; Provides the automatically generated sales receipt number and Date. 26

COCOMO applied to Semidetached Organic mode Embedded mode 27

COCOMO 81 Based on industry productivity standards database is constantly updated Allows an organization to benchmark its software development productivity Basic model effort = c x sizek C and k depend on the type of system: organic, semi-detached, embedded Size is measured in ‘kloc’ ie. Thousands of lines of code 28

The COCOMO constants System type c k Organic (broadly, 2. 4 information systems) 1. 05 Semi-detached 3. 0 1. 12 Embedded (broadly, real-time) 3. 6 1. 20 29

Development effort multipliers (dem) According to COCOMO, the major productivity drivers include: Product attributes: required reliability, database size, product complexity Computer attributes: execution time constraints, storage constraints, virtual machine (VM) volatility Personnel attributes: analyst capability, application experience, VM experience, programming language experience Project attributes: modern programming practices, software tools, schedule constraints 30

Software Project Planning Multipliers of different cost drivers Cost Drivers RATINGS Very low Low Nominal High Very high Extra high 0. 75 0. 88 1. 00 1. 15 1. 40 -- DATA -- 0. 94 1. 00 1. 08 1. 16 -- CPLX 0. 70 0. 85 1. 00 1. 15 1. 30 1. 65 TIME -- -- 1. 00 1. 11 1. 30 1. 66 STOR -- -- 1. 00 1. 06 1. 21 1. 56 VIRT -- 0. 87 1. 00 1. 15 1. 30 -- TURN -- 0. 87 1. 00 1. 07 1. 15 -- Product Attributes RELY Computer Attributes 31

Software Project Planning Cost Drivers RATINGS Very low Low Nominal High Very high Extra high ACAP 1. 46 1. 19 1. 00 0. 86 0. 71 -- AEXP 1. 29 1. 13 1. 00 0. 91 0. 82 -- PCAP 1. 42 1. 17 1. 00 0. 86 0. 70 -- VEXP 1. 21 1. 10 1. 00 0. 90 -- -- LEXP 1. 14 1. 07 1. 00 0. 95 -- -- 1. 24 1. 10 1. 00 0. 91 0. 82 -- 1. 24 1. 10 1. 00 0. 91 0. 83 -- 1. 23 1. 08 1. 00 1. 04 1. 10 -- Personnel Attributes Project Attributes MODP TOOL SCED Table 5: Multiplier values for effort calculations 32

33 COCOMOI

Using COCOMO development effor multipliers (dem) An example: for analyst capability: Assess capability as very low, nominal, high or very high Extract multiplier: very low 1. 46 low nominal high very high 0. 71 1. 19 1. 00 0. 80 Adjust nominal estimate e. g. 32. 6 x 0. 80 = 26. 8 staff months 34

COCOMOII Stage No Model Name Application for the types of projects Applications Stage I Application composition estimation model Application composition In addition to application composition type of projects, this model is also used for prototyping (if any) stage of application generators, infrastructure & system integration. Stage II Early design estimation model Application generators, infrastructure & system integration Used in early design stage of a project, when less is known about the project. Stage III Post architecture estimation model Application generators, infrastructure & system integration Used after the completion of the detailed architecture of the project. Table 8: Stages of COCOMO-II 35