Page 1 COCOMO Model The original COCOMO model was first published by Barry Boehm in 1981 at CSE Center for Software Engineering. This is an acronym derived.

Slides:



Advertisements
Similar presentations
Project Estimation: Metrics and Measurement
Advertisements

Metrics for Process and Projects
W5HH Principle As applied to Software Projects
Cocomo II Constructive Cost Model [Boehm] Sybren Deelstra.
Software Effort Estimation based on Use Case Points Chandrika Seenappa 30 th March 2015 Professor: Hossein Saiedian.
Software Quality Metrics
Project Risks and Feasibility Assessment Advanced Systems Analysis and Design.
Ch8: Management of Software Engineering. 1 Management of software engineering  Traditional engineering practice is to define a project around the product.
SOFTWARE PROJECT MANAGEMENT AND COST ESTIMATION © University of LiverpoolCOMP 319slide 1.
Software Process and Product Metrics
HIT241 - COST MANAGEMENT Introduction
Information System Economics Software Project Cost Estimation.
N By: Md Rezaul Huda Reza n
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 22 Instructor Paulo Alencar.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
Estimation Why estimate? What to estimate? When to estimate?
Software Estimation and Function Point Analysis Presented by Craig Myers MBA 731 November 12, 2007.
Chapter 6 : Software Metrics
Project Management Estimation. LOC and FP Estimation –Lines of code and function points were described as basic data from which productivity metrics can.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Software cost estimation 1.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Chapter 23 Software Cost Estimation.
Function Point Analysis What is Function Point Analysis (FPA)? It is designed to estimate and measure the time, and thereby the cost, of developing new.
Software Measurement & Metrics
Software Estimation How hard can it be? Peter R Hill.
Software cost estimation Predicting the resources required for a software development process 1.
1 Chapter 23 Estimation for Software Projects. 2 Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for.
Software Engineering SM ? 1. Outline of this presentation What is SM The Need for SM Type of SM Size Oriented Metric Function Oriented Metric 218/10/2015.
Software Function, Source Lines Of Code, and Development Effort Prediction: A Software Science Validation ALLAN J. ALBRECHT AND JOHN E.GAFFNEY,JR., MEMBER,IEEE.
Software Project Management Lecture # 3. Outline Chapter 22- “Metrics for Process & Projects”  Measurement  Measures  Metrics  Software Metrics Process.
Lecture 4 Software Metrics
10/27/20151Ian Sommerville.  Fundamentals of software measurement, costing and pricing  Software productivity assessment  The principles of the COCOMO.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
Chapter 3: Software Project Management Metrics
©Ian Sommerville 2000Software Engineering, 7th edition. Chapter 26Slide 1 Software cost estimation l Predicting the resources required for a software development.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
SFWR ENG 3KO4 Slide 1 Management of Software Engineering Chapter 8: Fundamentals of Software Engineering C. Ghezzi, M. Jazayeri, D. Mandrioli.
SOFTWARE PROCESS AND PROJECT METRICS. Topic Covered  Metrics in the process and project domains  Process, project and measurement  Process Metrics.
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
Project, People, Processes and Products Project management skills – schedule, monitoring, risk management, … People management skills – delegation, mentoring,
Hussein Alhashimi. “If you can’t measure it, you can’t manage it” Tom DeMarco,
Advanced Software Engineering Lecture 4: Process & Project Metrics.
Chapter 7: Project Cost Management
SOFTWARE PROCESS IMPROVEMENT SHARATH CHANDAR REDDY ALETI CSC 532 TERM PAPER.
Cost Estimation Cost Estimation “The most unsuccessful three years in the education of cost estimators appears to be fifth-grade arithmetic. »Norman.
Project Planning Goal 1 - Estimates are documented for use in tracking and planning project. Goal 2 - Project Activities and commitments planned and documented.
Software Engineering, COMP201 Slide 1 Software Engineering CSE470.
COCOMO Software Cost Estimating Model Lab 4 Demonstrator : Bandar Al Khalil.
Software Engineering, COMP201 Slide 1 Software Engineering CSE470.
THE FAMU-CIS ALUMNI SYSTEM
Chapter 33 Estimation for Software Projects
Software Metrics 1.
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Software Project Sizing and Cost Estimation
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Constructive Cost Model
Software Development & Project Management
Chapter 5: Software effort estimation- part 2
Software Metrics “How do we measure the software?”
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Chapter 33 Estimation for Software Projects
Software metrics.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Software Effort Estimation
Chapter 26 Estimation for Software Projects.
Center for Software and Systems Engineering,
COCOMO MODEL.
Presentation transcript:

Page 1 COCOMO Model The original COCOMO model was first published by Barry Boehm in 1981 at CSE Center for Software Engineering. This is an acronym derived from the first two letters of each word in the longer phrase Constructive Cost Model. The COCOMO cost estimation model is used by thousands of software project managers, and is based on a study of hundreds of software projects. The most fundamental calculation in the COCOMO model is the use of the Effort Equation to estimate the number of man-months required to develop a project. Most of the other COCOMO results, including the estimates for Requirements and Maintenance, are derived from this quantity. The original COCOMO model has been very successful, but it doesn't apply to newer software development practices as well as it does to traditional practices, but there is COCOMO II tuned to modern software life cycles. COCOMO II targets the software projects of the 1990s and 2000s. The COCOMO calculations are in the form of non-linear mathematical functions and are based on estimates of a project's size in Source Lines of Code (SLOC). Then the COCOMO model makes its estimates of required effort (measured in man-months) based on the estimate of the software project's size. From this value, the prediction of following values can be derived: project duration (typically in months) required to complete the software project, and required staffing (typically in FTE). Our approach Since all data were not available in the form required as inputs for the COCOMO method and only a basic information about Function Points and related project sizes in man-months were on hand, the man-months obtained from known Function Points were converted into its comparable COCOMO equivalent - the Effort value. This value was then used in the COCOMO equations to make all subsequent estimates. Our approach Since all data were not available in the form required as inputs for the COCOMO method and only a basic information about Function Points and related project sizes in man-months were on hand, the man-months obtained from known Function Points were converted into its comparable COCOMO equivalent - the Effort value. This value was then used in the COCOMO equations to make all subsequent estimates. Function Points / Feature Points The Function Point methodology was developed in 1979 by Allan Albrecht at IBM and was modified in 90’s as the Feature Point methodology by Jones. This methodology is based on the premise that the size of a software project can be estimated early, during the requirements analysis. If there are counted some requirement characteristics of the project, and then multiplied by weighting and adjustment factors, the sum is the total point count. The method used for staffing COCOMO is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity. Units counted through either Function Points or Feature Points represent the expected complexity and required effort of the project. Staffing issues

Page 2 Software Project Size 100 FP1000 FP10000 FP Productivity rates in FP per man/month Function Points (Albrecht, 1979) is a metrics used for estimating the size of an application. The basic idea of Function Points is that five items are counted: 1) the inputs to the application 2) the outputs from it 3) inquiries by users 4) the data files that would be updated by the application, and 5) the interface to the application. Once these figures are known, they are multiplied by following coefficients: 4, 5, 4, 10, and 7 (these values can be modified from own experience, if required). The result indicates the estimated size of an application. Function Points worked reasonably for simple transaction processing or management information systems in 80’s, but unfortunately they often proved to be inadequate for estimating complex application such as information systems for high-tech industries. Therefore, there exists the need for Feature Points (Jones, 1995), a superset of classical FP, to correct this problem. Feature Points introduces new measurement, algorithms, giving it a weighting of 3. Additionally, the data file weighting is decreased from 10 to 7. > < 1 (Jones) Source code statements required for one FP Assembler low level: C classical: Fortran, Cobol structured: Pascal, RPG, PL1 hybrid object oriented: Modula-2, C++ non imperative: Lisp, Prolog 4GL languages obj. oriented: VB, Java, C# pure object oriented: Smalltalk, CLOS query languages: SQL, QBE, OQL Programming Language (Jones) Complexity of applications in function points Metrics and motivation 1.0%0.01%0.0% 3.0%0.1 %0.0% 7.0%1.0%0.0% 15.0%5.0%0.1% 40.0%10.0%1.4% 25.0%50.0%13.5% 10.0%30.0%70.0% 4.0%4.0%15.0%

