Empirical Estimation Models Computer Science Software Engineering S

Empirical Estimation Models Computer Science Software Engineering S. Sambha Murthy MCA, M. Tech Govt. Degree College , Paderu Email. Id : sivakotimurthy 45@gmail. com 1

Learning Objectives: The objectives of Empirical Estimation Models are Ø to understand the basic structure of estimation model. Ø to understand the COCOMO model and its types. Ø to understand the COCOMO II model. 2

Empirical Estimation Models: Ø An estimation model for computer software uses derived formulas to predict effort as a function of LOC or FP. The Structure of Estimation Models: An estimation model is derived using regression analysis on data collected from past software projects. The overall structure of such models takes the form E =A + B* (ev)C where A, B, and C are empirically derived constants, E is effort in person-months, and evis the estimation variable either LOC or FP. 3

LOC- oriented estimation models: Model Name Equation Walston-Felix model E = 5. 2 * (KLOC)0. 91 Bailey-Basili model E = 5. 5 + 0. 73 * (KLOC)1. 16 Boehm simple model E = 3. 2 * (KLOC)1. 05 Doty model for KLOC Table >9 1 E = 5. 288 * (KLOC)1. 047 4

FP-oriented estimation models: Model Name Equation Albrecht and Gaffney model E = -91. 4 + 0. 355 FP Kemerer model E = -37 + 0. 96 FP Small project regression model E = -12. 88 + 0. 405 FP Table 2 5

COCOMO Model: Ø COCOMO was proposed by Barry Boehm in 1970 Ø COCOMO stands for Constructive Cost Model Ø It is a regression model based on number of Lines of Code (LOC). Ø It is a procedural cost estimation model for software projects. Ø This model is used for predicting the various parameters associated with developing a project such as size, effort, cost and time. 6

Outcomes of COCOMO model: Ø Effort Ø Schedule 7

Boehm’s projects classification: Ø Organic – small team size required to develop the project. Ø Semi-detached – lies between organic and embedded Ø Embedded – require highest level of creativity and experience and large team size. Types of COCOMO Models: Ø Basic COCOMO Model Ø Intermediate COCOMO Model Ø Detailed COCOMO Model 8

Basic COCOMO model: The Basic COCOMO can be used for quick and slightly rough calculations of Software Costs. Effort and time estimates formulas Effort ( E ) = A*(KLOC)B Time (T) = C*(Effort)D Persons required = Effort / Time Where A, B, C and D constant values. The effort is measured in Person-Months. The development time is measured in Months. 9

Software A B C D Organic 2. 4 1. 05 2. 5 0. 38 Semi 3. 0 1. 12 2. 5 0. 35 3. 6 1. 20 2. 5 0. 32 Project Detached Embedded Table 3: The constant values A, B, C and D for the Basic Model for the different categories of software projects 10

Example: Supposed that a project was estimated to be 400 KLOC. Calculate effort and development time for each of three modes i. e. Organic, semi-detached and embedded. Solution: The basic COCOMO equations are Effort ( E ) = A*(KLOC)B Time (T) = C*(Effort)D Given that Estimated size of project = 400 KLOC. 11

Organic mode: E = 2. 4 * (400)1. 05 = 1295. 31 Person-Months T = 2. 5 * (1295. 31). 38 = 38. 07 Months Semi- detached mode: E= 3. 0 * (400)1. 12 = 2462. 79 person –months T = 2. 5 * (2462. 79). 35= 38. 45 Months Embedded Mode: E= 3. 6 * (400)1. 2 = 4772. 81 person –months T = 2. 5 * (4772. 8). 32= 38 Months 12

Intermediate COCOMO Model: Ø The basic COCOMO model assumes that the effort is only a function of the number of lines of code. But in reality Lines of Code is not efficient to calculate effort and time. Ø In intermediate COCOMO model various other factors such as reliability, experience, Capability are considered along with LOC to estimate effort and time schedule. Ø These factors are known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost estimation. 13

Classification of Cost Drivers and their attributes are as follows. Product attributes: 1. Required software reliability extent 2. Size of the application database 3. The complexity of the product Hardware attributes: 4. Run-time performance constraints 5. Memory constraints 6. The volatility of the virtual machine environment 7. Required turnabout time 14

Personnel attributes: 8. Analyst capability 9. Software engineering capability 10. Applications experience 11. Virtual machine experience 12. Programming language experience Project attributes: 13. Use of software tools 14. Application of software engineering methods 15. Required development schedule 15

Ø The project manager is to rate these 15 different parameters for a particular project on a scale of one to three. Ø Then, depending on these ratings, appropriate cost driver values are taken from the table 4 and 5. Ø Then these 15 values are multiplied to calculate the EAF (Effort Adjustment Factor). 16

