A Technical History of the SEI

Feature-Oriented Domain Analysis
The Challenge: Achieve Cost Reductions By Means of Software Reuse
A 1993 report by the Government Accounting Office 61 [GAO 1993] cited a comprehensive effort
to incorporate software reuse practices into the DoD’s software development efforts. Reuse was
viewed as a way to manage software costs, which in 1993 exceeded $24 billion a year, and to improve
the DoD’s ability to develop and maintain high-quality software. In practice, however, the
promise of software reuse had not been realized. The report
stated that “methodologies to implement reuse have
not been fully developed, tools to support a reuse process
are lacking, and standards to guide critical software reuse
activities have not been established” [GAO 1993, p. 1].
One of the technical issues cited in the GAO report was
that the variation in the domains in which software reuse
was being attempted was proving intractable. Standard
methods were needed to process information about domains—“domain
analysis”—the purpose of which is “to
generalize common features in similar application areas,
identify the common objects and operations in these areas,
and define and describe their relationships.”
A Solution: Feature-Oriented Domain
Analysis
The View from Others
An examination of the proceedings
from the Software Product
Lines Conference (SPLC) over its
16-year history shows a preponderance
of papers that refer to
FODA and domain analysis.
FODA has proven to be a fruitful
research area, and FODA and variation/variability
analysis have
been the most common themes at
SPLC.
At this time, the SEI was working with an Army program called Army Tactical Command and
Control System (ATCCS) [Williamson 2005] that had five separate programs supporting five
function areas: maneuver control, air defense, combat service support, intelligence/electronic warfare,
and fire support. Seeking to identify isolated areas with common requirements shared by
these programs, the SEI identified “domains,” or specific areas of knowledge. An SEI staff member
on this project proposed the idea of “features” based on experience at AT&T, where equipment
builds were classified by their features. For example, for switches, some would be automatic,
some would be manual, etc. Features would be the way to analyze the common
characteristics of a domain, prior to formal requirements engineering. The SEI pioneered this idea
of features and developed a methodology that it called “feature-oriented domain analysis,” or
FODA [Kang 1990].
The SEI saw a domain as a special area of knowledge, and characterized large-scale systems as
comprising several domains. The Army asked the SEI to look at movement control—route planning,
scheduling, and deconfliction, to ensure that, for example, a road would not be taken up by
two different vehicles at the same time. Movement control was attractive to the Army because it is
a domain that applied to many of the ATCCS systems. The SEI described movement control as a
domain, identifying commonalities about how units were handled and organized, how routes were
planned and convoys scheduled, etc. After conducting this domain analysis, the SEI developed a
61 Now known as the Government Accountability Office.
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 262
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.