An Alternative to Technology Readiness Levels for Non-Developmental Item (NDI) Software

Defense acquisition policies require that program managers conduct technology readiness assessments for all critical technologies. Technology Readiness Levels (TRLs) are frequently used in performing these assessments. While there is considerable evidence to support the utility of using TRLs in assessing program risk, there are some difficulties in using TRLs with software. This report explores these problems as they apply to non-developmental item (NDI) software technology and products, including commercial off-the-shelf, government off-the-shelf, and open source software. The problems take four principal forms: 1. TRLs "blur" several aspects of technology and product readiness into a single number. 2. TRLs do not account for the criticality of a product or technology to the system as a whole. 3. TRLs don't account for software technology and product aging. 4. TRLs do not provide any means to deal with how the relative contributions of the various aspects of readiness vary throughout the life cycle of a system. This report examines these issues in detail and proposes an alternative approach for determining product readiness of NDI software technology

What About Ada? The State of the Technology in 2003

The projected life-cycle cost of a system is a central concern for any program manager (PM) in the Department of Defense (DoD). Choices made early in system development, such as choosing appropriate programming languages, can have profound effects on life-cycle cost. This report documents a recent investigation which characterized the technical and programmatic risks in reusing significant quantities of legacy Ada code in a new system. The investigation attempted to answer three questions: First, what is the business case for Ada? Second, how is Ada viewed by the defense industry? Third, how is Ada supported by academe? The results of this investigation point to a bleak future for Ada: no longer in the mainstream of computer science education, software engineering practice, or commercial support ADA is little more than a niche language used primarily within the DoD community and in limited civilian market segments, especially where there is defense market crossover or similar requirements as in commercial aviation, process control, and medical instrumentation. The data collected in this report should help PMs evaluate the risks—both during initial development and throughout the entire life cycle—of using Ada for software-intensive systems

Exploring Programmatic Interoperability: Army Future Force Workshop

This report documents the proceedings of the Future Force Workshop held at the Software Engineering Institute on October 13-14, 2004. It describes the background and motivation for the workshop, provides a brief overview of the workshop activities, and highlights the key observations and conclusions obtained through the course of the workshop and post-workshop analyses. In addition, a set of recommended next steps is described

Multi-view Decision Making (MVDM) Workshop

A major hurdle for complex development efforts is the lack of effective insight into problems early enough so solutions can be addressed without jeopardizing critical project and organizational constraints. Effectively addressing these challenges requires a set of programmatic and engineering practices that reflect the realities of system-of-systems development, acquisition, fielding and support: multi-view decision making. In support of the Army Strategic Software Improvement Program FY08 Strategic Software Improvement Plan, the Software Engineering Institute conducted a workshop to introduce three analysis techniques-(1) Mission-Oriented Success Analysis and Improvement Criteria, (2) Interoperable Acquisition, and (3) Survivability Analysis Framework-and how they can be combined to address the challenges of managing complexity. Through the use of examples, the limitations of decision making from any one single view and the value provided by a multi-view approach were presented and discussed. This report provides a recap of the workshop

Including Interoperability in the Acquisition Process

This report explores achieving interoperability in the acquisition process. It asserts that interoperability applies to the management and construction of a system, as well as to its operation. This idea leads to a broader view of interoperability. Also presented is the idea that the essential character of interoperability—related to data models and operational semantics—is independent of a domain of application. This report lists a number of basic assertions that can help organizations achieve interoperability in the acquisition process. A number of related key issues are also examined. Ultimately, it is expected that achieving interoperability will depend on a formal specification of acquisition

Requirements Management in a System-of-Systems Context: A Workshop

This report summarizes the results of a workshop focused on requirements management in a system of systems. The workshop attendees were affiliated with the Army Program Executive Office (PEO) Aviation and Training and Doctrine Command (TRADOC) Combat Developers. During the workshop, issues were identified in a number of areas, including requirements management, system-of-systems management, and system construction. Many of the issues raised address some form of the conflict that exists between a top-down, policy driven approach to the acquisition of a system of systems and a bottom-up, program-centric approach to the acquisition of an individual system

Rules of Thumb for the Use of COTS Products

More and more organizations are realizing the benefits-and sometimes the necessity-of incorporating commercial off-the-shelf (COTS) products in the systems they acquire and use. But COTS products are not necessarily the right solution for every system. When is it wise to pursue a COTS-based systems approach, and when is it best to hold back? How can sound COTS-based-system practices be reconciled with an organization's regulatory and policy constraints? This report provides some information to help guide these decisions

System-of-Systems Navigator: An Approach for Managing System-of-Systems Interoperability

We have crossed a threshold where most of our large software systems can no longer be constructed as monoliths specified by a single, focused, and unified team; implemented as a unit; and tested to be within known performance limits. They are now constructed as groups of interoperating systems (as systems of systems) developed by different but sometimes related teams and made to interoperate through various forms of interfaces. Unfortunately, while we can easily conceive these large systems of systems, we have trouble building them. Software engineering practices have not kept pace, and the problem will only get worse as the community begins to build Internet-scale systems of systems like the Global Information Grid. This technical note introduces the System-of-Systems Navigator (SoS Navigator), the collection and codification of essential practices for building large-scale systems of systems. These practices have been identified through the work of the Integration of Software-Intensive Systems Initiative at the Carnegie Mellon Software Engineering Institute. SoS Navigator provides tools and techniques to characterize organizational, technical, and operational enablers and barriers to success in a system of systems; identify improvement strategies; and pilot and institutionalize these strategies

Current Perspectives on Interoperability

This report describes current research within the software engineering community on the topic of interoperability between software systems. That research includes analyses of the different types of interoperability problems and issues and efforts to define models of interoperability that will aid in creating solutions to those problems. The report also describes work that is currently underway at the Software Engineering Institute (SEI) in this area. That work originated in an independent research effort and now has grown into a separate technical initiative in the area of interoperability. The SEI initiative is currently focused on analyzing several aspects of interoperability: how it is manifest in different kinds of activities (i.e., programmatic vs. constructive vs. operational activities), the essential characteristics of interoperability, and the key principles on which solutions will depend

Results of SEI Independent Research and Development Projects FY 2006

Each year, the Software Engineering Institute (SEI) undertakes several independent research and development (IRAD) projects. These projects serve to (1) support feasibility studies investigating whether further work by the SEI would be of potential benefit and (2) support further exploratory work to determine whether there is sufficient value in eventually funding the feasibility study work as an SEI initiative. Projects are chosen based on their potential to mature and/or transition software engineering practices, develop information that will help in deciding whether further work is worth funding, and set new directions for SEI work. This report describes the IRAD projects that were conducted during fiscal year 2006 (October 2005 through September 2006)