The initial release of the Software Technology Roadmap is a prototype to provide initial capability, show the feasibility, and examine the usability of such a document. This prototype generally emphasizes software technology¹ of importance to the C4I (command, control, communications, computers, and intelligence) domain. This emphasis on C4I neither narrowed nor broadened the scope of the document; it did, however, provide guidance in seeking out requirements and technologies. It served as a reminder that this work is concerned with complex, large-scale, distributed, real-time, software-intensive, embedded systems in which reliability, availability, safety, security, performance, maintainability, and cost are major concerns.

We note, however, that these characteristics are not only applicable to military command and control systems, they apply as well to commercial systems, such as financial systems for electronic commerce. Also, for a variety of reasons, commercial software will play an increasingly important role in defense systems. Thus, it is important to understand trends and opportunities in software technology -- including commercial software practice and commercially-available software components -- that may affect C4I systems.

Vision

Our long-term goal is to create a continuously-updated, community "owned," widely-available reference document that will be used as a shared knowledge base. This shared knowledge base will assist in the tradeoff and selection of appropriate technologies to meet system goals, plan technology insertions, and possibly establish research agendas. While we use the term "document," we anticipate that this product will take many shapes, including a Web-based, paper-based, or CD-ROM based reference.

With the release of this document we are seeking comment and feedback from the software community. We will use this feedback as we plan an ongoing effort to expand and evolve this document to include additional software technology descriptions. The Feedback Section provides vehicles by which readers can contribute to the further development of this effort.

Goal

The document is intended to be a guide to specific software technologies of interest to those building or maintaining systems, especially those in command, control, and/or communications applications. The document has many goals:

• to provide common ground by which contractors, commercial companies, researchers, government program offices, and software maintenance organizations may assess technologies

• to serve as Cliff's Notes for specific software technologies; to encapsulate a large amount of information so that the reader can rapidly read the basics and make a preliminary decision on whether further research is warranted

• to achieve objectivity, balance,² and a quantitative focus, bringing out both shortcomings as well as advantages, and provide insight into areas such as costs, risks, quality, ease of use, security, and alternatives

• to layer information so that readers can find subordinate technology descriptions (where they exist) to learn more about the topic(s) of specific interest, and to provide references to sources of more detailed technical information, to include usage and experience

Limitations/Caveats

While the document provides balanced coverage of a wide scope of technologies, there are certain constraints on the content of the document:

• Coverage, accuracy and evolution. Given the number of software technologies and the time available for this first release, this document covers a relatively small set of technologies. As such, there are many topics that have not been addressed; we plan to address these in subsequent versions. This document is, by nature, a snapshot that is based on what is known at the time of release. We have diligently worked to make the document as accurate as possible. Each technology description is rated as to its completeness. Subsequent versions will include corrections and updates based on community feedback.

• Not prescriptive. This document is not prescriptive; it does not make recommendations, establish priorities, or dictate a specific path/approach.³ The reader must make decisions about whether a technology is appropriate for a specific engineering and programmatic context depending on the planned intended use, its maturity, other technologies that will be used, the specific time frame envisioned, and funding constraints.

  For example, a specific technology may not be applicable to a particular program because the need is current and evaluations indicate that the technology is immature under certain circumstances. However, given a program that initiates in 3-5 years, the same technology may be an appropriate choice assuming that the areas of immaturity will be corrected by then (and, if necessary, directed action to ensure the maturation or to remedy deficiencies).

• Not a product reference. This document is not a survey or catalog of products. There are many reasons for this, including the rapid proliferation of products, the need to continually assess product capabilities, questions of perceived endorsement, and the fact that products are almost always a collection of technologies. It is up to the reader to decide which products are appropriate for their context. DataPro and Auerbach would likely be better sources of product-specific information.

• Not an endorsement. Inclusion or exclusion of a topic in this document does not constitute an endorsement of any type, or selection as any sort of "best technical practice." Judgments such as these must be made by the readers based on their contexts; our goal is to provide the balanced information to enable those judgments.

• Not a focused analysis of specific technical areas. Various sources such as Ovum, Ltd. and The Standish Group offer reports on a subscription or one-time basis on topics such as workflow, open systems, and software project failure analyses, and may also produce specialized analyses and reporting on a consulting basis.

Footnotes

¹ This spectrum of technologies includes past, present, under-used, and emerging technologies.

² As an example of balanced coverage, let's briefly look at information hiding of object-oriented inheritance, which reduces the amount of information a software developer must understand. Substantial evidence exists that such object-oriented technologies significantly increase productivity in the early stages of software development; however, there is also growing recognition that these same technologies may also encourage larger and less efficient implementations, extend development schedules beyond the "90% complete" point, undermine maintainability, and preclude error free implementations.

³ Similar to a roadmap for highways, the review prescribes neither the destination nor the most appropriate route. Instead, it identifies a variety of alternative routes that are available, gives an indication of their condition, and describes where they may lead. Specific DoD applications must chart their own route through the technological advances.