Date[ July 8, 1998 ]  Recordnr[        ]  Stored[ bookshelf?
Who[ P. Bassett
Title[ Managing for Flexible Software Manufacturing

Published[ IEEE Computer, vol31, no7, July 1998

Keywords[ 

Comment[ 

Summary[ The article discusses reuse, the reason why it does not happen, 
and proposes some remedies.

Reasons why reuse does not happen:
- Old manufacturing culture: we only trust our own software, and 
distrust other software; "our software will be far better"
- Management supports these habits

Management strategies to overcome old culture:
1) Promoting reuse within same project, i.e. avoiding perfectionism and 
over-generalisation syndrom.
2) Own and manage multiproject assets centrally by central profit-centre 
that rents out component engineers (actual glue)  that help individual 
projects to use these components fast and effectively.

Architectures for reuse, two types:
1) Execution architectures: system is encapsulated into executable 
modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... 
Point of view is runtime.
2) Construction architectures: the executable modules are partitioned 
into reusable components according to the isolation of change. Point of 
view is construction time, the goal is to localize the effects of 
change, to reduce complexity and ensure as much independance between 
components as possible, so when making changes to API's, data structures 
etc, as view components as possible have to be touched. ==> reuse is 
enhanced.

Infrastructure for reuse:
We have infrastructures for execution architectures (e.g. ORB's), but 
not really for construction time. It is hard to access and find multiple 
sources of supply of components. With infrastructure also come basic 
metrics that would give information about the return of investment in 
components. 

Flexible Software Manufacturing - a new paradigm?
What it means: components that have the capability to adapt/customize 
themselves to concrete requirements.

How does CHAIMS relate to this? 
- we are not changing any megamodules in the composition process, we may 
only add mediator megamodules to complete certain suites of megamodules
- yet the megamodule providers can provide more or less suitable 
megamodules ==> ideally they package the functionality in such a way 
that the megamodule can be used in as many different settings as 
possible (minimal interface yet still flexible enough for many uses). 

The article also mentions some books about reuse, e.g. McClure 1997, 
Jacobson 1997,