SECTION 2

IDEF modeling continued with the IEW Data Model. This effort began by selecting a baseline model to represent IEW information requirements. The C2 Core Data Model was chosen as base model for the IEW Data Model. The next key step was to highlight information flows in the IEW Process Model as they supported command and control activities. This led to the overall mapping of the data exchanges within the IEW Process Model to the C2 Core Data Model. Mapping continued with the comparison of the Moderniz ed Intelligence Database (MIDB), the C2 Core Data Model, and the United States Message Text Formatting Program.

From the above activities an entity pool was created which was reviewed by SMEs from IEW functional areas, as well as IEW materiel developers, combat developers, and outside functional area experts. Next, the Key-Based IEW Data Model was created and brought for review. This process continued through the development of non-key attributes, domain values, and metadata. Every step in the development of the IEW Data Model was extensively analyzed so that the information requirements of the SMEs, combat d evelopers, materiel developers, and functional area experts were addressed by the IEW Data Model. Finally, the IEW Data Model came to represent an accurate depiction of the information requirements needed to perform IEW operations.

2.1 THE MODELING PROCESS

The Department of Defense has mandated the use of IDEF modeling techniques as their modeling language because it is most easily understood by management, information users, and information system specialists. The IDEF modeling techniques are precise and inclusive, supporting Process Models, Data Models, consistent definitions, and analytic matrices.

Process Models (IDEF0) analyze and document business processes. For each process or sub-process, the necessary information flows and roles are defined (e.g., inputs, controls, and outputs). Additionally, the systems, people, or equipment that perform the activities are recorded (mechanisms).

Data Models (IDEF1X) analyze and document the fundamental data needed to support the business as defined by the Process Models. These data requirements and the associated business rules are discovered by examining the information requirements defined in the Process Models.

One of the most significant characteristics of the modeling process is this iterative and evolutionary nature. By definition, a model is a description of the real world expressed in a language or structure at a particular point in time. The modeling techniques recognize that each model is an approximation, a snapshot, or an abstraction of the real thing. As we learn more about the process modeled, either from further study or by merely applying the model to everyday business, we discover enhancements or corrections that need to be made.

A modeling procedure must be able to accept the inevitable iterations of its models, and be prepared to make changes as they occur. The approach anticipated the fallibility of the models and plans for the continual change that has always happened to organizations, their policies, and their information systems. The modeler anticipates this change rather than being caught off-guard by it.

2.2 USER-DRIVEN ANALYSIS

SME input was key to the success of both the Process and Data Models. Also, combat developers, materiel developers, and outside functional area SMEs helped with coordination efforts throughout the Intelligence Community, as well as DoD. The emphasis placed on SME input helped to create an accurate representation of IEW operations and its information requirements.

2.3 THREE-SCHEMA APPROACH

As the practice of Data Administration has evolved and more graphical techniques have evolved, the term "schema" has given way to the term "model". The conceptual model represents the view of data that is negotiated between end users and database administrators covering those entities about which it is important to keep data, the meaning of the data, and the relationships of the data to each other.

The ANSI group identified the requirement to formalize the conceptual model with a standard language and use it to actively manage data. Thus, a conceptual data model is a particular organized way of viewing or defining data, or simply a data structure with a specific scope and viewpoint.

Figure 2-1 Three-Schema Model

The objectives of the conceptual model are to:

1. Provide for the enterprise-wide logical integration of data, independent of the logical and physical storage structures, and independent of current and future applications or uses of the data.
2. Provide guidance and control for sharing of common data with flexible assess.
3. Provide guidance and control to ensure data integrity and quality, including consistency with business policies and procedures.
4. Provide for on-going extensions to formally defined and automated data.
5. Provide for identifying shared data, fixing acceptable meanings to these data, and assuring consistent interpretation throughout the enterprise.

In order to meet these objectives, the conceptual model must have the following characteristics:

1. It must be a single integrated view of the data which is consistent with the underlying rules of the business and must be true regardless of how the data is stored.
2. Once defined, the conceptual model only changes when the nature or rules of the business change.
3. It must be extendible without revising existing data definitions to allow for evolutionary development.
4. It must be mappable to multiple internal data models (physical database structures) to allow for the upgrading of computing technology and tuning of physical databases for efficiency.
5. It must be mappable to multiple external model views to allow for user flexibility and allow changes to the internal model without affecting user views of the data.

An external view or model has the following characteristics:

1. An external view is a subset of the conceptual data structured to provide specific information to a user.
2. Many different external views may exist for the same data.
3. External views change according to user information requirements.

An internal model has the following characteristics:

1. An internal model is a subset of the conceptual model structured for efficient and effective storage and retrieval of certain data.
2. The logical data structure (hierarchical, network, inverted, relational, etc.) for each physical database is defined as an internal model ( or schema).
3. An internal model is implemented with a specific data access and storage technology.
4. Internal models change according to data access and storage technology and according to how the data is physically distributed.

2.4 STRAP METHODOLOGY

Information Requirements Study		Strategic Planning
Information Requirements Study Implementation		Tactical Planning
Prototype Systems Implementation		Activity and Data Models
Prototype Systems Implementation		Physical Database Application Software

STEPS TO THE STRAP PROCESS

1. Overview.
2. Determine deliverable and schedule.
3. Identify participant roles.
4. Develop the Scope statement.
5. Develop the Process Node Tree outlining the process structure of the business area.
6. Identify SMEs who will participate in the development and validation of the Context and Decomposition Diagrams and the Data Model.
7. Develop Decomposition Diagrams and Context Diagrams by selecting the lower level activities from the Node Tree.
8. Develop higher level Decomposition Diagrams by integrating the lower level Context Diagrams.
9. Develop an entity pool from the ICOMs contained in the Context or Decomposition Diagrams.
10. Develop a Key-Based Data Model using the Entity-Relationship Data Model as a basis.
11. Validate the Key-Based Data Model by reviewing reports and validating the ICOMs supported in the Data Model.
12. Define activities, ICOMs, entities, and keys.
13. Prepare STRAP.

2.5 MODELING TECHNIQUES

The IDEF modeling techniques provide an effective means for:

1. Documenting the current ("AS-IS") and the planned ("TO-BE") environments.
2. Accomplishing interaction and consensus between user groups as part of system requirements definitions and subsequent development.
3. Achieving consistency, which facilitates data integration and sharing.
4. Providing documentation and audit trails during system conceptual design.

The IDEF modeling techniques are used to develop Process Models (known as IDEF0) and Data Models (known as IDEF1X). These models graphically and descriptively depict business processes and their basic data. The Process Models define and explain the business process, while the Data Models build the foundation of data needed to run the business.

Key Points of the IDEF modeling techniques:

1. IDEF is a structured development methodology that is standardized through a formal user’s group.
2. IDEF modeling techniques provide a picture of the business process and provide graphic documentation.
3. IDEF facilitates discussion and change.
4. IDEF permits evolution.
5. IDEF models business functions (activities) first.
6. IDEF identifies the information needed and its flow.
7. IDEF models the data needed to support the desired information.

2.6 TOOLS

1. Bpwin, Logic Works, Inc. - Used for the development of the Process Model.
2. ERwin/Erx, Logic Works, Inc. - Used for the development of the Data Model.

Previous Section

Next Section