A Process Driven Approach to Integrated Environments

Introduction

A process driven approach.

An integrated concurrent engineering environment requires an integrated engineering process as well as bridges among various tools. The integrated process defines the engineering tasks that will be performed. From an understanding of these tasks, the tool requirements for supporting each task can be derived. Understanding task support requirements enables both selection of an appropriate set of tools and the selection of the subset of tool capabilities within those tools to support a task.

Specifying the precise semantics of tool capabilities in the context of the engineering process enables the mapping of tool capabilities to task support requirements. This is important because modern flexible tools permit a wide range of interpretations for the same system model structure. A precise definition of semantics (McKennon 1993), based on task requirements, creates consistency among the users of a tool. This consistency is necessary to control the expression and interpretation of the model produced.

Precise semantics allows identification of semantically consonant capabilities in different tools. Identifying semantic consonance enables the construction of high fidelity inter-tool bridges in support of a specific engineering process. Identifying areas where semantic consonance would require major changes to the tools allows the process to be tuned to ensure a cost-effective bridge.

The role of the engineering process.

It is important to understand the key role of the engineering process in enabling an environment base on high fidelity integration of commercial off the shelf (COTS) tools.

from different vendors. Because each vendor provides as many features as possible, the chosen suite of tools will provide both unnecessary capabilities and capabilities that overlap among the chosen tools.

Task requirements allow a determination of which capabilities should not be used at all. The allocation of process tasks to functional units of an engineering organization may guide the choice of which tool should be employed to perform an overlapping capability. The choice can be made to minimize the number of tools required to support each functional role. Detailed semantic decisions can be made to enhance the integration of tools that support adjacent tasks or iterative threads of tasks. Finally, as the details of tool interactions emerge, the process can be refined to allow optimal use of tools.

DESIGN AND CONSTRUCTION OF BRIDGES

Process-based bridge design.

Process-based design of engineering environments has profound implications for the design and construction of inter-tool bridges. A single-semantic or hard-wired bridge will not accommodate the wide range of engineering processes in which a pair of tools will be embedded. However, process-driven bridges can be constructed. This may be done in two ways.

Highly individualized processes demand that bridges be built using the public open interfaces provided by tools. For example, many tools, from spreadsheets to RDD-100^reg. to CASE tools, can convey information through ASCII files containing data with appropriate delimiters and labels indicating the target semantic entity in the receiving tool, and can accept information from such files. While a bridge built using public interfaces permits a precise implementation of a process-driven semantic mapping, after the process and mappings between two tools are defined, full integration of transferred information requires disciplined change management to maintain a coherent model in both tools.

Tailorable processes and bridges

In cases where most of the engineering community adhere to similar processes and have similar tool needs, the bridging effort can be greatly reduced by the use of general-purpose tailorable process templates and associated tailorable bridge templates that fit the general process defined by the community. RDD-100 Design Guides(TM) are examples of tailorable process templates (Tronstad 1993). They are designed to be tailored to support families of processes and to be allocated onto various organization structures. Tailorable bridges, including the SEDB(TM) - RDD-100 bridge written by Martin Marietta (Stafford 1994) and the RTM reg. - Cadre Teamwork reg. bridge available from Marconi Systems Technology, support a reasonably wide range of engineering processes.

When tailorable processes or bridges are used, an engineering group using the bridge or process must agree on a mapping table to specify, in the context of their program's process, which entities in each tool are equivalent to or related to entities in another tool in the environment.

EXAMPLES

The following examples represent two very different processes and assignments of tool capabilities to tasks. They are simplified to permit an illustration of diversity without considering the dozens of objectives and hundreds of requirements that would drive an actual process/tool set selection. In both examples, there are only two tools in the environment: RDD-100, a systems engineering tool supporting requirements management, modeling, model execution, and creation of Mil-Standard reports; and a Requirements Traceability Tool supporting requirements management, allocation of requirements to a component architecture, creation of Mil-Standard reports, and a commercial repository for requirements and related entities.

