🚀 go-pugleaf

Software Engineering Institute
Information Management
Software Engineering Institute Documents


HOW TO ACCESS SEI REPORTS ELECTRONICALLY

The Software Engineering Institute (SEI) has begun electronic
distribution of some-not all-of its publications. The
procedure by which you can obtain electronic copies of SEI
reports is described on pages 1 and 2 of this document. Since
many SEI reports are yet unavailable in electronic form,
instructions for obtaining hardcopies of such reports appear
on page 5 of this document.

FTP File transfer protocol (FTP) is a facility that allows
files to be transferred to and from remote network sites.
Brief instructions for using FTP are provided below; if you
require additional information about FTP, contact your system
administrator.

SEI DIRECTORY NAME
The directories listed in /pub/documents contain files that
are accessible via anonymous FTP.


SEI MACHINE ADDRESS
The SEI machine address is:

		ftp.sei.cmu.edu
                      or 
		128.237.2.179


INSTRUCTIONS
If you are working at a UNIX machine connected to the Internet, use the 
following procedure to access SEI files.


TO CONNECT TO THE SEI FTP MACHINE
1	At your Unix prompt, type:

ftp ftp.sei.cmu.edu

2	At the login prompt, type:

anonymous

3	At the password prompt, 
type:

your electronic mail address 
(e.g., jones@cs.xsu.edu)

4	Change to the documents 
directory by typing:

cd /pub/documents

5	Get the READ.ME file by 
typing:

get READ.ME

You should now have a copy of the READ.ME file on your home 
machine.

Repeat Steps 1- 5 from the above procedure to obtain the
documents you want. Step 5 may be repeated as many times as
needed to obtain the desired documents; otherwise, terminate
the process, as is indicated below:

6	Terminate the FTP process 
by typing:

quit


COPYRIGHT NOTE
Some of the files may be temporarily read-protected pending the 
resolution of some copyright issues.
File format

The documents in /pub/documents are formatted as PostScript
files, and thus may be printed on a PostScript printer at
your site. All PostScript files have a .ps suffix.


FIGURES
Some of the files contain figures that have not yet been made
available electronically. Until this is resolved, such files
(ones containing figures markers) will print without figures.
Until the figures are made available electronically, feel
free to contact one of the distribution centers (listed
below) to obtain hardcopies of the documents.


PRINTER
Most of the documents use several of the following PostScript
fonts: Helvetica, Times, New Century Schoolbook, Courier, and
Symbol. Be certain to use a printer that can support these
fonts.  All files MUST be printed with the pages in the order
that they appear in the file. Some print spoolers attempt to
reverse the pages before printing so that the output page
stack will be in the proper order. This may cause the files
to fail to be printed. A common symptom of such a page order
error is having the file printed almost entirely in Courier
font.  Test print

You may want to test these procedures before downloading
large documents. For that purpose, a short test document
appears in the /pub/documents directory in file testTR.ps.
It is a three page excerpt from a technical report; the
second page should be blank.  Photocopying

Documents in PostScript form are intended to be reproduced as
two- sided documents. The left and right margins will be
different widths on odd- and even-numbered pages. If you
choose to make a two-sided document from the printed
original, you may wish to check the first few pages and
insert a blank page wherever needed (such as after the title
page on some documents) to ensure that the pagination is
correct.

THE ANNOTATED LISTING
Documents appearing in the annotated listing that are denoted
with the following icon are available via anonymous FTP:


QUESTIONS
If you cannot print a file, first verify that the print
failure is not due to a problem at your site. Next, reread
and retry the above instructions.  Lastly, if the problem
remains, send electronic mail to bjz@sei.cmu.edu describing
the hardware/operating system being used, the type of printer
on which you're attempting to print the document, and a
description of the problem.



HOW TO ORDER BOUND COPIES OF SEI REPORTS
Software Engineering Institute (SEI) technical reports are
available from Research Access, Inc. (RAI), National
Technical Information Service (NTIS), or the Defense
Technical Information Center (DTIC).  (Note: To order
documents from DTIC, you must provide the DTIC accession
number for the desired report. As an example, "ADA235641" is
the DTIC number for the SEI report Rate Monotonic Analysis
for Real-Time Systems.)

DISTRIBUTING CENTERS
If you wish to request a bound copy of an SEI report, please
contact RAI, NTIS, or DTIC directly. The addresses are
provided below. Several SEI reports have not yet been filed
with DTIC; therefore, they do not have DTIC accession
numbers.

RAI
Research Access Inc.
3400 Forbes Avenue
Suite 302
Pittsburgh, PA 15213
Telephone: 1800 685-6510
FAX: (412) 682-6530


DTIC
Defense Technical Information Center
ATTN: FDRA Cameron Station
Alexandria, VA 22304-6145
Telephone: (703) 274-7633

(Note that DTIC limits distribution to government contractors
who have established a DTIC account.).


