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 a product as a set of work products that offer opportunities for reuse.

In an organization practicing opportunistic Synthesis, the Application Engineering process combines activities that create work products from scratch with activities that reuse existing work products, in whole or in part, available from Application Engineering Process Support. Activities involving reuse focus on application engineers resolving standardized decisions relating to the work product to determine whether members of existing work product families will satisfy Application Engineering needs. Based on these decisions, application engineers obtain useful work products from Application Engineering Process Support and tailor them into work products that completely meet customer requirements.

Objectives

The objectives of Application Engineering are to:

• Understand the needs of customers, balancing concerns of cost versus value, to produce a product that fulfills those needs most effectively
• Organize and direct resources for the production and support of the product
• Produce software and documentation that support the delivery and use of the product
• Maximize productivity in creating work products through appropriate use of reusable components provided by Application Engineering Process Support

Required Information

Application Engineering requires the following information:

• Application Engineering Process Support
• Customer requirements

Required Knowledge and Experience

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

• The problems that the products in the domain are intended to solve and the engineering tradeoffs to be considered in creating a viable solution
• Understanding and interpreting customer requirements and developing applications that satisfy those requirements
• The management, production, and delivery of software work products
• How to use the Application Engineering Process Support to develop an application
• The information required by the Application Engineering process employed by the project

PRODUCT DESCRIPTION

The product of Application Engineering is a set of work products as determined by the process being followed. Projects use their organization's normal software development process producing familiar work products. Among the work products that an Application Engineering process might produce are software requirements documents, software system architectures, and software partitioned into separately developed components.

PROCESS DESCRIPTION

The Application Engineering Activity consists of a set of activities specific to the software development process your organization uses. You perform the same set of activities whether or not you practice opportunistic Synthesis. Within activities, however, you seek opportunities to reuse existing work products; thus, how you perform activities may differ when you incorporate opportunistic Synthesis into your software development.

Figure AE-1. A Prototypical Application Engineering Process. shows an ESP-derived and prototypical process for Application Engineering. It is recognizable as a conventional waterfall software development process and therefore straightforward to tailor to the needs of your organization. Reuse within this process is entirely localized to focus on rapid production of draft individual application engineering work products.

The activities of the Application Engineering process are organized into three classes. (In the ESP model, activities are grouped into subclasses, and the subclasses are grouped into classes.) The classes are as follows:

• Project Management. These management and administrative activities support planning, monitoring, and controlling the project. These activities include the following:
  • Plan and initiate those activities required to initially start the project, produce the project's master plan and schedule, estimate overall cost, and acquire necessary resources.
  • Determine the objectives, alternatives, constraints, and success criteria for a cycle.
  • Analyze the risks inherent in the cycle's objectives and suggest risk aversion strategies.
  • Produce the Cycle Development Plan which organizes and provides the details for the activities which will be performed during the cycle.
  • Initiate the cycle development activities and observe the project's progress and current status.

• Process Management. These activities manage the technical control and quality of the delivered product. These activities include the following:
  • Define quality standards and ensure that the work products conform to these standards.
  • Assess the project's current process, identify areas that need process improvement, and improve the process.
  • Baseline each increment of the product(s) and control any changes to the product(s).
  • Control the editing, production, and distribution of project documentation.
  • Create and maintain the software systems that the application engineers use to develop and test the product(s).
  • Develop, validate, and administer the training program for the developers and users of the system.

• Product Development. Activities in this class specify, design, implement, verify, and maintain the end product. Product Development consists of the following activities and subclasses:
  • Software Systems Engineering. Activities in this subclass provide the system's specification and design. It consists of the following activities:
    • Define System Requirements. This activity collects, integrates, specifies, relates, and organizes the project's needs and objectives to provide the foundation for system design and implementation. These needs and objectives are expressed in the system requirements.
    • Develop System Architecture. This activity identifies a system-level architecture, including hardware and software components, that satisfies the system requirements within budget and schedule constraints. It documents this architecture in the system architecture.
  • Software Engineering. This subclass includes all activities related to software requirements, software design, and software implementation:
    • Requirements. This activity analyzes the system requirements and architecture to derive software requirements that further clarify the allocated system requirements.
    • Architecture Design. This activity derives a software system configuration that performs the required functions at the necessary level of performance and reliability. This configuration is documented in the software system architecture.
    • Component Design. This activity refines the software system architecture to identify the lowest level components and their interfaces. It produces a detailed design document, the Component Design.
    • Create Components. This activity develops and documents the source code for each software component in accordance with the detailed design provided in Component Design.
    • Integrate Software Components. This activity integrates the software components into larger software configuration items through an incremental process of adding software components to grow the core of software into the finished system.
  • Product Verification and Validation. This subclass includes all activities related to the verification and validation of the system and software requirements.
    • Verify Software Components. This activity verifies the software components.
    • Verify Software Integration. This activity verifies the integrated software components up to the final system.
  • Operation and Maintenance. This subclass includes all activities related to system installation and operational support.
    • Provide Operational Support. This activity provides technical assistance in response to customer requests and performs regular maintenance to ensure that the finished system performs efficiently.

