RSP gb toc RSP Return Up Down GoTo Synthesis Leveraged Domain Engineering
PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES


DE.2.3. Domain Verification

Getting Started

Domain Verification is an activity of Domain Engineering for ensuring the correctness, consistency, and completeness of domain engineering work products. Both formal and informal techniques may be applied to the domain engineering work products to verify these properties. Domain Verification is an independent verification activity performed separately from, and in addition to, the verification performed as part of each Domain Engineering Activity.

The Domain Verification Activity is motivated by the same concern that motivates Independent Verification and Validation ( IV&V) in a conventional software development process; namely, that engineers involved in developing a work product cannot objectively judge the quality of that work product. Independent validation of the domain engineering product, from the perspective of client projects, is conducted in the Domain Validation step of the Project Support Activity.

Domain Verification establishes the correctness, consistency, and completeness of domain engineering work products. These terms have a precise meaning in the context of this activity. The concept of correctness is that of relative correctness. Similarly, the concept of completeness is that of relative completeness. A work product is said to be correct (complete) with respect to some criteria or to a more abstract representation of the entity the work product describes. For example, the Product Implementation can be said to be correct (complete) with respect to the Product Requirements. Consistency, on the other hand, is a term that applies to a collection of related work products (at the same level of abstraction) that form a whole. Two products are consistent when they exhibit the intended interrelationships. For example, the Product Architecture, Component Design, and Generation Design work products are strongly interrelated, and, therefore, mutual consistency is an important property for these work products.

Objectives

The objective of Domain Verification is to independently evaluate the quality of domain engineering work products.

Required Information

Domain Verification requires the following information:

Required Knowledge and Experience

The Domain Verification Activity requires domain and software knowledge and experience in:

PRODUCT DESCRIPTION

There are no Synthesis work products produced during Domain Verification.

PROCESS DESCRIPTION

The Domain Verification Activity consists of three steps shown in Figure DE.2.3-1 Domain Verification Process.

Procedure

Step: Verify Domain Definition

Action:
Verify the correctness, consistency, and completeness of the Domain Definition.
Input:
  • Domain Definition
  • Domain Plan: Practices and Procedures
Result:
None
Heuristics:
  • Verify that the parts of the Domain Definition are correct and complete with respect to the guidance provided in their respective activity descriptions.
  • Verify that the parts of the Domain Definition are correct with respect to any specific quality attributes required of them in the Practices and Procedures portion of the Domain Plan.
  • Verify that the Domain Synopsis, Domain Glossary, and Domain Assumptions are mutually consistent.
  • Use the verification criteria, established for the Domain Definition in its activity description, as guidance in verifying the Domain Definition.
  • Use static analysis techniques (e.g., formal inspections, reviews, analysis tools) to verify the Domain Definition. These techniques are appropriate because the Domain Definition is typically represented in document form.

Step: Verify Domain Specification

Action:
Verify the correctness, consistency, and completeness of each work product family in the Domain Specification.
Input:
  • Domain Definition
  • Domain Specification
  • Domain Plan: Practices and Procedures
Result:
None
Heuristics:
  • Verify that the parts of the Domain Specification are correct and complete with respect to the guidance provided in their respective activity descriptions.
  • Verify that the parts of the Domain Specification are correct with respect to any specific quality attributes required of them in the Practices and Procedures portion of the Domain Plan.
  • Verify that the Process Requirements, Product Requirements, and Product Design are consistent with the Decision Model. This means that these work products only reference decisions in the Decision Model and, conversely, all applicable decisions in the Decision Model are reflected in the work products.
  • Verify that the Product Architecture, Component Design, and Generation Design are mutually consistent.
  • Verify that the Product Design is correct and complete with respect to the Product Requirements.
  • Verify that the Process Requirements is correct and complete with respect to the assumptions about the Application Engineering process in the Domain Definition. The Application Engineering process is normally not explicitly described in the Domain Definition, but the Domain Definition will typically constrain what is an acceptable Application Engineering process.
  • Verify that the Product Requirements and Product Design are correct and complete with respect to the representation of the Product Family in the Domain Synopsis and Domain Assumptions parts of the Domain Definition.
  • Use the verification criteria, established for the Domain Specification work products in their respective activity descriptions, as guidance in verifying the Domain Specification.
  • Use static analysis techniques (e.g., formal inspections, reviews, analysis tools) to verify the Domain Specification. These techniques are appropriate because the Domain Specification is typically represented in document form. If parts of the Domain Specification are represented in an executable form, the use of dynamic analysis techniques may be appropriate.