Page 3 CMM Level NumberRecommended Number of Metrics The need for Metrics in CMM Metrics management is used to potentially improve both the quality of the software that is developed or maintained and also to improve the actual software processes of the organization itself. Metrics management provides the information critical to understanding the quality of the work that the project team has performed, and how effectively that work was performed. Software companies are used to collect metrics because this is the only proven tool to obtain managerial information for software development and quality assurance In the suggested Capability Maturity Model (CMM), there are recommended numbers of metrics to be collected and analyzed. Optimal frequency of collect the recommended metrics is weekly (or earlier, if there is a tool), and optimal frequency of analyze metrics is between weekly and monthly. Why to Collect Metrics?  To support greater predictability and accuracy of schedules and estimates.  To support quality assurance efforts by identifying the techniques that work best and the areas that need more work.  To support productivity and process improvements efforts by measuring how efficient the IT staff is and by indicating where the IT staff need improve.  To improve management control by tracking both projects and people.  To improve the motivation of developers by making them aware of what works and what does not.  To improve communications by describing accurately what is happening, and by identifying trends early on. Metrics management is the process of collecting, summarizing and acting on measurements Metrics and motivation

Page 4 Metrics and motivation StagePotential Metrics Number of use case Function/feature points Level of risk Project size Cost/benefit breakpoint Number of reused infrastructure artifacts Number of introduced infrastructure artifacts Requirements instability Procedure/Operation count of a module Number of variables per data structure Size of procedures/operations Number of data types per database Number of data relationships per database Number of interfaces per module Requirements instability Procedures/Operations size Procedures/Operations response Comments per procedure/operation Percentage of commented procedures/operations Global usage Number of candidate items for generalization Percentage of items generalized Effort required to generalize an item Percentage of deliverables reviewed Time to fix defects Defect recurrence Defect type recurrence Define Requirements and Justify Define Management Documents Model Program, Generalize and Test Family of potential SW metrics Recommended metrics are printed in bold face.

Page 5 StagePotential Metrics Time to fix defects Defect recurrence Defect type recurrence Number of defects Defect source count Work effort to fix a defect Percentage of items reworked Enhancements implemented per release Amount of documentation Percentage of customers trained Average training time per user trainer Number of lessons learned Percentage of staff members assessed Average response time Average resolution time Support request volume Support backlog Support request aging Support engineer efficiency Reopened support requests Mean time between failures Software change requests opened and closed Deliver and Test Assess Support Family of potential SW metrics Recommended metrics are printed in bold face. Metrics and motivation

Page 6 MetricsDescription Calendar time expended Overtime Release Stage Staff turnover Work effort expended This productivity metric is a measure of the number of people gained and lost over a defined period of time, typically a calendar month. This metric is often collected by position/role and can be used to help define human resources requirements and the growth rate of your information technology (IT) department. This cost metric is a measure of the amount of work expended to complete a task, typically measured in work days or work months. This metric is often collected by task (see above). This cost metric is a measure of the amount of overtime for a project and can be collected as either an amount of of workdays or a percentage of overall effort. This metric is often subdivided by overtime for work directly related to development, such as programming or testing, and by indirect effort, such as training or team coordination. This schedule metric is a measure of a calendar time to complete a task, where a task can be as small as the creation of a deliverable or as large as a project phase or an entire project. Metrics Applicable to All of the Phases and Stages Possible metrics to collect

Page 7 CategoryDescription Cost metrics measure the amount of money invested in a project. Examples of cost metrics include effort expended or investment in training. Cost Productivity metrics measure the effectiveness of the organization`s infrastructure. Examples of productivity metrics include the number of reused infrastructure items and trend analysis of effort expended over given periods of time. Productivity Quality metrics measure the effectiveness of the quality assurance efforts. Examples of quality assurance metrics include the percentage of deliverables reviewed and defect type recurrence. Quality Requirements metrics measure the effectiveness of the requirements definition and validation efforts. Examples of requirements metrics include requirements instability and number of use cases. Requirements Schedule metrics measure the accuracy of your proposed schedule to the actual schedule. Examples of schedule metrics include the calendar time expended to perform a task or project phase. Schedule Size metrics measure, as the name suggests, the size of the development efforts. Examples of size metrics include the number of methods of a class and the function/feature point count. Size Testing metrics measure the effectiveness of the testing efforts. Examples of testing metrics include the defect severity count and the defect source count. Testing Metric categories Possible metrics to collect