SEI Documents List

[2007] [2006] [2005] [2004] [2003] [2002] [2001] [2000] [1999] [1998] [1997] [1996] [1995] [1994] [1993] [1992] [1991] [1990] [1989] [1988] [1987] [1986] [PDF]

2002 Reports

Annual Report

2002 Annual Report
Annual Report, 2002

The 2002 SEI Annual Report describes the accomplishments of the SEI during fiscal year 2002 (October 1, 2001, through September 30, 2002). For each of the SEI's focus areas, the report summarizes key research and support that the SEI provided for developers and acquirers of software-intensive systems. The report also presents information about the SEI, its staff members, and its organization, including staff accomplishments, publications, leadership positions, demographics, dissemination activities, and funding data.

http://www.sei.cmu.edu/publications/documents/02.reports/02ar.html

Special Reports

CMU/SEI-2002-SR-001, ADA405789
Reeducation to Expand the Software Engineering Workforce: Successful Industry/University Collaborations
Ellis, H.; Moreno, A.; Mead, N.; & Seidman, S.

Software produced worldwide is growing at a phenomenal rate as software is used in such diverse products as automobiles, homes, and airplanes. In addition, the increasingly global business climate and expanding emphasis on distributed computing has accelerated the need for business software. However, there is currently an inadequate number of software engineers to produce and maintain software to meet this demand. One possible solution to correcting this shortfall is reeducating existing non-software engineering employees to become software engineers. For the past two years, the Industry/University (I/U) subgroup of the Working Group on Software Engineering Education and Training has been investigating active collaborations between companies and universities in which non-software professionals and practitioners who lack formal software education are reeducated to become software engineers. This paper reports on the I/U subgroup's findings by describing their approach to the investigation, the factors involved in successful collaboration construction and execution, and alumni views of the knowledge and skills transferred by the collaboration.

http://www.sei.cmu.edu/publications/documents/02.reports/02sr001.html

CMU/SEI-2002-SR-009, ADA408853
Tracking and Tracing Cyber-Attacks: Technical Challenges and Global Policy Issues
Lipson, H.

In the cyber world, the current state of the practice regarding the technical ability to track and trace Internet-based attacks is primitive at best. Sophisticated attacks can be almost impossible to trace to their true source using current practices. The anonymity enjoyed by today's cyber-attackers poses a grave threat to the global information society, the progress of an information-based international economy, and the advancement of global collaboration and cooperation in all areas of human endeavor.

Part I of this report examines the current state of the Internet environment and the reasons why tracking and tracing cyber-attackers is so difficult. Part II examines some promising research on technical approaches that may greatly improve the ability to track and trace cyber-attacks to their source. Also discussed are some policy considerations with regard to privacy, information sharing, liability, and other policy issues that would be faced by the U. S. State Department in negotiating international agreements for cooperation and collaboration in the tracking and tracing of cyber-attacks. The report concludes with a closer look at technical and policy considerations for next-generation Internet protocols to enhance track and trace capabilities.

http://www.sei.cmu.edu/publications/documents/02.reports/02sr009.html

CMU/SEI-2002-SR-027, ADA407785
Using the Technology Readiness Levels Scale to Support Technology Management in the DoD's ATD/STO Environments (A Findings and Recommendations Report Conducted for Army CECOM)
Graettinger, C.; Garcia, S.; Siviy, J.; Schenk, R.; & van Syckle, P.

In early 2002, the Communications Electronics Command (CECOM) Manager of the Army Tactical Wireless Network Assurance (TWNA) Science and Technology Objective (STO) FY03-07, hereafter referred to as STO, requested assistance from the Software Engineering Institute (SEI) in improving STO methods for assessing the maturity of new information-assurance technologies. The STO was seeking to use technology maturity, as measured by the Technology Readiness Levels (TRLs) scale, as a metric in its decision-making process for selecting new technologies for STO development and maturation, technologies that would eventually be transitioned to Army tactical programs. This report describes the results of the SEI study of the feasibility of (a) using TRLs in STO technology screening, (b) developing or acquiring a TRL tool, and (c) implementing a TRL tool.

http://www.sei.cmu.edu/publications/documents/02.reports/02sr027.html

Handbooks

CMU/SEI-2002-HB-002, ADA408309
Standard CMMI^® Appraisal Method for Process Improvement (SCAMPI^SM), Version 1.1: Method Implementation Guidance for Government Source Selection and Contract Process Monitoring
Barbour, R.; Benhoff, M.; Gallagher, B.; Eslinger, S.; Bernard, T.; Ming, L.; Rosa, L.; & Ryan, C.

SCAMPI V1.1 Method Implementation Guidance for Government Source Selection and Contract Process Monitoring provides guidance for use by Government personnel and their supporting organizations for fulfilling the objectives of the SCAMPI method in their acquisition environments.

The Standard CMMI^® Appraisal Method for Process Improvement (SCAMPI^SM) is designed to provide benchmark quality ratings relative to Capability Maturity Model^® Integration (CMMI) models. It is applicable to a wide range of appraisal usage modes, including both internal process improvement and external capability determinations. SCAMPI satisfies all of the Appraisal Requirements for CMMI (ARC) requirements for a Class A appraisal method and can support the conduct of ISO/IEC 15504 assessments. The SCAMPI Method Definition Document describes the requirements, activities, and practices associated with each of the processes that compose the SCAMPI method. It is intended to be one of the elements of the infrastructure within which SCAMPI Lead Appraisers conduct a SCAMPI appraisal. Precise listings of required practices, parameters, and variation limits, as well as optional practices and guidance for enacting the method, are covered. An overview of the method's context, concepts, and architecture is also provided.

http://www.sei.cmu.edu/publications/documents/02.reports/02hb002.html

Technical Notes

CMU/SEI-2002-TN-027, ADA407970
Application of an Iterative Approach to DoD Software Migration Planning, An
Bergey, J.; O'Brien, L.; & Smith, D.

In recent years, system modernization has received much attention within the Department of Defense (DoD). Typically, that attention has focused on the technical and acquisition issues associated with the new system. Less attention has been paid to the equally important issue of planning the migration from the old system to the new system.

This technical note reports on the early results of an approach that is currently being piloted to support software migration planning. This approach focuses on deriving actionable mini-plans for focus areas that are identified in an initial increment of an overall migration plan.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn027html

