idef3_kbsi_report (1013870), страница 25
Текст из файла (страница 25)
Additional fields included on theform include the following:1.Supports: The IDEF3 element numbers (e.g., UOB numbers, Object Statenumbers) supported by the source material are documented in this field,providing traceability for description elements to specific source material.2.Comments: This field is used to record special features or comments worthreferencing at a later date about the item being cataloged.3.Abstract: The abstract provides a concise overview of the main conceptsdiscussed in the source material.108Analyze Collected DataFollowing data collection, interview notes are analyzed, source material is studied andlogged in the Source Material Log, and the initial findings are cataloged into lists calledpools.
Four pools are used in IDEF3: (1) object pool, (2) scenario pool, (3) UOB pool,and (4) object state pool. Figure 4-4 shows an example of an object pool. All otherIDEF3 pools use the same basic layout as illustrated in Figure 4-4.10USED AT: ANALYST: I.M. ModelerX WORKINGDRAFTRECOMMENDEDRELEASEDDATE: 08 Feb 95PROJECT: Example IDEF3 DescriptionNOTES:1 2 3 4 5 6 7 8 9 10REV:ObjectID No.SourceMaterial No.NameREVIEWER:ObjectID No.NameDATE:SourceMaterial No.01Purchase RequisitionSM1018Bill of MaterialSM3802BuyerSM2019Route SheetSM4003VendorSM3020DestinationSM4104Purchase OrderSM15021ApproverSM4305Ship To LocationSM606RequesterSM1107DepartmentSM1208PatternSM2109PartSM26010Purchase Req.
ItemSM23011CommoditySM30012Purchase Req. ItemSM31013JobSM34014AccountSM36015ProductSM37016B.M. PageCONTEXT-SETTINGREFERENCE:SM38FORM TYPE:Object PoolITEM DESCRIBED:Figure 4-4Example IDEF3 Object PoolAcquire Additional Information as RequiredBoth analysis of the data collected and initial attempts to construct IDEF3 schematicsoften reveal the need for additional data. A number of approaches are available forcollecting additional information, including:10The field labeled “Object” on the form would be changed to Scenario, UOB, or Object State, asappropriate.
In addition, the ID No. fields would be prefaced by S (for Scenario), UOB, or OS (forObject State) to compose the element identification numbers.1091.Conducting follow-up interviews to answer questions and/or identify additionalsource material.2.Using the kit review process.3.Arranging for direct observation of the process or scenario in question.4.Revisiting source material with a new focus of analysis.5.Conducting facilitated workshops.The approach or combination of approaches used will be determined by both thenature of the information needed and the purpose for which IDEF3 is being used.Generally speaking, workshops are used only for group brainstorming and consensusbuilding, such as when developing ideas for and consensus among alternative “To-Be”process designs.Formulate IDEF3 SchematicsTwo types of IDEF3 schematics provide a mechanism for collecting and displayingprocess description information.
The Process Schematic provides a process-centeredview of a scenario. The Object Schematic provides an object-centered view of a scenarioor set of scenarios. Both constitute graphical projections of domain expert descriptions.A key point to remember in constructing IDEF3 schematics is that schematicdevelopment should not be constrained by idealized, testable conditions that must besatisfied, short of simple accuracy. For example, it is quite normal for ProcessSchematics to initially not show a logical flow. These schematics often start out with aset of UOB boxes with little connectivity among them.
This may be because thecomplete picture has not yet been acquired. Descriptions, after all, constitute a recordingof facts or beliefs about something within the realm of a domain expert’s knowledge orexperience. Such descriptions are generally incomplete; that is, the person giving adescription may omit facts that he or she does not think are relevant, which he or she hasforgotten in the course of describing the system, or of which he or she has noknowledge.11 Incredible as it may seem, there are many systems that work which haveelements that no single person understands or even knows about.11When domain experts know that some activity, object, or relation exists and they know what that is,they can easily display that knowledge using the IDEF3 schematic elements.
When domain expertsknow that one of these things does not exist, that fact is also easily captured. Specialized syntacticconventions may also be established to explicitly document a domain expert’s knowledge thatsomething exists of which they have no knowledge (i.e., Socratic versus Platonic information). For110The fact that a schematic includes elements that are disconnected should not causeoverwhelming concern.
It is not uncommon for the project to end successfully whilethere are still gaps in several of the schematics. This can happen when the goals of theproject do not require expenditure of the necessary effort to fill those gaps. Furthermore,when using IDEF3 to capture descriptions of the current environment, the IDEF3 users isnot designing a system but rather organizing known facts about how a system works. Theresulting descriptions may serve as the raw material from which models are made.
Thus,in addition to providing a precise and well-structured mechanism to capture and storeprocess knowledge, IDEF3 descriptions can be reused to construct multiple idealizationsor models with which to simulate and predict system behavior.Formulate Process SchematicsProcess Schematics provide a process-centered view of a process. These schematicsorganize process knowledge with a focus on processes and their temporal, causal, andlogical relations within the context of a scenario.The steps involved in constructing a Process Schematic are as follows.1.Identify the UOBs.2.Associate the UOBs with the appropriate scenario.3.Identify precedence constraints between pairs of UOBs in a scenario and layoutinitial schematic.4.Add junctions for logic description.5.Add constrained precedence links as required.6.Develop elaborations for UOBs, junctions, and links as needed.7.Develop decompositions for selected UOBs.8.Add relational links to highlight additional relationships of interest.example, a squiggly-lined arrow extending between UOBs might be used to indicate that someunknown collection of UOBs exist between those indicated.
A state represented in the shape of acloud might be used to indicate knowledge of the existence of a state, although what that state is maynot be known. When used, however, such conventions should only be used during intermediatestages of description development.111Identify the UOBsHaving completed initial data gathering activities, the analyst should have lists ofobjects of interest, activities, facts, and constraints. Using this data and the situationdescriptions, the analyst identifies the UOBs and begins to formulate the general structureof the IDEF3 schematics.The initial foundations for this activity occurred while establishing the context of theproject, wherein the analyst will have identified the scenario(s) of interest. At least oneProcess Schematic will typically be developed for each scenario identified.
The scenarioserving as the context for a given Process Schematic establishes the scope of the analyst’ssearch for candidate UOBs.Identifying UOBs is a mental classification activity that uses knowledge of the IDEF3paradigm and facts collected from the domain expert to identify and refine a candidate setof UOBs. It is helpful in this process for analysts to be attuned to how people describeprocesses. The capture of a description of “what’s going on” within an organization orany complex system needs to account for a number of natural language concepts. Each ofthe following concepts is used in everyday language to describe “things that happen in theworld.”1.Function4.Activity7.Action2.Process5.Operation8.Event3.Scenario6.Decision9.ProcedureEach of these concepts involves some circumscribed behavior.
For instance, areference to the Planning Activity, Make-or-Buy Decision, or the Contract Award Eventcarves up the world into spatio-temporal chunks to allow a description of “what is goingon” in that chunk to be separated from the rest of the world. In IDEF3, a generic packetof information (or UOB) encapsulates concepts such as those listed above.Lists of candidate scenarios developed in the project definition stage may be an earlysource for candidate UOBs. For example, by analyzing the initial set of candidatescenarios used to scope the project, analysts may question whether the scenarios may be“threaded together,” or subsumed by another candidate scenario listed.12The initial fact set is also a valuable source of candidate UOBs.
Identifying candidateUOBs may begin by searching for named processes (e.g., acquisition process), imperative12Some candidate scenarios listed may also be recognized simply as alternative names for the samesituation type.112verb forms (e.g., budget funds), and gerunds (e.g., identifying operational needs) in thedomain expert’s description. Through this analysis process, both additional scenarios andcandidate UOBs may be identified.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
