APPENDIX 3 INTRODUCTION TO IDEF METHODOLOGY

IDEF Methodology Introduction

The Department of Defense (DoD), including the Army and its major commands, has adopted the IDEF modeling technique for developing the logical models which describe functional processes and information flows. IDEF, which stands for Integrated Computer-Aided Manufacturing DEFinition, is a structured and proven methodology widely used throughout industry and government. "Modeling" has replaced traditional "systems analysis" as a preferred technique for discovering and documenting customer requirements. Modeling is faster, less cumbersome, and less subject to miscommunication. The initial phases in the life cycle management of an information system (e.g., development of a Mission Need Statement (MNS), Operational Concept Description (OCD), etc.) depend extensively on the Functional Proponent's ability to capture a detail description of the "AS-IS" and "TO-BE" worlds. As project sophistication and scope increase, the more critical it is that a modeling effort be supported through a groupware facility. Groupware can considerably reduce staff time required for the modeling process.

IDEF modeling, whether full scale or in an abbreviated version, provides both the methodology and vocabulary for accurately analyzing specific business processes, process improvements, information requirements, and system deficiencies.

IDEF models are graphical and textual representations of activities, and the data needed to support those activities. IDEF0 is the technique used for modeling activities, and IDEF1X is the technique used for modeling data. The explanations in this appendix will aid in reading and understanding the graphic diagrams of activity and data models. In addition, this appendix describes the analytical process from which IDEF

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-1

Appendix 3 - Introduction to IDEF Methodology

models will be derived, including a brief discussion of the Structured Requirements Analysis Planning (STRAP) process.

IDEF0 Activity Modeling

Activity modeling, sometimes called "process modeling," allows both functional experts (personnel responsible for executing the business on a daily basis) and IM technical staff (information engineers, computer programmers, database administrators, etc.) to communicate with each other and to effectively capture the activities involved in day-to-day business operations.

The activity models described in this section are called IDEF0 activity models. To understand activity models, it is necessary to understand the symbols used to represent the activities and the functions that define those activities. The diagram in Figure 3-1 is an example of a simple IDEF activity model:

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-2

Appendix 3 - Introduction to IDEF Methodology

Figure 3-1. Basic IDEF Activity Model

In the above activity model, the central box represents an activity. An activity is a process that occurs within the scope of this area of the business. The activity shown in the model is SCHEDULE-WORKREQUESTS. (Note that the activity name begins with a verb; all activities in an IDEF0 activity model begin with a verb.)

ICOMS

As shown in Figure 3-1, arrows enter and exit the box. These arrows represent products or resources which define the activity. IDEF0 activity models utilize four different types of functions. "Inputs," which are consumed or transformed by the activity, enter the activity box from the left side. "Controls," which constrain or control when or how the

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-3

Appendix 3 - Introduction to IDEF Methodology

activity is accomplished, enter the activity box from the top. "Outputs," or the products of the activity, exit from the right, and "Mechanisms," the people or tools used to execute the activity, enter from the bottom.

The arrows in an activity model are known collectively as "ICOMs," an acronym derived by taking the first letter of each function. All ICOMs are given a label, which helps to describe the function. A glossary defining each ICOM and each activity also accompanies the model diagrams. Activity names and ICOM labels should be unique throughout the model.

Context Diagrams

The activity previously illustrated in Figure 3-1 represents the simplest form of an activity model called a "context diagram." Only a single activity is shown in a context diagram. Multiple activities are shown in a "decomposition diagram." A decomposition diagram represents all the subactivities of a larger activity. (It is in this manner that the larger activity is said to be "decomposed.") The following example in Figure 3-2 represents a decomposition diagram.

Figure 3-2. Sample Decomposition Diagram

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-4

Appendix 3 - Introduction to IDEF Methodology

ICOMS - Split and Bundled

Note the output ICOM of the activity PROCESS-WORK- REQUESTS in the decomposition model in Figure 3-2. This ICOM splits into two separate ICOMs, one labeled INAPPROPRIATE-WORK-REQUEST, which goes straight to the border, and one labeled VALID-WORKREQUEST, which becomes an input into the next activity, SCHEDULE-WORK-REQUESTS. This is known as a split ICOM. The branches of a split ICOM must be labeled if they represent only a portion of the entire item, as they do below, but need not be labeled if they are identical to the originating ICOM. ICOMs can also be grouped, or "bundled," together. The same naming conventions that apply to split ICOMs also apply to bundled ICOMs.

IDEF0 Numbering Activities

Each activity in an IDEF0 activity model is given an alphanumeric identifier. This identifier can be found in the bottom right-hand corner of the activity box. In Figure 3-2, "A2.1" appears in the corner of the first activity, and "A2.2" appears in the second activity. The "A" stands for activity, and the number is of sequential significance to other activity models within this business area. This can be illustrated by remembering that activities may be decomposed into their component subactivities. These subactivities are distinguished from one another by an increasing string of decimal identifiers. For example, activity A3 would consist of subactivities A3.1, A3.2, A3.3, etc. Activity A3.2, in turn, may consist of subactivities A3.2.1, A3.2.2, etc. The highest level activity is called A0.

Sometimes it is desirable to reduce clutter on a diagram by suppressing an ICOM at a level where it is not of particular importance. This is shown by adding brackets [ ] to either the head or tail of the ICOM arrow. Brackets next to the activity box signify that the ICOM will not be seen on

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-5

Appendix 3 - Introduction to IDEF Methodology

the next level decomposition of that activity. Brackets next to the border end of an ICOM signify that the ICOM is not shown on the parent diagram.

The preceding text provided a brief overview of the IDEF0 activity modeling syntax needed to read or help build an IDEF0 model. If participation as a team member on a modeling project is required, additional training and practice will be necessary and should be provided. In addition, an experienced modeler usually acts as a facilitator on modeling projects, assisting team members in using the methodology. However, the information provided in this appendix can serve as preparation for taking part in model reviews.

IDEF0 - Model Review

When reviewing models as part of a review board, two things should be kept in mind. First, not all activities, as modeled, apply to every specific case in the business area. The IDEF0 models are comprehensive, taking into account all possibilities. When applying the model to a specific case, nonapplicable activities and arrows should simply be ignored. Secondly, the activities in decomposition diagrams are not necessarily in chronological order when read from left to right. Due to the iterative and repetitive nature of most business activities, one activity might occur before another in a certain situation, but won't in a different situation. Each activity should, however, depict the interdependence among other activities. The ICOMs and their definitions should sufficiently show precedence and dependencies so that the reader can meaningfully follow the sequence of events.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-6

Appendix 3 - Introduction to IDEF Methodology

IDEF Models Quality Issues

Whether building or reviewing models, AIS managers need to be aware of features that represent good modeling technique. Some of these features are:

The number of parent activities in a single decomposition model should range between 3 and 6. Less than three suggests that the decomposition may not be needed. More than six will tend to make the model too busy for clear communication.

Each subactivity in the decomposition of a parent activity, should be of approximately equal importance. Don't mix trivial activities with complex ones.

Verbs in activity names should decompose by changing from the general to the specific during the decomposition process. This means that the same verb should not appear in the parent and child activities of a good decomposition model.

Activities in the same decomposition diagram should have some interconnection of ICOMs. If not, the model may be decomposing an organization rather than a business activity.

Inputs need to undergo some transformation by the activity. If they don't, maybe they are actually controls or mechanisms or no activity is really being performed (i.e., "noise") and such "inputs" are good candidates for elimination.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-7

Appendix 3 - Introduction to IDEF Methodology

Above all else a good model must communicate. Anything that promotes effective communication is good, anything that impedes communication is bad.

IDEF0 Modeling Tools

There are a number of software packages available for use in capturing and diagraming IDEF0 models. Most of these packages run on Personal Computers (PCs), SUN workstations, or equivalent devices. The USACE Data Encyclopedia incorporates the capability to store captured IDEF0 models. The PM should consult the IM technical staff for specific recommendations of the most suitable tool for a specific AIS project.

IDEF1X - Data Modeling

Techniques for building IDEF1X data models are presented in this section together with an explanation of why modeling is important and how to understand a data model. Modeling data allows both functional experts (people who perform the activities on a daily basis) and IM technical staff (information engineers, computer programmers, database administrators, etc.) to communicate with each other and to talk on a "neutral" level. It allows a business to capture and store data once and only once, and to operate under a consistent set of internal rules. Robust internal rules, in turn, ensure availability of a wealth of useable data to support Corps missions.

Modeling data also allows for meaningful insight into the impact of major AIS modernization projects on Corps data resources. Finally, modeling the data allows discrete business areas the ability to integrate into a larger, corporate-wide view of the data.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-8

Appendix 3 - Introduction to IDEF Methodology

The data model examples in this section are called IDEF1X data models. To understand a data model, it is necessary to understand the symbols used to represent characteristics and rules of data in a business. The diagram in Figure 3-3 is an example of a simple IDEF data model:

Figure 3-3. Basic Data Model

In the data model shown in Figure 3-3, the boxes represent "entities." An entity is a set of real-world objects with common characteristics about which data is kept. The two entities shown in the model are CUSTOMER and WORK-REQUEST. (Note that it is a generally accepted convention that entity names are written in all capital letters, and in a multiword entity name such as "WORK-REQUEST," each word is separated by a hyphen rather than a space.) Since an entity is a set of real-world objects, this requires more than one occurrence of each entity. Each occurrence of an entity is called an "instance" of the entity. For example, John E. Smith

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-9

Appendix 3 - Introduction to IDEF Methodology

(with certain appropriate characteristics) might represent one instance of a CUSTOMER. Mary Jones would be another instance.

Entity Rules

There are four rules that determine an acceptable entity for a business data model:

The entity must be a noun (person, place, thing, concept or event).

There must be multiple instances of the entity.

Each instance of an entity must be uniquely identifiable.

The entity must be of interest to the business area being modeled.

Entity Relationships

Between the two entities is a line with a dot at one end representing a "relationship." The relationship name, in this case "submits," should help to define and restrict the link or connection between the two entities. (Note that multiword relationship names are also separated by hyphens rather than spaces, but are written in lower case letters.)

Cardinality

The dot at the end of the line represents the "cardinality" of the relationship. The cardinality depicts the number of instances of one entity per instance of the other. For example, CUSTOMER John E. Smith might submit many WORK-REQUESTs: one on Tuesday, one on Thursday, and a third on Friday. Mary Jones, on the other hand, may submit only one WORK-REQUEST. A third customer might not submit any. The cardinality between CUSTOMER and WORK-REQUEST

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-10

Appendix 3 - Introduction to IDEF Methodology

depicted in the example data model allows for all three of the above situations to occur. That is, an instance (or occurrence) of CUSTOMER may submit either zero, one, or multiple instances of a WORK-REQUEST. In this manner, a simple black dot represents a cardinality of "zero, one, or many" instances.

Other cardinalities, some of which are fairly complicated, can also be depicted. For example, a black dot with a "P" next to it represents a cardinality of "one or more." (The "P" stands for "positive.") A black dot with a "Z" next to it represents a cardinality of "zero or one." It is important to remember that when determining the cardinality between two entities, assume "X" occurrences of the dotted-end entity per one instance of the other entity.

Business Rules

It is in this manner that two entities can be related to each other, and an internal rule (also known as a business rule) is developed. For example, the business rule statement derived from the example data model above is:

"Every CUSTOMER submits zero, one, or many WORK-REQUESTs."

The business rule can also be read in reverse in this manner:

Every WORK-REQUEST must be submitted by one and only one CUSTOMER."

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-11

Appendix 3 - Introduction to IDEF Methodology

Given the relationship, the cardinality and the resultant business rule, the entity CUSTOMER is said to be a "parent" of WORK-REQUEST, and WORK-REQUEST, in turn, is a "child" of CUSTOMER. More about this later.

The data model example shown in Figure 3-3 represents the simplest and first form of a data model. It is called an Entity - Relationship (E-R) model because it depicts only entities and their relationships to each other. Building E-R models is a critical step in defining the requirements and relationships in a relational database.

The following example in Figure 3-4 is needed to illustrate a more detailed data model which is called a Key-Based (K-B) model:

Figure 3-4. Key-Based Model

Key-Based Models

The model in Figure 3-4 shows several different types of "data elements," which are sometimes referred to an "attributes" or "data items." Data elements are common characteristics of an entity. In the example above, the entity CUSTOMER has a common characteristic (data element) called

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-12

Appendix 3 - Introduction to IDEF Methodology

CUSTOMER-NAME. CUSTOMER-ADDRESS is another data element of the entity CUSTOMER. Naming conventions must be established for these data elements.

In a key-based data model, an entity is drawn as a box with a horizontal line through it. The data element(s) listed above the horizontal line denote the "primary key" of an entity. The primary key, also known as simply the "key," is said to be the minimum data element(s) needed to uniquely identify one instance of an entity from another. In Figure 3-4, the name of the CUSTOMER identifies one instance from another and is, therefore, a "key data element."

Non-Key Data Elements

Data elements that are below the line, such as CUSTOMER-ADDRESS, are called "non-key data elements." Non-key data elements are useful characteristics of the data entity, but are not needed to uniquely identify one CUSTOMER from another. As stated above, naming conventions must also be established for non-key data elements.

Foreign and Native Keys

The key to the entity WORK-REQUEST is both CUSTOMER-NAME and CUSTOMER-REQUEST-DATE. In order to uniquely identify one WORK-REQUEST from another, the model indicates that both data elements are needed. There is, however, an important difference between these two data elements. CUSTOMER-NAME is said to be a "foreign key" of WORK-REQUEST. It has "migrated" from the parent entity, CUSTOMER, to the child entity, WORK-REQUEST. A foreign key is denoted with an "(FK)" after the name of the data element. Conversely,

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-13

Appendix 3 - Introduction to IDEF Methodology

CUSTOMER-REQUEST- DATE is said to be a "native" data element to the WORK-REQUEST entity. Entities with only native keys are said to be independent. Entities that depend on another entity to supply one or more identifying keys, are said to be dependent. Independent entities [boxes] have square corners; dependent entities [boxes] have rounded corners.

Data Model Fully Attributed

The highest level of refinement of a logical data model is one that has been fully attributed, i.e., it includes all of the data elements pertinent to the business process(es) being considered for automation.

Data Model Glossary

The last important component to understanding a data model lies in the glossary that accompanies such a diagram. Complete definitions for all entities and data elements can be found in the glossary. An example of data definitions, extracted from the USACE Data Encyclopedia, is provided in the screen prints (initial and continuation) shown in Figure 35. The actual data resident in the encyclopedia is shown in bold type.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-14

Appendix 3 - Introduction to IDEF Methodology

Figure 3-5. Representative Data Definitions

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-15

Appendix 3 - Introduction to IDEF Methodology

Data Modeling Facilitation

The above paragraphs provide a brief overview of the IDEF1X data model syntax. If familiar with this material, the reader will be able to participate in validation of an IDEF1X data model. If the reader is a member of a modeling team, additional training is normally provided, along with the services of an experienced modeler to act as a facilitator for the project. While the technique may appear to be intuitive, the critical uses to which the models are put (development of the DBMS specific data definition language (DDL), guidance to programmers and maintainers, etc.) demand "professional" facilitation. "Professional" facilitation can be supplied by experienced Corps personnel or by contractor support. Facilitation by an experienced modeler can significantly accelerate the modeling process, but care must be exercised in the management of the modeling group's dynamics to insure that the facilitator does not dominate the modeling process.

