Reuse

Among the issues cited in the Defense Science Board report is insufficient focus on design for reusability. The matter of software reuse, however, con stitutes a significant trend in software development. The basic notion is that many software modules (builds, configuration items, etc.) whose performance has been verified can be reused in at least two contexts:

1. Within a company, utilizing the best software it has developed

2. In a government repository of ''certified'' software that can be accessed by persons and organizations that have approved reasons to have such access

There are, however, a large number of issues that surround the matter of reuse of software. A Deputy Assistant Secretary of the Air Force, in 1993, distributed a memorandum [12.42] that set forth a software reuse incentive policy. Some of the provisions of that memorandum are listed as follows:

• We should consider designing all new software for reuse.

• Every acquisition strategy panel should explore the full or partial reuse of existing software, including COTS.

• When software reuse may not be feasible, consideration should be given to the design of new software to facilitate reuse in future applications.

• We should identify several specific ''test'' programs that will require reuse and design for reuse.

A reuse education and training workshop in 1994 [12.43] had the goal of ''identifying key reuse concepts and how they can be integrated into an existing curriculum'' regarding software engineering. The following subgoals for that workshop reinforce the importance of reuse:

• Identify key software engineering assumptions and concepts relevant to reuse during the software life cycle.

• Explore how to introduce the preceding into various curricula.

• Identify the audience and roadblocks for reuse concepts.

• Compile lists of education resources and references.

There is also some activity regarding the development of a reuse capability model (RCM) [12.44]. This is a ''self-assessment and planning aid for improving an organization's reuse capability'' and is being addressed by the Software Productivity Consortium (SPC). Studies have also focused on reuse inhibitors, as well as the best of reuse practices [12.45]. Statistics regarding reuse initiatives have been cited as follows [12.46]:

• 14-68% productivity increase

• 20% reduction in customer complaints

• 25% less required time to repair and overall schedule

• 50% reduction in integration time

• 20-35% increases in quality

• 20% less training costs

Clearly, judging from these potential benefits, if organizations can make reuse work, they will increase software development productivity and make them more competitive in the marketplace.

In addition to the initiatives in the Department of Defense and its related contractors, the National Institute of Standards and Technology (NIST) has undertaken an Advanced Technology Program (ATP) in the area of ''component-based software.'' A news release from the U.S. Department of Commerce [12.47] announced the component-based software program as ''a five-year, $150 million program to develop the technologies necessary to enable systematically reusable software components.'' Selected NIST contracts under this ATP program involved:

• Automation of dependable software generation with reusable components

• Component integration: an architecture-driven approach

• Scalable business application development components and tools

• Component-based reengineering technology

From the preceding, it can be seen that there is a great deal of force behind software component reuse and considerable effort is likely to be expended to improve and refine software reuse. This author has also looked in some detail at software reuse and has suggested a reengineered software acquisition process that involves the reuse of entire developer off-the-shelf systems [12.48].

12.3.4 Development Methods

The Defense Science Board report strongly recommends that software be developed more in accordance with commercial practices. This also implies the use of commercial development methods, at least with respect to the use of commercial standards and specifications.

Returning also to Chapter 10, we see the suggestion in Military Standard 498 that there are three well-defined development strategies: (1) grand design, (2) incremental, and (3) evolutionary. The bottom line is that the latter two are preferred approaches, depending on the circumstances. We also note the trend in the direction of evolutionary acquisition of systems (see Section 12.2.9).

A more complete array of software development methods was examined by the Air Force's Software Technology Support Center in Ogden, Utah [12.49], namely:

• Software Development Models: —Waterfall

—Incremental —Spiral

• Software Development Techniques: —Prototype

—Cleanroom —Object-oriented

Strengths and weaknesses of these various approaches were explicitly cited. It was also indicated that the evolutionary approach was not considered, due to the variation in its meaning in the literature.

By noting the preceding, as well as other investigations of alternative development approaches, it is seen that the situation is in a state of flux, with new ideas and variations on a theme being proposed and analyzed. This investigatory trend will continue as we try to find a process that has the demonstrable productivity increases that we seek. The reader with a special interest in these alternatives that have not been discussed here (e.g., clean-room, object-oriented) is encouraged to examine the extensive literature on these subjects.

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


Post a comment