idef3_kbsi_report (1013870), страница 31
Текст из файла (страница 31)
Frequent assessments of progress towardsatisfying the purpose of the project promote early detection of high payoff opportunities,and limit the time and expense used in less fruitful activity. These discoveries oftenmotivate subtle or dramatic changes in scope. When the need for such changes arise, theclient should be notified and his or her approval should be sought. Analysts may alsorecognize the need to augment the use of IDEF3 with other methods.Using other IDEF Methods in Process Description CaptureIDEF3 was designed to work independently or in concert with other IDEF methods.Methods and techniques outside the IDEF family have been successfully applied withIDEF3 on a number of projects.14 In these cases, it is necessary to establish clear roles foreach method.
It is also important to clearly define the conventions that will be used inapplying each method. Selecting the appropriate set of methods for a given projectdepends on the nature and form of the available information and on the purpose of theproject. Each IDEF method is tailored for a unique set of information and cognitivesupport applications. For example, the IDEFØ Function Modeling and IDEF1Information Modeling methods are useful for analyzing complex situations.
The IDEF5Ontology Description Capture method provides additional expressive power fordescribing object structures and relations. The choice to apply more than one methodover the course of a project underscores the nature of methods as mechanisms designed tosupport predominantly narrowly-scoped tasks that may be applicable across a wide rangeof general and project-specific systems engineering frameworks.
These frameworks serveto establish a context for the required integration among the multiple tasks, andconsequently among the methods supporting those tasks.14See, for example, papers describing the use of IDEF3 in the Proceedings of the IDEF Users Group.144Using IDEFØ with IDEF3IDEFØ model and the UOBs in an IDEF3 Process Description, IDEF3 is notintended to be a replacement for IDEFØ. If the system being analyzed is very large (e.g.,Manufacture Aerospace Product), precedence relations may not be evident. In thesecases, it is often better to start with an IDEFØ model. Such a model can then bedecomposed to a level where the precedence relations among activities becomeprominent. On the other hand, if the facts collected can be organized into a cohesivestory, it is generally better to formulate the IDEF3 process description first, then abstractan IDEFØ model from that description.
The IDEF3 method was designed with thisinteraction in mind.The IDEF3 syntax recognizes this relationship by providing a means of referencingassociated IDEFØ activities from within the IDEF3 UOB. All UOB boxes have a field(see lower right of Figure 4-19) for providing a reference to an activity in an IDEFØmodel, or comparable function or process model (e.g., a node in a Logical Data FlowDiagram or HIPO chart).UOB LabelUOB #IDEFØ ActivityRef #Figure 4-19Unit of Behavior FieldsThe reference scheme in IDEF3 assumes that zero, one, or many IDEFØ activitieswill map onto a single UOB.
In cases where the UOB maps to only part of an IDEFØactivity, the activity referent should point to the set of child activities in the IDEFØ modelthat is actually involved. If the IDEFØ model is not defined to a low enough level ofdetail, the extent of the mapping should be described in the UOB elaboration. As UOBsare identified, IDEFØ references should be included.Using IDEF1 and IDEF1X with IDEF3In many large IDEF3 development projects, IDEF1 and/or IDEF1X models areavailable prior to the project initiation. These can help identify the objects for ObjectSchematics. The entity class number or attribute class (in IDEF1), or the entity number orattribute (in IDEF1X) that relates to each object or object state, should be referenced in145the glossary of the Object Schematic or the appropriate Object Schematic Descriptionform.While capturing process descriptions is generally straightforward, determining thebusiness rules that are supported by the information system is more difficult.
There areoften hidden pockets of information that constitute the “informal” information system ofthe enterprise. One of the primary roles of information modeling is to define the informaland formal information system. IDEF3 descriptions can be developed either before orafter the development of information models. When developed prior to informationmodeling, IDEF3 process descriptions can help users develop information models byfocusing domain expert attention on the information required to support their process.The resulting information models constitute a process-centered view of the informationrequirements of the enterprise.
Integrating a number of process-view information modelswill eventually yield a comprehensive information model that can be used to developenterprise-wide data standards.Using IDEF5 with IDEF3Because of the importance process kinds can have in the definition of a domainontology, IDEF5 permits one to refer to them as no less than object kinds. However,there are two distinct contexts in which such references can occur, and the informationthat is kept about a process kind will differ depending on the context. If a process kind Pis referred to in the description of a transformation or transition involving two kinds ofobjects, then the “internal” character of P is described in accordance with the IDEF3process description capture method.
That is, P is described in terms of the object kinds itinvolves, their properties, and the relevant relations that hold between instances of thosekinds when the process in question is instantiated. In particular, in such contexts, theusual sort of information kept about an object kind—its defining properties and soforth—is not kept about the process kind.On the other hand, it may be important for understanding a domain not only to knowhow objects are involved in the internal structure of a process, but also—as with objectkinds generally—how one kind of process relates logically to another kind of process,independent (in general) of the details of its internal structure.
For instance,manufacturing process planning is a subkind of planning. In these cases, processkinds are characterized using the procedure and language constructs provided within theIDEF5 ontology capture method.146IDEF3 DEVELOPMENT:MATERIAL ORDERING PROCESS EXAMPLEThe example description of a company’s purchase order process presented in thissection demonstrates the use of the IDEF3 method in a common setting. The exampleincludes some tips to help the user avoid common errors. Moreover, justifications forapplying a structured process to description development are documented as a guide tothe novice user.Define Purpose and ContextAssume that an owner of a business is interested in using IDEF3 to document thematerial ordering process to assist with new worker training and enforce companypurchasing standards.
Thus, he hires an analyst to develop an IDEF3 Process Descriptionfor the scenario Order Material. Assume that this project stems from the owner’s desireto record how purchase requests are processed for the benefit of new employees. Oneadvantage of applying IDEF3 in this situation will be that a new employee can quicklyunderstand how to acquire needed material by referring to the IDEF3 Process Description,without forcing the owner to spend time communicating this knowledge. In this example,the boundaries of the problem will be restricted to activities within the company.
Onlythe information needed to clearly specify the workings of the purchase order process to anew employee will be captured. This purpose and context would be entered on theIDEF3 Process Description summary form. At this stage of the description developmentprocess, the analyst would normally identify candidate scenarios and begin an IDEF3scenario pool. The contents of this pool will be refined and maintained throughout thelife of the project.In this example, only three IDEF3 project team roles are illustrated: (1) the analyst(the IDEF3 expert), (2) the domain expert (the business owner), and (3) the client (alsothe business owner).
The domain expert and the client are usually not the sameindividual. The remainder of this section will often refer to these individuals by theirproject role names.Collect DataHaving defined the project, the analyst prepares for and conduct data collectionactivities. One of the most valuable mechanisms for this data collection is the interview.For this example, we will focus primarily on this aspect of data collection.147Interview Domain Expert and Acquire Initial DescriptionRecognizing that well-planned and well-executed interviews are critical, the analystprepares carefully. When the scheduled interview time arrives, the analyst might beginby asking, “How does one go about purchasing material once the need has beenidentified?” Suppose the domain expert answers with the following description:“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.We like to develop long-term relationships with our suppliers.
That meanswe will always use a current supplier whenever possible. In return, weexpect their highest quality products on time and at reasonable prices.Right now, we have contracts or informal agreements with 7 trustedsuppliers. If we have no current supplier for the needed item, Purchasingrequests bids from potential suppliers and evaluates their bids to determinethe best value. Once a supplier is chosen, Purchasing orders the requestedmaterial.”During the interview, analysts often find it helpful to request to see copies of sourcematerial associated with the process. The analyst may also find it helpful to obtain copiesof relevant segments of policy and procedure manuals, previously developed models,purchase requests, supplier lists, solicitations, bid evaluation reports, purchase orders, andso forth. During the example interview, let us assume that the domain expert provides acopy of the purchase request form. The analyst notices three signature blocks at thebottom of the page—one titled “Requester,” another titled “Account Manager,” and athird titled “Purchase Authorization.” This leads to a new line of questioning which thedomain expert answers as follows.“To request material we must first prepare a purchase request.
Theinformation required on the purchase request form includes the itemdescription, the number of items needed, the required receipt date (ifapplicable), the number of the account that will fund the purchase, awritten justification for the stated need, and the requester’s printed nameand signature. The requester must then obtain the account manager’sapproval, or that of the designated backup, for the purchase. Accountmanagers, or their designated backups, are responsible for, and mustapprove, all purchases made against their project accounts.
After theaccount manager approves the purchase, an authorization signature may berequired. To avoid a potential conflict of interest, the person initiating thepurchase request cannot be the same individual as the one who approves orauthorizes the request. Once all the appropriate signatures have beenobtained, the requester submits the signed purchase request to Purchasing.148Purchasing then orders the requested material. The purchase request isthen tracked as an issued purchase order.”Note that the second description, although more detailed, omits any description ofhow the supplier is identified, although this information was deemed important enoughby the domain expert to include it in the first description. In practice, the completeness ofthe description provided by an interview will depend upon several factors:1.The amount of time the domain expert is willing (or allowed) todevote to the interview.2.The experience and domain-specific knowledge of the interviewer.3.The domain expert’s knowledge of the process being described.During the interview with the domain expert, the analyst will acquire the initialdescription that may include written documentation about the process.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