Data Model Validation

A data model should be read by both functional and technical components of an organization to validate the contents therein. The functional reviewers of a model bring to the analysis their day-to-day practical expertise in the business area from the viewpoint of a regular user of the data modeled. The technical reviewer, knowledgeable in the details of storage, manipulation, and management of the data involved, brings to the analysis expertise in the area of systems design and computer operations.

To validate a data model, team members should ask questions that seek to either contradict or reinforce the diagram. For example, using Figure 3-4, one could ask if a single WORK-REQUEST can be submitted by more

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-16

Appendix 3 - Introduction to IDEF Methodology

than one CUSTOMER. If so, then the model depicted is unable to incorporate this business rule; it is incorrect, or at least inadequate. Another example might be: Can a single CUSTOMER submit more than one WORK-REQUEST in a single day? If this is a valid possibility, then the keys used to uniquely identify WORK-REQUEST are inadequate and an alternative key should be considered.

Data Models Quality Issues

Some important considerations concerning the quality of a data model are:

The model must reflect the correct viewpoint for the purpose intended. If the viewpoint is not correct, data and rules excluded from the model will prevent proper automation of their associated work processes.

Relationships should be as specific as possible. Verbs like "is" and "has" should be avoided. For example don't say "a purchase request generates one or more purchase orders" if you really mean "a purchase request satisfies the need to purchase goods and services via one or more purchase orders".

Follow the rule same name - same meaning throughout the data model. Do not use words ambiguously. No duplicate names or relationships are allowed.

Avoid non-specific relationships such as "many to many". If one employee can belong to many committees and one committee can be staffed by many employees, it is impossible to associate a specific employee with a specific committee.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-17

Appendix 3 - Introduction to IDEF Methodology

Identify all alternate keys and aliases.

Make sure all key data elements can not have a null value.

Make sure that each entity is identified by the key, the whole key and nothing but the key.

STRAP Process

The Structured Requirements Analysis Planning (STRAP) process is the forum for detailing functional and information requirements using the IDEF0 activity and IDEF1X data models. The complexity of the business process and the impact of the project across organizational levels will determine the depth of the STRAP process. The following table presents considerations for the Project Manager (PM) in preparing for the STRAP.

Task 1. Select Team

Considerations Team includes core members and subject matter experts (SME). Core members should provide broad knowledge of subject under study. Team leader must have leadership skills needed to keep work on schedule and produce high quality deliverables. Normally the Core Team leader is the PM. Kick-off planning includes definition of schedule, deliverables, scope training, objectives, and critical success factors. Identify members of STRAP review board. FP should chair the review board and be present at kick-off. This includes trainers, facilitators, modeling technicians, and clerical staff. May be Corps employees or contractors or a mixture of the two. Proven capability is critical here, especially for the lead facilitator. Tailor IDEF training to the needs of the STRAP. Facilities include a room large enough to accommodate core team, support staff, and one or two SME. Equip room with white boards. printing whiteboards, if available, are a very desirable option. Equipment includes two PCs with capability of accessing USACE Data Encyclopedia, one printer, and software for word processing and financial analyses. The more sophisticated STRAPs should plan to use a groupware facility and software to expedite the modeling process. Arrange to bring together Core Team, Review Board, and subject matter experts. The key is to develop a shared and documented understanding of the scope and objectives, critical success factors, schedule, deliverables and level of commitment for all members of this STRAP effort.

2. Plan STRAP kickoff 3. Arrange STRAP support staff 4. Arrange for Facilities and Equipment

5. Conduct kick-off

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-18

Appendix 3 - Introduction to IDEF Methodology