CMU/SEI-2002-TN-026, ADA407797
Basis for Composition Language CL, A
Ivers, J.; Sinha, N.; & Wallnau, K.

CL is a composition language for predictable assembly from certifiable components. An application assembly process is predictable if the runtime behavior of an assembly of components can be predicted from known properties of components and their patterns of interaction. CL is similar to other composition languages that combine a component and connector style of description with a core compositional semantics specified in a process algebra. CL differs from these in its explicit treatment of details that are usually abstracted or ignored. For example, CL makes explicit the allocation of execution threads to component behavior; this distinguishes concurrent from sequential behavior, and leads to potentially smaller state spaces as well as more accurate behavioral descriptions. This report describes the main concepts of CL and its rudimentary graphical syntax. This report also defines and illustrates the compositional semantics for CL using Hoare's CSP. The twin objectives of this report are to consolidate our current thinking about an ideal CL and to provide a starting point for the design of a practical and implementable CL. This report closes with a discussion of several open issues that must be resolved before this second objective can be satisfied.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn026.html

CMU/SEI-2002-TN-001, ADA339792
Documenting Software Architecture: Documenting Behavior
Bachmann, F.; Bass, L.; Clements, P.; Garlan, D.; Ivers, J.; Little, R.; Nord, R.; & Stafford, J.

This report represents another milestone of a work in progress: a comprehensive handbook on how to produce high- quality documentation for software architectures. The handbook, tentatively titled Documenting Software Architectures, will be published in early 2002 by Addison-Wesley as part of the Software Engineering Institute (SEI) Series on Software Engineering.

The book is intended to address a lack of language-independent guidance about how to capture an architecture in a written form that can provide a unified design vision to all of the stakeholders on a development project.

A central precept of the book is that documenting an architecture entails two essential steps: (1) documenting the set of relevant views of that architecture, and then completing the picture by (2) documenting information that transcends any single view. The books audience is the community of practicing architects, apprentice architects, and developers who receive architectural documentation.

This technical note describes ways to document an important but often overlooked aspect of software architecture: the behavior of systems, subsystems, and components.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn001.html

CMU/SEI-2002-TN-015, ADA403788
Documenting Software Architecture: Documenting Interfaces
Bachmann, F.; Bass, L.; Clements, P.; Garlan, D.; Ivers, J.; Little, R.; Nord, R.; & Stafford, J.

This is the fourth in a series of SEI reports on documenting software architectures. This report details guidance for documenting the interfaces to software elements. It prescribes a standard organization (template) for recording semantic as well as syntactic information about an interface. Stakeholders of interface documentation are enumerated, available notations for specifying interfaces are described, and three examples are provided.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn015.html

CMU/SEI-2002-TN-004, ADA401737
Experiences in Architecture Reconstruction at Nokia
O'Brien, L.

This experience report outlines details of past and current architecture reconstruction work on several systems at Nokia. The Dali architecture reconstruction workbench developed by the Software Engineering Institute supported some of these efforts. Other efforts involved various tools and techniques, and in one case, the architecture reconstruction was performed manually.

This report describes five such reconstruction efforts and outlines the observations noted and lessons learned while performing them. This report also offers some guidelines for those undertaking a reconstruction effort.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn004.html

CMU/SEI-2002-TN-019, ADA443474
Flow-Service-Quality (FSQ) Engineering: Foundations for Network System Analysis and Development
Linger, R.; Pleszkoch, M.; Walton, G.; & Hevner, A.

Modern society could hardly function without the large-scale, network-centric information systems that pervade government, defense, and industry. As a result, serious failures or compromises carry far-reaching consequences. These systems are characterized by changing and often unknown boundaries and components, constantly varying function and usage, and complexities of pervasive asynchronous operations. Their complexity challenges human intellectual control, and their survivability has become an urgent priority. Engineering methods based on solid foundations and the realities of network systems are required to manage complexity and ensure survivability. Flow-Service-Quality (FSQ) engineering is an emerging technology for management, acquisition, analysis, development, evolution, and operation of large-scale, network-centric systems. FSQ engineering is based on Flow Structures, Computational Quality Attributes, and Flow Management Architectures. These technologies can help provide stable engineering foundations for the dynamic and often unpredictable world of large-scale, network-centric systems. Flow Structures define enterprise mission task flows and their refinements into uses of system services in network traversals. Flows are deterministic for human understanding, despite the underlying asynchronism of network operations. They can be refined, abstracted, and verified with precision, and deal explicitly with Uncertainty Factors, including uncertain commercial off-the-shelf functionality and system failures and compromises. Computational Quality Attributes go beyond static, a priori estimates to treat quality attributes such as reliability and survivability as dynamic functions to be computed in system operation. Computational Quality Attribute requirements are associated with flows and can be dynamically reconciled with network service attributes in execution. Flow Management Architectures include design and implementation frameworks for dynamically managing flows and attribute requirements, as well as processes for their development. FSQ foundations are defined by theorems that illuminate engineering practices and automation opportunities.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn019.html

CMU/SEI-2002-TN-006, ADA401709
Interpreting Capability Maturity Model^® Integration (CMMI^®) for Operational Organizations
Gallagher, B.

Capability Maturity Model^® Integration (CMMI^®) provides a framework for improving the processes organizations use to develop and deliver products for their customers. The process improvement concepts embedded in CMMI are based upon sound process management principles used in manufacturing communities for years. These principles have been successfully applied in software and systems engineering process improvement, and are codified for product development in CMMI. This technical note details how operational organizations that perform a variety of missions can benefit from the concepts in CMMI to improve the processes and effectiveness of mission operations.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn006.html

CMU/SEI-2002-TN-007, ADA403805
MAP and OAR Methods: Techniques for Developing Core Assets for Software Product Lines from Existing Assets
O'Brien, L. & Smith, D.

While it is commonly recognized that legacy assets are, in most cases, an important contributor to the core assets for software product lines, systematic methods for making decisions on when to incorporate legacy assets (versus building new assets) have not been available. Two methods developed by the Software Engineering Institute fill this gap: the Mining Architectures for Product Lines (MAP) method and the Options Analysis for Reengineering (OAR) method.

