Appendix A: Background of the STR

The Air Force acquisition community tasked the Software Engineering Institute (SEI) to create a reference document that would provide the Air Force with a better understanding of software technologies. This knowledge will allow the Air Force to systematically plan the research and development (R&D) and technology insertion required to meet current and future Air Force needs, from the upgrade and evolution of current systems to the development of new systems.

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 Cliffs 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

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

• 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.
• 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." Judgements such as these must be made by the readers based on their contexts; our goal is to provide the balanced information to enable those judgements.
• Not a market forecasting tool. While the technology descriptions may project the effect of a technology and discuss trends, more complete technology market analysis and forecast reports are produced by organizations such as The Yankee Group, Gartner Group, and IDC.
• 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.

This document is relevant to many audiences. The audiences and a description of how each audience can use this document are shown in the table below.

User	Job Roles/Tasks	Document Capabilities/Value
PEO/Executive Pentagon Action Officer	Acquisition oversight, funding advocacy Motivate introduction of new/commercial technologies Policy issues	Overview/introductory info Baseline reference document "Cliff Notes" approach--provides high-level, 6-8 page quick study Tradeoff information
System Program Manager (SPM) and Technical Staff (Includes FFRDCs (MITRE, etc.) and may include government laboratories)	Writes Request for Proposal (RFP) or some form of solicitation based on user requirements Reviews proposals and selects developers Manages development and/or maintenance work	All of previous category, plus: Taxonomies to aid in identifying alternatives Back pointers to high-level, related technologies Criteria and guidance for decision-making Tech transfer/insertion guidelines Selected high-value references to more technical information, to include usage and experience data Generally the sort of analysis and survey information that would not be accomplished under normal project circumstances
Developer (to include research and development (R&D) activity)	Performs advanced development, prototyping, and technology investigation focused on risk reduction and securing competitive advantage Concerned about transition and insertion issues Writes a proposal in response to solicitations Performs engineering development and provides initial operational system	Same as previous category.
Maintainer	Maintains operational system until the end of the life cycle Responds to user requirements for corrections or enhancements Concerned about inserting new technologies and migrating to different approaches	Same as previous category.
User	Communicates operational needs End customer for operational system	Communicates alternatives and risks, and provides perspective of what technology can (reasonably) provide