Costs by COCOMO
Another useful cost metric is the COCOMO model (short for COnstructive COst MOdel). This metric was first introduced by Barry Boehm in 1981 in his book Software Engineering Economics. It assumes that project growth follows a waterfall model.
The three basic equations of the COCOMO model are shown in Figure 4.
Equation A estimates the minimum amount of effort Edev needed to develop the project. It uses SLOC to base its estimate. Equation B estimates the total time tdev needed to complete the project. This estimate includes time spent on design, development and testing. Note this equation based its estimate on Edev. Lastly, equation C computes the minimum staff size nstaff.
Both equations A and B give their results in person-months. Plus, equation A expects SLOC to be expressed in thousands of lines of effective code.
The empirical constants on equations A and B are the cost factors. Their values vary with respect to the project type. COCOMO recognizes three possible types (Table 1).
The organic project is noted for its small well-skilled team and flexible design specs. Its end products are usually meant for internal use or for demo purposes.
The semi-detached project, however, is the typical commercial project. It undergoes the familiar build phases of alpha, beta, and final. The team itself is usually large and divided into distinct groups (designers, coders, and testers), with members having variable skill levels. Design specs are well-defined, with strong emphasis on user interaction and fault tolerance. On the other hand, those specs are subject to change based on user feedback. End products are always slated for public release.
The embedded project also undergoes the same build phases. Its specs are sharply defined, with restrictions in hardware and software resources. Its team are highly skilled, with some members having specialized skills. End products are also slated for public release. But they are rarely, if ever, upgradable by the users.
Listing Three is an Xcode utility script implementing a basic COCOMO metric. Here again, the script gets the active project file as input. It uses the same isProject() routine to work out the project directory (lines 68-72). Then the script collects those files with a '.m' and '.h' suffix (lines 75-85). And it uses the getELOC() routine to tally the effective lines of each file (lines 88-90) into the variable tSiz.
Next, the script sets the cost factors for an organic project. It divides the tSiz value by 1000, and calculates the project's effort, time and staff size. Finally, it prints the metric results to the user (lines 94-110).
Listing Three
#!/usr/bin/python
# -*- coding: utf-8 -*-
# import the following module
import os, sys
import string
import math
# Count the number of effective source lines
def getELOC(aPth):
# open an input stream
tInp = open(aPth, 'r')
# create the parse buffer
try:
tBuf = tInp.readlines()
finally:
tInp.close()
# start parsing the buffer
tLOC = 0
tBgn = False
for tLin in tBuf:
# filter out whitespaces
tTst = tLin.strip()
tLen = len(tTst)
if (tLen > 0):
# filter out inline comments
tMrk = tTst.find("//", 0)
if (tMrk != 0):
tMrk = tTst.find("/*", 0)
tMrk = tMrk + tTst.find("*/", 0)
if (tMrk <= 0):
# filter out import statements
tMrk = tTst.find("#import", 0)
if (tMrk != 0):
# filter out block comments
if (tBgn):
# check for a closing token
tMrk = tTst.find("*/", 0)
tBgn = (tMrk == -1)
else:
# check for an opening token
tMrk = tTst.find("/*", 0)
tBgn = (tMrk >= 0)
if (not tBgn):
tLOC += 1
# return the count results
return (tLOC)
# Is this the main project directory?
def isProject(aPth):
# get a list of files
tLst = os.listdir(aPth)
# parse the list
tChk = False
for tNom in tLst:
tChk = tChk or (tNom.find(".xcodeproj") > 0)
# return the check result
return (tChk)
# MAIN SCRIPT BODY
# locate the project directory
tPrj = '%%%{PBXFilePath}%%%'
tChk = False
while not(tChk):
tPrj = os.path.dirname(tPrj)
tChk = isProject(tPrj)
# parse the project directory
tSrc = []
for tRef, tDir, tLst in os.walk(tPrj):
# parse the project files
for tNom in tLst:
tExt = string.split(tNom, ".")
if (len(tExt) > 1):
tExt = tExt[1]
tChk = (tExt == "m") or (tExt == "h")
if (tChk):
tPth = os.path.join(tRef, tNom)
tSrc.append(tPth)
# calculate the project size
tSiz = 0
for tPth in tSrc:
tSiz += getELOC(tPth)
# estimate the project costs
# -- COCOMO:empirical constants:organic
kA = 2.4
kB = 1.05
kC = 2.5
kD = 0.38
# -- COCOMO:development:effort
tSiz /= 1000.0
tTe = kA * (tSiz ** kB)
print "Estimated development effort: %.3f months" % tTe
# -- COCOMO:development:time
tTd = kC * (tTe ** kD)
print "Estimated development time: %.3f months" % tTd
# -- COCOMO:development:staff:size
tNd = math.ceil(tTe / tTd)
print "Estimated staff size: %.3f units" % tNd
Rating a Cocoa Project
Now let us these two cost metrics to analyze two Xcode projects. One project compiles into a Cocoa binary, the other into an iOS binary. Both perform the same service, which is to convert a temperature reading from one unit to another. Both do not save data to a file, nor do they spawn any network tasks.
Our first project, "TemperatureConverter," consists of four ObjC source files, four header files, and several support files. It has a single XIB bundle, which defines the main window and its eight interface widgets. It has an eLOC of 155 lines.
The project is an example of an organic project. It is meant as a teaching tool to showcase basic Cocoa concepts to new developers. Though it is available publicly, it is not meant for commercial use. A copy of the project is available from the Apple website.
Table 2 shows how the Putnam script rates the project. Here, the metric uses three values for tproj: 3 months (0.25 years), 6 months (0.5 years) and 12 months (1 year). So for a time-to-market of 6 months, the project may need a total effort of 0.186 years (about 68 days) to complete. Developing it may take about 0.073 years (27 days).
Note how the amount of effort decreases with each increase in tproj. From 3 to 6 months, effort decreases by 93.74%. From 6 to 12 months, it decreases by 93.55%. Note also that a tproj of 3 months requires the most effort, almost 12 times more than the scheduled time. Difficulty is also quite high for that chosen time. This suggests that a time-to-market of 3 months is unrealistic.
Table 3 shows how the COCOMO script rates the same project. It shows that our organic project may take 0.339 months (about 10 days) to develop. The whole project may take 1.657 months (about 50 days) to complete, but it could be handled by a single person.
Bear in mind, of course, that these are estimates. They must be weighed against other factors like employee health, user feedback, tool stability, and so on.
Rating an iOS Project
The second project, also called "TemperatureConverter," has seven source files and six header files, plus the usual support files. It uses two XIB bundles to hold its user interfaces. But unlike its Cocoa sibling, this project updates the interface dynamically by code. The whole project has an eLOC of 227 lines.
The project is another example of an organic project. It too is meant as a teaching tool, to introduce new developers to the iOS framework. Its built binary is not intended for commercial use. A copy of this project is available from the AppsAMuck website.
Table 4 shows how the Putnam script rates this project. Here, too, there are three possible values of tproj. Both effort and difficulty decreases with each increase in tproj. Again, a tproj of 3 months seems unrealistic as it gave the worst estimates for effort and difficulty.
Now consider the tproj of 6 months and compare its estimates with those for the Cocoa project. We find that the iOS project may take more effort to complete. In this case, the project needs at least 0.584 years (213 days), the Cocoa project only 0.186 years. This suggests that an iOS project is perhaps more difficult, at least 200% more in this case.
Next, Table 5 shows how the COCOMO script rates our iOS project. Here, we see that developing the project takes about 0.506 months (15 days). Completing it may take 1.930 months (59 days). Again, the project could be managed by one person. We also find that an iOS project uses more effort and more time than its Cocoa sibling.
Conclusion
With cost metrics, we can estimate the time needed to complete a software project. We can find out how much time is spent on actual development and how many people are needed for the project. We can compare two projects of similar features in terms of difficulty.
This article explained how to implement two cost metrics as Xcode utility scripts. It showed how those scripts work against two types of Xcode projects. Again, readers are welcome to adapt these scripts for larger, more complex projects.
References
Farshad Faghih. Software Effort and Schedule Estimation. Electrical and Computer Engineering. University of Calgary. 1997.
Randall W. Jensen, Lawrence H. Putnam Sr, William Roetzheim. Software Estimation Models: Three Viewpoints [PDF]. Software Engineering Technology.
Chris Kemerer. An Empirical Validation of Software Cost Estimation Models [PDF]. Communications of the ACM. 1987 May.
NASA. "Basic COCOMO." Cost Estimating Web Site. National Aeronautics and Space Administration. 2007 May. [2011 Feb].
Mildred L. G. Shaw. "Cost and Effort Estimation." Practical Software Engineering. Department of Computer Science. University of Calgary. 1996 Jan [2010 Dec].
Cruz is a freelance engineering writer who resides in North Vancouver, British Columbia. He can be contacted at anarakisware@gmail.com.