NTIS
National Technical Information Service
U.S. Department of Commerce
Springfield, VA 22161-2103
Telephone: (703) 487-4600


		-----begin Part 1 (of 5) -----


TECHNICAL REPORTS

Ada Validation Tests for Rate Monotonic Scheduling Algorithms
CMU/SEI-92-TR-1, ADA253325
Kohout, K.A., Meyer, K., Goodenough, J.B.

This report presents a set of tests for checking whether an
Ada runtime system properly supports certain rate monotonic
scheduling algorithms, specifically, the basic inheritance
and priority ceiling protocols. These tests are intended to
be used by vendors and by users to validate implementations
of these protocols. The report describes the tests and how
they are to be used. The source code is available
electronically.


Conceptual Basis for a Project Support Environment Services Model, The
CMU/SEI-92-TR-2, ADA253324
Brown, A.W., Feiler, P.H.

The foundation for a Project Support Environment (PSE)
services reference model is presented. This model is to be
used as the basis for understanding more about the meaning of
integration in a PSE, comparing and contrasting PSE tools and
products, and for helping in the identification of PSE
interface areas that are candidates for standardization. The
model views a PSE as a set of services, distinguishing
between services as perceived by PSE end-users, and those
provided as mechanisms within the PSE infrastructure. Process
constraints on those services are separately identified. The
motivation for the view of a PSE is described, followed by a
detailed description of the main structure and elements of
the model.


Analysis Technique for Examining Integration in a Project Support Environment, An
CMU/SEI-92-TR-3, ADA253351
Brown, A.W., Feiler, P.H.

In this paper we describe the use of a Project Support
Environment (PSE) services reference model as an analysis
technique that helps in describing, understanding, and
comparing aspects of integration in a PSE. The model is
briefly described, before being used as the basis for
discussing a number of issues with regard to PSE integration.
A major focus of this paper is a discussion of the interfaces
of interest in a PSE - interfaces within a single service,
between services, and between services and the PSE end-users

The paper concludes with a discussion of possible
interpretations and developments of the model to suit
different user requirements.



Software Process Development and Enactment: Concepts and Definitions
CMU/SEI-92-TR-4
Feiler, P.H. and Humphrey, W.

The scientific treatment of the software process is
relatively new and, as with any new field, the initial
terminology is often confusing. When terms can have a
diversity of meanings, technical communication is more
difficult and technological progress is constrained. This
paper defines a core set of concepts about the software
process. These concepts are intended to facilitate
communications and to provide a framework for further
definitions. The definitions focus on essential concepts;
however, they do not represent a comprehensive glossary of
common software process terms. Following an initial overview,
this paper outlines the basic process concepts which underlie
the definitions. The definitions are then grouped in four
sets: a framework for process definition, an engineering of
process, an enactment of process, and process properties.
This is followed by illustrations of the use of these
concepts in several domains. The paper concludes with some
observations on the definition process.


Issues and Techniques of CASE Integration with Configuration
CMU/SEI-92-TR-5, ADA253323
Wallnau, K.C.

Commercial computer-aided software engineering (CASE) tool
technology has emerged as an important component of practical
software development environments. Issues of CASE tool
integration have received heightened attention in recent
years, with various commercial products and technical
approaches promising to make inroads into this difficult
problem.  One aspect of CASE integration that has not been
adequately addressed is the integration of CASE tools with
configuration management (CM)-including both CM policies and
systems. Organizations need to address how to make CASE tools
from different vendors work effectively with an
organization's CM policies and tools (in effect, integrate
CASE with CM) within the context of the rapidly evolving
state of commercial integration technology. This report
describes key issues of the integration of CASE with CM from
a third-party integrator's perspective, i.e., how to approach
the integration of CASE and CM in such a way as to not
require fundamental changes to the implementation of the
tools or CM systems themselves.


Introduction to Software Process Improvement
CMU/SEI-92-TR-7, ADA253326
Humphrey, W.

While software now pervades most facets of modern life, its
historical problems have not been solved. This report
explains why some of these problems have been so difficult
for organizations to address and the actions required to
address them. It describes the Software Engineering
Institute's (SEI) software process maturity model, how this
model can be used to guide software organizations in process
improvement, and the various assessment and evaluation
methods that use this model. The report concludes with a
discussion of improvement experience and some comments on
future directions for this work.


Past, Present, and Future of Configuration Management, The
CMU/SEI-92-TR-8, ADA254175
Dart, S.A.

