Product-Line Software Reuse
from an Automotive Perspective
| Engineering paradigms |
| Reusable components and component brokerage |
| Looking ahead |
- The life span of a car (or DoD software) may be 20+ years.
- You may need to take it back for defects (version control, recalls).
- May need to replace parts (shocks, battery, tires, etc.) --
likewise, a software application or system may need a module replaced
to use a new algorithm or be upgraded to a more recent release of a
commercial off-the-shelf (COTS) component.
- It can be repaired or serviced by the dealer (original developer) or
by a repair shop (analogous to a maintenance organization).
And an auto customization shop is very much like a reengineering shop.
- You may want to improve performance (bigger engine or transmission).
- You may want to add safety (traction bar or air bags), etc.
- Major reverse engineering may include stripping a car down to the
chassis and drive train, and then forward engineering with a new
engine and body.
Software can be reverse engineered from code to design and if
necessary, from design to requirements. There are tools and
techniques to reverse engineer applications to discover their software
Product lines are primarily an economic decision -- based on supply
The key to product lines is market demand -- there are unlimited
options in the automotive market, but not all are available from any
single automotive manufacturer or dealer. The automotive domain is
continuously analyzed to identify the most economically advantageous
subset of automotive styles and options that meets the majority of the
market demands. An automotive company can meet 80-90% of the market
needs (domain requirements) with only 40-50% of the market-defined
Reusable components and component brokerage
The automobile industry has matured to the point where de facto
standards govern most of the automobile architecture -- components,
connections, and controls.
- Components: nuts/bolts, parts, engines, chassis, etc.
- Connections: gaskets, threads, etc.
- Controls: the engine runs the transmission, which turns the axle(s),
Auto shops can be viewed as equivalent to centralized software
repositories. If they are properly organized, and if the specs for
your model are available in the shop, you can generally find what you
are looking for. Otherwise, you can take a chance. Ø
In software, the state of the practice is somewhere between the horse
and buggy days and Henry Ford's manufacturing line. The production of
software is evolving into an engineering discipline -- which leverages
a stable technology base (domain models, software architectures,
product-line components, etc.), applies routine engineering, and
develops reliable products using validated components and processes.
Class libraries are a modest example of this process, akin to the
stock room an ordinary worker can access. Software factories will
evolve as a larger demonstration of the process.
Automobile manufacturers have learned to separate factory costs (e.g.,
facility, tools/equipment, training and research) from product costs
(e.g., raw materials, labor and utilities. They have learned that the
additional capital investment in the factory yields increased
productivity and reliability, resulting in lower costs per product. A
software factory must likewise separate the factory costs (e.g.,
domain engineering, domain management, process engineering, integrated
software-engineering environments, software architectures, training
and metrics) from the product costs (e.g., application engineering,
integration, testing, COTS licensing and configuration management). A
disciplined, software-engineering product-line paradigm can then
realize the same benefits: faster, better and cheaper.
What will the impact be? What will things look like? We don't know
-- any more than Henry Ford could have predicted the social
consequences of the Interstate Highway System. We can suspect,
though, as the automobile industry found in the 1970s and 80s, that if
we don't meet the needs of the market, others will! Ø