Step: Verify Domain Implementation

Action:
Verify the correctness, consistency, and completeness of the Domain Implementation.
Input:
  • Domain Specification
  • Domain Implementation
  • Domain Plan: Practices and Procedures
Result:
None
Heuristics:
  • Establish the criteria that you expect the Domain Implementation to meet before you try to verify it. Identify analysis that you can perform to ensure that the Domain Implementation is correct with respect to the Domain Specification. Your plan should minimally establish verification objectives and describe a strategy for meeting those objectives.
  • Verify that the parts of the Domain Implementation are correct and complete with respect to the guidance provided in their respective activity descriptions.
  • Verify that the parts of the Domain Implementation are correct with respect to any specific quality attributes required of them in the Practices and Procedures portion of the Domain Plan.
  • Verify that the Process Support and Product Implementation are mutually consistent.
  • Verify that the Component Implementation and the Generation Implementation are mutually consistent.
  • Verify that the Process Support is correct with respect to the Process Requirements.
  • Verify that documents and automation that make up the Process Support are engineered in a way that adequately addresses human factors concerns. For example, you should establish that the Application Engineering Environment portion of Process Support has the qualities of usability, adequate performance, and tolerance of user errors.
  • Verify that the analyses that the Process Support allows to be performed on Application Models produce correct results.
  • Verify that the Product Implementation is correct and complete with respect to the Domain Specification. The requirements for the Product Implementation are represented in the Product Requirements portion of the Domain Specification. The internal organization for the Product Implementation is represented in the Product Design portion of the Domain Specification.
  • Verify that work products produced using the Process Support have expected properties. Do this by resolving the decisions of the product family's Decision Model, producing the work products corresponding to that model, and then verifying that the work products have the expected properties. Specifically:
    • Verify that the work products produced by the Process Support are correct and complete with respect to the Product Requirements and Product Design of the product family (appropriately instantiated with the decisions from the Decision Model).
    • Verify the usability and correctness of the Delivery Support. This should be established through direct inspection and by using the delivery support to install/deliver the Application Product.
    A good strategy for selecting work products to produce is to try to build all or part of Legacy Products that are within the intended scope of the domain.
  • Use the verification criteria, established for the Domain Implementation work products in their respective activity descriptions, as guidance in verifying the Domain Implementation.
  • Use conventional verification techniques that are appropriate to the task of verifying the Domain Implementation. Static analysis techniques (e.g., inspections) are appropriate for static representations of the Domain Implementation (e.g., Application Engineering User's Guide). Dynamic analysis techniques (e.g., testing) are appropriate for dynamic aspects of the Domain Implementation (e.g., automated support for specification, analysis, and product generation).

Risk Management

Risk:
The criteria used to evaluate the domain engineering work products will be unduly influenced by the final content and form of the work products themselves.
Implication:
The effectiveness of the verification effort will be reduced.
Mitigation:
Define acceptable levels of correctness, completeness, and consistency for each domain engineering work product prior to examining it.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:
The Domain Definition is incorrect, inconsistent, or incomplete.
Source:
Domain Definition Activity
Response:
Precisely communicate how the Domain Definition is incorrect, inconsistent, or incomplete.

Contingency:
The Domain Specification is incorrect, inconsistent, or incomplete.
Source:
Domain Specification Activity
Response:
Precisely communicate how the Domain Specification is incorrect, inconsistent, or incomplete.

Contingency:
The Domain Implementation is incorrect, inconsistent, incomplete.
Source:
Domain Implementation Activity
Response:
Precisely communicate how the Domain Implementation is incorrect, inconsistent, or incomplete.

Feedback From Product Consumers

None



PHS