Both of these methods, which are described in this report, support different aspects of the Product Parts Pattern, which is applied to develop the core assets for a product line. The MAP method provides a suitability analysis of existing systems' software architectures as candidates for a product line architecture. After an architecture has been developed or chosen, the OAR method provides a disciplined approach for making decisions on rehabilitating legacy assets that may be incorporated into the product line asset base.

This technical note describes both the MAP and OAR methods, the activities that each involves, and examples of applying them.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn007.html

CMU/SEI-2002-TN-011, ADA407774
Model-Based Verification: Abstraction Guidelines
Hudak, J.; Comella-Dorda, S.; Gluch, D.; Lewis, G.; & Weinstock, C.

Model-Based Verification (MBV) is a systematic approach to finding defects (errors) in software requirements, designs, or code. The approach judiciously incorporates mathematical formalism, in the form of models, to provide a disciplined and logical analysis practice, rather than a "proof of correctness" strategy. This technical note presents a number of abstraction techniques that can be used to build essential models of system behavior in the context of MBV and details a methodology for creating state machine models using those techniques. In building essential models, abstraction is used to hide details and expose the entities, variables, states, and transitions needed to construct a state machine model. Through illustrative examples, this technical note identifies the types of simplifications that are useful and effective and highlights the importance of the perspective in determining what are the important elements to include in an abstracted model.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn011.html

CMU/SEI-2002-TN-003, ADA339228
Model-Based Verification: Guidelines for Generating Expected Properties
Gluch, D.; Comella-Dorda, S.; Hudak, J.; Lewis, G.; & Weinstock, C.

This report presents a basic set of guidelines to facilitate the generation of expected properties in the context of Model- Based Verification. Expected properties are natural language statements that express characteristics of the behavior of a system-characteristics that are consistent with user expectations. Through model checking, expected properties of a system, formally expressed as claims, are analyzed against the model. This analysis can detect inconsistencies between models of the system and their expected properties and identify potential system defects.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn003.html

CMU/SEI-2002-TN-020, ADA405846
PAMD: Developing a Plug-In Architecture for Palm OS-Powered Devices Using Software Engineering
Eguiluz, H.; Govi, V.; Kim, Y.; & Sia, A.

This technical note describes a plug-in architecture for Palm Operating System devices developed by the authors, a team of graduate students from Carnegie Mellon's Master of Software Engineering program. The note highlights the architecture's three most important aspects: the product (a plug-in architecture) created from a software architecture point of view; the implementation details that made this a unique project; and the software engineering facets of the project. This note also shares lessons learned and suggests possible avenues that could be pursued in the future to make plug-in architecture for mobile devices (PAMD) more universal.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn020.html

CMU/SEI-2002-TN-033, ADA413548
PECT Infrastructure: A Rough Sketch
Hissam, S. & Ivers, J.

A prediction-enabled component technology (PECT) is an approach to achieving predictable assembly from certifiable components. A PECT consists of a component technology that has been extended with one or more reasoning frameworks that are used to predict how assemblies of components will behave. Developing and using a PECT involves a number of different activities, many of which are practical only when supported by automation. This paper investigates the nature of PECT infrastructures, summarizes the activities that a PECT infrastructure should support, and proposes a design for the tools that make up a PECT infrastructure. This paper also considers the reusability of such an infrastructure by evaluating the impact that three possible changes to a PECT have on its infrastructure.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn033.html

CMU/SEI-2002-TN-023, ADA405791
Plug-In Architecture for Mobile Devices
Keshavamurthy, M.; Kim, J.; Li, M.; & Sagetong, V.

This technical note describes plug-in architecture for mobile devices (PAMD)-an architectural specification that extends the function of applications in mobile devices. Users gain major benefits when the functionality of applications that run on these devices can be extended through the addition of new services that don't require changes to the application itself. PAMD provides interoperability between applications and plug-ins without sacrificing the performance of the mobile devices on which they run. Because existing applications can be made PAMD compliant with little modification, the development time and costs of adding functionality to them can be reduced dramatically. As PAMD bears the burden of communicating with plug-ins, application and plug-in developers can develop their own products independently and easily use each other's products.

This technical note also describes PAMD's interfaces, how applications and plug-ins interact with them, and the advantages of using PAMD. Also included are several scenarios that explain the architecture and how it can be implemented, and suggestions for extensions that enhance it.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn023.html

CMU/SEI-2002-TN-029, ADA405846
Product Line Production Planning for the Home Integration System Example
Chastek, G.; Donohoe, P.; & McGregor, J.

A production plan is a description of how a software product line organization builds products in a product line. This technical note examines the significant characteristics of the production plans of three hypothetical organizations that create product lines of home integration systems. Such systems enable homeowners to access and control equipment in their homes such as climate control and security systems. The plan for one of the organizations is presented in some detail, and the plans for the other two are described in terms of their differences from the first plan. The purpose of this note is to show how influences such as an organization's business goals, production strategy, and experience in product lines can lead to very different approaches to building products.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn029.html

CMU/SEI-2002-TN-017, ADA407780
Product Line State of the Practice Report
Cohen, S.

Software product lines represent a new and promising approach for fielding software systems. Companies that have launched software product line efforts report significant improvements in cost savings, quality, productivity, and time to market. Technically, they report a high degree of success in developing approaches that address the software engineering and technical management of their product lines. Organizationally, these companies report success as well as challenges that they must still overcome.

This technical note reports on the state of software product line practice in industry. The report uses a narrative approach, based on a composite of individual companies' experiences in implementing software product lines. The report blends a case study with the results of a product line questionnaire that was sent to organizations with meaningful product line experiences and with the results of a product line workshop held during the recent International Conference on Software Reuse.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn017.html

CMU/SEI-2002-TN-009, ADA403867
Replaceable Components and the Service Provider Interface
Seacord, R. & Wrage, L.

Several popular component-based standards have emerged recently, including JavaBeans and Enterprise JavaBeans from Sun Microsystems and the Component Object Model from Microsoft. These component models are being adopted for use in software development, as they eliminate opportunities for architectural mismatch and are supported by standard services. A highly touted property of component models is that they support the development of replaceable components. Unfortunately, a robust, commercial marketplace of replaceable components has not been established for any of these component models.

On the other hand, the properties of the Service Provider Interface (SPI), used in many Java language packages, has resulted in the development of reusable components in several technology areas. Examples of successful SPI packages include Java Database Connectivity, Java Cryptography Extension, Java Naming and Directory Interface, and the Java Application Program Interface for XML Processing.

This technical note considers the motivation for using replaceable components and defines the requirements of replaceable component models. It evaluates the properties of standard component models and the SPI approach that affect their ability to support replaceable components.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn009.html

CMU/SEI-2002-TN-008, ADA401712
SCAMPI^SM V1.1 Use in Supplier Selection and Contract Process Monitoring
Barbour, R. & Bernard, T.

The Standard CMMI^® Appraisal Method for Process Improvement (SCAMPI^SM), V1.1 is designed to provide benchmarks relative to Capability Maturity Model^® Integration (CMMI) models. This appraisal method is applicable to a wide range of appraisal applications, including support for both internal process improvement and external capability determination.

The SCAMPI, V1.1 Method Definition Document describes the requirements, activities, and practices associated with each of the processes that compose the SCAMPI. This technical note provides additional implementation guidance related to supplier selection and contract process monitoring applications of this appraisal method. This technical note does not cover current issues such as the definition of "independently led" appraisals or the registration and reuse of appraisal results.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn008.html

CMU/SEI-2002-TN-005, ADA413696
SEI Architecture Analysis Techniques and When to Use Them
Barbacci, M.

The Software Engineering Institute (SEI) has developed two methods for analyzing system and software architectures- the Quality Attribute Workshop (QAW) and the Architecture Tradeoff Analysis Method^SM (ATAM^SM). These techniques, which are described in detail in various SEI technical reports and on the SEI Web site, can be used in combination to obtain early and continuous benefits. Designed to complement the ATAM, the QAW provides a method for analyzing a conceptual architecture or a system architecture against a number of critical quality attributes-such as availability, performance, security, interoperability, and modifiability-before the software architecture is fully developed. Once the software architecture is developed, the ATAM can be used to reveal how well the architecture satisfies particular quality attribute requirements and the risks, sensitivities, and tradeoffs involved in satisfying the requirements.

The purpose of this technical note is to describe, using a hypothetical example, the alignment, combination, and uses of the two methods.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn005.html

CMU/SEI-2002-TN-012, ADA403868
Software Process Improvement and Product Line Practice: CMMI^® and the Framework for Software Product Line Practice
Jones, L. & Soule, A.

Many organizations report dramatic benefits from the adoption of software product line practice. Organizations that have established software engineering process discipline are better poised to succeed with product lines. While we acknowledge that there are different paths to successful process discipline, in this technical note, we concentrate on approaches based on the Capability Maturity Model^® Integration (CMMI^®) models. We describe practices that are most crucial to product line success. While some of these relate directly to the CMMI models process areas, others are uniquely important to product lines.

In this technical note, we first present fundamental concepts of software product lines. We then describe important product line practices as they have been documented in A Framework for Software Product Line Practice (framework). We next present an overview of the CMMI models, followed by a description of the general relationships between the framework and CMMI models. We amplify this comparison with a detailed example showing the relationship between configuration management practices in CMMI and in the framework. We conclude by describing the ways in which organizations can build upon their process improvement efforts to achieve success with product lines and realize additional benefits through the use of both technologies.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn012.html

CMU/SEI-2002-TN-002, ADA403810
Software Product Line Vision for Defense Acquisition, A
Campbell G.

Experience in industry and government over the last 10 years has shown that a software product line approach can significantly improve productivity and product quality, facilitate change, and reduce life-cycle costs. Defense acquisition policy calls for such improvements related to software but makes no explicit mention of a product line approach as an option. Although policy gives program managers sufficient flexibility to adopt a product line approach, there is little awareness of this possibility and considerable uncertainty concerning when and how to do it. This note presents a vision for software product lines as an acquisition focus and suggests extensions to current Department of Defense policy and practices to increase the awareness of and receptivity to product line acquisition as a viable alternative.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn002.html

CMU/SEI-2002-TN-018, ADA407788
Successful Product Line Development and Sustainment: A DoD Case Study
Cohen, S.

The Engineering, Test, and Evaluation Department of the Naval Undersea Warfare Center - Division Newport (NUWC) has developed a software product line asset base, named RangeWare, to support test range operations. NUWC has also fielded a product line of range systems using the asset base. RangeWare provides an object services architecture to support integration of sensor and other range data for analysis and display by range equipment. After several pilot applications of RangeWare, NUWC is now taking RangeWare into a sustainment phase, expanding the coverage of the asset base in terms of object and distribution services as well as applying the assets to new systems.

This case study describes RangeWare and NUWC's product line practices to sustain and support the evolution of RangeWare. These practices include "Operations," "Data Collection," "Metrics and Tracking," "Software System Integration," "Configuration Management," "Tool Support," "Structuring the Organization," "Building a Business Case," and others. The case study also examines NUWC's lessons learned and its plans for improved process definition for RangeWare product production.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn018.html

CMU/SEI-2002-TN-021, ADA408691
Supporting the CANCEL Command Through Software Architecture
Bass, L. & John, B.

A system that supports the user's ability to cancel a command should be designed to achieve particular results. These results include the responses the system should make to the user, such as providing feedback to the user about the command's receipt, predicting the time the cancellation should take (for long-running cancellations), and indicating the state to which the system was returned after the completion of the cancellation. To support a cancellation command, a system should be designed so that the command is handled on a thread separate from that of the command being cancelled, the resources being used by the command being cancelled should be freed, and any processes collaborating with the command being cancelled should be informed of the cancellation. This note details the responsibilities that a system must implement to support command cancellation.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn021.html

CMU/SEI-2002-TN-010, ADA403813
Use of the Architecture Tradeoff Analysis Method (ATAM^SM) in Source Selection of Software-Intensive Systems
Bergey, J.; Fisher, M.; & Jones, L.

Software architecture is critical to the quality of a software-intensive system. For an acquisition organization, such as the Department of Defense (DoD), the ability to evaluate software architectures as early as possible in an acquisition can have a favorable impact on the delivered system. This technical note explains the role of software architecture evaluation in a source selection and describes the contractual elements that are needed to support its use. The note then briefly describes the Architecture Tradeoff Analysis Method^SM (ATAM^SM) and provides an example that shows how to apply this method in a source selection. The example includes sample contractual language that an acquirer can adapt to meet specific acquisition needs.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn010.html

CMU/SEI-2002-TN-013, ADA405848
Use of Quality Attribute Workshops (QAWs) in Source Selection for a DoD System Acquisition: A Case Study
Bergey, J. & Wood, W.

The architecture of a software-intensive system is critical to its quality. For an acquisition organization within the Department of Defense (DoD), evaluating architectures as early as possible in an acquisition can have a favorable impact on the delivered system. This technical note is a case study of how a DoD organization used architecture analysis and evaluation in a major system acquisition, early on, to reduce program risk. The case study begins by describing the system, the motivation for including architecture evaluation in the acquisition, and the Quality Attribute Workshop (QAW) approach. Following this is a brief description of the system acquisition strategy. The case study then describes the set of events (and supporting artifacts) that were required to incorporate QAW architecture analysis and evaluation in the acquisition strategy. In addition, it describes the relationship of these events and artifacts to the source-selection process. Concluding the case study is a description of the accomplishments and lessons learned, along with sample sections from the request for proposal (RFP). These sections provide additional insight into the contractual language that was used to implement the architecture analysis and evaluation approach.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn013.html

CMU/SEI-2002-TN-016, ADA407766
Using CMMI^® to Improve Earned Value Management
Solomon, P.

For organizations using Earned Value Management (EVM) or that plan to implement EVM during Capability Maturity Model^® Integration (CMMI^®) implementation, this technical note provides guidance for cost-effective process improvement and appraisal. Mapping and comparison tables between CMMI and the U.S. national standard on EVM are provided. These tables can be used to identify practices within CMMI that are not included in the EVM standard but, if added to an organization's processes, will strengthen adherence to EVM principles. The tables also can be used to develop instruments that will provide evidence to an appraisal team to enable it to quickly verify and validate specific practices based upon effective implementation of EVM.

Furthermore, information such as glossary components, typical work products, and examples are included in this technical note to aid those using CMMI for process improvement. For organizations using technical performance measurement, a primary base measure for earned value, additional guidance and information is provided. Finally, additional references and an EVM glossary are provided.

http://www.sei.cmu.edu/publications/documents/02.reports/02tn016.html

Technical Reports

CMU/SEI-2002-TR-034, ADA412306
Architecture Reconstruction Guidelines, Third Edition
Kazman, R.; O'Brien, L.; & Verhoef, C.

Architecture reconstruction is the process of obtaining the "as-built" architecture of an implemented system from the existing legacy system. For this process, tools are used to extract information about the system that will assist in building successive levels of abstraction. Although generating a useful representation is not always possible, a successful reconstruction results in an architectural representation that aids in reasoning about the system. This recovered representation is most often used as a basis for redocumenting the architecture of an existing system if the documentation is out of date or nonexistent, and can be used to check the "as-built" architecture against the "as-designed" architecture. The architectural representation can also be used as a starting point for reengineering the system to a new desired architecture. Finally, the representation can be used to help identify components for reuse or to help establish a software product line.

This report describes the process of architecture reconstruction using the Dali architecture reconstruction workbench. Guidelines are presented for reconstructing the architectural representations of existing systems. Most of these guidelines are not specific to the Dali tool, can be used with other tools, and are useful even if the architecture reconstruction is carried out manually.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr034.html

CMU/SEI-2002-TR-028
CMMI^® for Software Engineering, Version 1.1, Continuous Representation (CMMI-SW, V1.1, Continuous)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD-CMM, SA- CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Software engineering concepts are covered by this model, including traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a continuous representation, which focuses on measuring process improvement using capability levels. Capability levels apply to process-improvement achievement within individual process areas such as Configuration Management or Verification.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr028.html

CMU/SEI-2002-TR-029
CMMI^® for Software Engineering, Version 1.1, Staged Representation (CMMI-SW, V1.1, Staged)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) concept, established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD- CMM, SA-CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Software engineering concepts are covered by this model, including traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a staged representation, which focuses on measuring process improvement using maturity levels. Maturity levels apply to process-improvement achievement across the organizational unit using the model.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr029.html

CMU/SEI-2002-TR-011, ADA339818
CMMI^® for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD/SS, V1.1, Continuous)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) concept, established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD- CMM, SA-CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Concepts covered by this model include systems engineering, software engineering, integrated product and process development, and supplier sourcing as well as traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a continuous representation, which focuses on measuring process improvement using capability levels. Capability levels apply to process-improvement achievement within individual process areas such as configuration management or verification.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr011.html

CMU/SEI-2002-TR-012, ADA339907
CMMI^® for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD/SS, V1.1, Staged)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) concept, established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD- CMM, SA-CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Concepts covered by this model include systems engineering, software engineering, integrated product and process development, and supplier sourcing as well as traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a staged representation, which focuses on measuring process improvement using maturity levels. Maturity levels apply to process-improvement achievement across the organizational unit using the model.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr012.html

CMU/SEI-2002-TR-003, ADA339219
CMMI^® for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD, V1.1, Continuous)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) concept, established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD- CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Concepts covered by this model include systems engineering, software engineering, and integrated product and process development as well as traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a continuous representation, which focuses on measuring process improvement using capability levels. Capability levels apply to process-improvement achievement within individual process areas such as configuration management or verification.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr003.html

CMU/SEI-2002-TR-004, ADA339221
CMMI^® for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD, V1.1, Staged)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) concept, established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD- CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Concepts covered by this model include systems engineering, software engineering, and integrated product and process development as well as traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a staged representation, which focuses on measuring process improvement using maturity levels. Maturity levels apply to process-improvement achievement across the organizational unit using the model.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr004.html

CMU/SEI-2002-TR-001, ADA339225
CMMI^® for Systems Engineering/Software Engineering, Version 1.1, Continuous Representation (CMMI-SE/SW, V1.1, Continuous)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) concept, established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD- CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Concepts covered by this model include systems engineering and software engineering as well as traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a continuous representation, which focuses on measuring process improvement using capability levels. Capability levels apply to process-improvement achievement within individual process areas such as configuration management or verification.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr001.html

CMU/SEI-2002-TR-002, ADA339224
CMMI^® for Systems Engineering/Software Engineering, Version 1.1, Staged Representation (CMMI-SE/SW, V1.1, Staged)
CMMI Product Team

Capability Maturity Model^® Integration (CMMI^®) models have evolved the Capability Maturity Model (CMM^®) concept, established by the Capability Maturity Model for Software (SW-CMM), to a new level that enables the continued growth and expansion of the CMM concept to multiple disciplines. Like the SW-CMM, EIA/IS 731, IPD- CMM, and other process improvement models, CMMI models are tools that help organizations improve their processes. This CMMI model is designed to help organizations improve their product and service development, acquisition, and maintenance processes. Concepts covered by this model include systems engineering and software engineering as well as traditional CMM concepts such as process management and project management. Each CMMI model is designed to be used in concert with other CMMI models, making it easier for organizations to pursue enterprise-wide process improvement at their own pace. This CMMI model has a staged representation, which focuses on measuring process improvement using maturity levels. Maturity levels apply to process-improvement achievement across the organizational unit using the model.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr002.html

CMU/SEI-2002-TR-020, ADA406781
Discovery Colloquium: Quality Software Development @ Internet Speed&
Levine, L.; Baskerville, R.; Link, J.; Pries-Heje, J.; Ramesh, B.; & Slaughter, S.

In October, 2001, the Software Engineering Institute hosted a colloquium to explore issues faced by organizations challenged with developing quality software at "Internet speed" and to examine the impact of Internet speed on current software-development practices. The colloquium was an element of an exploratory study being conducted by a team of researchers from Carnegie Mellon University, Georgia State University, and The IT University of Copenhagen. Team members shared their findings from a previous phase of the study in which they had investigated quality and fast- cycle Internet-software engineering in nine organizations. Members of those organizations attended the colloquium, along with others who were invited to participate based on their perceived ability to contribute to the discussion of Internet-speed development.

This report describes the activities of the colloquium and the raw data collected during group discussions and breakout sessions. It also includes a brief description of the field study done by the cross-institutional team. A preliminary analysis of the results of the colloquium is presented in the conclusion of the report.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr020.html

CMU/SEI-2002-TR-009, ADA405844
Evolutionary Process for Integrating COTS-Based Systems (EPIC): An Overview
Albert, C. & Brownsword, L.

Government and private organizations are escalating their use of commercial off-the-shelf (COTS) and other pre- existing components in critical business systems. Attempts to exploit these components through use of traditional engineering approaches that involve defining requirements, formulating an architecture, and then searching for components that meet the specified requirements within the defined architecture have been disappointing.

The Evolutionary Process for Integrating COTS-based systems (EPIC) redefines acquisition, management, and engineering practices to more effectively leverage the COTS marketplace and other sources of pre-existing components. This is accomplished through concurrent discovery and negotiation of diverse spheres of influence: user needs and business processes, applicable technology and components, the target architecture, and programmatic constraints. EPIC codifies these practices in a structured flow of key activities and artifacts. This alternative approach is a risk-based, disciplined, spiral-engineering approach which leverages the Rational Unified Process (RUP).

This document is the first release of an overview of the EPIC framework along with its activities and artifacts. The first release of the full description of EPIC is found in the Software Engineering Institute technical report: Evolutionary Process for Integrating COTS-Based Systems (EPIC). These documents will be updated based on reader's comments and lessons learned from use of EPIC.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr009.html

CMU/SEI-2002-TR-005, ADA408653
Evolutionary Process for Integrating COTS-Based Systems (EPIC) Building, Fielding, and Supporting Commercial-off-the-Shelf (COTS) Based Solutions
Albert, C.; Brownsword, L.; Bentley, D.; Bono, T.; Morris, E.; & Pruitt, D.

This document is the first release of a full description of the EPIC framework along with its activities and artifacts. The first release of an overview of EPIC is found in the Software Engineering Institute technical report: CMU/SEI- 2002-TR-009. These documents will be updated based on reader's comments and lessons learned from use of EPIC.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr005.html

CMU/SEI-2002-TR-006, ADA406687
Guidelines for Developing a Product Line Production Plan
Chastek, G. & McGregor, J.

A production plan is a description of how core assets are to be used to develop a product in a product line. A product line organization creates such a plan to ensure that the correct core assets are used appropriately to build a specific product in a specific way. The production plans and techniques used to create products vary widely from organization to organization and from one product line to another. Because of this variance, the developers of production plans need some guidance about the plans' form and content.

This technical report provides guidance for creating, using, and evaluating a production plan. In addition, this report presents a classification scheme that describes the characteristics of a product line organization that influence the form and content of the production plan.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr006.html

CMU/SEI-2002-TR-025, ADA407778
Illuminating the Fundamental Contributors to Software Architecture Quality
Bachmann, F.; Bass, L.; & Klein, M.

An architectural tactic is a design decision that helps achieve a specific quality-attribute response. Such a tactic must be motivated by a quality-attribute analysis model. This report presents the basic concepts of analysis models for two quality attributes-modifiability and performance, identifies a collection of tactics that can be used to control responses within those models, and discusses how to analyze the models in terms of these tactics.

This report also describes how to interpret architectural designs in terms of analysis models and how to apply those models to specific architectures. In addition, it presents the analysis of several different architectural patterns taken from current literature.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr025.html

CMU/SEI-2002-TR-037, ADA412321
Internal Consistency of Key Process Areas in the Capability Maturity Model^® (CMM^®) for Software (SW-CMM), The
Jung, H. & Goldenson, D.

Evaluating the reliability of maturity level ratings is crucial for providing confidence in the results of software process assessments. This report examines the dimensions underlying the maturity construct in the Capability Maturity Model^® (CMM^®) for Software (SW-CMM) and then estimates the internal consistency (reliability) of each dimension. The analysis is based on 676 CMM-Based Appraisal for Internal Process Improvement (CBA IPI) assessments conducted during the period of January 2000 through April 2002. The results suggest that the SW-CMM maturity is a three- dimensional construct, with "Project Implementation" representing the maturity level 2 key process areas (KPAs), "Organization Implementation" representing the maturity level 3 KPAs, and "Quantitative Process Management" representing the KPAs at both maturity levels 4 and 5. The internal consistency for each of the three dimensions as estimated by Cronbach's alpha exceeds the recommended value of 0.9. Although more should be learned about the distinctions between maturity levels 4 and 5, the internal consistency of those KPAs is comparable to those at levels 2 and 3.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr037.html

CMU/SEI-2002-TR-026, ADA407793
Life-Cycle Models for Survivable Systems
Linger, R.; Lipson, H.; McHugh, J.; Mead, N.; & Sledge, C.

Today's large-scale, highly distributed, networked systems improve the efficiency and effectiveness of organizations by permitting whole new levels of organizational integration. However, such integration is accompanied by elevated risks of intrusion and compromise. Incorporating survivability capabilities into an organization's systems can mitigate these risks. Current software development life-cycle models are not focused on creating survivable systems, and exhibit shortcomings when the goal is to develop systems with a high degree of assurance of survivability. If addressed at all, survivability issues are often relegated to a separate thread of project activity, with the result that survivability is treated as an add-on property. For each life-cycle activity, survivability goals should be addressed, and methods to ensure survivability incorporated.

This report explains survivability concepts, describes a software development life-cycle model for survivability, and illustrates techniques that can be applied during new development activities to support survivability goals. It also describes a software life-cycle model and associated activities to support survivability goals for systems based on commercial off-the-shelf products.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr026.html

CMU/SEI-2002-TR-035, ADA408740
Making Architecture Design Decisions: An Economic Approach
Kazman, R.; Asundi, J.; & Klein, M.

The resources available to build any system are finite. The decisions involved in building any nontrivial system are complex and typically involve many stakeholders, many requirements, and many technical decisions. The stakeholders have an interest in ensuring that good design decisions are made-decisions that meet their technical objectives and their tolerance for risk. These decisions should, as much as possible, maximize the benefit that the system provides and minimize its cost. The Cost Benefit Analysis Method (CBAM) was created to provide some structure to this decision-making process. The CBAM analyzes architectural decisions from the perspectives of cost, benefit, schedule, and risk. While the CBAM does not make decisions for the stakeholders, it does serve as a tool to inform managers and to structure the inquiry so that rational decisions can be made. This report describes the steps of the CBAM and its application to a real-world system.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr035.html

CMU/SEI-2002-TR-021, ADA407768
Model-Based Verification: An Engineering Practice
Gluch, D.; Comella-Dorda, S.; Hudak, J.; Lewis, G.; Walker, J.; Weinstock, C.; & Zubrow, D.

Model-Based Verification (MBV) involves building and analyzing formal models of a system as an approach to identifying and guiding the correction of defects in software engineering artifacts. This report summarizes MBV and outlines the responsibilities of engineers engaged in Model-Based Verification. Each of the practices is described together with an initial set of guideline documents. These descriptions include procedural information, technical foundations for the practice, and engineering techniques for an MBV practitioner.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr021.html

CMU/SEI-2002-TR-039, ADA413664
Network Survivability Analysis Using Easel
Christie, A.

The survivability of large, complex networks such as the Internet is an increasing concern, but such networks are difficult to analyze because they are topologically complex, highly non-linear in their responses, and inherently unbounded (i.e., no node in the network can have global knowledge). To support survivability research, this report will describe how to develop statistically valid networks for analysis and, as an example of their use, applying them to the simulation of virus propagation. It will illustrate the construction of network topologies with GENeSIS, a program written in the programming language Easel. The report will also summarize ongoing significant work in this area of research and give readers insight into how information or artifacts flow through networks and how networks respond to major disruptions.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr039.html

CMU/SEI-2002-TR-031, ADA418441
Predictable Assembly of Substation Automation Systems: An Experiment Report, Second Edition
Hissam, S.; Hudak, J.; Ivers, J.; Klein, M.; Larsson, M.; Moreno, G.; Northrop, L.; Plakosh, D.; Stafford, J.; Wallnau, K.; & Wood, W.

The Predictable Assembly from Certifiable Components (PACC) Initiative at the Software Engineering Institute (SEI) is developing methods and technologies for predictable assembly. A software development activity that builds systems from components is predictable if the runtime behavior of an assembly of components can be predicted from known properties of components and their patterns of interactions (connections), and if these predictions can be objectively validated. A component is certifiable if these known properties can be obtained or validated by independent third parties. The SEI's technical approach to PACC rests on prediction-enabled component technology (PECT). At the highest level, PECT is a scheme for systematic and repeatable integration of software component technology, software architecture technology, and design analysis and verification technology. This report describes the results of an exploratory PECT prototype for substation automation, an application area in the domain of power generation, transmission, and management. This report focuses primarily on the methodological aspects of PECT; the prototype itself was only a means to expose and illustrate the PECT method.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr031.html

CMU/SEI-2002-TR-019, ADA405790
Quality Attribute Workshops, 2nd Edition
Barbacci, M.; Ellison, R.; Lattanze, A.; Stafford, J.; Weinstock, C.; & Wood, W.

Quality attribute workshops (QAWs) provide a method for analyzing a systems architecture against a number of critical quality attributes, such as availability, performance, security, interoperability, and modifiability, that are derived from mission or business goals. The QAW does not assume the existence of a software architecture. It was developed to complement the Architecture Tradeoff Analysis Method^SM (ATAM^SM) in response to customer requests for a method to identify important quality attributes and clarify system requirements before there is a software architecture to which the ATAM could be applied. The analysis is based on applying a set of test cases to a system architecture. These test cases include questions and concerns elicited from stakeholders associated with the system. The process of building the test cases allows stakeholders to communicate among themselves, thereby exposing assumptions that may not have surfaced during requirements elicitation. Our experience to date includes multiple QAWs that were held with four different U.S. government acquisition programs.

This is the second edition of a technical report describing QAWs. This report clarifies the context in which a QAW is applicable, provides a rationale for developing the process and describes it in detail, and concludes with a list of lessons learned and a discussion of how these lessons have helped evolve the process to its current state.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr019.html

CMU/SEI-2002-TR-007, ADA339773
Road to CMMI^®: Results of the First Technology' Transition Workshop, The
Carter, L.; Graettinger, C.; Patrick, M.; Wemyss, G.; & Zasadni, S.

In May 2001, the Accelerating Software Technology Adoption (ASTA) Initiative of the Software Engineering Institute (SEI) piloted a workshop to support the management of technology transition and to capture feedback from adopters of the Capability Maturity Model^® Integration (CMMI^®) Product Suite. The workshop, titled "The Road to CMMI: What Works, What's Needed?," served as both a tool for improving the transition of the CMMI Product Suite and as the first pilot of the Technology Transition Workshop (TTW) series.

The workshop was a success, generating 75 prioritized recommendations of what works, what doesn't, and what's needed for an organization to successfully transition to the CMMI Product Suite. Feedback was very positive, with participants indicating that the workshop provided beneficial information they could put into practice at their home organizations. Since the workshop, ASTA's findings have been disseminated to the broader CMMI adopter population through the CMMI Technology Conference and User Group held in November 2001, and the on-going series of CMMI Transition Workshops held in conjunction with the National Defense Industrial Association (NDIA). The findings are also available on the TTW Web site. Organizations contemplating the implementation of the CMMI Product Suite, change agents for those organizations, and researchers in technology transition and adoption will be interested in this report.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr007.html

CMU/SEI-2002-TR-008, ADA404970
Relating the Team Software Process^SM (TSP^SM) to the Capability Maturity Model^® for Software (SW-CMM^®)
Davis, N. & McHale, J. (with Strategy and Overview by Watts S. Humphrey)

Organizations using the Capability Maturity Model^® for Software (SW-CMM^®) to guide their software process improvement efforts often struggle with implementation details. The Team Software Process^SM (TSP^SM) was designed to implement effective, high-maturity processes for project teams. The TSP contains a framework as well as a set of processes, procedures, guidelines, and tools for project teams to use in the production of high-quality software on time and on budget.

Since the SW-CMM describes what an organization at a high level of process maturity should be doing, and the TSP describes how high-maturity processes are implemented for project teams, the question arises: If all projects in an organization were using the TSP, would the organization exhibit the characteristics of high process maturity, as described in the SW-CMM? To help answer this question, we performed an analysis of the degree to which the SW-CMM is addressed by the TSP. Each key practice described in the SW-CMM was classified as having an organizational or project scope, or both. Then each practice was examined to determine how it was addressed by the TSP. The results presented in this report show that the TSP implements a majority of the key practices of the SW-CMM.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr008.html

CMU/SEI-2002-TR-032, ADA412298
Rules of Thumb for the Use of COTS Products
Motsko, M.; Oberndorf, P.; Pairo, E.; & Smith, J.

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.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr032.html

CMU/SEI-2002-TR-038, ADA412311
Salion, Inc.: A Software Product Line Case Study
Clements, P. & Northrop, L.

This report is another in a series of Software Engineering Institute (SEI) case studies of organizations that have adopted the software product line approach for developing systems. It details the story of Salion, Inc., an enterprise software company providing Revenue Acquisition Management solutions tailored to the unique needs of automotive suppliers. Salion's solutions enable suppliers to organize and manage their disparate customer-interfacing activities as one coordinated business process, resulting in higher revenues, profit margins, and customer satisfaction.

This case study is unique in that Salion did not have substantial experience in its application area, although its key designers and strategists were knowledgeable about related domains. Salion pursued a reactive approach to its product line that let it respond flexibly to spontaneous business opportunities and that significantly lowered the cost of adopting the product line paradigm to its software system development. This case study describes relevant dimensions of Salion's context, how it approached several product line practice areas that were key to its strategy, the benefits gained through its product line, lessons learned, and the major thematic aspects of the Salion story.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr038.html

CMU/SEI-2002-TR-023, ADA407792
SEI Independent Research and Development Projects
Cross, S.; Forrester, E.; Hissam, S.; Kazman, R.; Levine, L.; Linger, R.; Longstaff, T.; Monarch, I.; Smith, D.; & Wallnau, K.

Each year, the Software Engineering Institute (SEI) undertakes several Independent Research and Development (IR&D) projects. These projects serve to (a) support feasibility studies investigating whether further work by the SEI would be of potential benefit and (b) support further exploratory work to determine if 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 IR&D projects that were conducted during fiscal year 2002 (October 2001 through September 2002).

http://www.sei.cmu.edu/publications/documents/02.reports/02tr023.html

CMU/SEI-2002-TR-010, ADA399794
Software Acquisition Capability Maturity Model^® (SA-CMM^®)
Version 1.03
Cooper, J. & Fisher, M. (eds.)

Government and industry have the need to improve the maturity of their internal software acquisition processes. In order for organizations to make improvements, they must know the ultimate goal and what is required to achieve that goal. Additionally, progress toward achieving the goal must be measurable. A capability maturity model^® provides the framework needed to facilitate the desired improvement. The Software Acquisition Capability Maturity Model
(SA-CMM^®) has been developed to provide such a framework.

This new version incorporates change requests that have been received, as well as the results of lessons learned from conducting appraisals and from the use of Version 1.02.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr010.html

CMU/SEI-2002-TR-024, ADA407795
Software Architecture Reconstruction: Practice Needs and Current Approaches
O'Brien, L.; Stoermer, C.; & Verhoef, C.

Software architectures serve as the blueprints for systems, and they are central to the development of software product lines and the design of component-based systems. In existing systems, the architecture often must be reconstructed to reflect the as-built system accurately. This report presents the concept of practice scenarios for architecture reconstruction, which outline common problem/solution pairs that can be used in the strategic application of architecture reconstruction at Department of Defense (DoD) and commercial organizations. Based on an investigation of already developed and presented reconstruction approaches, the report describes deficiencies that have been uncovered in several practice scenarios and proposes improvements.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr024.html

CMU/SEI-2002-TR-022, ADA403815
Using EVMS with COTS-Based Systems
Staley, M. J.; Oberndorf, P.; & Sledge, C.

With the increased use of commercial off-the-shelf (COTS) software products, managers of software development projects must plan and track performance of projects that have new challenges and risks. A system developer may be required to integrate multiple COTS products with newly developed custom components and legacy system components. How are these new activities and tasks planned and monitored? Can traditional management methods be used?

Earned Value is a project management tool used extensively to plan and monitor performance against the plan. This paper's focus is on the use of Earned Value in the context of a COTS-Based System (CBS). It's written for an audience already familiar with Earned Value Project Management; only the basic definitions are discussed here with the associated terminology. A bibliography is included, offering good sources for obtaining more in-depth information on Earned Value history and methodology.

http://www.sei.cmu.edu/publications/documents/02.reports/02tr022.html

[2007] [2006] [2005] [2004] [2003] [2002] [2001] [2000] [1999] [1998] [1997] [1996] [1995] [1994] [1993] [1992] [1991] [1990] [1989] [1988] [1987] [1986] [PDF]