A Technical History of the SEI

Interpreting the Charter
In creating a technical strategy, the SEI engaged in some definitional activity that is important to
understand in evaluating the technical contributions in this report. Since the term software engineering
was prominent in the charter, was part of the SEI name, and was to be chiseled in granite
on the front of the building, it seemed prudent to define the term. The SEI adapted a definition of
engineering, “the application of science and mathematics to produce products...” to derive the definition
of software engineering, “the application of science, mathematics, computing, and the application
domain to produce software products.”
Since technology transition was a significant portion of the charter, time was spent in understanding
what that entails. The SEI adopted the view that transition implies
making the technology practical
providing the education and training materials from which practicing engineers can be prepared
to apply the technology
demonstrating that the technology works in a particular application domain
making practicing engineers aware of the technology
ensuring that the infrastructure was established to sustain its use and to continue development
The latter requires that commercial companies develop products to support technology and members
of the software community continue its development, thereby enabling the SEI to move on to
other work. The SEI understood that just as it requires an order of magnitude more effort and cost
to turn a prototype into a product as it did to create the prototype, so the time and effort to transition
technology broadly and successfully is substantially greater than the effort to create the technology
in the first place [Redwine 1985].
The research component of SEI work also needed careful consideration. The research paradigm
in the sciences was well understood, but research in software engineering was not as well defined.
There were no software engineering PhD programs to use as reference. Indeed, there were few, if
any, researchers with computer science PhDs whose dissertations focused on software engineering.
Engineering research is not the same as research in the sciences. Whereas scientific research seeks
to prove some scientific principle about the physical world through experimentation and observation,
the focus of research in the engineering disciplines is often on finding solutions to difficult
problems that can be generalized. Established engineering disciplines, such as electrical, mechanical,
and particularly chemical, provided a useful model, which often involved creating a new engineering
process, developing a new design method, or proposing mechanisms for increasing efficiency
of some process. The SEI concluded that each of these activities was appropriate to
software engineering. In addition, the SEI concluded that additional research activities more relevant
to software were appropriate, including demonstrating that some new approach would scale
and building a prototype that would demonstrate a new approach could work in a particular domain.
Such research requires real problems and access to those who encounter those problems. As
such, it is not an activity that is easily pursued by an individual or small team because the problem
set usually involves large and complex software systems with interfaces that are not tidy and uniform.
That is one reason why software engineering research is difficult in a purely academic setting.
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 7
Distribution Statement A: Approved for Public Release; Distribution is Unlimited