Procedure

In this opportunistic Synthesis process, reuse occurs while performing certain Application Engineering activities-specifically, those yielding work products for which Domain Engineering has implemented application engineering work product families. Thus, application engineers perform the activities of the process shown in Figure AE-1. A Prototypical Application Engineering Process.

The way each activity is performed depends in part on whether Domain Engineering has provided work product families that support reuse within that activity. The consequences of Domain Engineering support for opportunistic reuse are described in the following five representative steps for creating a work product. An application engineer performs these steps to create a work product whether or not reuse is supported. However, when reuse is supported, application engineers perform these five steps somewhat differently. The heuristics for each step include descriptions of differences due to reuse.

Step: Define Success Criteria for the Work Product

Action:

Determine the success criteria and characteristics that the work product must have to be considered complete.

Input:

Required information of the application development process relevant to the work product. This information would include customer requirements or appropriate work products from preceding activities.

Result:

Success criteria

Heuristics:

• Review the company's policies and procedures to determine the requirements and restrictions relevant to this particular type of work product. Define your success criteria as meeting relevant policies and procedures.
• Review customer requirements or appropriate work products from preceding activities to determine the success criteria relevant to this particular type of work product. Define your success criteria as meeting relevant customer requirements.
• Determine reviewers of the work product who can provide insights and alternative viewpoints relevant to the work product's subject matter.

Step: Develop Internal Structure

Action:

Design the internal structure of the work product based upon the needs of the application engineering project.

Input:

• Success criteria
• Application Engineering Process Support: User's Guide for the type of work product

Result:

Work product's internal structure

Heuristics:

• Select from the work product families (described in the User's Guide) for an existing family that might directly contribute to this activity's work product. For example, if you are producing a requirements specification document, search for a requirements specifications document family that could be used in producing the new specification.
• The internal structure depends upon the work product type. For a document, this might be an outline; for a plan, a set of milestones; for source code, an internal design.
• If you cannot find a suitable member of the work product family, you must create the structure.
• Modify or extend the structure to suit specific needs.

Step: Produce the Work Product

Action:

Produce the work product by filling in its internal structure.

Input:

• Success Criteria
• Application Engineering Process Support: User's Guide for the type of work product
• Work product's internal structure

Result:

Work product

Heuristics:

• The User's Guide describes a procedure for creating an Application Model (i.e., Application Modeling). This procedure identifies what decisions to make and how to apply those decisions to select a member of the work product family.
• Develop the desired work product by applying the decisions of the Application Model to select and tailor work product component families into components that fill in parts of the work product's internal structure.
• If you cannot find suitable component family members, you must create the work product.

Action:

Verify that the work product meets the success criteria.

Input:

• Work product
• Success criteria

Result:

None

Heuristics:

For each success criterion, determine whether the completed draft of the work product satisfies the success criteria. If it does not, alter the draft.

Step: Baseline the Work Product

Action:

Provide a copy to configuration management for baselining. Produce the necessary reports characterizing the work product and its cost.

Input:

Work product

Result:

None

Heuristics:

Include information in standardized reports characterizing the extent that work-product reuse occurred. To the extent possible, tell the domain engineers what kinds of work product components were needed and not found, or will be needed in the subsequent (follow-on) activities of this particular application project.

Risk Management

The risks associated with Application Engineering depend on the specific software development process followed by the application engineers. Nonetheless, the following risks are (more or less) independent of the particular Application Engineering process.

Risk:

Application engineers will select totally inappropriate (unknown to them) members of a work product family.

Implication:

Modifying or extending the selected family member so that it suits the application engineer's needs will be time-consuming, thereby making the cost of developing a work product more expensive than developing it from scratch.

Mitigation:

Have the Project Support staff initially work together with the application engineers to help them understand how to effectively express their needs in an Application Model.

Risk:

Application engineers will inadvertently invalidate certain desired properties of a family member when they modify or extend the member to suit their needs.

Implication:

Work product verification costs will increase because application engineers will have to perform more extensive testing than normally necessary to ensure that all properties of the family member are still valid.

Mitigation:

Have the Project Support staff available to review the impact of proposed modifications or extensions not addressed in the User's Guide.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:

Application Engineering Process Support does not provide the information needed to decide which families and which components are useful. Consequently, application engineers do not find reusable components or spend excessive time finding them.

Source:

Domain Engineering

Response:

• Request immediate (verbal) clarification from the project support staff.
• Characterize the additional information needed to assess the reuse potential of a family and its members. Proceed with the Application Engineering process using the Application Engineering Process Support to the extent possible given the inadequacies.

Contingency:

Application engineers are unable to identify work products, within the domain, that are relevant to the current application development project.

Source:

Domain Engineering

Response:

• Identify what kinds of families need to be developed.
• Proceed with the Application Engineering process using the Application Engineering Process Support to the extent possible given the inadequacies.

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.