James W. Moore

The guide to the Software Engineering Body of Knowledge

Reporting on the SWEBOK project, the authors-who represent the projects editorial team-discuss the three-phase plan to characterize a body of knowledge, a vital step toward developing software engineering as a profession.

Reuse library interoperability and the World Wide Web

The Reuse Library Interoperability Group (RIG) was formed in 1991 for the purpose of drafting standards enabling the interoperation of software reuse libraries. At that time, prevailing wisdom among many reuse library operators was that each should be a stand-alone operation. Many operators saw a need for only a single library, their own, and most strived to provide the most general possible services to appeal to a broad community of users. The ASSET program, initiated by the Advanced Research Project Agency STARS program, was the first to make the claim that it should properly be one part of a network of interoperating libraries. Shortly thereafter, the RIG was formed, initially as a collaboration between the STARS program and the Air Force RAASP program, but growing within six months to a self-sustaining cooperation among twelve chartering organizations. The RIG has grown to include over twenty members from government, industry, and academic reuse libraries. It has produced a number of technical reports and proposed interoperability standards, some of which are described in this report.

An integrated collection of software engineering standards

The IEEE Software Engineering Standards Committee has taken deliberate steps to unify and integrate its collection of software engineering standards. Encouraging results are apparent in its latest publication, which is organized around a single architecture for the SESC collection. This article explains the principles of the SESC collection and describes our progress toward integrating the various standards within it.

The use of encryption to ensure the integrity of reusable software components

Several efforts are currently underway to foster a marketplace for reusable software components based upon interoperating electronic libraries containing managed collections of components. In such a marketplace, it is necessary for potential users to be able to verify the origin of candidate components and to assure that they have not been modified by third parties. This paper proposes a method for providing the assurance through the application of modern encryption techniques.<<ETX>>

A search for fundamental principles of software engineering

Abstract In the 50-year history of software development, various methodologies and techniques have been proposed to facilitate the development of software responsive to needs. Most have proved to be more specific to the then-current state of technology than has been understood at the time. At this time, enough examples have accumulated that we can begin to perceive underlying principles that may be fundamental, hence enduring in applicability. This paper reports the results of a recent workshop, discussing the characteristics and criteria for identifying fundamental principles and the application of those criteria to eight candidates. Recommendations for continuing work are provided.

Standardizing reuse

T he distinction between use and reuse is sometimes a subtle one. We would argue that success in society is intimately linked, in the first instance, to the ability to create products and/or services that are used. The grander success occurs when what one produces becomes a critical building block in what others create—this is reuse. The popular reuse icon (three green arrows in a cycle) is typically about decomposing natural products and incorporating them in new natural products in a cyclic way (see Figure 1). Software can, however, be arbitrarily often copied, and software reuse should lead to new products in a spiraling way (see Figure 2). More rigorously, reuse is the practice of using an asset in more than one software system. An asset is any product of the software life cycle. Reuse requires the existence of a library of assets. A reuse library is a controlled collection of assets, together with the procedures and support functions required to provide the assets for reuse. Reuse typically occurs within a domain of activity or knowledge in which applications share a set of common capabilities and data. While the terminology of assets, reuse libraries, and domains is germane to understanding the technological side of software reuse, software reuse is also about processes that

Organizational badge collecting

Whenever a Boy Scout masters a new Scouting skill, he earns a merit badge. On ceremonial occasions, he wears the badges as a visible certificate of proficiency granted by a world-class authority. Internationally, 95,000 or so organizations wear the badge of ISO 9000 [1] conformance. To them its an important accomplishment in a highly competitive marketplace. Furthermore, its just the first of a chest-full of badges that serious software developers will soon be wearing as they complete their own youthful rites of passage toward software engineering as a profession rather than an ideal.

Software reuse standards

m To explore the impact of current software standards on software reuse, we describe the analysis, findings, and recommendations of the IEEE Software Engineering Standards Committee (SESC) Reuse Planning Group. The object of the Reuse Planning Group was to define, for the SESC, a statement of direction for IEEE standards related to the analysis, design, implementation, validation, verification, documentation, and maintenance of reusable software assets as well as supporting infrastructure in the creation of new applications. We also examine the current state of software reuse standards by the following: (1) an analysis of the needs of various users of standards and a classification of the needs with respect to the type of reuse standards that might be written; (2) a set of normative documents on the subject of software reuse, identified and evaluated for the role they might play in the standardization process; (3) a program element view of the IEEE Software Engineering Standards Committee collection, into which reuse standards must fit; and (4) recommendations for standardization projects. nsertion of any new innovation by an organization requires adoption, utilization, and management of the new technology. The motive for an organization to adopt a new technology is based on expectations for achieving a set of goals. The insertion of software reuse technologies is no different from other innovations, in that they must be adopted, utilized, and managed in software product development or maintenance lifecycles. The following goals are usually stated for software reuse: (1) the organization expects product development or maintenance efforts to decrease; (2) the organization expects an increase in product quality; and (3) the organization expects a decrease in product time-to-market. Although the benefits of software reuse have been discussed in the literature for several decades, it remains an elusive goal. Successful insertion of new technology depends on both technical and nontechnical factors. It is important that both be adequately addressed. Clearly, software standards are an important technical issue, and while explicit software reuse standards do not exist, a number of current de facto and official government standards are making an impact. To explore the impact of current software standards on software reuse, we describe the analysis, findings, and recommendations of the IEEE Software Engineering Standards Committee (SESC) Reuse Planning Group. The goal of the Group was to define, for the SESC, a statement of direction for IEEE standards on the analysis, design, implementation, validation, verification, documentation, and maintenance of reusable software assets, as well as their supporting infrastructure in the creation of new applications. We examine the current state of software reuse standards by addressing the following topics: (1) the needs of various users of standards and a classification of those needs with respect to kinds of reuse standards; (2) normative documents on software reuse, identified and evaluated for their roles in standardization; (3) a “Program Element” view of the IEEE Software Engineering Standards Committee collection, into which reuse standards must fit; and (4) recommendations for standardization projects. I ✮ F E A T U R E A R T I C L E

Language-independent standards

The trend in modem information technology standardization is to write standard specifications that are independent of any particular programming language. Some believe the standardization effort is thus provided with greater leverage--a single specification can be applied, more or less mechanically, to the various programming languages in current usage. This column takes a contrarian view to question the logic behind this trend. Despite efforts to define programming languages with a broad scope of applicability, it has become clear that no single programming language will support all the needs, real or perceived, of the information technology community. At various times, pi-oponenf~ of languages such as PUI, Ada, C, and even Lisp have suggested they are adequate for nearly all information processing needs; and in all cases, the marketplace has demonstrated otherwise by economically supporting a variety of languages for different application domains. In fact, the current trend in large information system development is toward multilanguage integrations, in other words, multiple languages implementing a single system. Standards organizations have reacted to the reality of a multilingual user community by encouraging the development of standards not specified in terms of a single programming language. Policy decisions made at various levels of both the American National Standards Institute (ANSI) and the International Organization of Standards (ISO) have directed working groups to develop base specifications expressed in a languageindependent fashion, plus a number of “bindings” explaining how the services provided by a particular specification may be obtained from a particular programming language. The approach has met with some notable successes. One example is the success of the X3H2 standards committee in specifying a standard for SQL.’ When the committee was formed, implementations provided a wide variety of functionality. However, aside from the issues of behavior, the various implementations used different syntaxes to embed SQL statements directly in the source language of the application programs

Debate on software reuse libraries

Does a single, general-purpose RSL or a domain-specific RSL provide the best method to leverage knowledge and assets across a large organization? My experience indicates the need for at least three fundamentally different types of libraries: local libraries; domain specific libraries; and reference libraries. Can RSLs can effectively interoperate across organizations? There are already come examples of the effective interoperation of reuse libraries. Does an RSL require a formal classification for components stored in the library? As collections grow, users will require more assistance in locating and selecting relevant candidates, but different classification mechanisms are relevant to different types of libraries. Must an RSL provide specialized reuse support, such as user registration, version control and problem notification? There will always be a role for libraries which are operated on a pro bone basis by members of the research community or other altruistic parties. On the other hand, as reuse transitions from a technological basis to an economic basis, there will be users willing to pay for additional services and there will be vendors willing to provide them.<<ETX>>