Automated support for configuration management (CM) is one
aspect of software engineering environments that has
progressed over the last 20 years. The progress is seen by
the burgeoning interest in CM, many technical papers and
conferences involving CM, a large number of CM tool vendors,
and new software development environments that incorporate CM
capabilities. This paper is about future issues affecting
solutions to CM problems. To put the future into perspective,
it is necessary to discuss the past and present situation for
CM. The past evolves around CM systems built in-house and
supplemented with manual procedures and policies for
executing the CM functions. The present consists of a better
understanding of CM, the beginnings of a common vocabulary
for CM, existence of many third-party CM tools and
environments supporting CM, and recognition that a single CM
system does not solve all CM problems and that there is a
need for better understanding of CM process support. The
future involves technical, process-oriented, political,
standardization and managerial challenges. These include the
need to provide for new CM requirements, understand the
effects of advances in environments, deal with governmental
requirements on contractors for using certain CM
capabilities, and acquire more management commitment for
resources in solving the CM problems of an organization. One
way to start addressing these challenges is through the
definition of a CM services model that provides a conceptual
framework for all CM capabilities. As CM is examined more
closely in relation to software engineering, it becomes
evident that advances in software technology are needed to
aid advances in CM technology.


Parallels in Computer-Aided Design Framework and 
Software Development Environment Efforts
CMU/SEI-92-TR-9, ADA253327
Dart, S.A.

This paper is an attempt to raise awareness about the
similarities between the efforts of the software development
environment (SDE) community and the electronic computer-aided
design (CAD) framework community. Apparently, SDE and CAD
engineers are not aware of what is happening in each other's
fields, yet cross-pollenization of efforts would assist
progress. Both communities are addressing the same problems
of providing configuration management (CM), tool integration,
and process management support in their environment.  Each
community can benefit from the other since both have similar
needs and have found, and are finding, similar solutions. It
is particularly useful to consider collaborative efforts as
both communities are evolving towards standardization.


Analysis of Reservation-Based Dual-Link Networks
CMU/SEI-92-TR-10, ADA254176
Sha, L., Sathaye, S.S., Strosnider, J.K.

Next-generation networks are expected to support a wide
variety of services. Some services such as video, voice, and
plant control traffic have explicit timing requirements on a
per- message basis rather than on the average. In this paper,
we develop a general model of reservation-based dual-link
networks to support real-time communication. We examine the
desirable properties of this network and the difficulties in
achieving these properties. We then introduce the concept of
coherence and develop a theory of coherent dual-link
networks. We show that a coherent dual-link network can be
analyzed as though it is a centralized system. We then
discuss practical considerations in implementing a dual-link
network, and implications of this work to address problems
observed in the IEEE 802.6 metropolitan area network
standard.


Software Measurement Concepts for Acquisition Program Managers
CMU/SEI-92-TR-11, ADA254177
Rozum, J.A.

For program managers to effectively manage and control
software development, they need to incorporate a measurement
process into their decision making and reporting process.
Measurement costs money, but it can also save money through
early problem detection and objective clarification of
critical software development issues. This report provides
some basic concepts that program managers can use to help
integrate measurement into the process for managing software
development. It also provides an initial set of measures to
help address common issues in software intensive
acquisitions.

 When the Software Acquisition Metrics Working Group first met in 1989, only a few 
reports existed on the subject of how program managers could use software measurement; 
now, other reports have been written. The goal of this report is not to compete with those 
reports, but to use them as starting points for expansion. This report should be viewed not 
as a standard, but as containing guidelines and advice for program officers and managers 
starting to use software measurement in their own organizations.


Issues in Requirements Elicitation
CMU/SEI-92-TR-12
Christel, M.G. and Kang, K.C.

There are many problems associated with requirements
engineering, including problems in defining the system scope,
problems in fostering understanding among the different
communities affected by the development of a given system,
and problems in dealing with the volatile nature of
requirements. These problems may lead to poor requirements
and the cancellation of system development, or else the
development of a system that is later judged unsatisfactory
or unacceptable, has high maintenance costs, or undergoes
frequent changes.  By improving requirements elicitation, the
requirements engineering process can be improved, resulting
in enhanced system requirements and potentially a much better
system.

Requirements engineering can be decomposed into the activities of requirements elicitation, 
specification, and validation. Most of the requirements techniques and tools today focus 
on specification, i.e., the representation of the requirements. This report concentrates instead 
on elicitation concerns, those problems with requirements engineering that are not 
adequately addressed by specification techniques. An elicitation methodology is proposed 
to handle these concerns.

This new elicitation methodology strives to incorporate the advantages of existing elicitation 
techniques while comprehensively addressing the activities performed during requirements 
elicitation. These activities include fact-finding, requirements gathering, evaluation and 
rationalization, prioritization, and integration. Taken by themselves, existing elicitation 
techniques are lacking in one or more of these areas.


Experience with a Course on Architectures for Software Systems Par I: Course Description
CMU/SEI-92-TR-17
Garlan, D. Shaw, M. Okasaki, C., Scott, C.M., Swonger, R.F.

As software systems grow in size and complexity their design
problem extends beyond algorithms and data structures to
issues of system design. This area receives little or no
treatment in existing computer science curricula. Although
courses about specific systems are usually available, there
is no systematic treatment of the organizations used to
assemble components into systems. These issues - the software
architecture level of software design - are the subject of a
new course that we taught for the first time in spring 1992.
In this pair of reports, Part I presents the motivation for
the course, the content and structure of the current version,
and our plans for improving the next version. Part II
consists of teaching materials from the first offering,
including assignments and overheads for lectures.



