A Technical History of the SEI

community, to do so without benefit to the DoD would clearly be neither appropriate nor sufficient.
Software Engineering Context into Which SEI was Formed and Evolved
At the time, even the notion that software development could be called an engineering discipline
was debated. There were, after all, few analytic techniques available to a “software engineer;” and
there was no set of accepted practices to guide managers, developers, and maintainers of software.
There was no widely accepted curriculum for preparing a student for such activities. Few universities
offered such a program (most universities did not even offer software engineering courses),
and few faculty were prepared to teach the subject. Moreover, there was no accepted body of
practice for professionals. Indeed, although the term “software engineering” was coined at a conference
in 1968 [Naur 1968], the term was notional and still not yet well defined in 1983.
In the DoD, software development and maintenance was an acknowledged source of failure [DoD
1982]. The department was about to adopt the Ada language for all new developments; but few
were familiar with the software engineering concepts that the language enabled, and even fewer
were prepared to adopt the new programming paradigm.
An example of the prevalent misconceptions was the assumption that the systems architecture and
hardware architecture should be defined before any thought was given to the software. The DoD
acquisition and review processes even dictated this approach, based on the assumption that systems
engineering could be separated from software engineering and that system capabilities could
be defined with no regard to how they might be implemented in software. This assumption held
that since software is changeable, software developers could respond appropriately and subsequent
changes to the hardware could be accommodated.
This hardware-centric acquisition process assumed that software could be completely defined before
any implementation began. It also generally ignored the impact on the software structure of
later changes to requirements or hardware characteristics. (The notion of software architecture had
not yet surfaced, at least not in the DoD). A consequence, for instance, is that systems would often
be fielded with computer hardware that was one or two generations old, real-time systems would
deadlock due to timing conflicts, software development would be behind schedule and over
budget delaying release of the system, and systems maintenance often led to disastrous results
[DoD 1982]. One reaction to these problems yielded the tendency to build custom hardware,
which often exacerbated the software problems.
The SEI Began by Interpreting the Charter and Developing a Technical
Strategy
With this context, CMU began the journey that has taken the SEI into technology that was undefined
in 1984 and into arenas that were not—and probably could not have been—predicted. With
a small staff recruited from the CMU Computer Science department, the SEI took up temporary
residence in an old factory while a new building was constructed. Experts were, thus, recruited to
an entity that was unknown, before a new administrative infrastructure was created and, most importantly,
a technical strategy envisioned [Barbacci 1985].
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 6
Distribution Statement A: Approved for Public Release; Distribution is Unlimited