idef3_kbsi_report (1013870), страница 22
Текст из файла (страница 22)
It contains a Note ID comprised of the referenced element numberand the Note number (e.g., J1/N1). The bottom section of the note box, called the notefield, is provided for the note itself. No formal structure is imposed on the contents ofthis field, although authoring conventions established for project-specific purposes arepermitted. For example, the note field may be structured to provide references to a set ofnotes associated with the referenced element, thereby permitting a restriction of no morethan one note for each schematic element.
Alternatively, the note field may be structured93to begin with some kind of note classification, thereby alerting readers to the main focusof the note.Representing Stochastic ProcessesMarkov chains and other types of stochastic processes are obvious candidates forrepresentation via object schematics with logical branches. Such processes consist of aset of states of a given system S together with, for any state A1, and for any other(possibly the same) state A2, the probability that S will transition from the former to thelatter. A system is a certain kind of complex object; hence, it is natural to represent thepossible transitions from A1 to any other state as a sort of exclusive disjunction as inFigure 3-86, where, in addition, real numbers representing probabilities have beenassigned to each transition link extending from the XOR junction.S:A2.2S:A1X.8S:A3Figure 3-86Transition Schematic Illustrating Possible Complex State Transition LogicThere is such a schematic for each state An.
Although this is illustrative in each case, it isclearly more efficient, and less cluttered, to represent the entire process—the entirecollection of probabilistic transitions from any state to any other—in terms of the morestandard graphical representation in which arcs extend directly between any two givenstates in both directions.94There is no reason why Transition Schematic syntax cannot be adapted to permit suchrepresentation as a convention, that is, as a sort of abbreviation for the collection of allTransition Schematics like the one in Figure 3-86. Use of IDEF3 transition links enablesone to augment such schematics with actual descriptions of the processes that effect thetransitions in question. The convention in question is illustrated in Figure 3-87;probabilities are suppressed to reduce clutter.S:A1S:A2S:A3Figure 3-87Transition Schematic Convention for Representing Stochastic ProcessesDEVELOPING IDEF3 DESCRIPTIONSThis section presents a procedure for using IDEF3 as a process description capture,consolidation, and validation method.
The procedure is targeted at the needs of a largeeffort involving a team approach; projects more narrow in scope may not require all ofthe activities described here. Because the application procedure depends largely on thepurpose for which the method is being used, project leaders are encouraged to prepare adetailed method application guide at the beginning of the project.The description development procedure is presented first in terms of the evolutionarycycle through which IDEF3 descriptions are realized and then in terms of a functionaldescription amenable to project phasing.95The IDEF3 Description Evolution CycleDeveloping IDEF3 descriptions involves the creation of Process Schematics, ObjectSchematics, and their associated elaborations.
The description capture and validationprocess is highly recursive and iterative. As with any recursive process, processtermination criteria are important—i.e., it is important to know when to stop. Although itis not possible to give precise criteria for the completion of description developmentactivities, some basic guidelines apply. First and foremost, description development isgenerally undertaken to accomplish some purpose.
That purpose may be simply todocument a process—in which case the development of schematics and elaborations is anend unto itself. In most cases, however, description development is undertaken to assistwith some discovery or decision-making activities. In these situations, the time and effortspent on description development will be determined by the information needs of theproject. Whether IDEF3 is used to document a process or to assist with discovery anddecision-making, descriptions approaching completion exhibit increasingly reduced ratesof change in terms of their structure, scope, and level of detail.The development of IDEF3 descriptions is a process of capturing knowledge abouthow activities are performed in a given organization.
In general, when using IDEF3 tocollect and organize these descriptions, the following five steps are applied recursively.1.Collect: Acquire observations and written descriptions of both processinstantiations and generalizations across process instantiations.2.Classify: Individuate situation types, objects, object types, object states, andrelations.3.Organize: Assemble the data that has been collected and classified usingIDEF3 structures.4.Validate: Ensure that the statements made in IDEF3 are grammatically correctand that they corroborate with the collected descriptions of the actual oridealized situation.5.Refine: Make adjustments to the existing structures to incorporate newlydiscovered information, to simplify the presentation, or to highlight importantelements of interest.Recursive application implies that the same development process continues until theinformation and knowledge available in the domain has been collected and organized intoa structure that satisfies the termination conditions of description development.96IDEF3 Description Capture ActivitiesExperience with IDEF3 indicates that description capture is similar to knowledgeacquisition and design endeavors.
It is highly iterative, driven by findings, and oftenstylized by the participants. The activities described in this section should be considered“modes of thought” rather than sequential steps. The user should not expect to applythese activities in a strictly sequential manner. With these ideas in mind, the frameworkpresented in this section provides a default structure for first-time IDEF3 users.Define the ProjectThe development team must establish the purpose and context of the descriptioncapture effort as early as possible in the project.
The purpose statement provides acompletion criteria for the description capture effort. The purpose is usually establishedby a list of (1) statements of objectives for the effort, (2) statements of needs that thedescription must satisfy, and (3) questions or findings the client wants answered.
Thecontext statement bounds or delimits the area of the domain addressed by the project.The context is established by scope statements and the identification of the initialscenarios for the description capture project.The purpose and context can rarely be determined completely in advance. The clientoften revises his list of needed findings or questions as data compilation begins.
The areaan analyst thinks will lead to the answer often turns up leads in other areas that wereconsidered out of scope. The purpose and context generally evolve during the initial partof the project. The purpose and context of an IDEF3 description are captured on anIDEF3 Description Summary Form similar to the one shown in Figure 4-1.97PROJECT LEADER:WORKINGDRAFTRECOMMENDEDRELEASEDDATE:COMPANY:PROJECT NO.:TASK NO.:REVIEWER:DATE:Purpose:Context:List of Scenarios:List of Objects:DESCRIPTION NAME:FORM TYPE:Description SummaryFigure 4-1IDEF3 Description Summary FormDefine the PurposeDefining the purpose is an important initial step in the development effort.
Without apurpose statement, the only completion criteria is the budget and time allocated to theeffort. Defining the purpose can be separated into two parts: (1) defining a NeedsStatement and (2) defining the information goals in terms of how that descriptiveinformation will be used.The Needs Statement should identify the source of the request (person or project) andparaphrase the stated objectives of the client. Identifying the information goals issimplified by answering the following questions:1.Who will use the description once it is available?2.What question(s) does the client need answered?3.What issues are behind the need for the process description?984.What decisions are behind the need for the process description?Establish the ContextOnce the purpose of the effort has been characterized, it is possible to define thecontext of the project in terms of the scope of coverage and level of detail.Defining the context of the project begins with defining the boundaries of thedescription capture effort and documenting those boundaries in a set of scope statements.Specifying project scope involves defining which parts of the system are to be includedand which are to be excluded.
Ideally, the scope should identify only those areas relevantto the needs of the client.An effective mechanism for defining the scope of the project is identifying theimportant scenarios of operation to be considered and those that, although related, falloutside the project boundaries. Identifying a scenario involves achieving a consensusamong the team members on a title and paragraph description of a commonly-occurringsituation or problem that the system (organization) addresses.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