Software Measurement for DOD Systems: Recommendations for Initial Core Measures
CMU/SEI-92-TR-19
Carleton, A.D., Park, R.E., Goethert, W.B., Florac, W.A., Bailey, E., and Pfleeger, S.L.

This report presents our recommendations for a basic set of
software measures that Department of Defense (DoD)
organizations can use to help plan and manage the
acquisition, development, and support of software systems.
These recommendations are based on work that was initiated by
the Software Metrics Definition Working Group and
subsequently extended by the SEI to support the DoD Software
Action Plan. The central theme is the use of checklists to
create and record structured measurement descriptions and
reporting specifications. These checklists provide a
mechanism for obtaining consistent measures from project to
project and for communicating unambiguous measurement
results.



The Analysis of SEI Software Process Assessment Results 1987-1991
CMU/SEI-92-TR-24
Kitson, D.H., and Masters, S.

This report presents our recommendations for a basic set of
software measures that Department of Defense (DoD)
organizations can use to help plan and manage the
acquisition, development, and support of software systems.
These recommendations are based on work that was initiated by
the Software Metrics Definition Working Group and
subsequently extended by the SEI to support the DoD Software
Action Plan. The central theme is the use of checklists to
create and record structured measurement descriptions and
reporting specifications. These checklists provide a
mechanism for obtaining consistent measures from project to
project and for communicating unambiguous measurement
results.

This report focuses on the results of SEI software process
assessments conducted over a four year period beginning in
1987. It characterizes the software processes used by
software managers and practitioners at the assessed sites and
classifies issues identified during the assessments. The
basis for the characterization and classification is a
software process maturity model developed by the SEI. This
report contributes to the existing body of knowledge on the
state of practice of software engineering in the U.S. by
characterizing the sites from a software process maturity
perspective and profiling site software process weaknesses.
The data analyzed is drawn from SEI software process
assessments of 59 government and industry software sites.
This work is an analysis of existing assessment data rather
than a designed study. The participating sites were not
randomly selected; accordingly, they do not necessarily
constitute a statistically valid sampling of the U.S.
software industry.


Software Measures and the Capability Maturity Model
CMU/SEI-92-TR-25
Baumert, J.H. and McWhinney, M.S.

This document describes a set of software measures that are
compatible with the measurement practices described in the
Capability Maturity Model for Software. These measures, in
the form of software indicators, cover thirteen different
categories that include progress, effort, cost, and quality.
Each indicator category contains example figures which
illustrate behavior that may occur on a project. The text
provides users with tips on how to use these figures or
similar ones on their projects. Project software managers and
software engineering process groups can use these indicators
during the software development life cycle to gain insight
into the software development process and software process
improvement activities. The indicators chosen have been
successfully used on projects in the software industry.



Software Development Risk: Opportunity, Not Problem
CMU/SEI-92-TR-30
Van Scoy, R.

What is risk? What is risk management? What does risk
management have to do with software? Noted software expert
Tom Gilb says:

If you don't actively attack the risks, they will actively
attack you [Gilb88, p. 72].

But what does it mean to actively attack risks? We answer
these questions by examining the problems that exist in
software development today and presenting the SEI Risk
Program approach to turning risk into opportunity.

We begin by reviewing the fundamental concepts of risk and
elaborating on how these basic concepts apply to the
development of large, software-intensive systems. We then
develop our strategy for seeing a systematic approach to risk
management in software development be routinely practiced.

There are two key activities we are using to implement our
strategy. The first is our risk management paradigm. The
paradigm defines a set of continuous activities that must be
undertaken to resolve technical risk in a systematic and
structured way.  The second is our risk assessment process
for collaborating with clients to identify their technical
risks.

We end with our ultimate goal: establishing an effective risk
management ethic as standard practice in the software
engineering industry.


Understanding Integration in a Software Development Environment
CMU/SEI-91-TR-31, ADA248119
Brown, A.W., Feiler, P.H., Wallnau, K.C.

In the past ten years there has been a great deal of interest
in the concept of a Software Development Environment (SDE) as
a complete, unifying framework of services supporting most
(or all) phases of software development and maintenance. We
identify three levels at which the issue of integration in a
SDE arises as a key concept at the mechanism level
(interoperability of the hardware and basic software), at the
end-user services level (combining the methods and paradigms
of the various tools), and at the process level (adapting
end-user services to the working practices of different
users, projects and organizations).

In this paper we examine SDEs from an integration
perspective, describing the previous work in this area and
analyzing the integration issues that must be addressed in an
SDE.  For illustrative purposes, a particular focus of the
paper is the configuration management aspects of an SDE.


Requirements Engineering and Analysis Workshop Proceedings
CMU/SEI-91-TR-30, ADA250415

