We are developing a set of checklists and a process model for commercial
business product reuse efforts. We describe our approach to scoping the
activities of Domain Analysis (DA) in order to optimize reusability of the
products (e.g., domain models) of that analysis. In particular, our model
for the Domain Analysis activity is complemented by a distinct activity for
analyzing the reusability constraints placed by the product development
environment (people, tools, process, objectives, etc.). We refer to this
as a ``Reusability Analysis.'' We contend that one benefit of
distinguishing between an analysis of the domain and an analysis of the
environment in which workproducts will be reused is that the domain models
and related workproducts of the Domain Analysis will be reusable, even if
software components cannot be reused across the range of intended
domain products.
Keywords: Domain Analysis, Reusability, Software Generation Process
1 Introduction
Hewlett-Packard Company has diverse lines of business in the commercial
marketplace. HP's electronic instruments, medical and analytical
equipment, and computer systems with vertical and horizontal application
products all include large software (and firmware) components. Within a
single line of business, there is extensive diversity in particulars of the
software generation and maintenance processes. A single product family may
span numerous hardware platforms, include multiple programming languages,
interface with diverse database systems, address niche markets or diverse
international standards, etc.
The time-to-market and return-on-investment criteria for products are
driving these organizations to consider reuse practices. Some early
adopters of reuse objectives have ``backed into'' performing domain
analyses in order to ensure the development of reusable components. We
are producing a set of checklists and a process model that incorporate
best practices from these reuse practitioners. The practitioners serve as
invaluable resources in the refinement of the reuse process model, so that
prescriptive guidance is tempered by practical experience.
2 Approach
The first phase of our investigation has essentially constituted a domain
analysis of Domain Analysis. Our efforts have included gathering data from
the literature on prescriptive domain analyses, interviewing domain
analysis experts, interviewing members of engineering teams that would be
users of the domain analysis results, looking at existing practices
(whether or not they are called ``domain analysis''), and generating a
model of the process that could be used across many application domains.
Initial steps of the process modelling involve defining the context for the
domain analysis: what are the peer activities, and what is the encompassing
activity. Our setting of the DA activity boundaries is based on the
various published uses of the term ``domain analysis,'' as well as on a
consensus among the reviewers of the model as to the prescriptive goals of
the process (i.e., what Domain Analysis ought to provide for commercial product development projects).
--- begin FOOTNOTE
We are employing the IDEF0 [IDEF90] practice of successive refinement of the
model, with quick-turnaround reviews of top-down generated process activities,
constraints, mechanisms, inputs, and outputs.
--- end FOOTNOTE
We define three interdependent activities in reuse: Developing Reusable
Workproducts (which includes Domain Analysis), Developing Software Products
(with reusable workproducts), and Managing Workproducts. Within Developing
Reusable Workproducts, we identify Analyzing The Domain (Domain Analysis),
Generating Reusability Requirements (Reusability Analysis), and Engineering
Reusable Components as the three primary activities.
From the Domain Analysis process model, we extract a hierarchical set of
checklists that can be used in reviews. The checklists are designed to
ascertain the quality and completeness of the domain model
--- begin FOOTNOTE
Typically today, a project initially plans to produce a reusable architecture
that embodies their domain model.
--- end FOOTNOTE
and other DA workproducts, whether or not a defined process has been explicitly followed. Through review of projects that are intentionally designing reusable workproducts, we will refine our process model with best practices and provide
timely feedback on weaknesses in projects' analyses.
We have chosen the checklist format as a near-term delivery vehicle for what we
have learned. This enables us to give immediate support to projects with
reuse objectives who are already in their analysis phase. For projects in
progress, the checklist serves as a set of guidelines, reminding the team
what questions they need to answer before they have finished their
analysis. (Note that this does not imply a waterfall lifecycle. This is
discussed further in Addressed Issues.)
To be of practical use in product teams, the process model will need to be
modified with feedback from early adopters. Until the process model has
stabilized, with careful assessment of its performance in application
product development environments (firmware, application and systems
software products), we do not want to oversell the model's benefits.
Reaction in product teams to checklists is more forgiving. There is less
expectation that checklists will provide complete coverage of a process,
and the interactions among activities are not expected to be called out
explicitly.
3 Addressed Issues
3.1 What Tasks Fall Within A Domain Analysis?
We contend that the proper focus of a domain analysis is the modelling
of the domain in the ``problem space,'' separate from the task of
engineering a (reusable) solution based on the domain model. The domain
analysis, together with a reusability analysis (See Section 4.1.2) constitute
the inputs to Engineering Reusable Workproducts for this domain. Our
motivation in disambiguating the role of Domain Analysis is to ensure that the
products of the DA efforts are reusable, independent of the choice of system
analysis and design paradigm. We find this to be consistent with the
philosophy of design for reusability, in which bindings are delayed, and
flexible application of workproducts is an explicit goal.
3.1.1 Systems Analysis and Design
The distinction between domain analysis and systems analysis and design
tasks is often blurred. Our process model draws the distinction by