Cost drivers Very low Number 1 0. 75 2 3 0. 70 4 5 6 7 8 1. 46 9 1. 29 Low 0. 88 0. 94 0. 85 0. 87 1. 19 1. 13 Ratings Nominal High 1. 00 1. 00 Table 4. 1. 15 1. 08 1. 15 1. 11 1. 06 1. 15 1. 07 0. 86 0. 91 Very high 1. 40 1. 16 1. 30 1. 21 1. 30 1. 15 0. 71 0. 82 Extra high 1. 65 1. 66 1. 56 17

Cost drivers Very low Number 10 1. 42 11 1. 21 12 1. 14 13 1. 24 14 1. 24 15 1. 23 Low 1. 17 1. 10 1. 07 1. 10 1. 08 Ratings Nominal High 1. 00 0. 86 0. 90 0. 95 0. 91 1. 04 Very high Extra high 0. 70 0. 82 0. 83 1. 10 - Table 5 18

The Intermediate COCOMO model formulas are Effort ( E ) = (A*(KLOC)B) * EAF. Time (T) = C*(Effort)D Persons required = Effort / Time Software A B C D Organic 3. 2 1. 05 2. 5 0. 38 Semi Detached 3. 0 1. 12 2. 5 0. 35 Embedded 2. 8 1. 20 2. 5 0. 32 Project Table 6 19

Detailed COCOMO Model: Ø The detailed model uses different effort multipliers for each cost driver attribute. Ø In this the whole software is divided into different modules and then apply COCOMO in different modules to estimate effort and then sum the effort. The Six phases of detailed COCOMO are Ø Planning and requirements Ø System design Ø Detailed design Ø Module code and test Ø Integration and test Ø Cost Constructive model The effort is calculated as a function of program size and a set of cost drivers are given according to each phase of the software lifecycle. 20

COCOMO II Model: COCOMO II is a hierarchy of estimation models that address the following areas Ø Application composition model Ø Early design stage model Ø Post-architecture-stage model 21

COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarchy. They are Ø Object points Ø Function points Ø Lines of source code. The COCOMO II application composition model uses object points. 22

Like function points, the object point is an indirect software measure that is computed using counts of the number of Ø screens (at the user interface) Ø reports, and Ø components likely to be required to build the application. Each object instance such as a screen or report is classified into one of three complexity levels i. e. simple, medium, or difficult using criteria suggested by Boehm 23

The screens are classified on the basis of number of views and sources. Reports are classified on the basis of number of sections and sources. Number of Views Number and sources of data tables Total < 4 Total < 8 Total 8+ ( >3 server (<2 server <3 (2 -3 server 3 -5 >5 client) <3 Simple Medium 3 -7 Simple Medium Difficult >8 Medium Difficult contained Table 7 for screens 24

Number of Number and sources of data tables Sections contained Total < 4 Total < 8 Total 8+ ( >3 (<2 server <3 (2 -3 server 3 -5 server >5 client) 0 or 1 Simple Medium 2 or 3 Simple Medium Difficult 4+ Medium Difficult Table 8 for reports 25

Once complexity has determined, the number of screens, reports, and components are weighted according to the following table 8. Object Type Complexity Weight Simple Medium Difficult Screen 1 2 3 Report 2 5 8 3 GL 10 component Table 9 26

Ø The object point count is determined by multiplying the original number of object instances by the weighting factor in the above tables 7, 8 and summing to obtain a total object point count. Ø When component-based development or general software reuse is to be applied, the percent of reuse (%reuse is estimated and the object point count is adjusted as follows. NOP = (object points) * [(100 - %reuse)/100] Where NOP = New Object Points. 27

28

Developer's Very Low Low Nominal High Very High 4 7 13 25 50 experience/capability Environment maturity/capability Productivity Rate (PROD) Table 10: productivity rate for different levels of developer experience and development environment maturity. 29

Example: Consider a database application project with the following characteristics. i) The application has 4 screens with 4 views each and 7 data tables for 3 servers and 4 clients. ii) The application may generate two reports of 6 sections each from 7 data tables for two servers and 3 clients. There is 10% reuse of object points. The developer’s experience and capability in the similar environment is low. The maturity of organization in terms of capability is also low. Calculate the object point count, new object points and effort to develop such a Project. 30

Solution: The project comes under the category of application composition COCOMO II estimation model. Number of screens = 4 with 4 views each Number of reports = 2 with 6 sections each. From tables 7 and 8 each screen complexity = medium (medium =2) and each report complexity = difficult (difficult =8) Using table 9 of complexity weights, Object point count = 4 * 2 + 2 * 8 = 24. 31

32

Summary: In this lecture the following topics has discussed Ø Structure of estimation models and different estimation models based on LOC and FP Ø COCOMO Model Basic COCOMO Intermediate COCOMO Detailed COCOMO Ø COCOMO II Model 33

References: Ø Software Engineering, A Practitioner’s approach by Roger S. Pressman, 7 th Edition. Ø Software Engineering by K K Aggarwal, Yogesh Singh, 3 rd Edition New Age International Publishers. Ø https: //www. geeksforgeeks. org/software-engineering-cocomo-model/ 34

Thank You S Sambha Murthy Lecturer in Computer Science GDC Paderu 35