Metrics for project size estimation


Published on

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Metrics for project size estimation

  1. 1. Nur Islam BESUS,IT 7th Sem)
  2. 2. A Good Manager Measures  Process process metrics measurement Product project metrics product metrics
  3. 3. Project Size Estimation  Accurate estimation of the problem size is fundamental to satisfactory estimation of the other project parameters such as effort , time duration for completing the project and the total cost for developing the software.  The project size is neither the number of the bytes that the source code occupies nor the byte size of the executable code.  The project size is a measure of the problem complexity in terms of the effort and time required to develop the product.
  4. 4. When to 2Size 1 DEFINE DESIGN SIZING 3 BUILD TEST IMPLEMENT SIZING SIZING 1) Initial sizing during or after Requirements Phase 2) Subsequent sizing after System Design or when Change occurs 3) Final sizing after Install .
  5. 5. Metrics to estimate size  The IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”  In software development, a metric (noun) is the measurement of a particular characteristic of a program's performance or efficiency.  Four metrics are popularly being used to estimate size. They are    Count the lines Lines of code(LOC) Function point(FP) Feature point
  6. 6. ways to count the lines  Lines of code, or LOC, looks like a simple concept. However, it's not. There are several ways to count the lines. Depending on what you count, you get a low or a high line count. In the table below you can see various alternatives. The "Supported as" column shows which metrics Project Metrics supports.
  7. 7. Project metrics Metric Supported as Description Physical lines LINES This metric counts the physical lines Physical lines of code (not supported) This type of a metric counts the lines but excludes empty lines and comments. Logical lines LLINES A logical line covers one or more physical lines. Two or more physical lines can be joined as one logical line with the line continuation sequence
  8. 8. Project metrics Logical lines of code LLOC A logical line of code is one that contains actual source code. An empty line or a comment line is not counted in LLOC Statements STMT This is not a line count, but a statement count
  9. 9. Line of code(LOC)  LOC is the popular and simplest one.  This measures the size of a project by counting the number of source instruction in the development program ignoring the commenting code and header lines.  In order to estimate the LOC count at the beginning of a project one would to make a systematic guess.  By using the lowest level modules(division of a problem) , project managers arrive the total size estimation.
  10. 10. Shortcomings of LOC  LOC gives a numerical value of problem size.  Problem:  If may vary widely with individual coding style.  Exampleone programmer may write several instruction in a single line but another programmer may write these instructions in several lines.  Solution: count the language tokens rather than the lines of code.
  11. 11. Shortcomings of LOC  LOC is a measure of the coding activity alone.  Problem: a good problem size measure should consider the total effort for specify, design, code , test etc.  It merely computes the number of source line in the final program.  Problem: coding is a very small part in the overall software development activities.
  12. 12. Shortcomings of LOC  LOC metrics measure the lexical complexity of a program and does not address the more important issue of logical or structure complexity.  Problem a program having complex logic would require much more effort to develop than a program with simple logic.  LOC measure correlates poorly with the quality and efficiency of the code.  Problem large code size does not imply better quality or higher efficiently.
  13. 13. Shortcomings of LOC  It is very difficult to accurate estimate LOC in the final product from the problem specification. The LOC count can only be accurately computed only after the code has been fully develop.  LOC metric penalizes use of high level programming language ,code reuse etc. if a programmer use many library routines or he/she reuse code then the LOC of that problem is less but it not mean that the effort of that program is very few. So it not the right way to estimate the project size.
  14. 14. Function point metrics  This metric overcomes the shortcoming of the LOC metric.  In LOC metric size can be determine accurately only after the product has fully been developed but in function point size can be determine directly from program specification.  Here the size of a software product is directly dependent on the number of different function or features it supported. It also depend on the number of the file and the interfaces.  It is certain that a product support many features is larger in size than a product with few features.
  15. 15. Steps to compute function point  Beside using the number of the input and output data values function point metric computes the size of a software product(in unit of function points or FPs).  The steps for computing function point-  To compute the unadjusted function point(UFP)  UFP is refined to reflect the differences in the complexities of the different parameters  FP is computed by further refining UFP to account for the specific characteristic of the project that can influence the development effort.  UDP=(number of inputs)*4+(number of outputs)*5+(number of inquires)*4+(number of files )*10+(number of interfaces)*10
  16. 16. Different parameters of function point  Number of inputs:  Here each data item input by the user is counted.  Data input should be distinguished from user inquiries.  Here the data item input by the user are not simply added to compute the number of input but a group of related inputs are consider as a single input.  Example- in employee payroll software the data itemname , age , sex , address are together consider as a single input.
  17. 17. Different parameters of function point  Number of outputs:  The output consider refer to reports printed , screen outputs , error message produce etc.  The individual data item within a report is not consider as a output a set of related data item is consider as a output.  Number of inquires:  It is the number of distinct interactive queries which can be made by the users.  Number of files:  Each logical file which implies a group of logically related data is counted.  Logical file include data structure and physical files.
  18. 18. Different parameters of function point  Number of interfaces:  The interface considered are the interface used to exchange information with other system. Complexity level of each parameter is graded as simple, average , complex. The weight for the different parameter can be compute based on the following tableType Simple Average complex Input 3 4 6 Output 4 5 7 Inquiry 3 4 6 Number of files 7 10 15 Number of interfaces 5 7 10
  19. 19. Calculation of function point  Then technical complexity factor(TCF)for the project     is computed and the TCF is multiply with UFP to get FP. There are 14 parameter that can be influence the development effort valued form 0(no influence)6(strong influence). The resulting numbers are summed to get degree of influence(DI). TCF=(.65+.01*DI) DI vary from 0-84 and TCF vary from .65-1.35. Finally FP is given as a product of UFP and TCF. FP=UFP*TCF.
  20. 20. Feature point metric  Function point does not account the algorithm complexity of a software.  It assume that the effort required to design and develop any two functionalities of the system is exactly the same. But normally it is not true.  To overcome this problem an extension of the function point metric is proposed. That is Feature point metric  In feature point metric an extra parameter is used. That is Algorithm complexity
  21. 21. Feature point metric  It is a superset of FP.  In this metric we compute the complexity of a function.  So when used on real time and systems software, Feature Points often generate higher totals than Function Points  It is certain that grater effort is required to develop a complex function and therefore its size should be larger compared to simple function.
  22. 22. Advantages and disadvantages of these metrics  Function point and feature point metrics are language independent.  They are easily computed from the SRS document during project planning.  But these metrics are very subjective. For example the data student_details contains student name and address. It is possible one consider it as a single unit of data and another consider name and address are two different unit of data.  So there is a possibility different project manager consider different function point measure in a same problem.
  23. 23. Conclusion  Project size estimation is an important thing which can be determined by different metrics. It helps the project manager to get the idea about different parameter like effort, time etc.  Between two metrics function point(FP) is better than line of code(LOC),because in LOC there is several problem and we can not properly estimate the size of project.
  24. 24. THANK YOU