Getting to the Goal: Setting Your Sights on Software Reuse
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When the time comes to launch a reuse initiative it's important to establish specific goals for the level of reuse you wish to achieve. Launching a reuse plan without a target reuse level is like choosing to drive a car while blindfolded: you'll get somewhere, but you're severely reducing the chances that anyone will be smiling when you arrive. And while it's important to know where you're going, if your reuse goals are to have any value at all they must be both reasonable and realistic.
What's reasonable and realistic? "It all depends," observes Hewlett Packard Software Technology Laboratory scientist Dr. Martin Griss, "on the domain, the size, distribution, and culture of the organization, the management, [and] the general process maturity."
Cutter Consortium™ consultant and author Paul Harmon offers a similar take. "It depends on the size of the application," he says. "Very simple applications that have been done with slight variations before go much faster. New, complex applications take time."
It's clear, then, that in order to set meaningful goals it is necessary to make a careful, critical assessment of the Who, What, Where, and How of your reuse plan.
Who No surprises here: there is a direct correlation between the level of reuse your initiative can achieve and the level of interest and enthusiasm maintained by those involved. But while the expertise exhibited by participating developers is of obvious importance, a significant share of the responsibility for the success of a reuse initiative is born by the executive sponsors of the reuse effort. Without their continued evangelism and patience, early efforts will fall flat, never realizing their full potential. Executive sponsors must be vocal and dynamic in their support. They must enact effective incentives and rewards for those developers who demonstrate prowess at solving development problems within their assigned roles in the reuse effort, either through their use of existing assets, or through the development of reusable assets that solve recurring problems. Above all, executive sponsors must understand both the organizational and cultural challenges that face any reuse effort, and the substantial benefits of meeting these challenges.
What Obviously, in order to reuse, there must be something to reuse. What reusable assets are at your disposal? Commercial assets are available, but that market has yet to mature. Even when the market reaches critical mass, the available assets by their very nature will be horizontal and generic, which will leave gaps in functionality must be filled with internally developed, vertical assets.
It's also important to remember than even the most comprehensive collection of highly reusable assets is of little value if developers can't find what they need when they need it. Nothing kills reuse faster than a poorly managed, inefficient repository. An easily accessed, well-managed library of reusable assets is critical to the achievement of any reuse goal.
Where In this particular case we're talking about a kind of virtual Where, that is, the application domain. Will the applications you develop be used vertically (within a specific domain), or horizontally (across several domains)? Horizontal reuse may be somewhat easier by virtue of the fact that the broader scope of horizontal solutions increases the likelihood that your developers have relevant experience. That's the upside. The downside is that horizontal, domain-independent reuse has it's limits, typically around twenty-percent of an application. Vertical reuse offers greater potential thanks to the redundancy of various inherent operations and processes. Vertical reuse will, of course, require either developers with domain-specific experience, or a significant learning curve. But the pay-off is worth the added effort. Upper limits of domain-specific reuse can reach as high as ninety percent.
How This is the big question: How will you know if you've met your target reuse level? First, let's define "reuse level" as that portion — expressed as a percentage — of the work on a specified development project that is accomplished through the use of existing software assets. Obviously some mechanism must be in place to calculate this percentage. Here again, a well-managed repository should provide this capability.
The specifics of software reuse metrics are beyond the scope of this article, but several excellent resources are available:
Metrics for Object-Oriented Reuse by Jeffrey S. Poulin, Ph. D.
Reuse Metrics Deserve a Warning Label: The Pitfalls of Measuring Software Reuse by Jeffrey S. Poulin, Ph. D.
Reuse Calculator by Jeffrey S. Poulin, Ph. D.
Familiar Metric Management — Productivity of the Reuse Organization by Lawrence H. Putnam President/CEO, QSM, Inc. & Ware Myers
Familiar Metric Management — Software Reuse by Lawrence H. Putnam & Ware Myers
Software Reuse: Metrics and Models by William Frakes & Carol Terry
Programmer Performance Measurement in a Software Reuse Context Marcus A. Rothenberger, Ph.D. & Kevin Dooley, Ph.D.
Data Collection, Metrics, and Tracking from A Framework for Software Product Line Practice — Version 3.0 by the Carnegie Mellon Software Engineering Institute
Keep in mind that while the percentage of reuse is an important and useful metric, in and of itself it does not express the value of reuse. Achieving a set percentage of reuse is a goal, but it isn't the goal.
Setting Your Sights Having considered the various aforementioned aspects of your reuse effort, the question remains: What's a reasonable and realistic goal for a ground-floor reuse effort?
"I normally set fifteen percent as a goal," reports Lockheed Martin systems analyst Dr. Jeffrey Poulin, author of Measuring Software Reuse. "The more a company wishes to promote reuse through reuse planning and domain-specific libraries, the closer they can get to higher levels, like eighty percent."
Dr. Martin Griss, co-author of Software Reuse suggests a similar albeit more reserved projection. "Sometimes, when pushed, I will say ten to fifteen percent."
For a reuse pilot project, consultant William Councill, co-author of Component-Based Software Engineering, agrees with Dr. Griss. "No more than ten to fifteen percent of software component assets will be used. In many settings, I cannot imagine that software component reuse would reach even ten percent."
Dr. Will Tracz, also of Lockheed Martin, and author of Confessions of a Used Program Salesman, is more optimistic. "The first twenty-five percent is easy," reports Dr. Tracz. "The next twenty percent is one and a half times as hard. Then you hit the wall and the rest is at least three times as costly to get."
Of course, your mileage may vary, but even the modest goals suggested by these experts translate into a substantial return on investment.
The Goal of Reuse Reuse is a powerful tool in service to the bottom line, and as well-managed reuse initiatives evolve, they become ever more efficient in fulfilling that role. So while setting and meeting goals for the level of reuse is an essential part of your early reuse strategy, it is a goal within a goal, a stepping stone. The final objective, the real goal of reuse, is to deliver the increasingly important strategic business advantage inherent in higher quality software, developed faster, at reduced cost.