EXAMPLE 1: A LOW RISK, WELL DEFINED SYSTEM

System 1 is a low risk system, built from well-understood and well-managed subsystems. The project team has integrated many of these subsystems into other projects. At the start of this project, the expected architecture is well understood and the originating requirements are fairly clear, consistent, and complete. One or two subsystems will use new technologies, and will require extensive design effort. In addition, these new subsystems may place unforeseen requirements on the overall design of the project, requiring some redesign of other subsystems to support the new technology. These factors represent areas of risk that will be mitigated by modeling and execution (Booth 1993).

A text based process

The engineering process for this project is text-based. In the Requirements Traceability Tool, the requirements are extracted, analyzed, and categorized into the specification sections in which they will appear. The architecture is defined, and the requirements are allocated onto the architecture. Subsystems whose behavior is not well-defined, based on the allocated requirements and legacy knowledge are identified as risky. For each risky subsystem, a package consisting of allocated requirements and a statement specifying analysis to be performed is prepared and sent to RDD-100.

In RDD-100, each subsystem is modeled and the models are executed to verify their dynamic consistency. The original requirements allocated to each subsystem are revised as necessary and augmented with behavioral requirements. The new and updated requirements are returned to the Requirements Traceability Tool.

In the Requirements Traceability Tool, the new requirements are allocated to the appropriate subsystems. The risk assessment is repeated and the need for further analysis is evaluated. If further RDD-100 work is necessary, any requirements that have been updated in the Requirements Traceability Tool will be sent to RDD-100 with a new analysis statement. The tasks and associated assignment of tools is shown in Table 1.

Table 1. Allocation of Tasks to Tools for a Well Defined System Simple bridge requirements

The initial bridge requirements are few and simple. For example, there is a natural mapping from an RDD-100 Requirement element to a Requirement entity in the Requirements Traceability Tool. There must also be a way to send the statement specifying the analysis to be performed to RDD-100, and to return data to the Requirements Traceability Tool as the design progresses.

Feedback to process requirements

The iterative nature of the modeling process suggests the need to control data transfer between the tools. Since requirements involved in the modeling can be edited in both tools, if there are no controls, the same requirements may be changed in different ways in each tool. Without some form of change management, either automated in each tool or implemented by a human procedure, the potential for confusion and loss of data exists. Because the risky areas in the design are small, the number of overlapping changes will be small enough to manage procedurally. Requirements received back by the Requirements Tool and those going back to RDD-100 for additional work will be reviewed to ensure that conflicting changes were not made.

EXAMPLE 2: A HIGH RISK, LARGELY UNPRECEDENTED SYSTEM

System 2 is a high risk project. Although it must conform to many thousands of government regulations, its behavior is only sketched by a few dozen high-level objectives, and much of its architecture is unprecedented.

A model based process using problem domain analysis

The project team must explore the parameters of the project, using scenarios to model the interaction of the system with its environment. These scenarios can be merged to model the behavior needed to support the interactions with the environment. They then must be executed in a simulation and the resulting behavior extensively analyzed to validate dynamic behavior such as timing, absence of lockouts, and resource usage.

The validated model constitutes the behavioral requirements; precise textual versions of these requirements can be produced by mechanically "walking" through the threads of the model (Karas 1993). Natural groupings of processes in the model will provide an important input to the architectural design.

Meanwhile, the huge number of regulatory requirements must be parsed, analyzed, and managed. Eventually these requirements will need to be reconciled with each other - there is no guarantee that different government agencies will impose consistent regulations - and with the behavioral requirements. This requires updates to the behavioral requirements, models, and architecture as well as to the textual requirements.

The Requirement Traceability Tool with it's repository provides excellent facilities for holding, analyzing, reconciling, and configuration managing the enormous number of requirements. To allow a consistent and robust change management process, the Requirements Traceability Tool will handle all configuration management (CM). The allocation of tasks to tools for this project is shown in Table 2.

Bridge requires process precision

