idef3_kbsi_report (1013870), страница 8
Текст из файла (страница 8)
Guidelines and simple-to-use graphicallanguage structures aid users in successfully capturing and organizing processinformation for multiple downstream uses. IDEF3’s unique design includes the ability tocapture and structure descriptions of how a system works from multiple viewpoints,thereby enabling users to capture information conveyed by knowledgeable experts aboutthe behavior of a system rather than directing user activity toward constructingengineering models to approximate system behavior. This feature is among the centralcharacteristics distinguishing IDEF3 from alternative offerings. As an integral member ofthe IDEF family of methods, IDEF3 works well in independent application or in concertwith other IDEF methods to identify and develop the vital processes of a business.IDEF3 OVERVIEWThis section provides a broad overview and examples of the IDEF3 method.
Becauseany discussion of the organizing structures requires references to the basic IDEF3elements,3 these will be referred to but not fully defined until Section 3, “IDEF3 ProcessDescription Language.”Scenarios: The Organizing Structure for IDEF3 Process DescriptionsThe notion of a scenario or story is used as the basic organizing structure for IDEF3Process Descriptions. A scenario can be thought of as a recurring situation, a set ofsituations that describe a typical class of problems addressed by an organization orsystem, or the setting within which a process occurs. Scenarios establish the focus andboundary conditions of a description.
Using scenarios in this way exploits the tendencyof humans to describe what they know in terms of an ordered sequence of activitieswithin the context of a given scenario or situation. Scenarios also provide a convenientvehicle to organize collections of process-centered knowledge.3IDEF3 elements are the basic language constructs of IDEF3, including UOBs, junctions, links, objectstates, referents, and so forth.10Since the primary role of a scenario is to bind the context of an IDEF3 ProcessDescription, it is important to name it appropriately.
Scenario names often take the formof an imperative (e.g., verb or verb phrases like Issue Purchase Order, Test Fit, and soforth) and at times may take the form of a gerund (e.g., a verb that functions as a nounlike Performing Consistency Checks). A well-chosen scenario name will ensure that theusers of the description make the appropriate associations with the real-world situationsbeing described. Correctly identifying, characterizing, and naming scenarios is anecessary step to creating process-centered IDEF3 Process Descriptions.
The followingexamples are typical scenario names.1.Develop Die Design for Side Aperture Panel2.Processing a Customer Complaint3.Implement Engineering Change RequestAn IDEF3 Process Description is developed using two knowledge acquisitionstrategies: a process-centered strategy and an object-centered strategy. The processcentered strategy organizes process knowledge with a focus on processes and theirtemporal, causal, and logical relations within a scenario. The second dimensionorganizes process knowledge with its focus on objects and their state change behavior ina single scenario or across multiple scenarios.Using one or both of these process knowledge acquisition strategies, IDEF3 usersdevelop IDEF3 Process Descriptions.
Both strategies use the basic elements of theIDEF3 language to capture and express the assertions that form the description.Graphical projections of the information contained in process descriptions are createdusing IDEF3’s graphical language. These graphical projections—used to both recordprocess information directly and as a mechanism to display process information—arecalled schematics.Two types of IDEF3 schematics parallel the two process knowledge acquisitionstrategies. The IDEF3 Process Schematic displays a process-centered view of a scenario.Object Schematics support the graphical display of object-centered information. ObjectSchematics that display an object-centered view of a single scenario are called TransitionSchematics.
Transition Schematics that display additional objects and object relations toprovide context-setting information are called Enhanced Transition Schematics. ObjectSchematics that display object-centered information spanning multiple scenarios aresimply called Object Schematics.An IDEF3 Process Description may contain zero or more Process Schematics andzero or more Object Schematics. For example, recording that a particular object isrecognized by participants in a domain is considered part of the description of thatdomain.
An object so identified may or may not have an Object Schematic associated11with it in a description. Yet these objects are considered part of the description. Thescenario concept is used to organize both the process-centered and object-centered views.The collection of scenarios and the information they serve to organize is the IDEF3Process Description.The following two sections briefly introduce the description representation conceptsand syntax available in the two types of IDEF3 schematics.Process-Centered Views: The Process SchematicsIDEF3 Process Schematics are the primary means for capturing, managing, anddisplaying process-centered knowledge. These schematics provide a graphical mediumthat helps domain experts and analysts from different application areas communicateknowledgeabout processes. This includes knowledge about events and activities, theobjects that participate in those occurrences, and the constraining relations that govern thebehavior of an occurrence.A process-centered description is constructed systematically, using the basic buildingblocks of the IDEF3 schematic language, linked together in different ways.
Thesebuilding blocks have specific semantics associated with them. That is, they are used torepresent certain kinds of activities or relations in the real-world. A detailed specificationof these building blocks is given in Section 3. In this section, some of the importantbuilding blocks are introduced, along with an example illustrating how they are used todevelop IDEF3 Process Schematics.The example shown in Figure 2-1 depicts a Process Schematic of the scenarioentitled, Order Material.
In IDEF3, scenarios bound the context of descriptions and areconvenient artifacts for describing similar situations from different perspectives. In thisexample, the owner of a business used IDEF3 to document the material ordering processto assist with new worker training and to enforce company purchasing standards. Inparticular, the owner wanted to record how Purchase Requests are processed for thebenefit of new employees. When asked to describe the process, the business ownerrelated the following.“The first thing we do is request material using a Purchase Request form.Then the Purchasing department either identifies our current supplier forthe kind of material requested or sets out to identify potential suppliers.
Ifwe have no current supplier for the needed item, Purchasing requests bidsfrom potential suppliers and evaluates their bids to determine the bestvalue. Once a supplier is chosen, Purchasing orders the requestedmaterial. Those requesting material must first prepare a Purchase Request.The requester must then obtain the Account Manager’s approval, or that of12the designated backup, for the purchase.
Purchase Requests submitted forAccount Manager approval must include the Account Number for theProject that will fund the purchase. Account Managers, or their designatedbackup, are responsible for, and must approve, all purchases made againsttheir project accounts. After the Account Manager approves the purchase,an authorization signature may be required.
To avoid a potential conflictof interest, the requester cannot be the same individual who approves orauthorizes the request. Purchase Requests involving Direct projectsrequire an authorization signature whereas Indirect projects do not. Onceall the appropriate signatures are in place, the requester submits the signedPurchase Request to Purchasing.
Purchasing then orders the requestedmaterial. The Purchase Request is thereafter tracked as an issued PurchaseOrder.”13RequestmaterialRequestbidsEvaluatebids45XOrderrequestedmaterial6X1Identifycurrentsupplier3PreparePurchaseRequest1.1.7Obtain AccountManager'sapprovalXXSubmit signedPurchaseRequest1.1.101.1.8Obtainauthorizationsignature1.1.9Scenario Name: Order MaterialFigure 2-1Example of a Process Schematic14The processes in the owner’s description are represented in the schematic as labeledboxes numbered 1 through 10.
Each box represents distinguishable packets ofIdentifypotentialsuppliers2information about an event, decision, act, or process. That is, boxes represent types ofhappenings. Such happenings are referred to by the neutral term units of behavior(UOBs). Each UOB box represents a real-world process. The information recordedabout a UOB includes (1) a name (often verb-based) that indicates what the UOBrepresents, (2) the names of the objects that participate in the process and their properties,and (3) the relations that hold between the objects. The arrows (called links) connectingthe boxes in Figure 2-1 indicate the precedence relationships (or more generallyconstraints) that hold between the processes being described.
Thus, an instance of theUOB at the source of a link would complete before an instance of the UOB at the end ofthe same link starts. For example, the UOB labeled Request bids would complete beforethe start of the UOB Evaluate bids. The small box containing the “X” denotes a junction.A junction is a point in the process where a process splits into multiple paths, or wheremultiple paths merge. Junctions represent constraints (or the effects of constraints) of theactivation logic for the process.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
