Synthesis Opportunistic Domain Engineering
PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES
The Process Requirements Activity is an activity of the Domain Specification
Activity for creating Process Requirements. Process Requirements is a
description of the Application Engineering process currently in use by projects
in your organization (including the targeted project). The description of the
process identifies the activities, work products, and common methods or
practices used by those projects to produce software work products. In the
Process Requirements Activity, you determine which types of work products are
produced, what steps engineers take to produce them, and how those steps can be
modified to allow for reuse.
In an opportunistic Synthesis process such as this one, the goal of the Process
Requirements Activity is primarily to document the actual process in use by
targeted projects. Any changes to that process intended to facilitate reuse
are minimized, with an ideal of not changing major activities, relationships,
or work products. Changes are limited to the way in which individual work
products are produced, with the intent of aiding the efficient discovery and
exploitation of opportunities for cost-effective reuse.
The objective of the Process Requirements Activity is to characterize the
prevalent Application Engineering process used by projects in a domain and the
work products that result. It is assumed that the targeted project will follow
a similar process and produce work products of the same types. Based on that
characterization, the Process Requirements Activity identifies which work
products the targeted project can likely produce more easily if reusable assets
are available.
The Process Requirements Activity requires the Domain Definition.
The Process Requirements Activity requires domain and software knowledge and
experience in:
-
The conventional life-cycle process of systems in the domain and the role of
customers and standards in that process
-
How each of the work products of Application Engineering is produced currently
and how it would be produced if reuse were a viable option
-
- Name:
-
Process Requirements
- Purpose:
-
Process Requirements are an analysis of the current Application Engineering
process that identifies work products which provide a focus for reuse efforts.
The process described in the Process Requirements may be manual or may
incorporate varying levels of automation.
- Content:
-
The Process Requirements work product consists of:
-
Process Specification.
A definition of the work products, activities, and contributing methods or
practices that application engineers currently
use."
For each activity, Process Specification describes its purpose, the work
products created, and interactions with other activities.
-
Work Product Creation Procedure.
A description of how application engineers produce a work product either with
or without reuse.
- Form and Structure:
-
A Process Specification can be described informally or using a process modeling
notation. The form and content of each work product should be described
explicitly or by reference to customer or industry standards. Section AE
provides an example of how a Work Product Creation Procedure might be
described.
- Verification Criteria:
-
The described Application Engineering process should accurately account for
current work products and practices of application engineering projects.
The Process Requirements Activity consists of two steps shown in
Figure 2.2.3-1. Process Requirements Process.
Follow these steps for the Process Requirements Activity.
Step: Describe the Application Engineering Process
Design a Process
-
- Action:
-
Describe the process that application engineering projects follow to create an
application product and its constituent work products.
- Input:
-
Domain Definition
- Result:
-
Process Specification
- Heuristics:
-
-
Identify the deliverables that the Application Engineering process
produces.
This set of work
products is determined by the needs of
customers for the targeted project.
The form and content of
some work products may be based on
corporate, customer, or industry standards, as appropriate.
Work products that must satisfy a form and content standard are more likely to
offer opportunities for reuse.
-
Identify additional (i.e., intermediate or auxiliary) work products that result
from the Application Engineering process. These work products retain
preliminary or supporting information or support project and process
management, including risk management and quantitative and qualitative analyses
of deliverable work products and of the production process.
Step: Formulate a Procedure for Reuse-Based Creation of Work Products
-
- Action:
-
Formulate a procedure that will serve as an informal guide for application
engineers to create a work product, allowing for discovery and exploitation of
supported reuse opportunities as appropriate.
- Input:
-
Process Specification
- Result:
-
Work Product Creation Procedure
- Heuristics:
-
-
Start with an approximate description of the steps of work product creation as
application engineers currently work. Section AE provides an example of such a
work product creation procedure. Any work product can be created, with or
without reuse, roughly following that procedure.
-
Consider how your work product creation procedure will be affected by the
availability of relevant reusable assets. Provide guidance on how reuse should
affect the way activities are performed. Consider the guidance given for the
procedure in Section AE as a starting point.
-
- Risk:
-
The documented Application Engineering process does not match actual
practices.
- Implication:
-
Subsequently developed work product families will not support the creation of
work products that projects need to produce.
- Mitigation:
-
Review the process with experienced project managers and engineers to ensure
that it encompasses all activities required of a project, those work products
that customers require, and those additional work products that benefit a
project. Variations in project needs must be anticipated and supported.
-
- Contingency:
-
The Domain Definition conflicts with the Domain Plan or
is incomplete, ambiguous, or inconsistent.
- Source:
-
-
Domain Definition Activity
-
Domain Management Activity
- Response:
-
Describe the inadequacies in the Domain
Definition (e.g., a targeted project whose needs seem to conflict with the
domain scope).
Proceed with Process Requirements, and document any assumptions made regarding
the inadequate portions of the Domain Definition.
- Contingency:
-
The practices and procedures specified in the Domain Plan are either
ineffective or inefficient.
- Source:
-
Domain Management Activity
- Response:
-
Describe the ways in which the practices and procedures are either ineffective
or inefficient. Propose revisions to the practices and procedures to make them
more effective.
-
- Contingency:
- The Process Requirements are incomplete, ambiguous, or inconsistent.
- Source:
- Process Support Development Activity
- Response:
- Refine the Process Requirements to correct inadequacies.
- Contingency:
-
The documented Application Engineering process identifies types of work
products that do not correspond to the needs of a particular project.
- Source:
-
Project Support Activity
- Response:
-
Include in the Process Requirements any activities and associated work products
that offer an opportunity for reuse but have not been identified as such
previously. Omit any that no longer correspond to accepted practice.