Inadequate, incomplete, erroneous, and ambiguous system and
software requirements are a major and ongoing source of
problems in systems development. These problems manifest
themselves in missed schedules, budget excesses, and systems
that are to varying degrees unresponsive to the true needs of
the sponsor. These difficulties are often attributed to the
poorly defined and ill-understood processes used to elicit,
specify, analyze, and validate requirements.

The Software Engineering Institute (SEI) hosted the
Requirements Engineering and Analysis Workshop in Pittsburgh,
Pennsylvania, on March 12-14, 1991. The intention of the
workshop was to focus discussion on issues and activities
that could help the Department of Defense (DoD) to deal more
effectively with the requirements of mission-critical
systems.  The SEI workshop built upon work performed
previously at the Requirements Engineering and Rapid
Prototyping Workshop held by the U.S. Army
Communications-Electronics Command (CECOM) Center for
Software Engineering in Eatontown, New Jersey, on November
14-16, 1989.

The workshop participants were divided into four working
groups: Requirements Engineering Process and Products,
Requirements Volatility, Requirements Elicitation, and
Requirements Engineering Techniques and Tools. A summary of
the findings of each working group follows.


Critical Review of the Current State of IPSE Technology, A
CMU/SEI-91-TR-29, ADA244294
Brown, A.W.

In the past ten years there has been a great deal of interest
in the concept of an Integrated Project Support Environment
(IPSE) as a complete, unifying framework of services
supporting most (or all) phases of software development and
maintenance. In this paper we evaluate the current state of
research work in this area, suggest some reasons for the
relative lack of success, and make proposals for ensuring
measured progress in the future.



Application of Feature-Oriented Domain Analysis to the Army 
Movement Control Domain and Appendices A-I
CMU/SEI-91-TR-28
Cohen, S.G., Stanley Jr., J.L., Peterson, A.S., and Krut, Jr., R.W.

This report documents an analysis of the army movement
control domain performed by the Software Engineering
Institute (SEI) and a team of movement control experts from
the Army. This report includes common terminology and
requirements extracted from Army doctrine, experts in the
field, and movement control systems. The report also
describes the potential for prototyping of systems using
domain analysis products and the tool support needed.


Comparison of U.S., Japanese Software Process Maturity, A
CMU/SEI-91-TR-27, ADA245051
Humphrey, W., Kitson, D., Gale, J.

This report characterizes the software processes currently
used by software managers and practitioners in the U.S.,
Japan.

The U.S. data for this comparative study of the state of
software practice in the U.S., Japan is drawn from extensive
SEI assessments conducted from 1987 through 1989. The
Japanese maturity data was gathered during a three-week trip
to Japan by the authors. This includes data on 168 U.S.
projects and 196 Japanese software projects.

This data is not a statistically valid sample of the software
capabilities of either the U.S.  or Japanese software
industries. However, the data does indicate that the Japanese
software industry is, in some respects, both weaker and
stronger than that in the U.S. There are also significant
differences in the maturity findings between the U.S.,
Japanese organizations, and these have important implications
for software organizations in both countries.


Application-Level Implementation of the Sporadic Server, An
CMU/SEI-91-TR-26, ADA242129
Gonzalez Harbour, M., Sha, L. 

The purpose of this paper is to introduce a sporadic server
algorithm that can be implemented as an application-level
task, and that can be used when no runtime or operating
system level implementation of the sporadic server is
available. The sporadic server is a simple mechanism that
both limits and guarantees a certain amount of execution
power dedicated to servicing aperiodic requests with soft or
hard deadlines in a hard real-time system. The sporadic
server is event-driven from an application viewpoint, but
appears as a periodic task for the purpose of analysis and,
consequently, allows the use of analysis methods such as rate
monotonic analysis to predict the behavior of the real-time
system.

When the sporadic server is implemented at the
application-level, without modification to the runtime
executive or the operating system, some of its requirements
cannot be met strictly and, therefore, some simplifications
need to be assumed. We show that even with these
simplifications, the application-level sporadic server
proposed in this paper has the same worst-case performance as
the full-featured runtime sporadic server algorithm, although
the average case performance is slightly worse. The
implementation requirements are a runtime prioritized
preemptive scheduler and system calls to change a task's or
thread's priority. Two implementations are introduced in this
paper, one for Ada and the other for POSIX 1003.4a, Threads
Extension to Portable Operating Systems.



Key Practices of the Capability Maturity Model
CMU/SEI-91-TR-25, ADA240604
Weber, C.V., Paulk, M., Wise, C., Withey, J. (Editors:
Chrissis, M.B., Couturiaux, S.D., Redish, G.)

This document, "Key Practices of the Capability Maturity
Model," provides the key practices that correspond to the key
process areas at each maturity level of the Capability
Maturity Model and information on how to interpret the key
practices.


Capability Maturity Model for Software
CMU/SEI-91-TR-24, ADA240603
Paulk, M.C., Curtis, B., Averill, E., Bamberger, J. Kasse, T., Konrad, M., Perdue, J. Weber, C., 
Withey, J.