Table 3-1. Considerations for STRAP Preparation The STRAP kick-off establishes expectations for the STRAP. It defines the who, what, when, how and where for the STRAP. The Review Board, Core Team and Subject Matter Experts (SME) come together for the first time. It is important to select a room with ample size and facilities for the meeting. The kick-off meeting will last from one to four hours, depending on the complexity of the project. The PM conducts the kickoff meeting. One of the first tasks is to develop a project scope statement during the meeting. Second, the team needs to identify the team's objectives and critical success factors. Third, the team should set schedules and define deliverables for the project.

Introductory training in IDEF is desirable either as part of the kick-off, or immediately following the kick-off. However, don't go overboard on training! Team and Review Board members are not going to become professional IDEF modelers. Training is to prepare them to work with a professional modeler (the facilitator) to build and understand models. Excessive training is a turn-off and a waste of resources.

AS-IS and TO-BE Models

After the kick-off meeting, the team begins detailing the original IDEF0 models of present business process. These are called "AS-IS Activity Models." The team should identify as many improvement opportunities as possible during this modeling effort. These improvement opportunities, after validation and prioritization by the Review Board, are the changes used to define the "TO-BE" activity models. Improvement opportunities do not have to include automation, since the goal is to define better ways

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-19

Appendix 3 - Introduction to IDEF Methodology

to do business. For a detailed discussion of the AS-IS IDEF0 modeling activity, see the beginning of this appendix.

After modeling the AS-IS work processes, continue detailing the original IDEF1X data models. As a part of building the IDEF1X data models, search the USACE Data Encyclopedia to determine whether the team is creating new data elements or merely discovering the need to use existing data elements. The Command or local Data Administrator can also serve as a guide to review the Command Data Models to see where the AISspecific project data models intersect with command data. A high or medium degree of data intersection means that other corporate information systems may meet the specific AIS information requirements.

The derived data models identify data entities (a.k.a. data classes) and their attributes (a.k.a. data elements). The models also capture current business rules (relationships and cardinality) controlling performance of work processes. Management should place all models under configuration control.

At the conclusion of the AS-IS modeling activity, the team needs to conduct a review of the work accomplished. The Review Board confirms the validity of the modeled work processes and improvement opportunities. The board also prioritizes improvement opportunities for incorporation in the TO-BE models.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-20

Appendix 3 - Introduction to IDEF Methodology

Implicit in the TO-BE modeling, is the need to decide on specific approaches to automation . These decisions require consideration of both costs and benefits. Build TO-BE activity and data models to reflect high priority improvements and cost efficiencies selected by the review board. In building these models, be sure to consider available alternatives. Modification of existing resources is a real alternative to complete new development. Before starting the modeling effort, survey and evaluate existing or "under construction" AIS capabilities. Activity and data models from other AIS will describe processes, entities, and business rules that may have applicability to the current modeling effort. At the conclusion of the TO-BE activity and data modelling effort, it is important to begin thinking about, discussing, and documenting what might be the best functional and technical approaches to satisfy work process improvements and the program strategy (i.e., Grand Design, Incremental, Evolutionary, or Other) for an AIS project. Functional and technical approaches will influence Acquisition Strategy/Planning, and Program Strategy will affect all activities in the LCMIS phases.

STRAP Wrap-Up

To complete the TO-BE modeling process, enter models, definitions and data characteristics into the USACE Data Encyclopedia. Data administration of the logical data model for the new AIS is required. Make sure that the System Developer (SD) is coordinating with the appropriate Corps Data Administrators. The team needs to follow established procedures for the handling of unique organization data. Compliance with data management and adminstration requirements is an exit criterion for each phase Milestone Review. The PM needs to ensure the SD does not circumvent these requirements. The data administration staff at each level of the Corps are potential partners for an AIS program - use them.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-21

Appendix 3 - Introduction to IDEF Methodology

STRAP IPR

