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
Modeling is a structured, analytical method of studying and documenting business activities and the data needed to support their information needs. Modeling employs a language, or syntax, to record the things modeled, in a structured format, so that trained users can communicate with each other and the Information Systems Community.
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
Models are "user-driven" to depict a realistic picture of enterprise business processes and the data used to support the processes. Thus, the input of functional area SMEs is critical to the success of the effort.
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
The notion of a three-schema model consisting of a conceptual model, an external model, and an internal (or physical) model was first introduced by the ANSI/X3/SPARC Study Group on Database Management Systems (DBMS) in 1977 (See Figure 2-1). The ANSI/X3/SPARC Report characterized DBMSs as having a two schema organization. That is, DBMSs utilize an internal schema, which represents the structure of the data as viewed by the DBMS, and an external schema, which represents various structures of the data as vi
ewed by the end user. The concept of a third schema (conceptual) was introduced in the report. The conceptual schema represents the basic underlying structure of data as viewed by the enterprise as a whole.
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.
The objectives of the conceptual model are to:
In order to meet these objectives, the conceptual model must have the following characteristics:
An external view or model has the following characteristics:
An internal model has the following characteristics:
2.4 STRAP METHODOLOGY
The Structured Requirements Analysis Planning (STRAP) methodology was used to develop the Process Models and Data Models for this effort (See Figure 2-2). During the STRAP process the information requirements of a business (both process and data) are analyzed and documented. The STRAP methodology is used to facilitate the modeling process.
|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
2.5 MODELING TECHNIQUES
IDEF modeling techniques are being employed for this project. IDEF modeling techniques are government owned and were originally developed by the U.S. Air Force. IDEF use and successful implementation are widespread throughout government and private industry. IDEF has proven to be an effective tool to aid in information management and information requirement definitions.
The IDEF modeling techniques provide an effective means for:
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:
The following tools were utilized in support of the STRAP process: