home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.umcs.maine.edu
/
2015-02-07.ftp.umcs.maine.edu.tar
/
ftp.umcs.maine.edu
/
pub
/
WISR
/
wisr6
/
proceedings
/
ascii
/
wartik.ascii
< prev
next >
Wrap
Text File
|
1993-10-19
|
23KB
|
464 lines
The Role of Process Families in Reuse Adoption
Steven Wartik
Software Productivity Consortium
2214 Rock Hill Road
Herndon, Virginia 22070
Tel: 703/742-7176
E-mail: wartik@software.org
Abstract
Organizations often overreach when trying to adopt reuse. They try to institute reuse visions
that are too complex, in whole or in part, for the knowledge and skills they possess. This paper
proposes that reuse processes be defined as families, with precisely-defined commonalities and
variations, and that the variations be chosen such that some family members are suited to orga-
nizations just learning reuse, whereas others are for organizations with much reuse experience.
This is illustrated using the Synthesis process family. Thepap er presents some of Synthesis'
commonalities and variabilities, then delineates how two members_one for advanced organiza-
tions, another for those new to reuse_resolve the variabilities. Comparing the two leads to some
insights on how one's ultimate reuse goals might be relaxed to accommodate current practice.
Keywords: Software reuse, software development process, family, process family, domain en-
gineering.
Workshop Goals: Validate problem and solution based on experiences of other researchers;
understand domain analysis/engineering in family-oriented terms.
Working Groups: Domain analysis/engineering,reuse process models, reuse maturity models.
Wartik- 1
1 Background
For the past four years, I have been working at the Software Productivity Consortium, a con-
sortium of aerospace companies. In these companies, pro jects develop software under contract
to an external customer. These projects are generally grouped into business-area organizations.
These organizations tend to amass expertise in particular areas, and try to win contracts in those
areas. Such organizations lend themselves to reuse approaches that incorporate domain analysis
techniques.
2 Position
2.1 Problem Statement
Reuse presents many challenging technical problems. However, a clear theme from last year's
workshop on software reuse was that some of the major imp ediments to its adoption are glaringly
non-technical [1, 2 , 3 , 4 ]. Companies often lack a comprehensive reuse program because project
managers are unwilling to gamble on anything new and unproven. Those willing to take the chance
often find their hands tied: contractual obligations and organizational requirements prevent them
from acquiring new tools, or using non-traditional software methods, or altering their software
development process_in brief, from making changesthat would facilitate reuse.
Management at organization-wide levels (above pro ject management) faces similar hurdles. An
organization might establish a reuse library, but be unable top opulate it with components from
previous projects_the contractors who paid for developing those components claim software owner-
ship rights, not being eager to see the components used todevelop a competitor's software cheaply.
Moreover, the cost of establishing a suitable environment for reuse can be high, and is difficult to
predict. An organization should not expect to recoup its investment immediately, which can make
management uncomfortable.
This situation is not universal, but it exists in manyorganizations that the Consortium supports.
This poses a problem. The Consortium has been tasked to develop advanced technologies that sup-
port reuse. It has done so, and the technology has been well-received by some organizations. Others
find the technology interesting, but do not feel able to risk trying anadvanced reuse technology.
Yet they are under pressure to reuse software. How should the Consortium support them?
The Consortium has devised a reuse adoption process that addresses this question [4]. This paper
concentrates on one aspect of reuse adoption: the software development process an organization
uses. Specifically, what problems does an organization face as it changes its software development
process to accommodate reuse, and what is an appropriate strategy to address those problems?
When an organization adopts a new software development process, it must expect to invest resources
in retraining, acquiring appropriate CASE tools, etc. This in itself can frighten away anyone con-
sidering making such a change. External factors pose even greater difficulties. The Consortium's
member companies are usually contractually obligated to use asp ecific software development pro-
cess. Projects cannot expect to use any process that is particularly radical.
Even those organizations wanting to tryan advanced reuse process often find that doing so is not
quite as easy as they thought. The Consortium has an abstract description of what a reuse-driven
software development process should b e, but its exact realization depends on both the software
domain and the organization using it. Tailoring the process takes both time and experience.
Wartik- 2
The Consortium must therefore support organizations that wish to adopt reuse slowly as well as
those willing to adopt it aggressively.
2.2 Proposed Solution
This paper proposes that an organization seeking to institute a reuse-driven software development
process should consider not a single process, but a family of processes. The term "family" is used
with a meaning analogous to how it is used to describe software components: a family of pro cesses
is a set of processes that are sufficiently similar that it is worthwhile to understand their common
properties before considering the special properties of individual instances.1 They differ in ways
that suit particular family members to projects and organizations at particular stages of reuse
capability.
The common properties ("commonalities") are what an organization expects to remain constant
about its process, independent of its reuse objectives. Examples of such properties include splitting
software development into domain engineering and application engineering, or use of particular
methods, tools, and technology (whether because of recognition of investment or belief in their
efficacy).
The family's variabilities are expectations of howsoftware development will change as the organiza-
tion improves its ability to reuse software. For example, an organization might want eventually to
reuse entire software subsystems or complete chapters of requirements documents; such a capabil-
ity would obviate, or at least substantially alter, many process activities concerned with creation,
integration, and validation of the work products a project produces. However, if an organization
does not yet possess the ability to do such large-scale reuse, it might be content to start by reusing
smaller entities (individual functions and paragraphs) which would not affect the process nearly so
much. Other examples of how reuse influences process are the effect on customer interaction activ-
ities (customers do not need as much formal involvement if they are confident that the contractor
is using previously-certified work products) and the activities associated with domain engineering.
(Domain engineering's importance in an organization correlates to how effectively it assists projects
in that organization. As an organization achieves its reuse goals, the process followed by domain
engineers encompasses more activities that directly relate to helping all pro jects in an organization
fulfill their contracts.)
The Consortium is developing a process family called Synthesis [6 , 7]. The rest of Section 2
is an illustration of our proposed solution using Synthesis. Section 2.2.1 presents some of the
commonalities and variabilities of the Synthesis process family. Sections 2.2.2 and 2.2.3 show how
the variabilities are resolved in two of the family members_one member being an "advanced"
process incorporating reuse, the other a more traditional process. Section 2.3 states what we
believe are the benefits of the family-oriented approach.
2.2.1 Characteristics of Synthesis Family Members
The following are some of the characteristics common to all members of the Synthesis process
family:
fflA Synthesis process involves an interaction of a domain engineering group with one or more
application engineering projects. Each application engineering project has a customer and an
___________________________________________________1
This is an adaptation of the definition for a program family given by Dijkstra [5].
Wartik- 3
obligation to build software satisfying that customer's requirements. The domain engineering
group is responsible for assuring that the application engineering project(s) with which it
interacts are able (through reuse) to deliver software to their customersin the most effective
manner practical.
fflDomain engineers formalize a domain as a family of products. A product is composed of a
set of work products (requirements, designs, implementations, etc.). Here, "formalize" means
that the ways in which the products vary are explicitly and precisely defined.
fflApplication engineers build work products by resolving the variations identified during domain
analysis. These variations are presented to the application engineers as engineering decisions
whose resolution requires their knowledge and experience of the problem at hand. The result
of this decision-resolution is an "application model."
fflApplication engineers build work products through mechanical adaptation of components
based on information obtained from the application model.
Now consider three variations among family members:
1. The degree to which the work products form an integrated product family. They might be
fully integrated, or they might be very loosely integrated.
2. Whether the application engineering process is based on the expectations and requirements
of the customer, or on considerations as to how software can most effectively be developed
within the domain and within the organization.
3. Whether domain engineering sees its objective as supporting the long-term needs of an entire
business-area organization or supporting a particular set of current or planned projects.
2.2.2 "Leveraged" Synthesis
In leveraged Synthesis, the variations are resolved as follows:
ffl(Variation 1) The product family is highly integrated. Domain engineers understand the
relationships between the variations among requirements documents in thedomain and the
variations among reusable code components. If they can describe their customer's needs in
terms of variations at the requirements level, they can also describe variations among reusable
code components. A single applicationmo del thendescrib esall the work products a project
needs to fulfill its contractual obligations.
ffl(Variation 2) The application engineering process is optimized for the domain. The process
might call for the use of specific analytical techniques, for instance. Reuse helps achieve
more radical innovation: if enough reusable components are present, then entire pro cess steps
can be skipped. Recall that Synthesis processes rely on mechanical adaptation of reusable
components. If develop ers can assemble a design document by selecting and mechanically
adapting fragments of existing designs, they do not need to perform the design step.
ffl(Variation 3) Domain engineering is a strategic component of a business-area organization's
ability to develop software within a domain. It determines and defines the optimal application
engineering process.
Wartik- 4
Leveraged Synthesis is an example of an advanced reuse process. It is the vision of a reuse process
the Consortium presents to its member companies,many of whom are eager to try it. Unfortunately,
most organizations today have trouble institutionalizing leveraged Synthesis. The following are
some reasons why:
fflDomain engineers must possess a thorough understanding of a domain to integrate the work
product families that comprise it. Most organizations do not have such expertise unless they
have developed many systems in a domain. Actually, organizationsdo tend to possess the
requisite knowledge, but are not willing to take the time to do a systematic domain analysis (a
lengthy task) and therefore cannot formalize a domain in terms of variabilities among family
members.
fflCustomers generally have their own ideas about what makes a software process acceptable.
These ideas will be based on processes that have been shown to be historically acceptable
(i.e., waterfall models) rather than optimal. The customer may mandate use of such a process
as a condition for signing any contracts.
fflDomain engineers need time to provide a useful domain implementation. Ongoing pro jects
do not have much opportunity to benefit from reuse. Management, however, often wants
immediate results.
This description is somewhat simplified, but it illustrates why an organizationmight not be able
to perform leveraged Synthesis.
2.2.3 "Opportunistic" Synthesis
Leveraged Synthesis was the original Synthesis process. As we b eganto appreciate the difficulties in
introducing it, we conceived of Synthesis as a process family, with the commonalities and variations
mentioned above. We defined a new family member, called opp ortunistic Synthesis (because reuse
is based on whatever opportunities arise; domain engineers do not attempt to gain leverage for
future projects). In this model, the variations are resolved as follows:
ffl(Variation 1) Domain engineers formalize variations among members of work product families,
rather than complete product families. Work product families are not integrated. A domain
is a collection of whatever work product families are necessary.
ffl(Variation 2) The application engineering process is based on whatever process application
engineering uses.
ffl(Variation 3) Domain engineering is responsible for assuring that a particular application
engineering project can benefit from reuse. Domain engineering's goal is always to support
upcoming phases of application engineering. Suppose application engineering uses a waterfall
process. During system design, domain engineers would be analyzing existing software re-
quirements documents that application engineers might be able to reuse during the software
requirements phase. During software requirements, domain engineers would analyze software
designs. During software design, they would be analyzing existing code.
Opportunistic Synthesis offers less long-term gain than leveraged Synthesis. It does not encourage
rewriting code to make it reusable, or devoting resources to create new reusable components. It
Wartik- 5
does not encourage innovative new software processes. Instead, it allows projects to maintain, more
or less, their current software development status quo. This, of course, is an advantage for many
projects today. Opportunistic Synthesis gives immediate, tangible results, with minimal investment
and low risk. We believe that opportunistic Synthesis would b e acceptable to many managers who
might find leveraged Synthesis (or mostother reuse technologies) interesting but too risky.
2.3 Benefits
The advantage of the family-oriented approach lies in how it facilitates transition from current
practice to one's ultimate reuse goals. The family's commonalities help people understand how
reuse fits into the software process. Because these properties are invariant, people can expect
certain investments in reuse to have long-term rewards. In Synthesis, for example, where performing
domain engineering is a commonality, the process and goals of domain engineering may vary between
family members, but the domain knowledge that engineers accumulate is always of benefit to current
and future projects.
The family's variabilities make reuse amenable to situations from current practice to ultimate reuse
goals. This is important for several reasons. First, variabilities help people transition between family
members: they describe exactly what is being changed, thus highlighting the only new principles
that must be mastered. Second, variabilities help organizations plan a long-term strategy to improve
reuse capability: they help organizations evaluate and compare the difficulty, relative to their own
environment, of using any two family members. Third, variabilities help organizations manage
the differences that individual projects may encounter. Differences in personnel experience, or
in customer requirements, may force two projects within the same organization to use different
processes. An understanding of the variabilities will help each project choose the process that best
fits its needs.
3 Comparison
Synthesis is a reuse-driven software development process. The software development process is only
one dimension of the Consortium's process for reuse adoption [8]. Others include management,
application development, and asset development. Each of these dimensions has its own variations.
An organization adopting reuse must be prepared to resolve many more variations than have been
discussed here, many of which are not concerned with software development processes. In other
words, the family-oriented approach can be used beyond software development process. However,we
still have much work to do in determining the most appropriate variations among family members.
At the 1992 workshop on software reuse, Mark Simos presented work towards an industry-wide
consensus reuse process model [9]. The work presented here has been more specific than his in
certain aspects. This isb ecause itreflects the concerns of our member companies. He envisioned
a domain-independent reuse process model that would be applicable in government, commercial,
and public-domain organizations. Our needs are not quite so general; thus we are able to define a
reuse process tailored to the commercial and government worlds, and incorporating domain-specific
enhancements where helpful.
Our model is also broader than Simos' in some areas. For instance, he proposed that the process
should only address aspects of process that relate to reuse. This is true of opportunistic Synthesis,
where the application engineers dictate the process; it is the responsibility of domainengineers to
Wartik- 6
determine those parts of application engineering that can benefit from reuse, and to influence no
others. In leveraged Synthesis, however, reuse drives what application engineering may do, rather
than the other way around. It is therefore hard to see what aspects of the process are not addressed
by reuse.
This should not be taken to mean that Synthesis is incompatible with Simos' work. Quite the
contrary, a process family is a way of organizing elements of a model such that the right process
can be defined for any given situation. Whether families are sufficiently expressiveto allow this is
a topic we are actively pursuing.
References
[1] B. Joos, "So Much for Motherhood, Apple Pie and Reuse," in Proceedings of the WISR 5th
Annual Workshop on Software Reuse, (Palo Alto, California), 1992.
[2] R. Erickson, "Software Reuse Adoption: Some Practical Issues," in Proceedings of the WISR
5th Annual Workshop on Software Reuse, (Palo Alto, California), 1992.
[3] P. Collins, "Considering Corporate Culture in Institutionalizing Reuse," in Proceedings of the
WISR 5th Annual Workshop on Software Reuse, (Palo Alto, California), 1992.
[4] T. Davis, "Toward a Reuse Maturity Model,"in Proceedings of the WISR5th Annual Workshop
on Software Reuse, (Palo Alto, California), 1992.
[5] E. Dijkstra, "Notes on Structured Programming," in Structured Programming (O. Dahl, E. Di-
jkstra, and C.Hoare, eds.), pp. 1-82, Academic Press, 1972.
[6] "Domain Engineering Guidebo ok," Tech. Rep. SPC-92019-CMC, Software Productivity Con-
sortium, Herndon, Virginia, 1992.
[7] S. Wartik and R. Prieto-Diaz, "Criteria for Comparing Reuse-Oriented Domain Analysis Ap-
proaches," InternationalJournal of Software Engineering and Knowledge Engineering, vol. 2,
no. 3, pp. 403-431, 1992.
[8] "Reuse Adoption Guideb ook,"Tech. Rep. SPC-92051-CMC, Software Productivity Consortium,
Herndon, Virginia, 1992.
[9] M. Simos, "Towards and Industry-Wide Consensus Reuse Process Model," in Proceedings of
the WISR 5th Annual Workshop on Software Reuse, (Palo Alto, California), 1992.
4 Biography
Steven Wartik is a Senior Member of Technical Staff at the Software Productivity Consortium.
His research interests are in domain analysis,software processes, and the relationship between the
two. He received his B.S. in 1977 in Computer Science from the Pennsylvania State University,
and his Ph.D. in 1984 from the University of California at Santa Barbara. From 1981 to 1984,
he worked on the Software Pro ductivity Pro ject at TRW. From 1984 to 1988, he was an assistant
professor of Computer Science at the University ofVirginia.
Wartik- 7