1 / 33

Software estimation techniques

Software estimation techniques. Lidia García Esparcia Daniel Román Planas Estefanía Caballero Ruiz Victoria Blanco Alegría. Index. Introduction Current situation Estimation techniques Function points Characteristic points Lines of code Comparative Conclusion Future trends Sources.

muncel
Download Presentation

Software estimation techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software estimation techniques Lidia García Esparcia Daniel Román Planas Estefanía Caballero Ruiz Victoria Blanco Alegría

  2. Index • Introduction • Current situation • Estimation techniques • Function points • Characteristic points • Lines of code • Comparative • Conclusion • Future trends • Sources

  3. Introduction • Why we measure? • Evaluate the productivity • Evaluate the profits • A previous stage before estimate • Justify using new tools • Software projects are typically controlled by four major variables; time, requirements, resources (people, infrastructure/materials, and money), and risks. • Overestimating needs can be very expensive for the organization • 3 kinds of methods

  4. Current situation • All sw development companies use planning techniques in order to estimate the cost of a project. • Break the project down into the different tasks needed. • Evaluate each task on two scales: complexity and size of work

  5. Function points Index • Introduction • ISO/IEC 14143 • IFPUG-FPA • MK II • COSMIC FFP • Method Evolution • Criticism

  6. Introduction • Functional Size Measurement Method • Simple • Independent of the technology • Based on functional user requirements • Consistent • Estandar • Unit of measurement to express the amount of business functionality an information system provides to a user.

  7. ISO/IEC 14143 • Define the concepts and features that a method should satisfy in order to be approved. • Methods: • ISO/IEC 20926:2003 Software engineering -- IFPUG 4.1 Unadjusted functional size measurement method • ISO/IEC 24570. Software engineering -- NESMA -- Function Point Analysis. • ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis • ISO/IEC 19761:2003 Software engineering -- COSMIC-FFP -- A functional size measurement method

  8. IFPUG - FPA “Standard method for measuring the development of software from the user's point of view. • In 1986, Allan Albrecht found the International Function Point User Group • Most famous and most used • Number of function points acording to the component type (transaction functions, data files) and its complexity. • Adjustment of the result • Evaluates the size of the project, cost and development time . • Has limitations for measuring software in real time systems.

  9. MK II • Developed in 1986 by KPMG, defined and published by Charles R. Symons in 1991. Adopted by UKSMA (United Kingdom Software Metrics Association. • Method of continuous measurement throughout the life cycle of an application • Derivation of the Albrecht’s function Points . • Logic discrete transactions consisting of entry, process and exit

  10. COSMIC-FFP • FFP (v. 1.0) was published in 1997 as an extension of IFPUG method to measure the functional size of real-time software and control systems. • In 1998, a group of experts in software metrics, established the Common Software Measurement International Consortium (COSMIC FFP). • Introduces additional data and transactional function types: • Control Data: • Multiple occurrence logical group • Single ocurrence logical group. • Transactions: • Full Function Points enter into the calculation not only processes but also includes subprocesses . • The other types of data and processes are counted with the standard FPA technique

  11. Method Evolution

  12. Criticism • Additional dedication in the software development projects. • It is hard to train staff in their use. • The method of calculation is subjective. • Need to re-estimate the size as we have more product knowledge. • Lacks precision when it comes to small projects. • Not applicable to all systems.

  13. Feature points Index • Introduction • Method • Example • Advantages

  14. Feature points Introduction • Software estimation method designed by Caper Jones. • Very similar to function points, but more accurate for estimating scientific and complex software. • Used specifically for CAD software, embedded systems and real-time applications.

  15. Feature points Introduction • The differences between function points and feature points are in the algorithm cost estimation, that is new on feature points, and the removal of the different complexity levels, establishing just one for each feature.

  16. Feature points Method • Count the number of the different features. • Calculate the cost of these features.

  17. Feature points Count the number of different features Features in this step are the same that function points define, adding the count of the algorithms. This is: • External inputs. • External outputs. • External queries. • Internal logical files. • External logical files. • Algorithms.

  18. Feature points Calculate features’ cost Each feature has an unique complexity value. Cost estimation of that features is calculated by multiplying complexity by the count of that feature. Final estimation are done by applying this equation: FPE = TOTAL_COUNT * (0.65 + 0.01 * SUM(Fi)) Fi => Result of question number i on information system survey, also defined on function points estimation.

  19. Feature points Example FUNCTION POINTS

  20. Feature points Example FEATURE POINTS

  21. Feature points Advantages • More accurate when is applied to scientific, mathematic, real-time or military software, which uses complex algorithms. • Used on other kinds of software, feature points offers similar results than function points calculate.

  22. Lines of code Index • Introduction • Types • Example • EstimatingEffort • Advantages • Disadvantages

  23. Lines of code Introduction Measures the size of a software project counting the number of lines of code. • Predict the amount of effort. • Estimate programming productivity. • Estimate effort once the software is produced.

  24. Lines of code Types • Physical SLOC • Count the lines of the program's source code. • Logical SLOC • Measure the number of statements.

  25. Lines of code Example

  26. Lines of code • Productivity = KLOC / person-month • Quality = defects / KLOC • Cost = Cost / KLOC • Documentation = pages of documentation / LOC

  27. Lines of code Estimatingeffort Itisbasedonpreviousprojectsorontheexperience of thedeveloper.

  28. Lines of code E =  (a + 4m + b) / 6 a= ideal number of LOC b= pessimistic number of LOC m= most probable number of LOC

  29. Lines of code Advantages • Easy method • Many methods use LOC as an imput

  30. Lines of code Disadvantages • Lack of Cohesion with Functionality • Lack of Accountability • Difference in Languages • Lack of Counting Standards • Psychology

  31. Comparative

  32. Conclusion • The fundamental goals of software estimation are to produce estimations of effort and schedule for anticipated software projects • Increasingly, it is recognized that software estimation techniques must reflect, and be an integral part of, the technical and managerial processes used to develop and modify software. • The preceding techniques can help one achieve better estimates

  33. Sources: • www.inf.udec.cl • www.monografias.com • www.willydev.net • www.wikipedia.com

More Related