Tools

Generating Code Metrics and Estimating Costs with Xcode

By José R.C. Cruz, November 21, 2011

A little Python enables you to generate a variety of code metrics for Xcode projects and estimate costs fairly accurately.

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

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.

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.

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.

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.

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.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!