LCMA3

8/2/2019 LCMA3

1/32

APPENDIX 3

INTRODUCTION TO IDEF METHODOLOGY

USACE LCM Manager's Guide - Version 2.0 March 31, 1996

Appendix 3 Page A3-1

IDEF Methodology - The Department of Defense (DoD), including the Army and its major

Introduction

commands, has adopted the IDEF modeling technique for developing thelogical 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

8/2/2019 LCMA3

2/32

Appendix 3 - Introduction to IDEF Methodology



models will be derived, including a brief discussion of the Structured

Requirements Analysis Planning (STRAP) process.

IDEF0 Activity Activity modeling, sometimes called "process modeling," allows both

Modelingfunctional 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:

8/2/2019 LCMA3

3/32




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-WORK-

REQUESTS. (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 arrowsrepresent 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

8/2/2019 LCMA3

4/32




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 The activity previously illustrated in Figure 3-1 represents the simplest

Diagramsform 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

8/2/2019 LCMA3

5/32




ICOMS - Split Note the output ICOM of the activity PROCESS-WORK- REQUESTS in

and Bundledthe 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-WORK-

REQUEST, 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 - Each activity in an IDEF0 activity model is given an alphanumeric

Numbering

Activitiesidentifier. 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

8/2/2019 LCMA3

6/32




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 briefoverview 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 When reviewing models as part of a review board, two things should be

Reviewkept 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 otheractivities. The ICOMs and their definitions should sufficiently show

precedence and dependencies so that the reader can meaningfully follow

the sequence of events.

8/2/2019 LCMA3

7/32




IDEF Models - Whether building or reviewing models, AIS managers need to be aware of

Quality Issuesfeatures 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 isreally being performed (i.e., "noise") and such "inputs" are good

candidates for elimination.

8/2/2019 LCMA3

8/32




Above all else a good model must communicate. Anything that

promotes effective communication is good, anything that impedes

communication is bad.

IDEF0 Modeling There are a number of software packages available for use in capturing

Toolsand 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 Techniques for building IDEF1X data models are presented in this section

Modelingtogether 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.

8/2/2019 LCMA3

9/32




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 ahyphen 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

8/2/2019 LCMA3

10/32




(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 Between the two entities is a line with a dot at one end representing a

Relationships "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. Smithmight 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

8/2/2019 LCMA3

11/32




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."

8/2/2019 LCMA3

12/32




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 The model in Figure 3-4 shows several different types of "data elements,"

Modelswhich 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

8/2/2019 LCMA3

13/32




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 Data elements that are below the line, such as CUSTOMER-ADDRESS,

Elementsare 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 The key to the entity WORK-REQUEST is both CUSTOMER-NAME

Native Keysand 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 betweenthese 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,

8/2/2019 LCMA3

14/32




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 - The highest level of refinement of a logical data model is one that has

Fully Attributed been fully attributed, i.e., it includes all of the data elements pertinent to

the business process(es) being considered for automation.

Data Model - The last important component to understanding a data model lies in the

Glossaryglossary 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 3-

5. The actual data resident in the encyclopedia is shown in bold type.

8/2/2019 LCMA3

15/32




Figure 3-5. Representative Data Definitions

8/2/2019 LCMA3

16/32




Data Modeling - The above paragraphs provide a brief overview of the IDEF1X data model

Facilitationsyntax. 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 A data model should be read by both functional and technicalValidation

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

8/2/2019 LCMA3

17/32




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 - Some important considerations concerning the quality of a data model are:

Quality Issues

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.

8/2/2019 LCMA3

18/32




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 Considerations

1. Select Team 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.

2. Plan Kick-off planning includes definition of schedule, deliverables, scope training, objectives, and

STRAP kick- critical success factors. Identify members of STRAP review board. FP should chair the review

off board and be present at kick-off.

3. Arrange This includes trainers, facilitators, modeling technicians, and clerical staff. May be Corps

STRAP employees or contractors or a mixture of the two. Proven capability is critical here, especially for

support staff the lead facilitator. Tailor IDEF training to the needs of the STRAP.

4. Arrange for Facilities include a room large enough to accommodate core team, support staff, and one or twoFacilities and SME. Equip room with white boards. printing whiteboards, if available, are a very desirable

Equipment 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.

5. Conduct Arrange to bring together Core Team, Review Board, and subject matter experts. The key is to

kick-off 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.

8/2/2019 LCMA3

19/32




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 kick-

off 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 After the kick-off meeting, the team begins detailing the original IDEF0

Modelsmodels 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

8/2/2019 LCMA3

20/32




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 AIS-

specific 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.

8/2/2019 LCMA3

21/32




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 bestfunctional 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.

8/2/2019 LCMA3

22/32




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 theofficial project file.

8/2/2019 LCMA3

23/32




Modeling and To support the modeling of business/functional processes, DoD has

Related Toolsestablished 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 - The following key reference is relevant to this appendix:

Appendix 3 Designing Quality Databases with IDEF1X Information Models by

Thomas A. Bruce, Dorset-House Publishing, 1991, ISBN, 0-

932633-18-8.

8/2/2019 LCMA3

24/32




THIS PAGE INTENTIONALLY LEFT BLANK

8/2/2019 LCMA3

25/32




ATTACHMENT 1

DoD LOANER TOOL LIBRARY

8/2/2019 LCMA3

26/32




THIS PAGE INTENTIONALLY LEFT BLANK

8/2/2019 LCMA3

27/32




Loaner Tool To support DoD Functional Process Improvement (FPI) efforts, DoD

Libraryestablished 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.

8/2/2019 LCMA3

28/32




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 VENDOR FUNCTION

EasyABC ABC Technologies Activity Based Costing

Modeler Alpha Tech Simulation

Simprocess CACI Simulation

COSMO Coe-Truman Activity/Data Models/ABC

Authormate Eclectic Solutions Activity Models

AI0win Knowledge Based Systems Activity Models

SmartER Knowledge Based Systems Data Models

PROsim Knowledge Based Systems Process Models Simulation

ERwin/ERX Logic Works Data Models

ERwin/DBF Logic Works Data Models

ERwin/BPwin Logic Works Activity Models

DesignIDEF Meta Software Activity & Data Models (ABC)

AblePM Triune Software Activity Models

IDEFine Wizdom Systems Activity & Data Models

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

8/2/2019 LCMA3

29/32




Vendor Below is a list of Vendors (alphabetical) with products that support IDEF0

Informationand 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 (503) 626-4895

Mitchell Systems Corporation (703) 351-6700

ADAPT

Alpha Tech (617) 273-3388

AT&T ISTEL Witness (216) 292-2688 ext 318

Interfaces with KBSI tools

CACI (703) 875-2900

Coe-Truman (703) 836-2671

Eclectic Solutions (619) 454-5781

KBSI (409) 260-5274

Logic Works (800) 783- 7946

Meta Software (617) 576-6920

Technology Economics, Inc. (301) 984-1334

Texas Instruments (703) 849-1464

Triune Software (513) 427-9900

Systems Modeling Corporation (412) 741-3727

Wizdom Systems (703) 548-7900

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

8/2/2019 LCMA3

30/32




UNCLASSIFIED FACSIMILE PAGE

DEFENSE INFORMATION SYSTEMS AGENCY

REQUEST FOR A LOANER TOOL

FROM: TO: BETTY ROE

OFFICE: OFFICE: DISA JIEO/CIM/TXF

FAX PHONE: FAX PHONE: 703-681-2863

PHONE: PHONE: 703-681-2421

NO. OF PAGES (incl header) NO. OF PAGES (incl header)

DATE: 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

8/2/2019 LCMA3

31/32




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

8/2/2019 LCMA3

32/32


STRAP IPR A3-22

STRAP Process A3-18STRAP Wrap-Up A3-21

Vendor Information A3-29

LCMA3

Documents