Software Effort Estimation 1 Introduction In the organizations

Software Effort Estimation 1

Introduction: In the organizations, still there is no accurate and proper way of finding estimated cost for developing software applications or systems. Initial basic estimates are done on the basis of high level requirements which don‟t give you the clear depiction of overall estimation. 2

For new project which require to be developed in latest technologies, there might be requirement of upgraded resources may be in terms of skilled employees, latest software technologies and good infrastructure etc. So, while new development during early stages of software development it is quite impossible to estimate actual cost of project. 3

In software development, software estimation is the estimation of the software size, software development effort, software development cost, and software development schedule for a specified software project in a specified environment, using defined methods, tools, and techniques. 4

Basic steps for software project estimation are: 1. Estimate the size of the development product. 2. Estimate the effort in person-months or person-hours. 3. Estimate the schedule in calendar months. 4. Estimate the project cost 5

Software Size Metrics z. LOC (Lines of Code): y. Simplest and most widely used metric. y. Comments and blank lines should not be counted. 6

Disadvantages of Using LOC z. Size can vary with coding style. z. Focuses on coding activity alone. z. Correlates poorly with quality and efficiency of code. z. Higher level programming languages, code reuse, etc. 7

Function Point Metric z. Overcomes some of the shortcomings of the LOC metric z. Proposed by Albrecht in early 80's: 8

Type of Component Complexity of Components Low Average High External Inputs X 3= X 4= X 6= External Outputs X 4= X 5= X 7= Internal Inquiries X 3= X 4= X 6= Internal Logical Files X 7= X 10= X 15= External Interface Files X 5= X 7= X 10= Total number of unadjusted Function points Multiplied value adjustment factor Total Adjusted Function Points 9

Information domain values are defined in the following manner: z Number of user inputs: Each user input that provides distinct application-oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately. z Number of user outputs: Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately. 10

z Number of user inquiries: An inquiry is defined ass an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted. z Number of files: Each logical master file (i. e. a logical grouping of data that may be one part of a large database or a separate file) is counted. z Number of external interfaces: All the machine-readable interfaces (e. g. , data files on storage media) that are used to transmit information to another system are counted 11

Once these data have been collected, a complexity value is associated with each count. Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex. Nonetheless, the determination of complexity is somewhat subjective 12

z. To compute function points (FP), the following relationship is used: z z FP est. = Count Total * [ 0. 65 + 0. 01 * (Fi)] z z Where count total is the sum of all FP entries obtained from above figure and (Fi) is value adjustment factor (VAF) is based on 14 general system characteristics (GSC's) that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help determine the degrees of influence of the characteristics. The degrees of influence range on a scale of zero to five, from no influence to strong influence. 13

14 general system characteristics z 1. z 2. z 3. z 4. z 5. z 6. z 7. Data communications Distributed data processing Performance Heavily used configuration Transaction rate On-Line data entry End-user efficiency z 8. z 9. z 10. z 11. z 12. z 13. z 14. On-Line update Complex processing Reusability Installation ease Operational ease Multiple sites Facilitate change 14

Expert judgement z. Experts divide a software product into component units: ye. g. GUI, database module, data communication module, billing module, etc. z. Add up the guesses for each of the components. 15

Price-to-Win z. Estimate is estimated atwhatever the optimum value is in order to win the contract or zwhatever funds or time the customer has available 16

Analogy Costing Analogous estimating is the act of using former projects to estimate how long or how much a current project will take or cost. In other words, it is a technique that centers on comparison. This means that the more data that is available, the better the estimate will be. 17

COCOMO Model z. COCOMO (COnstructive COst MOdel) proposed by Boehm. z. Divides software product developments into 3 categories: y. Organic y. Semidetached y. Embedded 18

COCOMO Product classes z. Roughly correspond to: yapplication, utility and system programs respectively. x. Data processing and scientific programs are considered to be application programs. x. Compilers, linkers, editors, etc. , are utility programs. x. Operating systems and real-time system programs, etc. are system programs. 19

Elaboration of Product classes z. Organic: y. Relatively small groups xworking to develop well-understood applications. z. Semidetached: y. Project team consists of a mixture of experienced and inexperienced staff. z. Embedded: y. The software is strongly coupled to complex hardware, or real-time systems. 20

COCOMO Model (CONT. ) z. For each of the three product categories: y. From size estimation (in KLOC), Boehm provides equations to predict: xproject duration in months xeffort in programmer-months z. Boehm obtained these equations: yexamined historical data collected from a large number of actual projects. 21

COCOMO Model (CONT. ) z. Software cost estimation is done through three stages: y. Basic COCOMO, y. Intermediate COCOMO, y. Complete/deatiled COCOMO. 22

Basic COCOMO Model (CONT. ) z. Gives only an approximate estimation: y. Effort = a 1 (KLOC)a 2 y. Tdev = b 1 (Effort)b 2 x. KLOC is the estimated kilo lines of source code, xa 1, a 2, b 1, b 2 are constants for different categories of software products, x. Tdev is the estimated time to develop the software in months, x. Effort estimation is obtained in terms of person months (PMs). 23

Development Effort Estimation z. Organic : y Effort = 2. 4 (KLOC)1. 05 PM z Semi-detached: y. Effort = 3. 0(KLOC)1. 12 PM z Embedded: y. Effort = 3. 6 (KLOC)1. 20 PM 24

Development Time Estimation z. Organic: y. Tdev = 2. 5 (Effort)0. 38 Months z. Semi-detached: y. Tdev = 2. 5 (Effort)0. 35 Months z. Embedded: y. Tdev = 2. 5 (Effort)0. 32 Months 25

Example z The size of an organic software product has been estimated to be 32, 000 lines of source code. z Effort = 2. 4*(32)1. 05 = 91 PM z Nominal development time = 2. 5*(91)0. 38 = 14 months 26

Intermediate COCOMO z. Basic COCOMO model assumes yeffort and development time depend on product size alone. z. However, several parameters affect effort and development time: x. Reliability requirements x. Availability of CASE tools and modern facilities to the developers x. Size of data to be handled 27

Intermediate COCOMO z. For accurate estimation, ythe effect of all relevant parameters must be considered: y. Intermediate COCOMO model recognizes this fact: xrefines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers). 28

Intermediate COCOMO (CONT. ) z. If modern programming practices are used, yinitial estimates are scaled downwards. z. If there are stringent reliability requirements on the product : yinitial estimate is scaled upwards. 29

Intermediate COCOMO (CONT. ) z. Rate different parameters on a scale of one to three: y. Depending on these ratings, xmultiply cost driver values with the estimate obtained using the basic COCOMO. E=ai(KLo. C)(bi)(EAF) 30

Software project ai bi Organic 3. 2 1. 05 Semi-detached 3. 0 1. 12 Embedded 2. 8 1. 20 31

Intermediate COCOMO (CONT. ) z. Cost driver classes: y. Product: Inherent complexity of the product, reliability requirements of the product, etc. y. Computer: Execution time, storage requirements, etc. y. Personnel: Experience of personnel, etc. y. Development Environment: Sophistication of the tools used for software development. 32

Shortcoming of basic and intermediate COCOMO models z. Both models: yconsider a software product as a single homogeneous entity: y. However, most large systems are made up of several smaller sub-systems. x. Some sub-systems may be considered as organic type, some may be considered embedded, etc. xfor some the reliability requirements may be high, and so on. 33

Complete COCOMO z. Cost of each sub-system is estimated separately. z. Costs of the sub-systems are added to obtain total cost. z. Reduces the margin of error in the final estimate. 34