![[Copyright 1995 Web Publishing Inc.]](/sunworldonline/icons/b-copyright95.gif){kind=icon}
By Brian Fromme
Despite prevailing beliefs fortified by news accounts like the baggage-systems debacle at the new Denver airport, you really can get a handle on how much software development costs. There are ways to evaluate and control some of the less-tangible costs. Software development managers simply need to focus attention on four factors: people, management, tools, and processes. Once you do, you may be pleasantly surprised to find there's room for savings.
Of course, there are a variety of other corporate costs related to development efforts -- equipment, office space, and staff training, for instance. But all of these are routinely recorded and analyzed. You need to do the same in your software development efforts, particularly with the help of a configuration management (CM) system.
The people make the place
Most companies spend the majority of their cash resources on people. Salaries make up the biggest chunk of cost; benefits and support aren't far behind. This makes perfect sense. Without talent, creativity, and determination, you can't outrun the competition. So scrutinize, but don't do a full-frontal assault on your salary line when you're looking to hire or trim the budget. Good people expect to be rewarded with good pay.
At the same time, focus on other ways to keep your software developers well fed and happy. Though they come in all forms, they share common threads, principally the passion and rugged individualism needed to create something from nothing and make it work. Salary and benefits aside, if you also can buy developers' loyalty and hard work with flexible hours and dress codes, why not do it? A main point here, too, is that as much as we want to make software development a science, it is still more an art; you must find ways to keep creativity alive in your teams.
Fundamental skills for software development managers include the ability to communicate well, to set clear goals, and to delegate responsibility. I believe companies ask too much of their first-level software managers, expecting them also to be technical, business savvy, people skilled, and customer aware. These are lofty goals for a manager, but they are not all necessary. Their main task is to keep the project on schedule, which requires good people skills.
Good management skills rarely come free. They are developed through a combination of training and experience. The effect management has on the motivation, personal productivity, and morale of their software development teams is difficult to measure, but clearly all affect the cost of a software project. Efficient smaller companies usually have first- and second-level managers who have been trained at larger firms.
Software metrics
How do you calculate and control software development costs? How can you understand the results if certain decisions are made, such as if you cut out the enhancement that improves performance in the software? Would that save money at the end of the project, or would it cost more to revise the code?
The software development guru Tom DeMarco often defended his CASE methodologies with the motto, "You can't control what you can't measure." Software metrics is a standard, reproducible way of measuring attributes of the software development process, including software system and project information, such as code or project size, number of defects, risk, and time.
Some attributes are easy to measure, such as project or code size; some are not, such as risk. For consistency, you must precisely define and adhere to your own definition for each attribute so their metrics are meaningful and comparable over time. You might define project size as the total number of software developers, while others might define it as the number of individuals who are involved at some point in the project. Companies need to develop not only what they intend to measure, but how they intend to measure it, and most importantly, how they intend to use the results.
Measuring the costs and effects of testing pre-release versions of software is a good example. You must have some predetermined expectation for the interim release's level of quality. In this example, let's define it as the user's ability to operate the software's main functions without crashing. The next step is to measure when you actually attain that level of quality. One way to estimate it is to measure daily the number, in 1,024 (K) units, of real source code statements (not comments), also known as KNCSS.
As the release date approaches, you will find the KNCSS number leveling off because no new code is being added to the project; only bug fixes are changing the code. As the number of changes decreases, the stability and quality level should increase, assuming people are actually testing and fixing defects. The KNCSS metric will teach you how fast your team can work. And you'll be able to estimate to within a few days when future software releases can be prepared.
This use of metrics to facilitate better planning can save you money, too, by giving you control over where your engineering time is spent, for example. To carry our example farther, how often have you been confronted with the choice between putting out an interim release and forging ahead on new development? Now you have a tool to help you clearly analyze the cost of choosing between these options.
Tools and processes
It is the combination of metrics and the use of specific development tools and environments that can make a company realize the value of their investment in software development tools. Normally, businesses purchase tools to solve very specific problems. For example, you need to manage the volume of source code your developers create. You will find that you might spend upwards of $5,000 per developer for a solution. When you combine this purchase with the cost of other development tools, you begin to see the advantage of integrated environments to help make each of your tools work better together. This ups the per-developer cost, but there may be other benefits not possible with standalone tools. While it may seem difficult to determine the cost
benefits of integration versus standalone toolsets, most managers intuitively sense the former approach will save the company development time.
What you need are metrics: actually measure the cost of doing certain tasks with different tools and technologies. For example, when creating an interim release, you must complete a number of steps before it is ready for shipment. Without an automated metrics collections system, developers must spend their time evaluating those steps and determining whether the code has become stable enough to release. Many such tasks can take anywhere from one day to a week -- developers' time away from developing software.
Alternatively, you could install automated metrics collection on the source code. For instance, you might collect the McCabe Cyclomatic Measure, a measure of the number of decision points in source code, and also collect the daily number of KNCSS. Both of these are based on what the development team checks in your CM system. Two popular metrics tools are McCabe Tool Set from McCabe & Associates (Columbia, MD) and Hindsight from ASA (Santa Clara, CA). With an automated system, the software manager simply reviews these metrics over time, perhaps for a week, to determine whether the code is stable for release. The information is basically the same as that which had to be manually collected and analyzed by your developers in the nonmetrics model. Clearly the benefits of automated metrics collection overcome the costs.
Integration is better metrics
As more of your software development tools become integrated, you can move your attention from source code measurements to metrics of your company's software development processes. You already have many processes by which your software teams create and maintain code. You may not have written them all down, but they are used every day. It would make sense to understand the use of tools in your software development environment and to collect metrics on the current use versus possible future uses.
Today, there are no standard metrics frameworks for making these environment calculations, although SparcWorks from SunSoft (Mountain View, CA) and SoftBench from HP (Fort Collins, CO) have an inter-tool communications infrastructure that can help you build your own. There is much that you can do with tools and technologies available today to automate useful metrics collection.
It's fair to say that software development costs will continue to climb while the price of the software being shipped continues to go down. To survive, software development companies must look for new and better ways to trim cost without sacrificing quality. Automated metrics is one of the best ways to achieve that goal.
About the Author
Brian Fromme is president of Fromme Custom Solutions, a software development consultancy specializing in HP systems, in Fort Collins, CO. He can be reached at brian.fromme@advanced.com.
If you have problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/asm-03-1995/asm-03-swtools.html.
Last updated: 1 March 1995.