idef3_kbsi_report (1013870), страница 7
Текст из файла (страница 7)
Thisfeature of IDEF3 allows users to concentrate efforts on collecting observations and beliefsabout how business systems operate without having to concern themselves with the timeconsuming and decision-intensive creation of idealizations characteristic of modeling. Incontrast, methods that presume the intent to do modeling are designed to assist in thedevelopment of mathematical idealizations, or models, that predict what a system will dounder a predefined set of conditions.The distinction between descriptions and models, though subtle, is an important one.In the context of Integration Definition methods, these terms have a precise technicalmeaning.
The term description is used as a reserved technical term to mean records ofempirical observations; that is, descriptions record knowledge that originates in or isbased on observations or experience. The term model is used to mean an idealization ofan entity or state of affairs. That is, a model constitutes an idealized system of objects,properties, and relations that is designed to imitate, in certain relevant respects, thecharacter of a given real-world system. Frictionless planes, perfectly rigid bodies, theassumption of point mass, and so forth are representative examples of models.The power of a model comes from its ability to simplify the real-world system itrepresents and to predict certain facts about that system by virtue of corresponding factswithin the model.
Thus, a model is a designed system in its own right. Models areidealized systems known to be incorrect but assumed to be close enough to providereliable predictors for the predefined areas of interest within a domain. The true benefitof models stems from the speed and low cost with which relevant aspects of a real orproposed system can be evaluated. However, the usefulness of a model is limited to therange of questions addressed by its design and the reliability of its approximations indiffering contexts.A description, on the other hand, is a recording of facts or beliefs about somethingwithin the realm of an individual’s knowledge or experience.
Such descriptions aregenerally incomplete; that is, the person giving a description may omit facts that he or she4believes are irrelevant, or which were forgotten in the course of describing the system.Descriptions may also be inconsistent with respect to how others have observed situationswithin the domain. IDEF3 accommodates these possibilities by providing specificfeatures enabling the capture and organization of alternative descriptions of the samescenario or process (See Figure 1-1).
Modeling necessitates taking additional stepsbeyond description capture to resolve conflicting or inconsistent views. This, in turn,generally requires modelers to select or create a single viewpoint and introduce artificialmodeling approximations to fill in gaps where no direct knowledge or experience isavailable. Unlike models, descriptions are not constrained by idealized, testableconditions that must be satisfied, short of simple accuracy.Figure 1-2IDEF3 Captures Multiple Viewpoints of a ProcessThe purpose of description capture may be simply to record and communicate processknowledge or to identify inconsistencies in the way people understand how key processesactually operate.
By using a description capture method users need not learn and applyconventions forcing them to produce executable models (e.g., conventions ensuringaccuracy, internal consistency, logical coherence, non-redundancy, completeness).Forcing users to model requires them to adopt a model design perspective and riskproducing models that do not accurately capture their emperical knowledge of thedomain.5Description capture may also be undertaken to produce models.
Whetheraccomplished implicitly or explicitly, descriptions are the raw material from whichmodels are made. Thus, the utility of descriptions may also be realized through theirreuse in constructing multiple idealizations or models.Interestingly, models are a form of description. The reverse, however, is not true. Adescription is not a model. Models are exercised to create analysis data that is notavailable in descriptions. Unlike models, descriptions do not create analysis data; theymay, however, serve as one form of analysis data. For example, descriptions of busroutes and arrival times may be useful forms of data for developing a model of the publictransportation system but they do not themselves constitute that model. Similarly,descriptions of an automobile, while potentially useful for other purposes, cannot be usedto generate finite element analysis data.When compared to model building, description capture is attractive as a strategy forknowledge acquisition for several reasons.
First, practitioners generally require lesstraining to produce descriptions, rather than models, of their domains. Second, adescription of a given situation can easily be reused for a variety of purposes, includingmodel building (e.g., function models, simulation models). IDEF3 is a descriptionorganizing and capture method that directly addresses these needs.Workflow managementapplication developmentEngineering datamanagementFunction modeldevelopmentSimulation modeldesignFigure 1-3IDEF 3’s Focus on Description Capture Enables Maximized Reuse6ApplicabilityIDEF3 has been successfully applied in subject areas spanning all segments of theenterprise. IDEF3 has also been designed to be useful throughout the systemdevelopment and business evolution process, as illustrated in Figure 1-3.Document current processesIdentify and capturecritical processknowledgeAnalyzecurrent processesDesign new processesEvaluateand select amongalternativesDevelop a businesscasefor actionObtain approval for implementingchangePlan for and implement processchangeMaintain competitiveadvantagethrough continuousprocessimprovementFigure 1-4IDEF3Can Facilitate Business ImprovementBenefitsBenefits previously realized through the application of IDEF3 can be measured interms of cost savings, schedule gains, quality improvements, organic capabilityimprovements, and lasting changes to organizational culture.
IDEF3 has been used to:71.Identify obscure process links between organizations.2.Highlight redundant and/or non-value-added activities.3.Rapidly design new processes.Additional benefits gained through IDEF3 have been realized through its usefulnessas a mechanism to:1.Capture and distribute detailed manufacturing process knowledge(e.g., Hubble telescope mirror fabrication process) amonggeographically dispersed units.2.Determine the impact of an organization’s information resource onthe major operating scenarios of an enterprise.3.Provide an implementation-independent specification for humansystem interaction.4.Define data configuration management and change control policy.5.Document the decision procedures affecting the states and life cycleof critical shared data.6.Speed the development of high quality IDEFÆ function models.7.Speed the development and validation of simulation models.8.Develop real-time control software by providing a mechanism toclearly define facts, decision points, and job classifications.9.Define the behavior of workflow management systems andapplications.10.Prescribe the process by which change within an organization will beachieved.8Document OrganizationThis document is divided into the following eight sections:Section 1IntroductionSection 2IDEF3 OverviewSection 3IDEF3 Process Description LanguageSection 4Developing IDEF3 DescriptionsSection 5IDEF3 Development: Material Ordering Process ExampleSection 6Understanding IDEF3 Process DescriptionsAppendix AIDEF3 Elaboration LanguageAppendix BGlossary of TermsA brief method overview is presented in Section 2, including a description of thebasic building blocks used to develop IDEF3 Process Descriptions.
Section 3 presents adetailed discussion of the IDEF3 language and its semantics together with advancedconcepts for experienced users. Sections 4 and 6 offer practical guidelines forsystematically applying the method. A detailed example is described in Section 5.Appendix A describes the IDEF3 elaboration language and Appendix B defines theprincipal terminology of the IDEF3 method. The elaboration language is computerprocessable medium for reusing the information captured through IDEF3 application.The authors anticipate the use of this document for a wide variety of purposes.
Thus,the material is presented in a manner that allows readers to obtain information withouthaving to read the entire document. The following guidelines are suggested.1.For an executive overview, read Sections 1 and 2.2.To become proficient in the development of accurate IDEF3 ProcessFlow Descriptions, read the entire manual. Place special emphasison Sections 2, 3, 4, and 6.3.Experienced IDEF3 analysts can use Section 3 as a languagereference.4.To become proficient in reviewing IDEF3 Process Descriptions, readSection 6 in detail and browse Sections 2 and 3.95.An IDEF3 project leader should study Sections 3 and 4 in detail, butmust also have an understanding of the method in its entirety.SummaryIDEF3 is designed to assist those engaged in capturing and analyzing the vitalprocesses of an existing or proposed system.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
