Jacob L. Cybulski (University of Melbourne)
Jeffrey C. Allen (University of Maine)
Anthony Kram (Motorola)
Ralph D. (Butch) Neal (NASA Software Research Lab)
Our group worked on the identification, characterization, and effective reuse of software artifacts resulting from the earliest stages of the software development life cycle, i.e., software conception, requirement analysis, feasibility study, specification, and architectural and detailed design.
We established that reuse of early life cycle products is beneficial to software development projects. Early development stages constitute a major part of development effort, hence, reuse of software products in these development stages should lead to significant savings and increased productivity. This benefit is amplified by the fact that successful reuse of software products upstream in the development cycle leads to the subsequent reuse of the downstream products that were derived from those early artifacts. Hence, we considered nearly one hundred early artifact types, we classified them, and we compared their main features. We also suggested the methods for processing of these artifacts when engaged in different reuse activities, e.g.:
In our comparison, the majority of considered artifacts had a significant bearing on the software project, e.g., requirement specifications, designs or test plans. At the same time, we also looked at the possibility of reusing artifacts resulting from those business activities leading to the conception of a software project. Frequently, such artifacts only have marginal impact on any particular software project, but on the other hand, they determine the direction of all projects undertaken by an organization. Here we included such artifact types as organizational mission statements, policy documents, information system plans or company budgets. Some of these business artifacts are highly reusable from one project to the next, e.g., contracts or tender documents. Others have no significant reuse value, e.g., forecasts or requests for project proposals, both of which are either too specific to the companys goals or the goals of the undertaken project. The same applies to the artifacts produced downstream in the software development life cycle. The best potential for reuse appears to be offered by artifacts in the mid-stream of the development process, i.e., specification and design artifacts. On the other hand, artifacts that are specific to an individual project or one of its components are not deemed as highly reusable, e.g., design constraints, prototypes or integration plans. Artifacts that are created in an ad-hoc, opportunistic fashion are usually not reusable at all, e.g., minutes of meetings, memoranda or logs of electronic discussions. Such documents, however, are being preserved to allow full traceability of design and implementation concepts.
We also came to the conclusion that early reuse is very difficult in practice, as there are no readily available software products to facilitate this process. Therefore, we reviewed numerous methods and techniques that could be utilized by tool builders in the construction of new software development environments that would be capable of assisting analysts, designers, architects and programmers in effectively reusing the results of the initial life cycle activities.
One of the most serious problems in dealing with early artifacts is their insufficient formality, lack of structure, and incompleteness. Project proposals, tenders, developmental plans, or requirement documents are commonly expressed in plain natural language (such as English). Other project information may also be contained in photographs, pictures, charts, audiocassettes, and videotapes. The computer representation and processing of information in such media is very difficult and the subsequent reuse of this information is thus a challenge.
Nonetheless, there are numerous methods and techniques from a variety of different computing disciplines that could significantly enhance the reusability of early life cycle products. For instance, we could rely on some well-known techniques used by widely available software tools to process some types of ill-structured and informal artifacts. Such tools include text editors and word processors, diagram and resource editors, parsers, audio and video capture systems, multimedia tools, browsers, full-document and thumbnail previewers, smart menus, intelligent assistants, etc.
Textual artifacts will greatly benefit from more general representation schemes that are more suitable for reuse, e.g., master documents, outlines, templates and forms. Representation, classification and retrieval of such unwieldy texts can be further facilitated by techniques drawn from information retrieval, natural language processing, hypertext, and intelligent decision support systems. Glossaries, completion menus, and macros may further assist in the creation of new documents. Formal texts can be dealt with in much the same way as informal documents. The main advantage of formality is the possibility of a full semantic representation of all concepts contained in a document.
Reuse of graphics, especially those in a bitmap format, is equally difficult. Hence, artifact classification, search and selection may rely on artifact annotations that can be dealt with using common text processing tools. Design diagrams, on the other hand, have a well-defined structure, notation and representation that can utilize existing data dictionary and CASE technology support.
The last group of artifacts we considered were processes. Any process is difficult to reuse unless its characteristics are captured in a formalism that can subsequently be understood easily and that admits further computer processing. Prototypes, design patterns and development processes must, then, be described in a form useful for further processing and reuse. Here we considered the use of action patterns, scenarios, traces, and macros.
Our conclusions are very optimistic. We believe that despite the great variety of artifact types used in the preliminary stages of software development, and despite many problems with artifact structure, formality and completeness, there exist widely available techniques that could assist tool builders in the construction of new, reuse-aware development environments. We also feel very strongly that the next generation of reuse tools, especially those intended for use with early life cycle artifacts, needs to have a much stronger emphasis on the reuser rather than on the reusable artifact, as is common practice today.
Reusability of early software artifacts is a new research direction for the reuse community. Our working group members were happy to be the trailblazers on this new path. We believe, however, that there is much more effort required to lay further grounds for conceiving, refining and implementing new techniques, methods and tools applicable to the task of reusing early life cycle artifacts. Future WISR workshops may assist us in reaching this goal.