Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Generating Code Metrics and Estimating Costs with Xcode

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.

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

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

# -*- 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
		tBuf = tInp.readlines()
	# 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)
							# 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)

# 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)

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

Table 2.

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.

Table 3.

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.

Table 4.

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.

Table 5.


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.


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 [email protected].

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.