In November 1986, the Software Engineering Institute with
assistance from the Mitre began developing a process maturity
framework that would assist organizations in improving their
software process. This effort was initiated in response to a
request to provide the federal government with a method for
assessing the capability of their software contractors. in
September 1987, the SEI released a brief description of the
process maturity framework and a maturity questionnaire
(CMU/SEI-87-TR-23). The SEI intended the maturity
questionnaire to provide a simple tool for identifying areas
where an organization's software process needed improvement.
Unfortunately, the questionnaire was too often regarded as
"the model" rather than as a vehicle for exploring process
maturity issues.

After four years of experience with the software process
maturity framework and the preliminary version of the
maturity questionnaire, the SEI has evolved the software
process maturity framework into a fully defined model. This
model will be used in a systematic, principled way to derive
a maturity questionnaire. By fully elaborating the maturity
framework, a model has emerged that provides organizations
with more effective guidance for establishing process
improvement programs that were offered by the maturity
questionnaire. Using knowledge acquired from software process
assessments and extensive feedback from both industry and
government, an improved version of the process maturity
framework and been produced called the Capability Maturity
Model for Software (CMM).  This paper is an introduction too
the revised model.


Building Distributed Ada Applications from Specifications and Functional Components
CMU/SEI-91-TR-22, ADA244697
Doubleday, D.L., Barbacci, M.R., Weinstock, C.B., Gardner, M.J., Lichota, R.W.

Durra is a language and support environment for the
specification and execution of distributed Ada applications.
A Durra programmer describes an application as a collection
of processes and data links.  More complicated application
descriptions may also include a structuring of this
collection that varies dynamically according to a set of
reconsideration conditions.  Each process defined in the
application description is associated with an independently
compiled Ada subprogram that implements the behavior of that
process. The Durra programmer specifies the distribution of
application components by assigning them to virtual nodes
called clusters.  For each cluster, the Durra compiler
generates a multithreaded Ada program that imports the code
for the processes assigned to that node and manages their
execution.  Durra also facilitates rapid prototyping through
the use of tools that interpret timing specifications
associated with processes and generates Ada code to simulate
their expected behavior.


Durra:  An Integrated Approach to Software Specification, Modeling, and Rapid Prototyping
CMU/SEI-91-TR-21, ADA242128
Barbacci, M., Doubleday, D. Weinstock, C. Lichota, R.

Software specification, modeling, and prototyping activities
are often performed at different stages in a software
development project by individuals who use different
specialized notations. The need to manually interpret and
transform information passed between stages can significantly
decrease productivity and can serve as a potential source of
error. Durra is a non-procedural language designed to support
the development of distributed applications consisting of
multiple, concurrent, large-grained tasks executing in a
heterogeneous network. Durra provides a framework through
which one can specify the structure of an application in
conjunction with its behavior, timing, and implementation
dependencies. These specifications may be validated by
passing behavioral and timing information associated with
each Durra task description to a run-time interpreter.
Similarly, software prototypes may be constructed by
directing this information to a suitable source code
generator. We have already developed an interpreter and
source code translator for a language based on simple timing
expressions. We are presently constructing a source code
generator for a more complex language defined by SMARTS (the
Specification Methodology for Adaptive Real-Time systems
developed by Hughes Aircraft Company).



Design Specifications for Adaptive Real-Time Systems
CMU/SEI-91-TR-20, ADA245051
Lichota, R.W.

The design specification method described in this report
treats a software architecture as a set of run-time entities,
including tasks and external input/output elements, which
interact either via messages or shared data structures.
Tasks have a single thread of execution and represent program
units that may be executed concurrently.  External input
elements produce input requests which in turn trigger a set
of low level activities to be executed by tasks.  External
output elements consume results which are produced by tasks.
The specification method discussed here facilitates the
description of the dynamic structure of run-time entities,
the synchronization and communication between these entities,
and their resource consumption and production properties
(which include timing and sizing).



Description of Cluster Code Generated by the Durra Compiler, A
CMU/SEI-91-TR-19, ADA248118
Doubleday, D., Gardner, M., Weinstock, C.

Durra is a language and support environment for the
specification and execution of distributed Ada applications.
The Durra programmer specifies the distribution of
application components by assigning them to virtual nodes
called clusters. For each cluster named in an application
description, the Durra compiler generates an Ada package body
with a standardized format. Within the confines of the
format, the content of the package body varies according to
the requirements placed upon the cluster by the Durra
application description. The cluster-specific package body is
compiled and linked with a fixed set of Ada compilation
units, common to all clusters, to form a multitasking Ada
program. The intended audience for this document is Durra
application developers, who will need an understanding of the
concepts presented here in order to be effective Durra
application debuggers.


DURRA: A Task-Level Description Language Reference Manual (Version 3)
CMU/SEI-91-TR-18, ADA246405
Barbacci, M.R., Doubleday, D.L., Gardner, M., Lichota, R.W., Weinstock, C.

