idef3_kbsi_report (1013870), страница 6
Текст из файла (страница 6)
There are reasons for electing to expend theresources for developing each architectural representation. And, there arerisks associated with not developing any one of the architecturalrepresentations.The consistent, reliable creation of correct architectural representations requires theuse of a guiding method. These observations underscore the need for many “architecturalrepresentations,” and, correspondingly, many methods.Methods, and their associated architectural representations, focus on a limited setof system characteristics and ignore those that do not pertain to the task at hand.
Methodsare not intended to evaluate and represent every possible state or characteristic of thesystem under study. Hence, the search for a single method, or modeling language,supporting the specification, analysis, design, and representation of all relevant systemcharacteristics continues to frustrate those making the attempt. If such a goal wereachievable, the exercise would itself build the actual system, negating the benefits ofmethod application (e.g., problem simplification, low cost, rapid evaluation of anticipatedperformance, and so forth).On the other hand, lack of integration among special-purpose methods can beequally frustrating. The IDEF family of methods is intended to strike a balance betweenspecial-purpose methods, which are limited to specific problem types, and “supermethods” which attempt to include everything.
This balance is maintained by providingexplicit mechanisms for integrating the results of individual methods within the IDEFfamily.xiiPrevious research identified critical needs for new methods2 and led to a renewedeffort in IDEF method development, with a mandate for compatibility among the familyof IDEF methods. New method development has gone in directions where obvious voidsexisted (rather than reinventing existing methods) with the mission to forge integrationlinks among existing IDEF methods. When applied in a stand-alone fashion, IDEFmethods embody knowledge of good practice for the targeted activity. As with any goodmethod, the IDEF methods are designed to raise the performance level of novicepractitioners by focusing attention on important decisions while masking irrelevantinformation and unneeded complexity.
Viewed as a toolbox of complementary methodstechnology, the IDEF family is designed to promote the integration of effort in anenvironment where effective results have become increasingly dependent on effective useof enterprise information and knowledge assets.2Notably,the Knowledge-Based Integrated Information Systems Engineering Project was conducted atthe Massachusetts Institute of Technology (MIT) in 1987, where a collection of highly qualifiedexperts from academic and research organizations, government agencies, computer companies, andother corporations identified method and tool needs for large-scale, heterogeneous, distributedsystems integration.
See Defense Technical Information Center (DTIC) reports A195851 andA195857.xiiiINTRODUCTIONOne of the most common communication mechanisms to describe a situation orprocess is a story told as an ordered sequence of events or activities. For example, anengineer often describes the design process of his company by telling a story about aproduct that was recently developed.
Likewise, a shop floor supervisor may describe theoperation of his manufacturing system by describing the process of building a product inhis shop.The IDEF3 Process Description Capture Method was created specifically to capturedescriptions of sequences of activities. The primary goal of IDEF3 is to provide astructured method by which a domain expert can express knowledge about the operationof a particular system or organization. Knowledge acquisition is enabled by directcapture of assertions about real-world processes and events in a form that is most naturalfor capture.
This includes the capture of assertions about the objects that participate inthe process, assertions about supporting objects, and the precedence and causalityrelations between processes and events in the environment.IDEF3 supports this kind of knowledge acquisition by providing a reliable and wellstructured approach for process knowledge acquisition, and an expressively powerful, yeteasy-to-use, language for information capture and expression. These two dimensions ofIDEF3—the procedure embodying proven practices and an expressively powerfullanguage—work together to focus user attention on relevant aspects of a given processand provide the expressive power necessary to explicitly represent information about thenature and structure of that process.MotivationIn the most general sense, a process issimply an ordered sequence of events.
Inhuman-designed systems, the events that constitute a process are designed and ordered toachieve some desired outcome. A business process, in particular, is an ordered sequenceof events involving people, materials, energy, and equipment that is designed to achieve adefined business outcome [(Davenport & Short, 1993, 103), (Pall, 1987)]. Theimportance of business processes is self-evident. They not only define what the businessdoes, but more importantly, they determine how well the business does what it does.Several motivating factors led to the development of IDEF3. Some of the moreprominent motivations are described in the following sections.1Enhance the Productivity of Business Systems AnalysisOne major motivation behind IDEF3 development was the need to speed up theprocess of business systems modeling.
Business systems analysis often begins byacquiring an accurate description of the problem situation. Domain experts expressrecurring situations in terms of an ordered sequence of events or activities. Moreover,domain experts generally describe the specific ways in which activities and the objectsthat participate in them are related.
There is a need for both a method to facilitate thecapture of the dynamics of business activities and process descriptions, and for arepresentation medium to store and manipulate this captured knowledge. IDEF3 fulfillsthese requirements with a structured approach to communicate such process informationdescribed by domain experts.Facilitate Design Data Life-Cycle ManagementEarlier studies to identify method needs revealed the lack of methods to capturedescriptions of design-data life cycles (Mayer 1987). To describe the engineering designdata life cycle, it is necessary to describe: (1) design information artifacts (i.e., drawings,CAD models, etc.), (2) state transitions through which these artifacts proceed, and (3) thedecision logic or processes that determine the state transitions.
IDEF3 providesmechanisms to describe this data life cycle information.Support the Project Management ProcessProject management techniques are used to monitor and control projects in variousapplication domains. Several software tools support these project managementtechniques. However, many of these techniques are not expressively powerful enough tocapture many of the complexities that occur in project management situations. IDEF3provides mechanisms to capture the constraints (including resource and temporalrelationships) between the activities of a project. The IDEF3 language also representsdetailed information about the objects that participate in, are produced by, or are used bythe project activities. Furthermore, the activation of IDEF3 diagrams, which can besupported by an automated tool, will provide the means to monitor and control projectactivities in real-time.Facilitate the System Requirements Definition ProcessAnother motivation for the development of IDEF3 was the need to provide theconcepts, syntax, and procedures for building system requirements descriptions.
Thesedescriptions must be adequately detailed to determine whether a delivered system isacceptable. This requirement implies that the IDEF3 method must support descriptionsof the following items.21.Scenarios of organizational activities.2.Roles of user types in these organizational activities.3.User scenarios or user interaction with the information system at theuser-function level.4.System response to user functions.5.User classes and delineation of user classes.6.Declaration of timing, sequencing, and resource constraints.7.User interface objects (e.g., menus, keywords, screens, and displays).Support Coordinated Activity and Integration of EffortThe process view of business systems is critical to the business decision-makingprocess.
This view does need to be coordinated, however, with other views (e.g., thefunction, information, and organization views). Recognizing this need, the IDEF3method was designed explicitly to work well both independently and jointly with othermethods which address different areas of concentration (e.g., the IDEFØ FunctionModeling method) as a complementary addition to the IDEF method family.Design Features of IDEF3The needs expressed above levied special requirements on the IDEF3 team of methoddesigners. Given the need to provide an efficient process knowledge capture and displaymechanism, IDEF3 was designed to:1.Be easy to learn and use by individuals having little or no training instructured techniques while promoting consistent, reliable practice.2.Store, manage, and reuse process information for a variety ofdownstream uses.3.Provide an effective means for rapid, reliable, and cost-effectivemanagement of both individual and team-based applications.4.Enable users to readily recognize key differences between alternativeprocess architectures.35.Enable tailored application to small- and large-scale efforts, andcollect process information at both coarse- and fine-grained levels ofdetail.6.Function well across varying system domains (e.g., engineering,manufacturing, logistics, and business systems domains).7.Support integration of effort when applied with other IDEF methods.IDEF3 achieves these goals by focusing user activity on capturing descriptions of howa particular system operates, making it easier to use than traditional modeling methodsand enabling maximized downstream reuse of the collected process information.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
