1. 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

2. 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. > 100 75 - 100 50 - 75 25 - 50 15 - 25 5 - 15 1 - 5 < 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) 320 150 106 80 71 64 40 32 21 16 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%

3. Page 3 CMM Level NumberRecommended Number of Metrics 1234512345 0 - 11 11 - 22 22 - 30 30 - 36 36 - 50 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

4. 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.

5. 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

6. 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

7. 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