Software Estimation Exercise with COCOMO II

EEE492A

  1. Aim

The aim of this lab is to become familiar with COCOMO II software estimation through a hands-on exercise.

  1. Background Info

As you know, COCOMO-II is one of the many algorithmic based software estimation models. It includes models for estimating levels of effort (in person months) and development time (in calendar months) for three increasingly detailed stages of estimation. The first stage of estimation occurs during the early conceptual and exploration phases of project and is supported by the Application Composition model; here the granularity of the both the data available and the estimate are quite coarse. The second stage coincides with the architectural design phase of the project and is supported by the Early Design model. The third stage of estimation directly supports the software development activities and is supported by the Post-Architecture model; much is already known about the project and its product design thus allowing for much finer grained estimates. This exercise will concentrate upon the more detailed, Post-Architecture model.

For more information regarding the model assumptions and specific formulae you are referred to your course notes. For specific information regarding COCOMO-II cost driver factors you are referred to the course handout, “COCOMO II Data Sheets”.

Important Note: The performance of a parametric estimating tool is fundamentally limited by how well its calibration data matches the project under estimate.

3.Procedure

3.1Exercise Scenario

  1. Read the exercise enclosed scenario. This scenario describes the software product you are estimating, your work setting and much of the pertinent information required for establishing the model parameters.
  2. You should initially set the parameters based solely on the information provided in the scenario. In cases where the scenario description provides no direct information regarding a particular factor, you should assume that the nominal setting is appropriate. However, after you have completed the exercise described below, you are encouraged to adjust other factors based on your experience or curiosity. You will then be in a position to observe their impact on effort and schedule.
  3. Sensitivity Analysis
  1. Explore the impact that various parameter changes have on your effort or schedule estimate. In particular, observe the effort and schedule difference between a very high and a very low setting for the Documentation Needs (DOCU) cost driver. You may find it useful to set up your model in a spreadsheet (like MSExcel) ; this will make sensitivity analysis much easier, and much more productive.
  2. Experiment with schedule compression as provided for by the Required Development Schedule (SCED) cost driver. In particular observe the effect on effort and schedule for both extreme settings (very high and very low). How do you explain the apparent inconsistencies, in other words why is it not cheaper if the schedule is allowed to be relaxed?

3.3Reuse Analysis

  1. One aspect of the required application can be satisfied by adapting an existing and recently developed departmental application called the Capital Tax Rate Calculator (CTRC). If used this 4000 SLOC Java applet could satisfy roughly 20% of the required functionality; in other words it satisfies 20% of the necessary function points.
  2. It is estimated that the amount of redesign for the applet would be conservatively less than 20% and the amount of rewrite would be no more than 30%.While the CTRC appears to provide more than the required equivalent functionality, it remains to test and evaluate it for specific conformance. It is expected that integration of the CTRC product into the new application will require no more than a 25% incremental effort.
  3. Due to the high personnel turn-over, the individuals who developed the CTRC are no longer on contract in your organization and the current staff has a limited familiarity with CTRC. There is however a good correlation between PIT and CTRC, which follow the same documentation and coding standard.
  4. Using the COCOMO II reuse model, determine whether it will be cost effective to reuse CTRC in the PIT development. What additional factors might you want to consider with this case?

1/2

Annex

COCOMO II Exercise

The Income Tax Application Project

Setting

You are a systems engineer in charge of software development and maintenance of in-house information systems with the Canada Revenue Agency. You have been assigned the task to initiate and oversee the development of a Personal Income Tax (PIT) software application to be made available freely to all Canadian taxpayers. Your supervisor has asked you to submit an estimate of the cost and schedule to her by early next week. Fortunately for you, an earlier feasibility study has been conducted and the requirements have been validated through prototyping and a preliminary design has even been formulated. In addition, an estimate of the size of the PIT has been provided in unadjusted function points. Unfortunately, your supervisor has already (read promised her boss over lunch) committed to releasing the software on the internet before next tax season ends and therefore has directed that your answer had better be 6 months or less. Budget is not limitless, but given her predicament, finding the monetary resources is not your problem.

Your immediate task, therefore, is to use the information you have available today, and the COCOMO II cost estimation model to determine an objective estimate of project effort and schedule. Be sure to let your supervisor know how your estimate fits in with the promise she made to her boss.

Size Estimate

From the feasibility study, the system has been sized according to the following function points:

Business Functions / Raw Count / Weight / UFPs
User Input Functions (IT) / 45 / 4 / 180
User Output Functions (OT) / 22 / 5 / 110
User Inquiries (QT) / 65 / 4 / 260
Internal Files (FT) / 7 / 10 / 70
External Interfaces (ET) / 4 / 7 / 28
Total / 648

Development Language

Given that PIT will be deployed as a standalone application on CDor via the Internet, Java has been selected as the development language. According to your organization’s own project management records (and very consistent with standard translation tables), each implemented function point requires an average of 23 SLOC.

Staffing

Many years ago your organization has decided to contract out the vast majority of its software development. You currently have an engineering services contract with ACME Programming, a local CMM Level II IS company. You also have access to a medium sized pool of contracted resources, of varying skills, working on-site.

Other Factors

Based upon your years of experience in this group, and your hands-on approach to management, you have compiled the following “points of note” in your engineering logbook:

  • The personnel that get assigned to your contract from Company X are generally well versed in the business domain, and have previous IS development experience.
  • While you consider process important and often monitor the development, you do not regularly interfere in this regard so as to avoid the appearance of employee-employer relationships.
  • Despite the good calibre of developers you receive, you are constantly aggravated by the high turn-over rate (> 30% per year).
  • You have recently observed that the current group of programmer / analysts are adequate (or better) programmers, but that their analysis skills are weak. You had made a note to rectify this at a contract review meeting next week; your concern is that this weakness might have a costly long-term affect.
  • You have also noted, from a distance, that all three currentACME Programming managers (late 40’s gentlemen) are often in conflict with the younger team leaders and senior programmers. Again, you realize that your hands are somewhat tied (you are not supposed to get directly involved in ACME personnel management), but it is causing increasing friction.
  • Other than the exceptions noted above, the teams appear to get along well at the working level.

A - 1/2