In this example, the allocation of tasks between the tools demands a precise process for the tool interactions. The tasks in Table 2 are not sequential. For example, the tool interaction process could provide for the Traceability Tool's task Parse and Manage Regulatory Requirements to proceed concurrently with the RDD-100 tasks Model and Execute, and Define Behavioral Requirements. Once requirements reconciliation has begun, requirements will be moved between the tools frequently, and requirements work will be done in both tools.

Table 2. Allocation of Tasks to Tools for an Unprecedented System High fidelity semantic map

The semantic map for requirements must have a very high fidelity. To insure this, it will probably be necessary to restrict use of the requirements functionality to match that of the more restrictive tool. At a minimum, this requires process revisions to clearly specify what parts of requirements capabilities are off limits in each tool. Ideally there should also be tool support to lock out or hide the unused capabilities or at least consistency checks to warn that users have strayed outside of the prescribed process.

There must be support for change management; tool support is needed at least to identify conflicting changes. Unlike in System 1 where the conflict volumes will almost certainly be low, the high volume of conflicts in System 2 would overwhelm a human check. Tool support for conflict resolution would also be helpful.

To deal with the large data volumes, incremental changes, not entire sets of requirements, must pass over the bridge in both directions. This requires that both tools be able to create and read incremental change files.

The decision to allocate CM to the Requirements Traceability Tool requires sending the entire body of data from RDD-100 to the Requirements Traceability Tool whenever the design is baselined. To baseline the design, the Requirements Traceability Tool must know about all RDD-100 elements. If the Requirements Traceability Tool allows schema extensions, one approach is simply to define all RDD-100 element types as entities in the Requirement Traceability Tool's repository. Another approach is to confine the detailed semantic mapping to requirements and to address the change management issue by depositing successive RDD-100 model configurations as Binary Large OBjects (BLOBs) in the repository. The second approach limits bridge costs, but will require additional procedures to handle and track BLOBs.

CONCLUSIONS

A successful multi-tool environment

A successful project team working in a multi-tool engineering environment requires:

Engineering Processes and Procedures

Processes and procedures define engineering activities and specify which tool capabilities are used in each activity.

Semantic Mappings

Semantic mappings define how the entities and constructs of one tool are mapped into those of another.

Connectivity Mechanisms

Connectivity mechanisms are the conduits that move information among the tools.

Concurrent development of process and bridge

Because the decisions made in process definition determine the inter-tool interfaces, process definition provides the requirements for the semantic mappings. When process definition and the design and implementation of semantic mappings proceed concurrently, the costly work of constructing unnecessary bridge capabilities is eliminated.

REFERENCES

Booth, Stuart, "Risk Assessment and Mitigation Planning Early in the Development Life Cycle", Proceedings of the Third Annual Symposium of the National Council on Systems Engineering (Washington, D. C., July 26-28, 1993).

Karas, Len and Donna Rhodes, "Enabling Concurrent Engineering through Behavioral Analysis", Proceedings of the Third Annual Symposium of the National Council on Systems Engineering (Washington, D. C., July 26-28, 1993).

Malcolm, Nadine and Jane McKennon, "Integrating the Concurrent Engineering Tool Set: Issues and Approaches", Proceedings of the Twelfth Structured Development Forum (Philadelphia, PA, August, 1993).

Stafford, Randy and Herb Axe, "On the Dimensions of Interfaces between Database Applications", Proceedings of the Fourth Annual Symposium of the National Council on Systems Engineering (San Jose, CA, August 10-12, 1994).

Tronstad, Y. D., J. Peterson and S. Shreve, "Development of a System Engineering Process Model Template, Proceedings of the Third Annual Symposium of the National Council on Systems Engineering (Washington, D. C., July 26-28, 1993).

BIOGRAPHY

Jane McKennon is a Systems Engineer for RDD-100 at Holagent Corporation. Presently she writes specifications for new capabilities for RDD-100. Her background includes software development and testing.

RDD-100 is a registered trademark of Holagent Corporation. Other product names mentioned in this document are trademarks or registered trademarks of their respective owners and are used for identification purposes only.