IDEF0

A0 (A minus zero)

The A-0 diagram also sets the model scope or boundary and orientation. The A-0 context diagram also shall present brief statements specifying the model's viewpoint and purpose, which help to guide and constrain the creation of the model.

The viewpoint determines what can be "seen" within the model context, and from what perspective or "slant". Depending on the audience, different statements of viewpoint may be adopted that emphasize different aspects of the subject. Things that are important in one viewpoint may not even appear in a model presented from another viewpoint of the same subject.

The statement of purpose expresses the reason why the model is created and actually determines the structure of the model. The purpose establishes the intent of the model or the goal of communication that it serves. Purpose embodies the reason why the model is created (functional specification, implementation design, customer operations, etc.).

The single top box of an IDEF0 model represents the subject as a whole, the descriptive name in the box is general. The same is true of the external arrows of the model, since they represent the complete set of external boundary conditions of the subject as a whole, including access to mechanism support that supplies additional means of performance.

Naming of boxes is critical. Boxes are named using descriptive verb phrases.

ICOM

Input

Arrows entering the left side of the box are inputs. Inputs are transformed or consumed by the function to produce outputs.

Control

Arrows entering the box on the top are controls. Controls specify the conditions required for the function to produce correct outputs. Think of those items that are needed to insure/help (standards, guidelines) that when used leverage the production of correct output from a process.

Output

Arrows leaving a box on the right side are outputs. Outputs are the data or objects produced by the function.

Mechanism

Upward pointing arrows identify some of the means that support the execution of the function. Other means may be inherited from the parent box. Sometimes thought of as the resources needed.

Mechanism arrows that point downward are call arrows. Call arrows enable the sharing of detail between models (linking them together) or between portions of the same model.

Through the scheme defined for IDEF modeling you can establish a context/viewpoint/purpose for a variety of roles/activity centers in an organization. The call arrows defined under mechanism may provide an interesting strategy for linking different models.

The first process model I worked with was for designing web documents. I used the unit cell strategy offered by Humphrey (Managing the Software Process). My initial reaction to these was positive. I liked the way the various tasks became identified and how potential concurrent activities presented themselves. The unit cell approached looked as though it provided an opportunity to assign roles to team members and thereby allow progress on the project through clearly defined tasks to individuals or subgroups. An additional positive was the use of feedback from a given task to other tasks, thus providing a clear way to indicate and/or track interaction, potenital at least, between tasks.

The move to IDEF modeling for the same problem was not without rewards and problems.

Design/IDEF

Design/IDEF allows a model's pages to be saved in PICT format. The diagram above is an example of saving a page then converting to GIF. NOTE: There is a difference between saving the project and saving a page.