Software Task Estimation

758 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
758
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Software Task Estimation

  1. 1. Software Task Estimation Copy Number _____Copyright © All Rights Reserved. Page 1
  2. 2. Document ControlChange Record Date Author Version Change Reference 7th June 2010 Venkat Alagarsamy Draft No previous documentReviewers Name PositionDistribution Copy No. Name Location 1 Library Master 2 3 4Connect Type Location Linkedin https://www.linkedin.com/in/venkatalagarsamy Scribd http://www.scribd.com/VenkatAlagarsamy Slideshare http://www.slideshare.net/VenkatAlagarsamy Blog http://venkatalagarsamy.blogspot.in/ Facebook https://www.facebook.com/Venkatachalapathi.alagarsamyCopyright © All Rights Reserved. Page 2
  3. 3. Contents Document Control ............................................................................................................. 2 Overview ............................................................................................................................ 4 Traditional Methods ................................................................................................... 4 Estimating Life Cycle.................................................................................................. 4 Estimating Program Volume ..................................................................................... 4 How to estimate the project based on KSLOC? ............................................................... 4 How to calculate KSOLC? ................................................................................................ 5Copyright © All Rights Reserved. Page 3
  4. 4. OverviewThough everyone has a favourite theory as to why software failures occur. In my view projects are failed becausepoor cost and incorrect estimates than by technical, political, or team problems. Software cost estimation is not anart. It is a science. Only few organizations and individuals understand this science.It is possible to accurately and consistently predict development life cycle costs and schedules for a wide range ofprojects. Using this concept, to estimate the cost, the only tool required is spredsheet.Traditional MethodsThe traditional methods that are used to estimate the size and/or volume of the program/task are:  Code size in kilo bytes (Program Volume)  Function pointsEstimating Life CycleAccuracy of cost estimates varies based on the software development stage. Early uncertainty is largely based onvariances in the input parameters to the estimate. Later uncertainty in the estimate is based on the variance to theestimating models. Initially, at the concept stage, you may be presented with high-level definition of the project.Though the requirements may not yet be fully understood, the general purpose of the new software can berecognized. At this point estimates with an accuracy of plus or minus 50% are typical for an experienced estimatorusing informal techniques such as historical comparisons and/or group consensus.The key to accuracy lies in making periodic reestimates through out the project life cycle, there by identifying theproblems rarely enough to take corrective action.Estimating Program VolumeThe first step in preparing an estimate is to characterize the project volume. One measure is the number of sourcelines of code or SLOC. A SLOC is a human return line of code that is not a blank line or commen. Same lineshould not be counted more than once, even if the code appears several times in an application. Normally theworkload is estimated in terms of KSLOC. How to estimate the project based on KSLOC? Person months of effort required for the project is arrived by multiplying estimated quantity of KSLOC and the effort required per KSLOC. This is the bease of all estimating models. Table: Common Values for linear productivity factor# The values in the table below are derived from work by Barry Boehm(COCOMO), Raymond Kyle and the U.S. Air Force Cost Analysis Agency’s revised COCOMO (REVIC), and firms or organizations working directly with the Cost Xpert Group. Exponential Size Penalty Project Type Linear Productivity Factor Factor Default 2.94 1.052 Embedded Development 2.58 1.110 eCommerce Development 3.6 1.030 Web Enabling 3.3 1.030 Military Development 2.77 1.072 ERP 3.96 1.926 Enterprise Application Integration 4.08 2.136 Man months for the smaller projects are calculated as: The Person Man-day = KSLOC * Linear Productivity Factor * 30 For example, To web enable an exsisting application of size 10,000 SOLC it would take, 10 * 3.3 * 30 = 990 Man-day.Copyright © All Rights Reserved. Page 4
  5. 5. The above equation could be used only for smaller projects. Productivity varies with project size. In fact, large projects are significantly less productive than small projects- probably because they require increased coordination and communication time, plus more rework due to misunderstandings. This would lead to penalize large projects for decreased efficiency. The exponential size penalty factor column in above table helps with penalty adjustments. Man months for the larger projects are calculated as: The Person Man-Day = KSLOC * Linear Productivity FactorExponential Sise Penalty Factor * 30 For the same above example (Web enabling an exsisting application) and the project is big, The new estimated time would be, 10 * 3.31.030 * 30 = 1,026 Man-days. The above examples are applicable only when the number of KSLOC is known. How to calculate KSOLC? There are two approaches to this. They are:  Direct Estimation  Function points with backfiring For both approaches the fundamental input variables are the experts and developers opinion. Direct Estimation: Normally, the first step in estimating the number of lines of code is the break the project down into modules or some other logical grouping. For example, a very high-level breakdown might be front-end process, middle-tier process, Database code and Reports. Then the developers use their experience in building similar systems to estimate the number of source lines of code required. It is suggested to get three different types of estimate from every input resource. They are:  Best case estimate (BEST)  Worst case estimate (WORST)  Expected case estimate (EXPECTED) Based on these estimates calculate the Mean and Standard Deviation as, Mean = (BEST + WORST + (4 * EXPECTED)) / 6 Standard Deviation = (WORST – BEST) / 6 Standard Deviation is a measure of how much deviation can be expected in the final number. For example, the mean plus three times the Standard Deviation will ensure that there is a 99% probability that the project would be completed as estimated. Function point estimation with backfiring: An alternative to direct SLOC estimating is to start with function points, and then use a process called backfiring to convert them to SLOC. To determine the number of function points, start by estimating the number of external inputs, external interface files, external outputs, external queries and logical internal tables.  External inputs are largely data entry screens. If a screen contains a tabbed notebook or similar metaphor, each tab counted as a separate external input.  External interface files are file-based inputs or outputs. Each record format within the file, or, in the case of XML, each data object type, would count as a separate interface file even if residing in the same physical file.  External outputs are reports.Copyright © All Rights Reserved. Page 5
  6. 6.  External queries are message or external function-based communication “into” or ”out” of application.  Logical internal tables are the number of tables in the database, assuming the database was third normal form or better. Table: Factors for coverting raw values into factor points Raw Type Function Point Conversion Factor External Inputs 4 External Interface Files 7 External Outputs 5 External Queries 4 Logical Internal Tables 10 To convert from these raw values into an actual count of function points, the raw numbers must be multiplied by a conversion factor from above table. For example, if there is a eCommerce system consisting of ten data entry screens, five interface files, thirty reports, twenty queries and ten logical internal tables, then the total function points are: (10 * 4) + (5 * 7) + (30 * 5) + (20 * 4) + (10 * 10) = 405 Function Points By converting this function points into SOLC using the following table rule. Table: Lines of code per function point by programming language Language SLOC per fun ction point C++ 53 COBOL 107 Oracle 25 SQL 13 VB 24 Java 43 .NET Framework 70 J2EE Framework 70 HTML 14 For example, To implement 405 Function Points using J2EE frame work, it requires 405 * 70 = 30,375 SLOC. To implement a eCommerce systems using J2EE frame work, it takes about 30,375 * 3.31.030 * 30 = 3,316 Man-days.Copyright © All Rights Reserved. Page 6

×