Durra is a language designed to support the development of
distributed programming applications consisting of
concurrent, large-grained processes devoted to specific
pieces of the application. During execution time the
application processes run on possibly separate processors,
and communicate with each other by sending messages of
different types across communication links. The application
developer is responsible for prescribing a way to manage all
of these resources, called a task-level application
description. It describes the processes to be executed, the
assignments of processes to processors, and the communication
channels required to transmit messages data between
processes. Durra is a task-level description language, a
notation in which to write these application descriptions.

This document is a revised version of the original reference
manual. It describes the syntax and semantics of the language
and incorporates all the language changes introduced as a
result of our experiences writing application descriptions in
Durra.

A companion document, Durra: A Task-Level Description
Language User's Manual, describes how to use the compiler and
support tools.


Issues in Real-Time Data Management
CMU/SEI-91-TR-17, ADA240712
Graham, M.

This report explores issues related to the use of database
management technology in support of real-time systems
programming. It describes the potential benefits of database
support for real-time systems, and it describes the state of
the art in database technologies relevant to real-time. The
report concludes that more research and development will be
needed before the benefits of database management can be
applied to real-time system development.


Measurement in Practice
CMU/SEI-91-TR-16, ADA241781
Rifkin, S.

A few organizations have reputations for implementing
excellent software measurement practices. A sample of these
organizations was surveyed in site visits. Clear patterns of
practices emerged and they are reported at a consolidated,
"lessons learned" level and in more detailed case studies.


Proceedings of the CASE Adoption Workshop
CMU/SEI-91-TR-14
Huff, C., Smith, D., Stepien-Oakes, K., Morris, E., Zarrella, P.

The Software Engineering Institute (SEI) CASE Technology
Project sponsored a workshop to address a number of key CASE
adoption issues. The workshop was held at the SEI in
Pittsburgh, Pennsylvania on November 13-14, 1990. At the
workshop, a representative group of SEI affiliates from
industry, government, and academia discussed among themselves
such adoption topics as CASE benefits, realistic CASE budget
estimates, CASE tool fit, CASE adoption roles, and factors in
the project success of CASE. The results of these discussions
are summarized in this report.


CASE Studies in Environment Integration 
CMU/SEI-91-TR-13, ADA248152
Morris, E.J.

Four environment builders and participants at two workshops
were queried concerning the environment standards,
implementations, and technology that prove useful in the
integration of tools into software engineering environments.
Specific information was gathered about the software and
hardware environments in which tool integration occurred, the
goals of integration, the tools integrated, mechanisms used,
and the standards applied. Observations concerning the
current state of tool and environment integration are
provided, and trends in integration are identified.



Notes on Applications of the SQL Ada Module Description Language (SAMeDL)
CMU/SEI-91-TR-12, ADA240851
Chastek, G., Graham, M., Zelesnik, G.

The SQL Ada Module Description Language (SAMeDL) is a
language for describing information services to be provided
to Ada application programs by SQL database management
systems. This report shows how the SAMeDL can be adapted and
extended to provide services to applications needing advanced
features (e.g., dynamic SQL, or using non-ANSI standard data
types (decimal, date) or having other unusual requirements.
It also contains short descriptions of some implementation
details.


Tool Integration and Environment Architectures
CMU/SEI-91-TR-11, ADA237810
Wallnau, K., Feiler, P.

The expanding CASE market is having substantial impact on
software development environment technology in the area of
environment support for tool integration. Sharpened awareness
of CASE integration requirements, particularly in the context
of the larger number of fully developed CASE tools, has
resulted in a technology shift away from monolithic
integrated project support environments (IPSE) derived form
the Stoneman model in favor of highly distributed
environments based upon a federation of environment services.
Federated environments promise environment framework support
for the reuse of a large number of existing CASE tools and
the development of highly interactive, tightly-integrated
CASE environments. The evolution of environment framework
technology to support CASE federation is predicated on an
improved understanding of the techniques and issues of tool
integration. One reflection of this improved understanding is
recognition of the need to address integration mechanisms,
tool semantic integration, and tool process integration as
separate but related issues. This paper describes the
evolution of environment architectures to support federated
CASE integration and outlines the implications of this
evolution on the technical issues of CASE tool integration.


Models for Undergraduate Project Courses in Software Engineering
CMU/SEI-91-TR-10, ADA241780
Shaw, M., Tomayko, J.

The software engineering course provides undergraduates with
an opportunity to learn something about real-world software
development. Since software engineering is far from being a
mature engineering discipline, it is not possible to define a
completely satisfactory syllabus. Content with a sound basis
is in short supply, and the material most often taught is at
high risk of becoming obsolete within a few years.

Undergraduate software engineering courses are now offered in
more than a hundred universities. Although three textbooks
dominate the market, there is not yet consensus on the scope
and form of the course. The two major decisions an instructor
faces are the balance between technical and management topics
and the relation between the lecture and project components.
We discuss these two decisions, with support from sample
syllabi and survey data on course offerings in the United
States and Canada. We also offer some advice on the
management of a project-oriented course.

This report also appears as Carnegie Mellon University,
School of Computer Science Technical Report No.
CMU-CS-91-174.



Software Engineering Education Directory
CMU/SEI-91-TR-9, ADA250039

This directory provides information about software
engineering courses and software engineering degree programs
offered by colleges and universities, primarily in the United
States.


Issues in Tool Acquisition
CMU/SEI-91-TR-8, ADA244292
Zarrella, P. Smith, D., Morris, E.J

This technical report identifies issues involved in the
acquisition of Computer Aided Software Engineering (CASE)
tools. Among the issues identified and discussed are cost,
performance, process support, maintenance, data management,
tool integration, and standardization. The report concludes
with recommendations intended for individuals or groups
responsible for acquiring CASE tools.


Configuration Management Models in Commercial Environment
CMU/SEI-91-TR-7, ADA235782
Feiler, P.

A number of advances can be observed in recent commercial software development 
environments in support of configuration management (CM). These advances include: 
configurations as managed objects; transparent access to repositories; and, in addition to 
the familiar checkout/checkin model, three CM models based on configurations. These CM 
models are the composition model, the long transaction model, and the change set model. 
Typically, one or two of the models can be found in a system.

This report analyzes the models with respect to their
potential impact on the software development process,
resulting in several observations. Some of the models exist
in a number of variations, each impacting the software
process differently. CM capabilities can be found not only in
CM tools and environment frameworks, but also in development
tools.  Integration of such tools into environment raises the
need for different CM models to interoperate. Therefore, it
is desirable to evolve to a unified CM model that encompasses
the full range of CM concepts and can be adapted to different
process needs.



Rate Monotonic Analysis for Real-Time Systems 
CMU/SEI-91-TR-6, ADA235641
Sha, L., Klein, M., Goodenough, J.

The essential goal of the Rate Monotonic Analysis (RMA) for
Real-Time Systems Project at the Software Engineering
Institute is to catalyze improvement in the practice of real-
time systems engineering, specifically by increasing the use
of rate monotonic analysis and scheduling algorithms. In this
report, we review important decisions in the development of
RMA. Our experience indicates that technology transition
considerations should be embedded in the process of
technology development from the start, rather than as an
afterthought.



Evaluation of Process Modeling Improvements
CMU/SEI-91-TR-5, ADA244293
Krut, Jr, R., Wood, D.P.

 The SEI has been involved with the development and analysis
of software process models for several years. As part of the
ongoing process of technology evolution, a study has been
undertaken to experimentally implement a set of proposed
improvements to the process modeling techniques used by the
SEI, and to evaluate the results of that experimentation.  As
a result of that study, a number of modifications to our
techniques have been identified.  These modifications enhance
the support of software engineering concepts in the
development and use of process models. This report describes
the study and elaborates upon the advantages and
disadvantages of the proposed technique improvements.


Rationale for SQL Ada Module Description Language SAMeDL 
CMU/SEI-91-TR-4, ADA235780
Chastek, G., Graham, M., Zelesnik, G.

The SQL Ada Module Description Language, SAMeDL, is a
language for the specification of Abstract Interfaces as
delineated by the SQL Ada Module Extensions (SAME)
methodology. The language is formally defined in the SAMeDL
Reference Manual. This document is a companion to the
Reference Manual. Whereas the Reference Manual is meant to be
precise, the Rationale is meant to be clear.

An explanation of the problem solved by the SAMeDL is given.
The creation of a new language is justified and the
underlying principles of that language are described. Crucial
issues in the language are then explained. These include:

	o	The form and meaning of identifiers in the
SAMeDL.

	o	The role of and procedures for data
definition in the SAMeDL. This includes support for
enumerations and constants in the SAMeDL.

	o	The typing rules of the SAMeDL.

The proposed use of some SAMeDL features is also illustrated.
These include Standard Post Processing and User Defined Base
Domains.


1991 SEI Report on Graduate Software Engineering Education
CMU/SEI-91-TR-2, ADA236340
Ford, G.

This report on graduate software engineering education
presents a variety of information for university educators
interested in establishing a software engineering program.
This includes a model curriculum, an annotated bibliography
of software engineering textbooks, and descriptions of major
software engineering research journals. It also includes
detailed descriptions of the SEI Academic Series of videotape
courses, which constitute an example of an implementation of
the model curriculum. Twenty-three university graduate
programs in software engineering are surveyed. Software
engineering textbooks and research journals are also
surveyed.


		-----end Part 1 (of 5) -----

Barbara Zayas			Software Engineering Institute
(bjz@sei.cmu.edu)		(412) 268-6378
===========================================================================
Co-moderator:  Richard Golding, Computer & Information Sciences, UC Santa Cruz
	    compdoc-techreports-request@ftp.cse.ucsc.edu