A Technical History of the SEI

design with some variation built in and did an implementation for the Army, building a system
that could operate on Army equipment.
The Consequence: Application to Reuse and a Product Lines Approach
Because of the resistance of contractors and the inability of program managers to justify the effort
with ongoing programs, the results of this work were not transitioned to an operational Army system.
However, the concepts developed were picked up in the reuse and eventually the product
lines communities. The key insight was that effective reuse requires an understanding of the commonalities
across all systems in a particular mission area, such as command and control, and
where they vary, this information is captured in a model representation. In FODA, the information
was captured in tree fashion with a hierarchy of mandatory features, optional features, and alternative
ways of describing how the features would be used.
The SEI began to hold product line workshops around 1996, and the work that had begun with
FODA evolved into a concentration on product lines. At this time, the SEI began working of these
issues with industry customers, including Motorola, HP, Avaya (Lucent at the time), and other
early adopters.
The SEI Contribution
Compared to other approaches to domain analysis, the SEI’s FODA was a lightweight approach
that could be applied in two to three weeks. The DARPA STARS program also developed a domain
analysis approach, but it required more effort and was more time consuming. The SEI advocated
moving quickly from FODA on to requirements, architecture, and implementation, preferring
that domain analysis feed downstream activities. This methodology evolved into what is now
known as commonality/variation design, and then architecture-component variation points, in current
product line practice.
Others at the time were working on object-oriented design, building a set of classes and a class
hierarchy once and then having everyone in the software development organization use these classes
for all the systems they built. Object-oriented design, the principal mechanism at the time for
achieving reuse, was undermined by variation and an inability by organizations to control the proliferation
of subclasses, which effectively prevented widespread reuse. As the product line concept
began to mature, the software community began to recognize the need for domain analysis.
Many other systems and methods have been built around the FODA model. David Weiss and Chi
Tau Robert Lai wrote a textbook in 1999 called Software Product Line Engineering: A Family-
Based Software Development Process [Weiss 1999]. The methodology described therein, known
as commonality variability analysis, examined, for example, organizational commonality in provisioning,
configuration management, and billing operations. It was broader than domain analysis,
but similar, and there were cross-influences between Weiss and the SEI.
In 2000, Krzysztof Czarnecki [Czarnecki 2000] worked on automatic software generation that
was built on FODA models or variation models. Around the same time, in early 2002, a company
in Germany called Pure Systems developed a tool to manage variation and feature modeling. Pure
Systems had been working in configuration management and moved into feature modeling. Also
around that time, Charles Kreuger of Big Lever developed Gears, which had built into it the feature
concept. Gears also applied to configuration management and mass customization—a lot of
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 263
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.