Synthesis Leveraged 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
specification of a standardized Application Engineering process for a domain
and an associated Application Modeling Notation. A process specification
tailors and standardizes the activities, methods, and procedures by which
Application Engineering is practiced within a domain. This process replaces
conventional, domain-independent approaches to software development.
As a part of a standardized Application Engineering process, application
engineers create an Application Model that describes a required system. An
Application Modeling Notation defines the form and mechanisms that application
engineers can use to describe and evaluate an Application Model for products in
the domain. This notation must be usable by engineers knowledgeable in domain
concepts and must produce an Application Model that is an accurate model of the
resulting product. The information content expressible with an Application
Modeling Notation for a domain must be equivalent to the information content
defined by the Decision Model for that domain. The organization and form of
the notation, however, are tailored to the needs of application engineers.
The objective of the Process Requirements Activity is to define a standardized
process for Application Engineering within a domain and an accompanying
Application Modeling Notation for creating a precise description of a required
product. The process should be tailored to the needs of the organization so
that established productivity (process efficiency and product quality) goals
are most attainable.
The Process Requirements Activity requires the
following information:
-
Domain Definition
-
Decision Model
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 application engineers resolve issues in constructing systems in the domain
-
The concepts and structures that are convenient forms by which domain experts
communicate concerning the distinguishing features of systems in the domain
-
- Name:
-
Process Requirements
- Purpose:
-
Process Requirements define a standard process that application engineers
follow to develop and evolve systems in the domain.
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
use." process of Application Engineering.
For each activity, Process Specification describes its purpose, the work
products created, and interactions with other activities.
-
Application Modeling Notation Specification.
A description of the form of the Application Modeling Notation. The description
of the notation consists of:
-
Presentations.
The form of each set of logically-related decisions from the Decision Model
that application engineers tend to treat as a unit.
-
Structure.
The structure of the Application Modeling Notation, which organizes
Presentations into a decision process based on dependencies and constraints
among decisions.
- Form and Structure:
-
The Process Specification defines the products, activities, and process of
Application Engineering. Each application engineering work product has a
specified content and form. The form of a product may be defined explicitly or
by reference to customer or industry standards. Each activity of Application
Engineering is described by its purpose, the work products to be created, a
procedure that defines and organizes the steps of the activity, and
interactions with other activities. The Application Engineering process is
described as a set of Activities (e.g., Specify Model, Assess Model) that are
to be performed in a specified (partial) order. Each activity consists of a
number of Steps (e.g., Specify Platform and Start Simulation). The description
of the activity includes a specification of the order in which steps may be
performed. Each step is specified in terms of a presentation that describes
the particular information the application engineer sees during that step and a
set of actions that he can perform.
The Application Modeling Notation can be specified as a set of paper or
automated forms that allow application engineers to make requirements or
engineering decisions about the needed product. By completing these forms,
application engineers construct an Application Model for a product. In
addition, the Notation organizes the forms into a network that defines a
sequence in which application engineers can address any particular decision.
The description of an activity in an Application Modeling Notation is written
in terms of a standard presentation paradigm. A presentation paradigm defines
a generic form in which information may be presented interactively and is
conceived as a notational aid for describing the Application Modeling Notation.
Presentation paradigms for simple decisions are textual, graphical, or iconic.
Presentation paradigms for grouped decisions organize simpler presentations
into aggregate (possibly hybrid) forms (e.g., textual, graphical, tabular).
- Verification Criteria:
-
-
All decisions specified in the Decision Model should be accessible through the
Application Modeling Notation.
-
The Application Modeling Notation should support only those decisions that can
be expressed in some equivalent way in the Decision Model.
-
The Process Requirements must enforce all of the constraints specified in the
Decision Model.
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:
-
Specify a process for creating and evaluating an Application Model and the
generation of work products from the Application Model. Define the process by
organizing the Presentations defined in the Application Modeling Notation into
activities and specifying ordering constraints and prerequisites that structure
the process. Define the points at which analyses may be performed and work
products may be produced.
- Input:
-
Domain Definition
- Result:
-
Process Specification
- Heuristics:
-
-
Identify the deliverables that the Application Engineering process must
produce.
This set of
products is determined by the needs of customers.
The form and content of each product should be defined in keeping with
corporate, customer, or industry standards, as appropriate. If an adequate
standard is not available for any product, create a standard for your
organization.
-
Identify additional (i.e., intermediate or auxiliary) work products that result
from the Application Engineering process.
These work products support the need for quantitative and qualitative analyses
of deliverable work products and the Application Engineering process.
-
Define the activities to be performed during the process in terms of necessary
inputs, expected results, and procedures for attaining those results. Identify
risks in attaining acceptable results and interdependencies with other
activities. Define the checks to be performed during the process and specify
when they are to be performed. Specify what is to be done when checks fail.
-
The process should be described to a level of detail that allows you to
formalize standard practice and the engineer's past experience. For example,
Project Management, Delivery and Operation Support, and configuration
management practices may be based on conventional experience with those tasks.
-
Creating an Application Model and using that Application Model to create work
products are essential elements of any Application Engineering process. As a
starting point, consider the prototypical, iterative Application Engineering
process described in Section AE (consisting of Project Management, Application
Modeling, Application Production, and Delivery and Operation Support
activities), refined appropriately to the needs of your projects.
Step: Develop Application Modeling Notation
-
- Action:
-
Organize decisions into a set of presentations in terms of a set of standard
presentation paradigms.
- Input:
-
Decision Model
- Result:
-
Application Modeling Notation Specification
- Heuristics:
-
-
Identify a set of presentation paradigms; consider the ways domain experts
generally represent various problem facets in a manner consistent with the ways
decisions are grouped in the Decision Model. Identify a set of paradigms that
are adequate to represent decisions in all the facets of a problem
description.
-
First, identify presentations by describing each decision group in the Decision
Model as a presentation, then describe the presentation in terms of allowed
decisions and any auxiliary (e.g., labeling, layout) information required by
the appropriate presentation paradigm.
-
Create the structure of the Application Modeling Notation by considering how
presentations interrelate (derivable from how decision groups in the Decision
Model interrelate). Some presentations may be meaningful only if accessed in
the context of, or in combination with, other related presentations. These
relationships determine a reasonable structure for the Notation. The ideal
structure for an Application Model is one that domain experts would consider
natural and appropriate as a model of a system. Refine the structure by
consulting with domain experts as to how decision making is best organized.
-
Identify any analyses that the application engineer should be able to perform
on individual presentations and on the Application Model as a whole. To be
most effective, these analyses should provide insights into the functional and
operational characteristics of the described system in terms of alternative
resolutions of decisions, rather than in terms of the details of generated work
products.
-
- Risk:
-
The Application Engineering process will not meet all of the needs of a
project.
- Implication:
-
Projects will have to modify the process in an ad hoc fashion and work around
incorrect assumptions of the Process Requirements.
- Mitigation:
-
Review the process with experienced project managers to ensure that it
encompasses all activities required of a project, those products that customers
require, and those products that benefit a project. Variations in project
needs should be anticipated and supported.
- Risk:
-
The Application Modeling Notation will not be usable by application engineers.
- Implication:
-
Application engineers will have difficulty creating valid Application Models.
- Mitigation:
-
Review the Notation with experienced engineers to ensure that it is
understandable and that it uses terminology and notations familiar to
application engineers.
-
- Contingency:
-
The Domain Definition
is incomplete, ambiguous, or inconsistent.
- Source:
-
Domain Definition Activity
- Response:
-
Describe the inadequacies in the Domain Definition.
Proceed with Process Requirements, and document any assumptions made regarding
the inadequate portions of the Domain Definition.
- Contingency:
-
The Domain Plan cannot be satisfied with available technical capabilities.
- Source:
-
Domain Management Activity
- Response:
-
Propose (alternative) revisions to the Domain Plan that better match available
capabilities. Complete the Process Requirements to satisfy the Domain Plan as
closely as possible.
- 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 Decision Model is incomplete, ambiguous, or inconsistent.
- Source:
-
Decision Model Activity
- Response:
-
Describe the inadequacies in the Decision Model. Proceed with Process
Requirements, and document any assumptions made regarding the inadequate
portions of the Domain Definition.
- Contingency:
-
The structure or content of the Decision Model conflicts with domain expert's
conception of an Application Model.
- Source:
-
Decision Model Activity
- Response:
-
Describe the elements of an acceptable Application Modeling Notation not
supported by the Decision Model.
-
- Contingency:
-
The Process Requirements violate constraints on the Application Engineering
process established in the Domain Definition.
- Source:
-
Domain Management Activity
- Response:
-
Evolve the Process Requirements to be consistent with the Domain Definition.
- Contingency:
- The standardized Application Engineering process is inefficient or leads
to less-than-ideal results for a particular project.
- Source:
-
Project Support Activity
- Response:
-
-
Determine that the benefits of process standardization outweigh the interests
of the particular project.
-
Evolve the Process Requirements to reflect the generally-applicable insight of
this project's experience or to be adapted to the particular conditions of
concern.
