PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES

DE.1. Domain Management

Getting Started

Domain Management is an activity of Domain Engineering for managing business-area resources to increase opportunities for cost-effective reuse of previously developed assets. Domain Management plans, assigns resources, and directs Domain Engineering to serve the needs of a targeted application engineering project.

Domain Engineering develops and evolves a domain through a series of increments. The Domain Plan lays out both a master plan for evolution through projected increments (evolution plan) and, as each increment is initiated, a detailed plan for each increment (increment plan). The evolution plan identifies the systems that provide the basis for a domain (i.e., the source of raw material) and the application engineering projects that are targeted for support. An increment plan determines how domain engineering resources are applied to create reusable assets that can be exploited effectively in the targeted application engineering project.

Domain Management monitors domain engineering performance to assess progress, ensure proper adherence to plans, and guide needed revisions to the evolution and increment plans based on feedback from Application Engineering use of domain assets. A key concern of Domain Management is coordinating Domain Engineering activities to support the needs and priorities of targeted application engineering projects in satisfying customers' needs. Domain Management attempts to ensure effective use of allocated resources by coordinating its planning to match the needs of a targeted application engineering project.

Objectives

The objective of Domain Management is to manage business-area resources to create cost-effective reuse opportunities for a targeted application engineering project. Management establishes domain objectives for the organization to guide the creation and revision of an increment plan for a series of domain increments. An increment begins when a project is first targeted for support or when the needs or status of the targeted project changes significantly.

For each increment of development, Domain Management develops a plan to deliver capabilities that match the needs of targeted application engineering projects. Application engineering projects are planned independently, but with an awareness of domain capabilities, to meet particular customer needs.

Required Information

The Domain Management Activity requires the following information:

• Business objectives, specifically the priorities of executive management for business area development
• Domain Definition: Domain Status

Required Knowledge and Experience

The Domain Management Activity requires domain and business-area knowledge and experience in:

• The nature of projects in the business area
• All aspects of strategic business-area management in the organization
• All aspects of application project management in the organization

PRODUCT DESCRIPTION

Name:

Domain Plan

Purpose:

Define near-term objectives for a business area and organize and manage domain resources to achieve those objectives.

Content:

A Domain Plan consists of three parts:

• Domain Evolution Plan. The Domain Evolution Plan establishes a purpose and scope for near-term domain development.
• Practices and Procedures. Practices and Procedures prescribe the preferred practices and procedures that are to guide the proper performance of domain development.
• Domain Increment Plans. A Domain Increment Plan specifies how to organize and manage Domain Engineering resources to facilitate reuse of previously developed assets by the targeted application engineering project.

Both the Domain Evolution Plan and the Domain Increment Plans include the following:

• Risk Analysis. Identification of uncertainties in meeting allocated business (for the Domain Evolution Plan) or domain (for a Domain Increment Plan) objectives, assessment of the risks of failure, and identification of mitigation strategies.
• Objectives. The scope and focus of support to be provided for the domain or the increment of domain development, reflecting the needs and priorities of targeted application engineering projects. Scope is indicated by an identification of previously built systems upon which the domain will be based; focus is indicated by the choice of targeted project. Objectives are divided into risk objectives and product objectives. Risk objectives attempt to mitigate risks identified in the risk analysis. Product objectives establish goals and success criteria for creating specific work products.
• Schedule. The allocation of domain resources to development increments that satisfy domain objectives or to activities within an increment that satisfy increment objectives. The schedule establishes specific milestones and success criteria for domain development increments or for the activities of a development increment.
• Issues. A description of issues that arise in performing the plan.

Form and Structure:

To the extent possible, the form of a Domain Evolution Plan should be the form your organization currently uses: the Domain Evolution Plan should follow the form used for business planning; Practices and Procedures should follow the form used for standardizing the practices of application projects; and the Domain Increment Plans should follow the form used for application project planning.

Verification Criteria:

The verification criteria for the Domain Evolution Plan are:

• The expected needs (i.e., opportunities for reuse) of planned projects in the business area are sufficient to compensate for projected costs of domain development.
• The Domain Evolution Plan gives the domain a viable near-term purpose that is consistent with the needs of targeted projects.
• Each Domain Increment Plan institutes a plan that seems likely to satisfy the expected needs of the targeted project.

PROCESS DESCRIPTION

The Domain Management Activity consists of three steps as shown in Figure DE.1-1 Domain Management Process.

The Domain Evolution step begins upon creation of a domain and continues until the domain is no longer judged to be viable in serving the needs of an application project within the business area. The Domain Evolution Plan prescribes a series of Domain Development increments. Each increment is planned and performed iteratively until its objectives in the Domain Evolution Plan are met. The Domain Evolution Plan is subject to revision after the completion of each increment to reflect progress or changing needs of targeted application engineering projects and their customers. The step to Institute Practices and Procedures occurs before the initiation of the first increment of Domain Development and is revisited as needed to update the Practices and Procedures to ensure an effective and efficient approach to Domain Engineering.

The plan is iterated whenever a targeted project is initiated, terminated, or has a significant change in its own plan. Plan iteration requires you to reconsider the scope and focus of support you are providing to projects.

Procedure

Follow these steps for the Domain Management Activity.

Step: Domain Evolution

Action:

Create a plan for Domain Evolution.

Input:

• Business objectives
• Domain Definition: Domain Status

Result:

Domain Plan: Domain Evolution Plan

Heuristics:

• Develop a prioritized set of near-term domain objectives that will guide you in domain development. Develop a preliminary statement of domain objectives that identifies targeted projects and their needs. Refine the objectives to reflect the views of project managers, particularly their perceptions of their projects' risks and assets of greatest benefit to their projects. (Refer to the heuristics for the Domain Development step for suggestions on a risk-based management process that you can also apply in performing this step.)
• Identify any previously built systems that are to be taken as characteristic instances of the domain and from which reusable assets are likely to be extracted.
• Try stating objectives in terms of commonalities and variations that characterize systems in the domain or that arise in the practice of Application Engineering.

Step: Institute Practices and Procedures

Action:

Develop and document standard practices and procedures to be followed in the activities of Domain Engineering.

Input:

None

Result:

Domain Plan: Practices and Procedures

Heuristics:

• Prescribed practices and procedures should encompass administrative, software development (e.g., requirements and design methods, coding and documentation standards), project management and control, and quality assurance (e.g., testing, walkthrough, and review procedures).
• Configuration management procedures are a key element for controlling iterative domain development. Each iteration of domain development is represented by one version of each domain engineering work product that you produce. Feedback on the use of a product version leads to the creation of a new version in a later iteration of development.
• Consider how consistency and quality standards will be achieved in domain practices.

Step: Domain Development

Action:

Create a plan for developing a domain increment.

Input:

• Domain Evolution Plan
• Practices and Procedures
• Domain Definition: Domain Status

Result:

Domain Increment Plan

Heuristics:

• A Domain Development increment consists of repeated cycles through a process comprised of four steps as shown in Figure DE.1-2. A Risk-Based Process for Increment Management This guidance assumes you are experienced in project management. Refer to the descriptions of the process model and activities for the ESP (Software Productivity Consortium 1992b) for a detailed project management method that you can follow to tailor and elaborate this process.
• The Domain Evolution Plan identifies the objectives to be met by the increment. Identify and rank the domain development risks faced by the organization in meeting these objectives.
  • A recurring class of risks that domain development must face is the near-term ability of targeted application engineering projects to create required products. Actions to mitigate these risks take priority over other domain objectives.
  • Another important class of risks relates to problems discovered in previous iterations of domain development.
• Develop a prioritized set of near-term increment objectives that address the risks identified in the risk analysis. These objectives may be revised, as Domain Engineering iterates, to meet the Domain Evolution Plan objectives for the increment.
  • A domain-development approach must address the short-term needs of targeted projects.
  • Each objective should have associated success criteria that are used to determine whether the objective has been met. The success criteria should be written in such a way that they are directly measurable (if possible).
  • Objectives are often stated in terms of variations that characterize systems in the domain as represented by a set of work products or variations to be allowed in the practice of Application Engineering.
  • Set objectives for this increment of domain development that respond to both the risk and the intended result of domain objectives. Increment objectives should address the particular needs of targeted projects.
• Develop a schedule that allocates resources to tasks.
  • Create specific goals and completion criteria for each task. Each task is characterized by a Domain Engineering activity to be performed and completion criteria appropriate to that activity. The full set of tasks must address the near-term objectives within the resource budget provided. If the resource budget does not allow all the objectives to be addressed, the objectives with the highest priority should be addressed.
  • Plan for short iterations so that mistakes made in front-end tasks may be caught and corrected quickly in a subsequent iteration. Iterations at the beginning of the life cycle of a domain should be particularly short (three to four months) to compensate for the likely learning curve in domain concepts.
• Monitor domain engineering work progress to planned milestones and completion criteria.
  • The schedule establishes milestones and completion criteria for activities that are used to evaluate progress. Whenever new issues are identified or progress differs from that planned, evaluate whether to document your concerns for future planning or to revise the current plan for immediate action.
  • Document the source, implications, and possible and actual resolutions of each issue.

Risk Management

Risk:

Domain plans will not be met within schedule with allocated resources.

Implication:

Domain capabilities will fall short of plans.

Mitigation:

• Review plans with experienced engineers to ensure that planned development is technically viable.
• Reevaluate domain objectives and replan domain evolution to provide for shorter iterations that achieve essential capabilities sooner; defer work on less important objectives.

Risk:

Domain engineers resist using standardized practices and procedures.

Implication:

Inefficient operation and employee dissatisfaction will reduce productivity.

Mitigation:

• Involve domain engineers in developing practices and procedures.
• Provide education and apprenticeships.
• Conduct pilot projects that emphasize learning new skills over product delivery.

Risk:

Domain engineers fail to recognize when to terminate an iteration.

Implication:

• There will be excessive detail in products without adequate foundation or potential benefit.
• Schedules will slip.

Mitigation:

Review objectives and completion criteria to make sure they are specific and understood by the domain engineers.

Risk:

Project needs will not be met by planned development.

Implication:

Provided reusable assets will not have sufficient value to targeted projects to justify costs of the domain.

Mitigation:

Review objectives and plans with project managers to ensure that the needs of their projects and the projects' customers are properly understood.

Risk:

Domain plans will not be met within schedule with allocated resources.

Implication:

Domain capabilities will fall short of plans.

Mitigation:

• Review plans with experienced engineers to ensure that planned development is technically viable.
• Reevaluate objectives and project needs to focus support on key needs of the targeted projects first; defer work on less urgent objectives.
• Revise the Domain Increment Plan to add or defer activities, or to reallocate time and resources among planned activities, as priorities dictate.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:

The Domain Definition and/or Domain Specification fails to provide the needed capabilities required by the Domain Plan.

Source:

Domain Analysis Activity

Response:

Describe ways in which the Domain Definition and/or Domain Specification fail to provide the necessary capabilities. Modify schedule to allow completion of indicated Domain Definition or Domain Specification revisions.

Feedback From Product Consumers

Contingency:

Project needs are not being met by the domain.

Source:

Project Support Activity

Response:

• Revise the Domain Plan to accommodate new needs.
• Determine that the needs of a project are outside the proper boundaries of the domain.

Contingency:

Practices and procedures are either ineffective or inefficient.

Source:

• Domain Analysis Activity
• Domain Implementation Activity
• Project Support Activity

Response:

Revise practices and procedures to reflect domain experience.

Contingency:

The Domain Plan is too ambitious for available resources or expertise.

Source:

• Domain Analysis Activity
• Domain Implementation Activity

Response:

• Allocate additional resources or time to domain development.
• Refine the Domain Plan to reduce the scope.