Chapter 1 introduced Boehm's top 10 software metrics [Boehm, 1987] as an objective presentation of the current state of the software management practice. That framework can be used to summarize some of the important themes in an economic context and speculate on how a modern software management framework should perform.
There are not enough project data to prove my assertions, but I believe that these expected changes provide a good description of what an organizational manager should strive for in making the transition to a modern process. (Quotations are presented in italics.)
1. Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases.
▲ Modern processes, component-based development technologies, and architecture frameworks are explicitly targeted at improving this relationship. In many domains, and for software problems local to an individual component, advances in encapsulation techniques should reduce the impact on resources significantly, perhaps by an order of magnitude. Nevertheless, an architecture-first approach will likely yield tenfold to hundredfold improvements in the resolution of architectural errors. Consequently, the iterative process places a huge premium on early architecture insight and risk-confronting activities.
2. You can compress software development schedules 25% of nominal, but no more.
a This metric should remain valid for the engineering stage of the life cycle, when the intellectual content of the system is evolved. However, if the engineering stage is successful at achieving a consistent baseline—including architecture, construction plans, and requirements—schedule compression in the production stage should be more flexible. Whether a line-of-business organization is amortizing the engineering stage across multiple projects or a project organization is amortizing the engineering stage across multiple increments, there should be much more opportunity for concurrent development.
3. For every $ 1 you spend on development, you will spend $2 on maintenance.
a It is difficult to generalize about this metric, because there are many different maintenance models. The comparison of absolute numbers makes little sense except for one-of-a-kind projects. A better way to measure this ratio would be the productivity rates between development and maintenance. (Appendix C describes this maintainability measurement.) One interesting aspect of iterative development is that the line between development and maintenance has become much fuzzier. A mature iterative process and a good architecture can reduce scrap and rework levels considerably. Given the overall homogenization of development and maintenance activities, my gut tells me that this metric should change to a one-for-one relationship, where development productivity will be similar to maintenance productivity.
4. Software development and maintenance costs are primarily a function of the number of source lines of code.
▲ This metric says that the size of the product is the primary cost driver, and the fundamental unit of size is a line of code. While this was obvious in previous generations of software technology, it is becoming much less obvious in today's component-based technologies. Commercial components, reuse, and automatic code generators can seriously pollute the meaning of a source line of code. Construction costs will still be driven by the complexity of the bill of materials. The use of more components, more types of components, more sources of components, and more custom components will necessitate more integration labor and will drive up costs. The use of fewer components, fewer types, fewer sources, and more industrial-strength tooling will drive down costs. Unfortunately, the component industry is still too immature to agree on standards for a bill of materials that could improve the fidelity of its cost estimations. Therefore, the next-generation cost models should become less sensitive to the number of source lines and more sensitive to the discrete numbers of components and their ease of integration.
5. Variations among people account for the biggest differences in software productivity.
▲ For any engineering venture in which intellectual property is the real product, the dominant productivity factors will be personnel skills, teamwork, and motivations. To the extent possible, a modern process encapsulates the requirements for high-leverage people in the engineering stage, when the team is relatively small. The production stage, when teams typically are much larger, should then operate with far less dependency on scarce expertise.
6. The overall ratio of software to hardware costs is still growing. In 1955, it was 15:85; in 1985, 85:15.
▲ I'm not sure what this metric looks like today. The popularity of the personal computer and the differences in post-1985 versus pre-1985 software costs, particularly personal computer software tools, have undoubtedly changed the relationship. The main impact of this metric on software economics is that hardware continues to get cheaper. Processing cycles, storage, and network bandwidth continue to offer new opportunities for automation. Consequently, software environments are playing a much more important role. From a modern process perspective, I can see the environment doing much more of the bookkeeping and analysis activities that were previously done by humans. Configuration control and quality assurance analyses are already largely automated, and the next frontier is automated production and automated testing.
7. Only about 15% of software development effort is devoted to programming.
a In the past 10 years there has been a noticeable shift away from investments in languages and compilers, Java and Ada 95 notwithstanding. Modern technology investments have transitioned into process maturity (for example, the SEI CMM), visual modeling (such as UML), automated software quality (such as test automation), components (such as ActiveX, Java, and CORBA), configuration management, metrics, and other aspects of software engineering. The amount of programming that goes on in a software development project is still roughly 15%. The difference is that modern projects are programming at a much higher level of abstraction. An average staff-month of programming produced perhaps 200 machine instructions in the 1960s and 1,000 machine instructions in the 1970s and 1980s. Programmer productivity in the 1990s can produce tens of thousands of machine instructions in a single month, even though only a few hundred human-generated source lines may be produced.
8. Software systems and products typically cost 3 times as much per SLOC as individual software programs. Software-system products (i.e., system of systems) cost 9 times as much.
a This diseconomy of scale should be greatly relieved with a modern process and modern technologies. Under certain circumstances—such as a software line of business producing discrete, customer-specific software systems with a common architecture, common environment, and common process—an economy of scale is achievable.
9. Walkthroughs catch 60% of the errors.
a I have emphasized the need for this metric to be banished from the top 10. Human inspections and walkthroughs will not expose the critical issues; they will only help resolve them. This metric should be replaced by the following: While the environment catches most of the first-level inconsistencies and errors, the really important architectural issues can be exposed only through demonstration and early testing and resolved through human scrutiny.
10. 80% of the contribution comes from 20% of the contributors.
a This relationship is timeless and constitutes the background philosophy to be applied throughout the planning and conduct of a modern software management process.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.