Reusable Components Of A System Project Management

Reusing existing components and building reusable components have been natural software engineering activities since the earliest improvements in programming languages. Software design methods have always dealt implicitly with reuse in order to minimize development costs while achieving all the other required attributes of performance, feature set, and quality. Reuse achieves undeserved importance within the software engineering community only because we don't do it as well as we should. In all other engineering and manufacturing disciplines, reuse is more or less an underlying assumption, not some necessary technological breakthrough. I try to treat reuse as a mundane part of achieving a return on investment. Common architectures, common processes, precedent experience, and common environments are all instances of reuse.

One of the biggest obstacles to reuse has been fragmentation of languages, operating systems, notations, machine architectures, tools, and even "standards." As a counterexample, the level of reuse made possible by Microsoft's success on the PC platform has been immense.

In general, things get reused for economic reasons. Therefore, the key metric in identifying whether a component (or a class of components, or a commercial product) is truly reusable is to see whether some organization is making money on it. Without this economic motive, reusable components are rare. Beware of "open" reuse libraries sponsored by nonprofit organizations. They lack economic motivation, trustworthiness, and accountability for quality, support, improvement, and usability. Most truly reusable components of value are transitioned to commercial products supported by organizations with the following characteristics:

• They have an economic motivation for continued support.

• They take ownership of improving product quality, adding new features, and transitioning to new technologies.

• They have a sufficiently broad customer base to be profitable.

The cost of developing a reusable component is not trivial. Figure 3-1 examines the economic trade-offs. The steep initial curve illustrates the economic obstacle to developing reusable components. It is difficult to develop a convincing business case for development unless the objective is to support reuse across many projects. Positive business cases rarely occur in software development organizations that are not focused on selling commercial components as their main line of business. Most organizations cannot compete economically with established commercial organizations whose investments are broadly amortized across the user base. To succeed in the marketplace for commercial components, an organization needs three enduring elements: a development group, a support infrastructure, and a product-oriented sales and mar-

Many-project solution: Operating with high value per unit investment, typical of commercial products ^

Many-project solution: Operating with high value per unit investment, typical of commercial products ^

Number of Projects Using Reusable Components Figure 3-1. Cost and schedule investments necessary to achieve reusable components

keting infrastructure. Another consideration is that the complexity and cost of developing reusable components are often naively underestimated.

Although the value of reuse can be immense, I have never been a fan of identifying reuse as a separate "technology." Reuse is an important discipline that has an impact on the efficiency of all workflows and the quality of most artifacts. I think of it as a synonym for return on investment, which should be a consideration in almost every activity and decision. There have been very few success stories in software component reuse except for commercial products such as operating systems, database management systems, middleware, networking, GUI builders, and office applications. On the other hand, every software success story has probably exploited some key avenues of reuse (without calling it that) to achieve results efficiently.

3.1.4 Commercial Components

A common approach being pursued today in many domains is to maximize integration of commercial components and off-the-shelf products. While the use of commercial components is certainly desirable as a means of reducing custom development, it has not proven to be straightforward in practice. Table 3-3 identifies some of the advantages and disadvantages of using commercial components. (These trade-offs are particularly acute in mission-critical domains.) Because the trade-offs frequently have global effects on quality, cost, and supportability, the selection of commercial components over development of custom components has significant impact on a project's overall architecture. The paramount message here (discussed further in Chapter 7) is that these decisions must be made early in the life cycle as part of the architectural design.

Table 3-3. Advantages and disadvantages of commercial components versus custom software

approach

advantages

disadvantages

Commercial

Predictable license costs

Frequent upgrades

components

Broadly used, mature technology

Up-front license fees

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

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.

Get My Free Ebook


Responses

  • Fiorella
    What are the" instances of reuse" in SPM?
    3 years ago
  • meneaduc goodchild
    Why reuse software components?
    5 months ago

Post a comment