The final effort of the STRAP is the final In-Process Review (IPR). In this review, the FP and the Review Board validate the TO-BE models and analyses supporting those models. The AIS PM should prepare for the final IPR by completing all documentation requirements for models and analyses. In addition, the PM should ensure that data adminstration requirements are under control. Finally, the PM should prepare a brief outline of the proposed implementation plan for the AIS.

The PM should schedule the final IPR with the FP and Review Board, with the full STRAP team in attendance at the IPR. The PM should also invite representatives of organizations who have worked with the team during the STRAP. The objectives of the final IPR are:

Validation of alternative analysis.

Validation of TO-BE models.

Concurrence on outline of important documents such as the Operational Concept Description (OCD) and System Decision Paper (SDP)/Abbreviated System Decision Paper (ASDP).

After the review, the PM needs to update all documentation to reflect final decisions of the FP and Review Board. A copy of the final documentation should be sent to each member of the STRAP Core Team and to the official project file.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-22

Appendix 3 - Introduction to IDEF Methodology

Modeling and Related Tools

To support the modeling of business/functional processes, DoD has established a Loaner Tool Library of software for use in preparing activity/data models and associated cost/economic analysis requirements. A omplete description of the library resources is provided in Attachment 1 to this appendix.

Key References Appendix 3

The following key reference is relevant to this appendix: Designing Quality Databases with IDEF1X Information Models by Thomas A. Bruce, Dorset-House Publishing, 1991, ISBN, 0932633-18-8.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-23

Appendix 3 - Introduction to IDEF Methodology

THIS PAGE INTENTIONALLY LEFT BLANK

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-24

Appendix 3 - Introduction to IDEF Methodology

ATTACHMENT 1 DoD LOANER TOOL LIBRARY

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-25

Appendix 3 - Introduction to IDEF Methodology

THIS PAGE INTENTIONALLY LEFT BLANK

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-26

Appendix 3 - Introduction to IDEF Methodology

Loaner Tool Library

To support DoD Functional Process Improvement (FPI) efforts, DoD established a Loaner Tool Library in 1992. The library, operated by the DoD Center for FPI Expertise (CFFE), contains software that enables an organization to prepare function or activity models, data models, perform activity based costing, simulation, and functional economic analysis. The information in this attachment was provided by the DoD Business Process Reengineering (BPR) Lab on June 14, 1995.

These tools are intended to assist users in fast start projects and to enable organizations to have temporary use of a tool while expedient purchase of a tool takes place.

There are rules in place for using the tools, as follows:

Individuals requesting the tool must complete the request form (see attached form), sign it, and return it to the CFFE.

The individual requesting the tool must sign the Loaner Tool receipt upon receiving the tool and return the form to the CFFE. Anyone leaving an organization after signing the request form will still be held responsible for the tool. Special arrangements must be made with the CFFE to turn the tool over to another person.

The tool must be kept in the same condition as when received and all parts of the package must be returned to the CFFE at the end of the loan period.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-27

Appendix 3 - Introduction to IDEF Methodology

Any tool damaged or lost is the responsibility of the borrowing organization.

The software must be removed from computer before returning the package.

Tools available from the library are (alphabetical by vendor):

TOOL EasyABC Modeler Simprocess COSMO Authormate AI0win SmartER PROsim ERwin/ERX ERwin/DBF ERwin/BPwin DesignIDEF AblePM IDEFine

VENDOR ABC Technologies Alpha Tech CACI Coe-Truman Eclectic Solutions Knowledge Based Systems Knowledge Based Systems Knowledge Based Systems Logic Works Logic Works Logic Works Meta Software Triune Software Wizdom Systems

FUNCTION Activity Based Costing Simulation Simulation Activity/Data Models/ABC Activity Models Activity Models Data Models Process Models Simulation Data Models Data Models Activity Models Activity & Data Models (ABC) Activity Models Activity & Data Models

Point of Contact is Betty Roe at DISA/JIEO/CSW/TXF, (703) 681-2421.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-28

Appendix 3 - Introduction to IDEF Methodology

