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

AE. Application Engineering Overview

Getting Started

Application Engineering is a Synthesis process for creating and supporting an application product that satisfies specified customer requirements. A product is represented by a set of associated work products that result from analysis of those requirements. Application Engineering is characterized by a comprehensive life-cycle process for the management, analysis, production, and support of the members of a product family. This is similar in purpose to a conventional software development process, but is tailored to the problems and the needs of projects in a particular business area. Such a business-area focus allows for the systematic reuse of standardized work products within and among projects in that business area.

Domain Engineering identifies a set of characteristic decisions for a business area that determine how a product can be tailored to meet particular needs. It also provides standardized work products in a form that supports tailoring to those decisions. Application engineering concentrates on the analysis of customer requirements to resolve those decisions. The result is a model of a corresponding product that can be evaluated according to those requirements. When a model is found to be acceptable, it is used to drive the generation of tailored work products that implement the model. After the resulting work products are verified to the model, they are delivered to customers for further evaluation and use.

Objectives

The objectives of Application Engineering are to:

Required Information

Application Engineering requires the following information:

Required Knowledge and Experience

Application Engineering requires domain, business, and software knowledge and experience in:

PRODUCT DESCRIPTION

Application Engineering creates four work products:

PROCESS DESCRIPTION

The Application Engineering process defined here is prototypical in the sense that an objective of Domain Engineering is to define such a process tailored to the needs of a domain. This Application Engineering process consists of the four activities shown in Figure AE-1. A Prototypical Application Engineering Process. Figure OV-1. Interaction between Application and Domain Engineering

Procedure

Step: Project Management

Action:
Plan, monitor, and control project resources to deliver a product.
Input:
Customer requirements
Result:
Project Plan
Heuristics:
  • Institute policies and procedures in accordance with the Application Engineering Process Standard of Application Engineering Process Support. Allocate time and budget for personnel to receive needed training in use of Application Engineering Process Support. Domain Engineering Project Support staff will deliver, including installing automation, and support effective use of Application Engineering Process Support.
  • Create a plan that reflects the process defined and supported by Application Engineering Process Support. Revise the plan to reflect unexpected progress or delays.
  • For more accurate monitoring and control of the effort, set specific, measurable objectives and schedule repeated short iterations through the process to achieve them. Build the required product incrementally and review interim capabilities with the customer and users in order to maximize opportunities for feedback that can ensure timely delivery of a valid result.
  • Coordinate development and performance of the plan with Domain Management both to exploit any forthcoming domain development and to schedule domain improvements (in process or product) needed by this project.

Step: Application Modeling

Action:
Resolve decisions to specify a required product, based on an analysis of customer requirements, and evaluate it with respect to customer or technical constraints on an acceptable solution.
Input:
Customer requirements
Result:
Application Model
Heuristics:
  • The User's Guide of Application Engineering Process Support defines an application modeling process for products within a domain. This process provides a framework, notation, and mechanisms for:
    • Specification. Analyzing customer requirements and expressing them in an Application Model as a set of decisions that describe an Application Product which should satisfy those requirements.
    • Validation. Evaluating the functional adequacy of a modeled Application Product by analyzing the static (consistency and completeness) and dynamic (execution behavior in a simulated environment) characteristics implied by the Application Model.
    • Assessment. Evaluating relevant properties of alternative Application Models to determine, qualitatively and quantitatively, which will result in a system that best satisfies the customer's operational and product quality requirements.

    The Application Engineering Environment provides associated automated support for this process.

  • Perform the prescribed application modeling process to create an Application Model that expresses customer requirements. Extend the model, as necessary, to reflect engineering decisions needed to specify a complete product. Review your understanding of those requirements, as expressed in the model, with customer (and user) representatives.
  • Use provided mechanisms to specify, validate, and assess alternative Application Models and review the results with customer representatives. If one of the provided mechanisms is simulated execution, review use of the simulated application with customer and user representatives.
  • Based on your perception of the risks, rapidly build an approximate (i.e., complete but inaccurate) model of the complete product or partial models of poorly understood aspects of the product. For parts of the customer requirements that are incomplete or unclear, create alternative (partial) models that can be compared in review and evaluation with the customer.
  • If the implications for the Application Product of aspects of an Application Model are not clear, seek clarification and elaboration from Domain Engineering Project Support staff. Project support can determine how decisions (individually and in combination) affect each of the work products that will make up the Application Product.
  • When some aspect of customer requirements cannot be expressed accurately in an Application Model or acceptable properties cannot be attained for the product, seek Domain Engineering assistance. For particular problems, there may be workarounds or alternative ways of describing particular facets of the product.

Step: Application Production

Action:
Create a standardized product and accompanying delivery support work products in accordance with an Application Model.
Input:
Application Model
Result:
  • Application Product
  • Delivery Support
Heuristics:
  • Application Engineering Process Support provides a mechanical, possibly automated, process for creating an Application Product and Delivery Support, given a valid Application Model representing customer requirements and engineering decisions.
  • For each work product that makes up the Application Product and Delivery Support, there is a manual (documented in the User's Guide) or automated (implemented in the Application Engineering Environment) generation procedure, driven by the Application Model, for constructing a tailored version of the work product.
  • In some cases, there may be facilities in Application Engineering Process Support for special component implementation. These facilities support the direct construction of highly variable parts of particular work products without violating the integrity of the Application Model. Such modifications generally entail greater effort and risk of error, both initially and when requirements change.
Step: Delivery and Operation Support
Action:
Deliver the Application Product to the customer, support its use, and evaluate its effectiveness.
Input:
  • Application Product
  • Delivery Support
Result:
None
Heuristics:
  • Delivery Support provides the mechanisms needed to deliver an Application Product to the customer. Delivery includes installing the Application Product into its operational environment and training users in its operation. Procedures for accomplishing this are part of the User's Guide of Application Engineering Process Support with additional specifics included as part of Delivery Support.
  • Application engineers provide consulting assistance as needed for users to become effective with the Application Product. This encompasses both initial training and subsequent troubleshooting if unexpected behaviors are detected.
  • Operation support includes analyses of the effectiveness of the Application Product for users. Application engineers should identify and document any problems encountered and any additional or changed needs revealed as the Application Product is used.

Risk Management

None

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:
The standardized product family is inadequate to support the needs of particular customers.
Source:
Domain Engineering
Response:
Describe why the standardized product family is deemed inadequate, and suggest how it can be improved.

Contingency:
The standardized Application Engineering process is inefficient or leads to less-than-ideal results for this project.
Source:
Domain Engineering
Response:
Describe why the standardized Application Engineering process is deemed inefficient or inadequate, and suggest how it can be improved.

Contingency:
The Application Engineering Process Support provided is incomplete or deficient.
Source:
Domain Engineering
Response:
Describe the inadequacies in the Application Engineering Process Support. Indicate which sections are incomplete or deficient. These may include: missing work product families, an incomplete User's Guide, errors in the User's Guide, improperly described Adaptable Components, malfunctioning generation procedure(s), and bugs in interface software provided by Domain Engineering.

Feedback From Product Consumers

Contingency:
The customer requests new or modified capabilities for the system.
Source:
Customer
Response:
  • Build a new version of the system.
  • Reject the suggestions as out of scope.
  • Ask Domain Engineering to make necessary changes in the domain.

Contingency:
The customer identifies system anomalies, changes to the target environment, inadequate system performance, or inadequate reliability.
Source:
Customer
Response:
  • Correct system anomalies, accommodate changes to the target environment, tune the system.
  • Reject changes as out of scope.
  • Ask Domain Engineering to make necessary changes in the domain.



PHS