Ads
  

Effort Measures

Effort Measures

By "effort" in the software estimation process, we mean the amount of person-effort, or labor, that will be needed to carry out a task. It can be measured in any units, as long as the unit is kept consistent. On the other hand, the de facto standard is staff-hours (person-hours), staff-days (person-days), or, most commonly, staff-months (person-months).

On a given project, the project manager and team can find out the unit of measure and stick with it, resulting in good communication and meaningful comparisons. Just beware that if productivity measures are compared between and among organizations, the definition of staff-month must be the same. (Does everyone agree that a staff-month is 320 hours, based on four weeks comprised of five days made up of eight hours? Sometimes the answer is "no"). Also be aware that a staff-month means one person working for one month (or two people working for two weeks each or some other combination).

One of our main topics in this section is the effort-schedule-cost estimating tool, COCOMO (COnstructive COst MOdel), which assumes that there are 19 productive staff-days per staff-month and 152 staff-hours per staff-month. These figures are arrived at by allowing for the average number of vacation days and holidays in the U.S. - they would need to be customized for other countries.

In the words of Dr. Dennis Frailey, "If you measure effort consistently, you can understand what it costs, compare different projects, and predict future performance". Like lines of code, there are many ways to measure effort and many arguments why each is good or bad. You cannot make meaningful evaluations if each project measures effort differently. As listed by Dr. Frailey, typical inputs to effort estimate contain:

●   Tasks to be performed (WBS)
 
    - Software development tasks (design, code, test)
    - Additional development tasks (requirements, system)
    - Support tasks (CM, QA, management)
    - Tasks requiring additional labor (documents, etc.)

●   Additional dollar costs (travel, equipment, etc.)
●   Size estimate for software
●   Historical data on effort and productivity
●   High-level schedule
●   Process and methods
●   Programming language
●   Operating system for target system
●   Tools to be used
●   Staff experience level

Simple effort calculation is based on historical data: Size x Historical Productivity = Effort

No matter what unit is measured, reliance on good historical data is the best way to achieve accuracy.

Assume that historical data showed the following productivity:     



Thus, if new software is estimated to be 8,000 SLOC, then

       If it is complex, it should take 2,000 staff-days.
       If it is simple, it should take 1,000 staff-days.

Typical values for productivity rates are:

   ●   50 - 300 SLOC/month (2 - 15 SLOC/day) for high-order language
   ●   60 - 500 SLOC/month for assembly language

Lower numbers are for government projects with very serious restrictions, such as embedded real-time systems with life-critical safety characteristics. Higher numbers are for commercial applications with few restrictions. Even higher numbers can be obtained if you use 4GLs, high levels of reuse, and so on.

Here's an example:

The effort for complicated software differs from 2 to 8 SLOC per staff-day, with a mean of 5 SLOC per staff-day. In this case, the expected effort for a 5,000 SLOC program might be 1,000 staff-days. But it could be as high as 2,500 staff-days or as low as 625 staff-days.

Use of different methods and re-estimations are the best hedge against project risk linked with inaccurate (generally optimistic) estimates. The objective, as shown in Figure (a), is to match what is attainable with what is desirable.
The Estimating Paradigm

The major challenge in software development, illustrated in Figures (a) and (b), is to deliver a fully functional, high-quality product on time within budget using forecasted assets.

The Estimating Paradigm as a Box


Tags

software estimation, productivity measures, software development
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus