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]

2000 Reports

Security Improvement Modules

CMU/SEI-SIM-010, ADA379469
Securing Network Servers
Allen, J.; Kossakowski, K.; Ford, G.; Konda, S.; & Simmel, D.

The development of computer networks has resulted in an important class of computers: network servers. The primary purpose of these machines is to provide services, including both computational and data services, to other computers on the network.

Because of their service role, it is common for servers to store many of an organizations most valuable and confidential information resources. They also are often deployed to provide a centralized capability for an entire organization, such as communication (electronic mail) or user authentication. Security breaches on a network server can result in the disclosure of critical information or the loss of a capability that can affect the entire organization. Therefore, securing network servers should be a significant part of your network and information security strategy.

Many security problems can be avoided if servers and networks are appropriately configured. Default hardware and software configurations are typically set by vendors to emphasize features and functions more than security. Since vendors are not aware of your security needs, you must configure new servers to reflect your security requirements and reconfigure them as your requirements change.

The practices recommended here are designed to help you configure and deploy network servers that satisfy your organizations security requirements. The practices may also be useful in examining the configuration of previously deployed servers.

http://www.cert.org/security-improvement/#modules

CMU/SEI-SIM-011, ADA379920
Securing Public Web Servers
Kossakowski, K. & Allen, J.

The World Wide Web is one of the most important ways for your organization to publish information, interact with Internet users, and establish an e-commerce business presence. However, if you are not rigorous in securely configuring and operating a public Web site, you leave yourself and your organization vulnerable to a variety of security problems. You could find yourself in an embarrassing situation because malicious intruders have changed the content of your Web pages.

Compromised Web sites have served as the entry point for intrusions into an organization's internal networks for the purpose of accessing confidential information. Your organization can face business losses or legal action if an intruder successfully violates the confidentiality of customer data. Denial-of-service attacks can make it difficult, if not impossible, for users to access your Web site. This is especially critical if you are using your site to conduct business.

The practices recommended here are designed to help you mitigate the risks associated with these and several other known security problems. They build upon and assume the implementation of all practices described in the security module Securing Network Servers [Allen 00]. You need to ensure that you first configure a secure general purpose server before tailoring its configuration to operate as a public Web server.

http://www.cert.org/security-improvement/#modules

Special Reports

CMU/SEI-2000-SR-009, ADA383836
Application of the Architecture-Based Design Method to the Electronic House, An
Bachmann, F.; Bass, L.; & Klein, M.

The Architecture-Based Design (ABD) Method is a method for designing the software architecture of a product line of systems. It has previously been described in the technical report, The Architecture Based Design Method (CMU/ SEI-2000-TR-001). This report elaborates an example of the application of this method to designing the software architecture. The example is the house of the future.

The house of the future is assumed to have a collection of devices within the house that are controlled by a computer network. Entertainment, security, heating/air-conditioning, and utility devices will all interoperate and will be controlled from a central network. The software architecture to support the house must be extendible and flexible, and it must have high security, high performance, and high availability. In this report, we present a first-level decomposition of the software architecture as a demonstration of the ABD Method.

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

CMU/SEI-2000-SR-013, ADA387258
Guidance on Commercial-Based and Open Systems for Coast Guard Program Managers
Place, P.

With increasing frequency, Coast Guard Program Managers are acquiring systems based on both commercial products and open systems. This brings both benefits and risks. Although the benefits of using commercial products and open systems are widely publicized, the risks are often overlooked. This document discusses various risks and provides guidance that may be used to mitigate those risks.

http://www.sei.cmu.edu/publications/documents/00.reports/00sr013.html

CMU/SEI-2000-SR-011, ADA387262
Improving Predictability in Embedded Real-Time Systems
Feiler, P.; Lewis, B.; & Vestal, S.

This paper discusses a model-based architectural approach for improving predictability of performance in embedded real-time systems. This approach utilizes automated analysis of task and communication architectures to provide insight into schedulability and reliability during design. Automatic generation of a runtime executive that performs task dispatching and inter-task communication eliminates manual coding errors and results in a system that satisfies the specified execution behavior. The MetaH language and toolset supports this model-based approach. MetaH has been used by the U.S. Army in a pilot project applied to missile guidance systems. Reduced time and cost benefits that have been observed will be discussed as a case study. The paper closes by outlining the current state of commercial availability of such technology and efforts to develop standards, such as those put forth by the Society of Automotive Engineers (SAE); Avionics Systems Division (ASD); working group on Avionics Architecture Description Language (AADL); and the Object Management Group (OMG) Unified Modeling Language (UML) working group on real-time and performance support in UML.

http://www.sei.cmu.edu/publications/documents/00.reports/00sr011.html

CMU/SEI-2000-SR-003, ADA377440
November 1999 High Maturity Workshop, The
Paulk, M. & Chrissis, M.

A workshop for high maturity organizations was held on November 16-18, 1999, at the Soft-ware Engineering Institute (SEI) in Pittsburgh. The purpose of this workshop was to better understand practices that characterize Level 4 and 5 organizations. Topics of discussion included both practices described in the CMM^® (Capability Maturity Model^®) and other practices that have a significant impact in mature organizations. Two themes were anticipated to be important to the workshop participants: statistical process control for software and the reliability and credibility of Level 4 and 5 assessments. Additional topics were solicited from the participants on CMM integration, measurement, technology, human issues, and quality assurance. This report contains brief summaries of the high maturity organizations participating in the workshop and the various working group reports.

http://www.sei.cmu.edu/publications/documents/00.reports/00sr003.html

CMU/SEI-2000-SR-001
Quality Attribute Workshop Participant's Handbook
Barbacci, M.; Ellison, R.; Weinstock, C.; & Wood, W.

In large software systems, the achievement of qualities such as performance, security, and modifiability is dependent not only on code-level practices but also on the overall software architecture. Thus, it is in developers' best interests to determine, at the time a system's software architecture is specified, whether the system will have the desired qualities.

With the sponsorship of the U.S. Coast Guard's Deepwater Acquisition Project the SEI has developed the concept of a "Quality Attribute Workshop" in which system stakeholders focus on the analysis and evaluation of system requirements and quality attributes. The purpose of the workshop is to identify scenarios from the point of view of a diverse group of stakeholders and to identify risks (e.g., inadequate performance, successful denial-of-service attacks) and possible mitigation strategies (e.g., replication, prototyping, simulation). Stakeholders include architects, developers, users, maintainers, and people involved in installation, deployment, logistics, planning, and acquisition. This special report describes the process we use to conduct a workshop, information required, suggested tools, and expected outcomes of a workshop.

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

CMU/SEI-2000-SR-004, ADA377988
Software Architecture Documentation in Practice: Documenting Architectural Layers
Bachmann, F.; Bass, L.; Carriere, J.; Clements, P.; Garlan, D.; Ivers, J.; Nord, R.; & Little, R.

This report represents the first milestone of a work in progress. That work is a comprehensive handbook on how to produce high-quality documentation for software architectures. The handbook, tentatively entitled Software Architecture Documentation in Practice, will be published in mid- to late-2000 by Addison Wesley Longman as a book in the SEI series on software engineering. Aimed squarely at the practitioner, the handbook is intended to fill a gap in the literature: There is a complete lack of language-independent guidance about how to actually capture an architecture in written form so that it can fulfill its purpose as a communication vehicle providing a unified design vision to all of the varied stakeholders of a development project.

The theme of the work is that documenting an architecture entails documenting the set of relevant views of that architecture, and then completing the picture with documentation of information that transcends any single view. The report lays out our approach and organization for the complete book, and provides full guidance for one of the most commonly used architectural views: the layer diagram. The audience for this book is the community of practicing architects, apprentice architects, and developers who are on the receiving end of architectural documentation.

http://www.sei.cmu.edu/publications/documents/00.reports/00sr004.html

CMU/SEI-2000-SR-006, ADA382585
Spiral Development-Building the Culture
Report on the CSE-SEI Workshop, February, 2000, A
Hansen, W.; Foreman, J.; Carney, D.; Forrester, E.; Graettinger, C.; Peterson, W.; & Place, P.

A number of organizations are successfully applying the Spiral Development Model (SDM) and finding it valuable in addressing such challenges as rapid development, COTS (commercial-off-the-shelf) software integration, new technologies, and product line management. However, other organizations have experienced difficulties with spiral development-due to over-relaxed controls, underestimated risks, existing sequential development policies, inflexible financing mechanisms, ingrained cultures, and confusion about what spiral development is and how to apply it. To attack these problems, a workshop was held February 9-11, 2000, at the University of Southern California under the sponsorship of its Center for Software Engineering (CSE) and the Software Engineering Institute (SEI) of Carnegie Mellon University. Work groups at the workshop recommended specific actions aimed at building and spreading a culture for the SDM community. These can be described as defining, improving, promoting, and studying SDM, educating about SDM, adapting to SDM, and enhancing teamwork. This report summarizes the workshop and presents its recommendations.

http://www.sei.cmu.edu/publications/documents/00.reports/00sr006.html

CMU/SEI-2000-SR-008, ADA382590
Spiral Development: Experience, Principles, and Refinements
Spiral Development Workshop February 9, 2000
Boehm, B.

Spiral development is a family of software development processes characterized by repeatedly iterating a set of elemental development processes and managing risk so it is actively being reduced. This paper characterizes spiral development by enumerating a few "invariant" properties that any such process must exhibit. For each, a set of "variants" is also presented, demonstrating a range of process definitions in the spiral development family. Each invariant excludes one or more "hazardous spiral look-alike" models, which are also outlined. This report also shows how the spiral model can be used for a more cost-effective incremental commitment of funds, via an analogy of the spiral model to stud poker. An important and relatively recent innovation to the spiral model has been the introduction of anchor point milestones. The latter part of the paper describes and discusses these.

http://www.sei.cmu.edu/publications/documents/00.reports/00sr008.html

CMU/SEI-2000-SR-002, ADA377375
Survey of High Maturity Organizations, The 1999
Paulk, M.; Goldenson, D.; & White, D.

Over the last few years the Software Engineering Institute has investigated the high maturity practices of Maturity Level 4 and 5 software organizations via assessments, site visits, workshops, and surveys. This report summarizes the observations from the 1999 survey of high maturity organizations. Areas covered in the survey include management, engineering, tools and technology, quantitative analysis, and people issues. A specific area of interest is statistical process control, which is addressed in some detail in this report, but the observations cover a variety of engineering and management practices, including issues outside the scope of the Capability Maturity Model^® for Software.

http://www.sei.cmu.edu/publications/documents/00.reports/00sr002.html

Technical Notes

CMU/SEI-2000-TN-009, ADA383775
Active Reviews for Intermediate Designs
Clements, P.

This paper introduces a technical review approach that is a blend of a stakeholder-centric, scenario-based, architecture evaluation method such as the Architecture Tradeoff Analysis Method^SM (ATAM^SM), and an active design review (ADR) of design specifications. There is a need for a technical review of a design finer-grained than an architecture, but not yet completely documented. Such a review exposes the design to its user community of application programmers, and allows early feedback on the overall approach, before the design is institutionalized in a detailed specification. This paper describes a recently piloted software design review technique that we call Active Review for Intermediate Designs (ARID). A hybrid of ADRs and scenario-based methods such as the ATAM, ARID fills a niche in the spectrum of technical design techniques between architecture at one end, and design specification documents at the other.

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

CMU/SEI-2000-TN-001, ADA375859
Basic Concepts of Product Line Practice for the DoD
Bergey, J.; Fisher, M.; Gallagher, B.; Jones, L.; & Northrop, L.

Industrial experience demonstrates clearly that a product line approach for software-intensive systems can save money and result in faster time to field higher quality systems. Many within the Department of Defense (DoD) recognize the benefits of product lines, but also recognize that there are significant challenges to adopting this approach. Many of these challenges stem from the fact that the DoD is in the business of acquiring systems rather than developing them.

The Product Line Systems Program is publishing a series of technical notes designed to condense knowledge about product line acquisition practices into a concise and usable form for the DoD acquisition manager and practitioner.

This technical note provides background information about product lines to serve as a foundation for other technical notes in this series. Key terms, concepts, and benefits of a product line approach are given. Additionally, concepts of product line acquisition in a DoD context are discussed.

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

CMU/SEI-2000-TN-004, ADA377385
Guidelines for Using OAR Concepts in a DoD Product Line Acquisition Environment
Bergey, J. & Smith, D.

Many DoD organizations are considering product line initiatives as a means of overcoming the issues of quality, cost, and schedule inherent in a "one-at-a-time" system development or acquisition paradigm. Because a product line approach revolves around the creation of a comprehensive set of core assets, mining and adapting (i.e., reengineering) existing legacy system assets can offer significant leverage. By mining and adapting these assets, an organization can exploit the proven capabilities of existing systems, reduce the funding required, and develop/acquire new systems of higher quality within a shorter time frame.

This technical note focuses on providing guidance for DoD organizations for mining legacy systems to obtain core assets that will fit into a previously defined software architecture for a product line. We explain how insights from a conceptual model, Options Analysis for Reengineering (OAR), can be used in an acquisition context to provide the government with an approach for obtaining greater insight and understanding into a contractor's proposed technical reengineering approach.

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

CMU/SEI-2000-TN-015, ADA389005
K-BACEE: A Knowledge-Based Automated Component Ensemble Evaluation Tool
Seacord, R.; Mundie, D.; & Boonsiri, S.

Component reuse suffers from the inability of system integrators to effectively identify ensembles of compatible software components that can be easily integrated into a system. To address this problem, we have developed an automated process for identifying component ensembles that satisfy a system requirements specification; and for ranking these ensembles based on a knowledge base of system integration rules.

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

CMU/SEI-2000-TN-008, ADA378147
Mining Existing Assets for Software Product Lines
Bergey, J.; O'Brien, L.; & Smith, D.

Mining of existing assets offers an organization the potential to leverage all, or part, of its cumulative system investments, and thus represents a critical practice area in implementing a software product line. However, there are significant risks in achieving success because of the poorly documented and maintained state of many existing systems and the fact that many systems were initially developed for different paradigms than current distributed, Web-oriented, object-oriented approaches.

Four basic steps are required to successfully mine assets: 1) preliminary information gathering, 2) making decisions on whether to mine assets and which type of overall strategy to use, 3) obtaining detailed technical understanding of existing software assets, and 4) rehabilitation of assets.

This note outlines basic considerations for each of these steps. It outlines typical information to collect before an analysis. It then outlines a model for making decisions on mining legacy assets, and discusses the technical understanding of assets and the rehabilitation of assets.

Because of its importance as a strategy for product lines, architecture reconstruction is discussed, as it is supported by an automated tool set known as the Dali workbench.

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

CMU/SEI-2000-TN-002, ADA377656
Modeling the Space Shuttle Liquid Hydrogen Subsystem
Atanacio, B.

This paper describes experiences with modeling the liquid hydrogen subsystem of the space shuttle. The Symbolic Model Verifier tool and the Software Cost Reduction tool set were used to model and specify the behavior of the system. The tools were then used to check for errors in the models. Modeling a problem from several different perspectives offers the chance to uncover discrepancies among different models and to understand the problem space enough to ask important questions about the behavior of the system. Each tool presented different issues in modeling the problem. Both models and a breakdown of the time spent during this study are included as appendices.

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

CMU/SEI-2000-TN-017, ADA392284
Quality Attribute Design Primitives
Bass, L.; Klein, M.; & Bachmann, F.

This report focuses on the quality attribute aspects of architectural mechanisms. An architectural mechanism is "a structure whereby objects collaborate to provide some behavior that satisfies a requirement of the problem" [Booch 96]. This report addresses mechanisms that significantly affect quality attribute behavior and have sufficient content for analysis. Codifying such mechanisms will enable architects to identify the choices necessary to achieve quality attribute goals. This, in turn, will set a foundation for further software architectural design and analysis.

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

CMU/SEI-2000-TN-003, ADA377453
Survey of Legacy System Modernization Approaches, A
Comella-Dorda, S.; Wallnau, K.; Seacord, R.; & Robert, J.

Information systems are critical assets for modern enterprises and incorporate key knowledge acquired over the life of an organization. Although these systems must be updated continuously to reflect evolving business practices, repeated modification has a cumulative effect on system complexity, and the rapid evolution of technology quickly renders existing technologies obsolete. Eventually, the existing information systems become too fragile to modify and too important to discard. However, organizations must consider modernizing these legacy systems to remain viable. The commercial market provides a variety of solutions to this increasingly common problem of legacy system modernization. However, understanding the strengths and weaknesses of each modernization technique is paramount to select the correct solution and the overall success of a modernization effort. This paper provides a survey of modernization techniques including screen scraping, database gateway, XML integration, database replication, CGI integration, object- oriented wrapping, and "componentization" of legacy systems. This general overview enables engineers performing legacy system modernization to preselect a subset of applicable modernization techniques for further evaluation.

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

CMU/SEI-2000-TN-010, ADA395200
Using Quality Attribute Workshops to Evaluate Architectural Design Approaches in a Major System Acquisition: A Case Study
Bergey, J.; Barbacci, M.; & Wood, W.

To a large extent, a system's software architecture determines the quality attributes of both the software and the entire system. It is also one of the earliest artifacts available for evaluation. For a Department of Defense (DoD) or government acquisition organization, the ability to evaluate software architectures early in the acquisition cycle can positively affect the delivered system. To assist a government organization in evaluating architectures, a series of Quality Attribute Workshops (QAWs) were planned and an initial set conducted as part of a competitive acquisition of a complex, integrated command and control system. The QAW is a "lightweight" (i.e., non-intrusive) version of the Architecture Tradeoff Analysis Method^SM (ATAM^SM) developed by the Software Engineering Institute (SEI).

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

CMU/SEI-2000-TN-007, ADA388773
Using the Architecture Tradeoff Analysis Method^SM to Evaluate a Reference Architecture: A Case Study
Gallagher, B.

The software architecture of a system is a major determinant of software quality and one of the earliest artifacts available for evaluation. For a government acquisition organization, the ability to evaluate software architectures can have a favorable impact on the delivered system. This technical note describes the application of the Architecture Tradeoff Analysis Method^SM (ATAM^SM) to evaluate a reference architecture for ground-based command and control systems. The use of the term reference architecture in the context of this application is presented. A general overview of the ATAM process is provided and the results of the ATAM are explored, including the benefits of performing an ATAM-based architecture evaluation both to the acquirer and to the developer.

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

Technical Reports

CMU/SEI-2000-TR-010, ADA385347
Activity Framework for COTS-Based Systems, An
Oberndorf, T.; Brownsword, L.; & Sledge, C.

As the use of commercial technology and products in systems becomes increasingly popular, particularly for government organizations, program managers need a new understanding of the dynamic principles of system creation. However, there is little information on how the use of commercial off-the-shelf (COTS) products affects existing system development practices or what new processes are needed for the successful use of COTS products. As part of the COTS-Based Systems Initiative at Carnegie Mellon University's Software Engineering Institute (SEI), we are studying this diversity in the software development process. As part of that work, we have started to articulate some of the activities and practices that are necessary for the effective development and lifetime support of COTS-based systems. This document provides an introduction to those activities and practices.

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

CMU/SEI-2000-TR-005, ADA377438
Analysis of Lead Assessor Feedback for CBA IPI Assessments Conducted July 1998-October 1999
Dunaway, D.; Seow, M.; & Baker, M.

In the Appraiser Program of the Software Engineering Institute (SEI), authorized Lead Assessors lead Capability Maturity Model-Based Appraisals for Internal Process Improvement (CBA IPI). At the conclusion of each assessment, they are required to submit certain artifacts to the SEI. Data from assessments is recorded to provide the community with information on the state of the software community's process maturity, as related to the Capability Maturity Model^® (CMM^®) for Software Version 1.1. These data can be viewed on the SEI Web site: http://www.sei.cmu.edu/ sema/profile.html.

Additional feedback data are required of a Lead Assessor in order to monitor the consistency of use of the assessment method for quality control purposes. Data are collected from Lead Assessors, assessment team members, and sponsors of the assessments. The results reported in this document reflect information sent to the SEI by Lead Assessors through a Lead Assessor's Requirements Checklist. The checklist aids the Lead Assessors in keeping track of their implementation of each of the method's requirements. The checklist also provides information back to the community regarding metrics being reported by Lead Assessors; this helps in more effective planning for future assessments. In addition, the checklist acts as a quality control mechanism to monitor the consistency of use of each of the method's activities.

Thanks to the Lead Assessors who contributed the data in order that it can be shared with other Lead Assessors and the community.

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

CMU/SEI-2000-TR-011, ADA382587
ARC, V1.0 Assessment Requirements for CMMI^,® Version 1.0
CMMI Product Development Team

The Assessment Requirements for CMMI^® (ARC) V1.0 defines the requirements considered essential to assessment methods intended for use with CMMI models. In addition, a set of assessment classes is defined based on assessment usage scenarios. These classes are intended primarily for developers of assessment methods to use with CMMI capability models in the context of the CMMI Product Suite. Additional audiences for the document include lead assessors, and other individuals who are involved in or may be interested in process assessment or improvement.

The approach employed to provide guidance to assessment method developers is to define a class of assessment method usage scenarios (which are based on years of experience in the process improvement community) called assessment classes. Requirements are then allocated to each class as appropriate based on the attributes associated with that class. Thus, a particular assessment method may declare itself to be an ARC class A, B, or C assessment method. This designation implies the sets of ARC requirements which the method developer has considered when designing the method.

Assessment methods which satisfy all of the ARC requirements are called class A methods; in addition to being used to render ratings for benchmarking purposes, class A assessment methods can be used to conduct 15504-conformant assessments.

More information on the CMMI Product Suite is available on the World Wide Web at http://www.sei.cmu.edu/cmmi.

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

CMU/SEI-2000-TR-001, ADA375851
Architecture Based Design Method, The
Bachmann, F.; Bass, L.; Chastek, G.; Donohoe, P.; & Peruzzi, F.

This paper presents the Architecture Based Design (ABD) method for designing the high-level software architecture for a product line or long-lived system. Designing an architecture for a product line or long-lived system is difficult because detailed requirements are not known in advance. The ABD method fulfills functional, quality, and business requirements at a level of abstraction that allows for the necessary variation when producing specific products. Its application relies on an understanding of the architectural mechanisms used to achieve this fulfillment.

The method provides a series of steps for designing the conceptual software architecture. The conceptual software architecture provides organization of function, identification of synchronization points for independent threads of control, and allocation of function to processors. The method ends when commitments to classes, processes and operating system threads begin to be made. In addition, one output of the method is a collection of software templates that constrain the implementation of components of different types. The software templates include a description of how components interact with shared services and also include "citizenship" responsibilities for components.

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

CMU/SEI-2000-TR-004, ADA382629
ATAM: Method for Architecture Evaluation
Kazman, R.; Klein, M.; & Clements, P.

If a software architecture is a key business asset for an organization, then architectural analysis must also be a key practice for that organization. Why? Because architectures are complex and involve many design tradeoffs. Without undertaking a formal analysis process, the organization cannot ensure that the architectural decisions made-particularly those which affect the achievement of quality attribute such as performance, availability, security, and modifiability- are advisable ones that appropriately mitigate risks. In this report, we will discuss some of the technical and organizational foundations for performing architectural analysis, and will present the Architecture Tradeoff Analysis Method^SM (ATAM^SM) a technique for analyzing software architectures that we have developed and refined in practice over the past three years.

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

CMU/SEI-2000-TR-019, ADA388776
CMMI^® for Systems Engineering/Software Engineering, Version 1.02, Continuous Representation (CMMI-SE/SW, V1.02, Continuous)
CMMI Product Development Team

Capability Maturity Model^® Integration (CMMI^®) provides guidance for improving your organization's processes and ability to manage the development, acquisition, and maintenance of products and services. CMM Integration places proven practices into a structure that helps your organization assess its organizational maturity and process area capability, establish priorities for improvement, and guide the implementation of these improvements. CMM Integration was conceived to sort out the problem of using multiple CMMs. Three source models-(1) Capability Maturity Model for Software (SW-CMM^®) v2.0 draft C, (2) Electronic Industries Alliance/Interim Standard (EIA/IS) 731, and (3) Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98-were combined into a single model to be used in enterprise-wide process improvement and integration activities.

A common framework to support the future integration of other discipline-specific CMMI models was developed. In addition, all CMMI products were developed to be consistent and compatible with the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 15504 technical report for software process assessment. Like other CMMs, CMMI models provide guidance for organizations to use when they develop processes. CMMI models are not processes or process descriptions. The actual processes used in an organization depend on many factors, including application domain(s) and organization structure and size.

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

CMU/SEI-2000-TR-018, ADA388775
CMMI^® for Systems Engineering/Software Engineering, Version 1.02, Staged Representation (CMMI-SE/SW, V1.02, Staged)
CMMI Product Development Team

CMMI^® Product Development Team Integration provides guidance for improving your organization's processes and ability to manage the development, acquisition, and maintenance of products and services. CMM Integration places proven practices into a structure that helps your organization assess its organizational maturity and process area capability, establish priorities for improvement, and guide the implementation of these improvements. CMM Integration was conceived to sort out the problem of using multiple CMMs. Three source models-(1) Capability Maturity Model^® for Software (SW-CMM^®) v2.0 draft C, (2) Electronic Industries Alliance/Interim Standard (EIA/IS) 731, and (3) Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98-were combined into a single model to be used in enterprise-wide process improvement and integration activities.

http://www.sei.cmu.edu/publications/documents/00.reports/00tr018.html

CMU/SEI-2000-TR-031, ADA388992
CMMI^® for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.02, Continuous Representation (CMMI-SE/SW/IPPD, V1.02, Continuous)
CMMI Product Development Team

Capability Maturity Model^® Integration (CMMI^®) provides guidance for improving your organization's processes and ability to manage the development, acquisition, and maintenance of products and services. CMM Integration places proven practices into a structure that helps your organization assess its organizational maturity and process area capability, establish priorities for improvement, and guide the implementation of these improvements. CMM Integration was conceived to sort out the problem of using multiple CMMs. Three source models-(1) Capability Maturity Model^® for Software (SW-CMM^®) v2.0 draft C, (2) Electronic Industries Alliance/Interim Standard (EIA/IS) 731, and (3) Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98-were combined into a single model to be used in enterprise-wide process improvement and integration activities.

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

CMU/SEI-2000-TR-012, ADA387265
Evaluation Theory Perspective of the Architecture Tradeoff Analysis Method^SM (ATAM^SM), An
Lopez, M.

Evaluation is a key analytical process in all disciplines and intellectual and practical endeavors. Also it is a key process in the software engineering field in which it is possible to apply different types of evaluation methods. The study of diverse evaluation methods performed in software and non-software disciplines and theoretical concepts could provide knowledge of the complexity and ubiquity of this important process. This study was the basis to obtain a set of basic evaluation components. They constitute a framework which can be used to developed a new evaluation method or review an existing one with the purpose of improving the development of the method being analyzed. In particular, this framework had been applied to review the Architecture Tradeoff Analysis Method^SM (ATAM^SM) by means of the identification of the evaluation components and the analysis of their development or elicitation. In this paper, the target, evaluation criteria, yardstick, data-gathering techniques, synthesis techniques and evaluation process of ATAM have been identified and analyzed. The most relevant conclusions are the role of stakeholders and the significance of attribute- based architectural styles (ABASs) in an ATAM evaluation.

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

CMU/SEI-2000-TR-002, ADA375843
Fourth Product Line Practice Workshop Report
Bass, L.; Clements, P.; Donohoe, P.; McGregor, J.; & Northrop, L.

The Fourth Software Engineering Institute (SEI) Product Line Practice Workshop was a hands-on meeting held in December 1999 to share industry practices in the area of tool support for software product lines, to explore the technical and non-technical issues involved, and to evolve the SEI Product Line Practice Framework. This report synthesizes the workshop presentations and discussions, which described practices and issues associated with tool support for software product lines.

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

CMU/SEI-2000-TR-003, ADA381033
Improving the Acquisition of Software Intensive Systems
Goldenson, D. & Fisher, M.

Acquisitions of software intensive systems by the Department of Defense (DoD) have often suffered from poor product quality, cost overruns, and schedule slips. In turn, these problems have frequently been linked to the inability of project offices to successfully manage the acquisition of the software components of the systems.

There have been a number of efforts to provide the necessary education and training to improve the skills and capabilities of managers for software intensive acquisitions. However, acquisition problems remain pervasive in the DoD.

More must be known about the causes and underlying issues surrounding these problems. Specifically, the needs of the acquisition management offices must be better understood to help them improve. This includes a better understanding of how education and training can improve the individual manager's skills and competency related to acquiring such systems.

To elicit these needs, the Software Engineering Institute (SEI) conducted a survey of senior acquisition managers. The survey focused on the performance of their organizations, particularly with respect to a series of skills and competency areas that may affect an organization's ability to successfully acquire software intensive systems.

Results indicate that the program executive officers (PEOs) and program managers (PMs) who completed the survey were reasonably well satisfied with the capabilities of their organizations to acquire software intensive systems. In many cases, however, the source of the expertise for such acquisitions were contractors either supporting the organizations or the prime contractors developing these systems. Comparable expertise often was unavailable in government acquisition organizations themselves. From this fact, the need for government expertise in these acquisitions was noted. In addition, the survey queried participants on the best way to obtain this expertise through education and training.

Finally, recommendations derived from survey results are offered to increase software acquisition education and training opportunities for managers.

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

CMU/SEI-2000-TR-022, ADA387268
Personal Software Process^SM (PSP^SM), The
Humphrey, W.

The Personal Software Process^SM(PSP^SM) provides engineers with a disciplined personal framework for doing software work. The PSP process consists of a set of methods, forms, and scripts that show software engineers how to plan, measure, and manage their work. It is introduced with a textbook and a course that are designed for both industrial and academic use. The PSP is designed for use with any programming language or design methodology and it can be used for most aspects of software work, including writing requirements, running tests, defining processes, and repairing defects. When engineers use the PSP, the recommended process goal is to produce zero-defect products on schedule and within planned costs. When used with the Team Software Process^SM (TSP^SM), the PSP has been effective in helping engineers achieve these objectives.

This report describes in detail what the PSP is and how it works. Starting with a brief discussion of the relationship of the PSP to general quality principles, the report describes how the PSP was developed, its principles, and its methods. Next is a summary of the PSP courses, the strategy used for teaching the PSP, selected data on PSP experience, PSP adoption in university curricula, and the status of PSP introduction into industry. The report concludes with comments on likely future trends involving the PSP.

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

CMU/SEI-2000-TR-006, ADA407772
Simplex Architecture Performance and Cost
Gagliardi, M.; Marz, T.; Altman, N.; & Walker, J.

The Simplex Architecture facilitates the building of dependable and upgradable real-time systems. Before using the technology, potential users want to know more about the costs of adopting the Simplex paradigm compared to the benefits of using it. This paper examines Simplex performance and the costs associated with its use.

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

CMU/SEI-2000-TR-020, ADA388773
Simulation Model for Managing Survivability of Networked Information Systems, A
Moitra, S. & Konda, S.

In this paper we develop a model to evaluate the tradeoffs between the cost of defense mechanisms for networked systems and the resulting expected survivability after a network attack. The model consists of three submodels. The first submodel simulates the occurrence of attacks or incidents. The second submodel simulates the impact of an attack on the system. This depends on the type of attack and the defense mechanism installed in the system. The third submodel assesses the survivability of the system which depends on the degree of its degradation after the attack. By varying the level of defense in the simulation, we examine how this expected survivability changes with the defense level. Since costs are assumed to increase with the strength of the defense system, we can derive a cost/survivability curve that managers can use to decide on the appropriate level of security for their organizations. We have also explored the sensitivity of expected survivability to various parameters of the model, such as, the mix of attack types and the rate of occurrence of incidents.

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

CMU/SEI-2000-TR-014, ADA383774
Software Process Achievement at Tinker Air Force Base
Butler, K. & Lipke, W.

On May 20, 1999, the Test Software and Industrial Automation Branches of the Oklahoma City Air Logistics Center's Directorate of Aircraft Management's Software Division at Tinker Air Force Base were awarded the IEEE Award for Software Process Achievement. This report will outline the process improvement activities and successes that led to the award.

http://www.sei.cmu.edu/publications/documents/00.reports/00tr014.html

CMU/SEI-2000-TR-021, ADA388774
Survivability of Network Systems: An Empirical Analysis, The
Moitra, S. & Konda, S.

This report presents an extended analysis of CERT Coordination Center^® incidents data (from 1988 to 1995) and applies the results to simulate attacks and their impacts on network sites. The data were "sanitized" prior to the analysis to ensure complete anonymity. A model for the incidents process is discussed and extended. It consists of three parts: a stochastic process for the random occurrence of incidents at sites, a model for the state transition process for an attacked system given a level of defense, and a method of estimating the expected survivability of the system given possible degradations due to these attacks. This approach leads to the estimation of a survivability/cost function, which shows the tradeoffs involved between cost and system survivability. Information Systems (IS) managers can use this to determine the most appropriate level of defense for the network systems of their organizations. The stochastic process was simulated based on parameter values obtained from actual reported data. Extensive sensitivity analyses are reported that indicate how expected survivability would change with varying parameter analysis results values. The report concludes with a discussion of future work to be done and the appendix has details of the simulation model and further data.

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

