idef3_kbsi_report (1013870), страница 5
Текст из файла (страница 5)
168Figure 5-15 Transition Schematic for Path where Authorization is Required............................................ 169Figure 5-16 Combined Transition Schematic Combining Figures 5-14 and 5-15...................................... 170Figure 5-17 Complete Schematic Before First Review..............................................................................
172Figure 5-18 Elaboration for Object State PR: Prepared........................................................................... 173Figure 5-19 Elaboration for Object State PR: Approved requiring authorization.................................... 174Figure 5-20 Elaboration for Object State PR: Authorized ........................................................................
175Figure 5-21 Completed Transition Schematic............................................................................................ 176Figure 5-22 Final Object Schematic........................................................................................................... 178Figure 6-1 Example IDEF3 Process Schematic .........................................................................................
182Figure 6-2 Example Partitioning of Figure 6-1 .......................................................................................... 182Figure 6-3 Analyzing the Groupings.......................................................................................................... 183Figure 6-4 Example IDEF3 Object State Transition Schematic.................................................................
184Figure 6-5 Example Partitioning of Figure 6-4 .......................................................................................... 185Figure 6-6 Analyzing the Groupings..........................................................................................................
186Figure A-1 Paint/Review/Dry Scenario...................................................................................................... 208viiiPREFACEThis document provides a method overview, practice and use description, andlanguage reference for the IDEF3 Process Description Capture Method developed underthe Information Integration for Concurrent Engineering (IICE) project, F33615-90-C0012, funded by Armstrong Laboratory, Logistics Research Division, Wright-PattersonAir Force Base, Ohio 45433, under the technical direction of United States Air ForceCaptain JoAnn Sartor and Mr. James McManus.
The prime contractor for IICE isKnowledge Based Systems, Inc. (KBSI), College Station, Texas. Dr. Paula S. deWittewas the IICE Project Manager at KBSI. Dr. Richard J. Mayer was the PrincipalInvestigator on this project. Mr. Thomas Blinn was the IICE Technical Manager and alsoserved as the Project Manager during the close out of this effort. Michael K. Painter wasthe Methods Engineering thrust manager. The authors gratefully acknowledge thetechnical contributions of the following people.Bruce E. CarawayThomas P. Cullinane, Ph.D.John W. Crump, IVFlorence FillionMike Graul, Ph.D.Richard HendersonArthur Keen, Ph.D.William K.
KnappenbergerMadhavi LingineniM. Sue WellsKBSI also acknowledges the technical input to this document made by previous workunder the Integrated Information Systems Evolutionary Environment (IISEE) projectsponsored by the Armstrong Laboratory Logistics Research Division and performed bythe Knowledge-Based Systems Laboratory, Department of Industrial Engineering, TexasA&M University.ixFOREWORDSignificant technological, economic, and strategic benefits can be attained through theeffective capture, control, and management of information and knowledge resources.Like manpower, materials, and machines, information and knowledge assets arerecognized as vital resources that can be leveraged to achieve a competitive advantage.The Air Force Information Integration for Concurrent Engineering (IICE) program,sponsored by the Armstrong Laboratory’s Logistic Research Division, was established aspart of a commitment to further the development of technologies that will enable full useof these resources.The IICE program was chartered with developing the theoretical foundations,methods, and tools to successfully evolve toward an information-integrated enterprise.These technologies are designed to leverage information and knowledge resources as thekey enablers for high quality systems that achieve better performance in terms of lifecycle cost and efficiency.
The methods research described in this report reflects recentadvancements in technology for leveraging available information and knowledge assets.The name IDEF originates from the Air Force program for Integrated ComputerAided Manufacturing (ICAM) which developed the first ICAM Definition, or IDEF,methods. Continued development of IDEF technology supports an overall strategy toprovide a family of mutually-supportive methods for enterprise integration.. Morerecently, with the expanded focus and use of IDEF methods as part of ConcurrentEngineering, Total Quality Management (TQM), and business re-engineering initiatives,the IDEF acronym has been re-cast as an integrated family of Integration Definitionmethods.
Before discussing the development strategy for providing an integrated familyof IDEF methods, the components and general nature of methods are described.Method AnatomyA method is an organized, single-purpose discipline or practice (Coleman, 1989).A method may have a formal theoretical foundation, although this is not a requirement.Generally, methods evolve as a distillation of the best-practice experience in a particulardomain of activity. The term tool is used to refer to a software system that supports theapplication of a method.Though a method may be thought of informally as a procedure for doingsomething plus (perhaps) a representational notation, it may be described more formallyas consisting of three components (Figure 1).
Each method has (1) a definition, (2) adiscipline, and (3) a use component. The definition specifies the basic intuitions andxmotivations behind the method, the concepts involved, and the theory of its operation.The discipline component includes the syntax of the method and the procedure forapplying the method. The method procedure gives the practitioner a reliable process forconsistently achieving good results. The method syntax eliminates ambiguity whendeveloping complex engineering products.
Many system analysis and engineeringmethods use a graphical syntax to provide visualization of collected data so that keyinformation can be easily extracted.1 The use component characterizes how tosuccessfully apply the method in different situations.In theSystemEvolutionProcessProcedureLexiconDiscipGraphicalSyntaxIn anIntegratedSuite ofMethodseUsComputerinterpretableSyntaxStand-alonelineDataAssimilationFormulationValidationMethodIndependentof SystemDevelopmentGrammarDefinitionTheoryConceptsInformalFormalSemanticsFormalLanguageMotivationFigure 1-1Anatomy of a Method1Graphical facilities provided by a method language serve not only to document the analysis or designprocess undertaken, but more importantly, to highlight important decisions or relationships that mustbe considered during method application.
The uniformities to which an expert, through experience,has become attuned are thus formally encoded in visualizations that emulate expert sensitivities.xiUltimately, methods are designed to facilitate a scientific approach to problemsolving. This goal is accomplished by first creating an understanding of the importantobjects, relations, and constraints that must be discovered, considered, or determined.Second, scientific problem solving occurs by guiding the method practitioner through adisciplined approach that is consistent with good-practice experience and leads towardthe desired result.
Formal methods, then, are specifically designed to raise theperformance level (quality and productivity) of the novice practitioner to a levelcomparable to that of an expert (Mayer, 1987).Family of MethodsJohn Zachman, in his pioneering work on information systems architecture,observed:[T]here is not an architecture, but a set of architectural representations.One is not right and another wrong. The architectures are different. Theyare additive, complementary.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