Vendor Information

Below is a list of Vendors (alphabetical) with products that support IDEF0 and 1X, Activity Based Costing, and Simulation. This list includes vendors who do not presently have software in the DoD Loaner Library, although access to their tool(s) may be possible when visiting the Center for FPI Expertise:

ABC Technologies Mitchell Systems Corporation ADAPT Alpha Tech AT&T ISTEL Witness Interfaces with KBSI tools CACI Coe-Truman Eclectic Solutions KBSI Logic Works Meta Software Technology Economics, Inc. Texas Instruments Triune Software Systems Modeling Corporation Wizdom Systems

(503) 626-4895 (703) 351-6700 (617) 273-3388 (216) 292-2688 ext 318 (703) 875-2900 (703) 836-2671 (619) 454-5781 (409) 260-5274 (800) 783- 7946 (617) 576-6920 (301) 984-1334 (703) 849-1464 (513) 427-9900 (412) 741-3727 (703) 548-7900

For further information call 1-800-TELL-CIM.

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-29

Appendix 3 - Introduction to IDEF Methodology

UNCLASSIFIED FACSIMILE PAGE DEFENSE INFORMATION SYSTEMS AGENCY REQUEST FOR A LOANER TOOL
FROM: OFFICE: FAX PHONE: PHONE: NO. OF PAGES (incl header) DATE: TO: BETTY ROE OFFICE: DISA JIEO/CIM/TXF FAX PHONE: 703-681-2863 PHONE: 703-681-2421 NO. OF PAGES (incl header) DATE:

The information below must be completed by a Government person responsible for the loaner tool package. For information or assistance please call Betty Roe at 703-681-2421. NAME: ORGANIZATION (spell out): COMPLETE MAILING ADDRESS:

TELEPHONE: DATE OF CALL: METHOD REQUESTED: IDEF0 IDEF1X ABC SIMULATION FEA MODEL NAME OF TOOL: FUNCTION AREA (Information Management, Material Resources, Finance, Health, Human Resources, etc.): NAME OF BUSINESS PROCESS REENGINEERING PROJECT:

LIST OF PROJECT OBJECTIVES:

Loaner tools are loaned to DoD Agencies involved in an BPR/FPI project(s). An Agency may only have one tool at a time. Period of loan is for 30, 60, or 90 days. The borrowing organization is responsible for damaged or lost tool packages. You must remove the software from computer IAW licensing agreements before return. All original documentation, software diskettes, and other parts of the package must be returned in working order.

Signature UNCLASSIFIED FACSIMILE PAGE

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-30

Appendix 3 - Introduction to IDEF Methodology

Appendix 3 - Topic Index AS-IS and TO-BE Models A3-20 Business Rules A3-11 Cardinality A3-10 Context Diagrams A3-4 Data Model - Fully Attributed A3-14 Data Model - Glossary A3-14 Data Model Validation A3-16 Data Modeling - Facilitation A3-16 Data Models - Quality Issues A3-17 Entity Relationships A3-10 Entity Rules A3-10 Foreign and Native Keys A3-13 ICOMS A3-3 ICOMS - Split and Bundled A3-5 IDEF Methodology - Introduction A3-1 IDEF Models - Quality Issues A3-7 IDEF0 - Model Review A3-6 IDEF0 - Numbering Activities A3-5 IDEF0 Activity Modeling A3-2 IDEF0 Modeling Tools A3-8 IDEF1X - Data Modeling A3-8 Key References - Appendix 3 A3-23 Key-Based Models A3-13 Loaner Tool Library A3-27 Modeling and Related Tools A3-23 Non-Key Data Elements A3-13

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-31

Appendix 3 - Introduction to IDEF Methodology

STRAP IPR A3-22 STRAP Process A3-18 STRAP Wrap-Up A3-21 Vendor Information A3-29

USACE LCM Manager's Guide - Version 2.0 Appendix 3

March 31, 1996 Page A3-32