RSP gb toc RSP Up Up Up GoTo Synthesis Leveraged Domain Engineering
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 achieve assigned business objectives. The business-area organization provides resources and direction for both domain engineering and associated application engineering projects.

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 determines the nature of the market addressed and how resources are allocated between domain engineering and application engineering projects. An increment plan determines how domain engineering resources are applied to create an efficient Application Engineering process and a high-quality product family.

Domain Management monitors domain engineering performance to assess progress, ensure proper adherence to plans, and guide needed revisions to the evolution and increment plans. 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 and in achieving the overall objectives of the business area. Domain Management assists the management of targeted application engineering projects to create plans that ensure optimal leverage from the domain and to identify enhancements needed by the projects for inclusion in timely increments of domain evolution.

Objectives

The objective of Domain Management is to manage business-area resources to achieve the organization's business objectives. Management establishes domain objectives for the organization to guide the creation and revision of an increment plan for incremental domain development and evolution. Domain evolution is concerned with the overall trends in the market for the business area and how resources should be applied to best serve the evolving market. The primary concern in planning for domain evolution is projecting the evolution of market need and organizational capability to meet that need over time.

Each increment of domain development should result in the ability to serve a particular level of market need. 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 in coordination with Domain Management and with an awareness of domain objectives and capabilities, to meet particular customer needs.

Required Information

The Domain Management Activity requires the following information:

Required Knowledge and Experience

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

PRODUCT DESCRIPTION

Name:
Domain Plan
Purpose:
Define long-range and near-term objectives 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 defines long-range objectives for the domain and organizes resources to achieve them. This plan is strategic in nature and recognizes that both an organization's capabilities and its opportunities for profitable business change over time. Not all objectives can be met initially but must develop in the course of time, in increments that balance alternative uses of available resources against the potential for return.
  • 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 achieve near-term domain objectives.

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 mix of near-term and long-term business objectives. 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 long-range 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 plan must show how near-term objectives contribute to long-range objectives. All near-term objectives must support long-range objectives.
  • The projected market for products in the business area must be large enough to compensate sufficiently for projected costs and risks.
  • For the Domain Evolution Plan:
    • The plan is complete (i.e., it addresses all business objectives).
    • The plan is credible (i.e., it sets forth a strategy that is feasible, given projected resources).
    • Domain objectives are realistic, given the projected availability of resources and strength of the competition.
    • All important risks are identified and addressed.
    • Criteria are defined to measure progress against objectives and to choose among alternative plans or indicate a need for replanning.
  • Each Domain Increment Plan institutes a plan that seems likely to achieve the objectives assigned to that Domain Engineering increment by the Domain Evolution Plan.

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 economically viable. 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 the market or 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.

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 domain objectives that will guide you in the long-term evolution of the domain. Develop a preliminary statement of domain objectives that expresses the strategic mission of the organization. (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.)
  • Develop market projections as a basis for understanding current and future customer needs to be met. Refine the objectives to match perceived market opportunities. Consider the following questions:
    • What are the critical aspects of your market?
    • Who are your customers and what factors are most important to them in deciding to award contracts?
    • What type of products will you produce to address this market?
    • Who are your competitors? What are their strengths and weaknesses?
    • What are your strengths and weaknesses?
    • How many systems do you expect to produce both in the first year and as the domain matures?
  • Describe a strategy for achieving domain objectives. The life cycle of a domain comprises four phases:
    • Conception. A small, cohesive group explores the boundaries of a domain to establish a viable market basis; project support is not viable yet.
    • Elaboration. One or a few very similar projects are directly supported; domain evolution emphasizes needs that are important to most customers.
    • Expansion. Supporting the planned diversity of projects is now viable; market opportunities drive further domain evolution.
    • Consolidation. Little additional diversification is viable; projects are managed to fit within the supported/variations in domain capabilities as much as possible.
  • Develop a profile of the market to be supported as the domain matures. Provide details in terms of evolving domain objectives.
  • Develop a profile of the evolution of automation to be developed in support of application engineering projects. Consider the degree of automation you expect to deploy in support of application engineering, both initially and as the domain matures.
  • Develop a profile of the resources needed to fulfill domain objectives. Consider both quantitative and qualitative needs in all skill categories. Project how these resources are to be allocated between domain engineering and application engineering projects. Consider how resources will be allocated between domain development and application engineering projects.
  • Define a series of domain development increments, and define objectives, consistent with domain objectives and allocate them to increments. Consider the following questions:
    • How do you expect the market, your business, and your competition to change over time?
    • What are the long-term risks in developing the domain, and how will you mitigate each one?
    • What are the objectives for the domain, and what are the objectives of each increment of development that is to achieve those objectives?

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. Another recurring class of risks involves how to evolve the domain to meet long-range domain objectives. Actions to mitigate these risk classes may conflict.
    • Another important class of risks relates to problems discovered in previous iterations of the Domain Engineering process.
  • 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 balance long-term domain objectives against 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.
  • 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:
Market needs will not be met by projected development.
Implication:
Demand for projects will not be sufficient to justify planned investment in the domain.
Mitigation:
Review objectives and plans with marketing and major customers to ensure that market needs are properly represented.

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 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:
Customer needs are not being met by the domain.
Source:
Project Support Activity
Response:
  • Revise the Domain Plan to accommodate new needs.
  • Determine that needs are incompatible with your organization's business objectives.

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 incompatible with the organization's business objectives and therefore 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.


PHS