CMU/SEI-2000-TR-013, ADA383771
Survivable Network Analysis Method
Mead, N.; Ellison, R.; Linger, R.; Longstaff, T.; & McHugh, J.

Society is increasingly dependent on large-scale, networked information systems of remarkable scope and complexity. This dependency magnifies the far-reaching consequences of system damage from attacks and intrusions. Yet no amount of security can guarantee that systems will not be penetrated. Incorporating survivability capabilities into an organizations systems can mitigate the risks. Survivability is the capability of a system to fulfill its mission in a timely manner despite intrusions, failures, or accidents. The three tenets of survivability are (1) resistance to intrusions, (2) recognition of intrusion effects, and (3) recovery of services despite successful intrusions. The survivability of existing or planned systems can be analyzed at the level of system architectures or requirements. This report describes the Survivable Network Analysis (SNA) method developed at the SEI's CERT Coordination Center^®. The four-step SNA method guides stakeholders through an analysis process intended to improve system survivability when a system is threatened. The method focuses on preservation of essential system services that support the organizational mission. SNA findings are summarized in a Survivability Map that enumerates current and recommended architectural strategies. SNA has been successfully applied to commercial and governmental systems, and continues to evolve toward increasing rigor in its application.

http://www.sei.cmu.edu/publications/documents/00.reports/00tr013.html

CMU/SEI-2000-TR-023, ADA387279
Team Software Process^SM (TSP^SM), The
Humphrey, W.

The Team Software Process^SM (TSP^SM) guides engineering teams in developing software-intensive products. Early experience with the TSP shows that its use improves the quality and productivity of engineering teams while helping them to more precisely meet cost and schedule commitments. The TSP is designed for use with teams of 2 to 20 members, and the larger multi-team TSP process is designed for teams of up to about 150 members. While TSP versions are planned for larger projects, they are not available at the time of this writing.

This report describes the TSP and how it was developed. Starting with a brief background discussion of software quality, the report provides an overview of the basic elements of teamwork. It then describes the relationships among the TSP, Personal Software Process^SM (PSP^SM), and Capability Maturity Model^® (CMM^®) process improvement initiatives. The report also describes the TSP process structure, launching a TSP team, the TSP teamworking process, and the issues and methods for introducing the TSP. The report concludes with a review of TSP experience, current status, and trends.

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

CMU/SEI-2000-TR-024, ADA387259
Third DoD Product Line Practice Workshop Report
Cohen, S.; Gallagher, B.; Fisher, M.; Jones, L.; Krut, R.; Northrop, L.; O'Brien, W.; Smith, D.; & Soule, A.

The Software Engineering Institute (SEI) held the Third Department of Defense (DoD) Product Line Practice Workshop in March 2000. The workshop was a hands-on meeting to identify industry-wide best practices in software product lines; to share DoD product line practices, experience, and issues; and to discuss ways in which the current gap between commercial best practice and DoD practice can be bridged. This report synthesizes the workshop presentations and discussions.

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

CMU/SEI-2000-TR-015, ADA387260
Team Software Process^SM: An Overview and Preliminary Results of Using Disciplined Practices, The
McAndrews, D.

The Software Engineering Institute has developed the Team Software Process^SM (TSP^SM) to help engineering teams more effectively build software-intensive products. The TSP addresses many of the current problems of building software-intensive products and shows teams and managers explicitly how to address these problems.

This report describes the TSP technology as an implementation strategy for teams that are attempting to apply disciplined software process methods. It provides some of the background and rationale for the TSP approach, as well as an overview of the technology. Then, the report presents initial results of the use of the TSP technology in four different organizational settings. In each of these organizations, the data show that defect densities found in system- level test activities and the actual duration of these system-level tests were reduced significantly with the use of the TSP. In addition, the accuracy of software estimates improved, and the variation in estimation accuracy was significantly reduced. Based on the analysis of these results, some assertions are made to help organizations set goals for improvement.

http://www.sei.cmu.edu/publications/documents/00.reports/00tr015.html

CMU/SEI-2000-TR-008, ADA379930
Volume II: Technical Concepts of Component-Based Software Engineering, 2nd Edition
Bachmann, F.; Bass, L.; Buhman, C.; Comella-Dorda, S.; Long, F.; Robert, J.; Seacord, R.; & Wallnau, K.

The Software Engineering Institute is undertaking a feasibility study of "component-based software engineering" (CBSE). The objective of this study is to determine whether CBSE has the potential to advance the state of software engineering practice and, if so, whether the SEI can contribute to this advancement. This report is the second part of a three-part report on the study. Volume I contains a market assessment for CBSE. Volume III outlines a proposed course of action for the SEI. Volume II, this report, establishes the technical foundation for SEI work in CBSE. The paper asserts that the key technical challenge facing CBSE is to ensure that the properties of a system of components can be predicted from the properties of the components themselves. The key technical concepts of CBSE that are needed to support this vision are described: component, interface, contract, component model, component framework, composition, and certification.

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

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