A Technical History of the SEI

case). This structural modeling approach enabled developers to reduce complexity and facilitate
changeability. The SEI also developed a reference model and supporting tools. The benefits included
significant reductions in test problems (from 2,000–3,000 to 600–700), in staff requirements
for installation, in test expense, in defects, and in side effects from software changes.
The U.S. Department of Transportation and the DoD asked the SEI to join Lincoln Laboratory in
conducting an independent technical assessment (ITA) of a problematic FAA upgrade of the inflight
air traffic control system. This FAA study included three FAA members contributing insights
and documents. The team began to investigate the underlying software structure and concluded
that it was sound and the upgrade project could be salvaged. The team provided a 14-point
list of recommendations, which the FAA implemented. As a result, the contractor completed the
upgrade, which went smoothly [Brown 1995]. The system is in use today. This experience encouraged
the SEI to begin thinking more deeply about software architecture.
Earlier, the SEI had embarked on the development of a user interface management system
(UIMS) intended to simplify the creation and modification of the user interface for interactive applications.
Because the user interface is one of the most highly modified portions of most systems,
special attention was needed to support the modification of the user interface. The Serpent UIMS
consisted of a language for specifying the user interface, a compiler for that language, and a
runtime engine to support the execution of the language. It was based on the architectural principle
of separating the user interface from the remainder of the system to allow for the user interface
to change without affecting any of the other code in the system. Again the notion of software architecture
had become evident.
Because Serpent was one of a number of competing UIMSs, the SEI developed a method for comparing
alternative designs for UIMSs to achieve the same functionality. This method—the Software
Architecture Analysis Method (SAAM)—was useful in a more general context than the user
interface domain and was based on recognizing that different systems, even in the same domain,
may be created with different business goals. Business goals, such as length of use of the system,
time to market, and execution within particular environments, led to different design choices.
SAAM included a step in which these goals were explicitly stated so that design decisions could
be evaluated against the goals.
The SEI first presented the SAAM at the International Conference on Software Engineering
(ICSE) in 1994. The SAAM was based on the development and evaluation of scenarios for determining
the ability to achieve defined business goals. Other methods in use at that time employed
checklists (AT&T) and surveys (Siemens). The SAAM was seminal in the use of scenarios to perform
architecture evaluation. Another scenario-based method, 4+1 View [Krutchen 1995], was
developed concurrently at Rational. The SEI published a report for executives about software architecture
in 1996 [Clements 1996].
SAAM led directly to the Architecture Tradeoff Analysis Method (ATAM), which evaluated a
system for a collection of quality attributes (non-functional requirements) in addition to the modifiability
of the user interface. Quality attribute requirements, such as those for performance, security,
reliability, and usability, have a significant influence on the success of a system. The notion
of paying attention to quality attributes first emerged from SEI work on Durra, a task-level appli-
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 234
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.