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). 1
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 2 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.