idef3_kbsi_report (1013870), страница 13
Текст из файла (страница 13)
This constraint rules out the activationscharacterized by the middle plot (in which the instance of B occurs after E completes).Some Concrete ExamplesThe following examples give further illustrations of the constructs discussed in thepreceding section. Figure 3-24 depicts a scenario in which the receipt of a proposal isfollowed by cost and technical evaluations. The evaluations must be completed prior tocontract award. Because the junctions are asynchronous, no constraints are placed on therelative timing of the initiation and completion of the evaluations. They must simplyfollow the receipt of the proposal and precede the contract award.EvaluateCostProposalReceiveProposal12&&EvaluateTechnicalProposalAwardContract43Figure 3-24Asynchronous AND Junction ExampleContrast this with the scenario displayed in Figure 3-25 in which the synchronousAND describes a situation in which the cost and the technical evaluation must startsimultaneously, but may end separately.
If there had been an organizational rule that39required both to end together as well, Figure 3-25 would in addition have used asynchronous fan-in AND junction to describe the intended process.EvaluateCostProposal2ReceiveProposal&AwardContract&14EvaluateTechnicalProposal3Figure 3-25Synchronous AND Junction ExampleFigure 3-26 shows a description of the Select Contractor scenario. This processdescription states that, following evaluation, one either rejects the proposal, or elseaccepts the proposal for core contract work, accepts the proposal for options to thecontract, or both, before awarding the contract.RejectProposalEvaluateProposal2AcceptProposal forCore Contract3X1OOAcceptProposal forOptions4AwardContract5Figure 3-26Asynchronous OR Junction ExampleIn the scenario depicted in Figure 3-26, Reject Proposal is a terminating activity;however, either of the other two activities (or both) will result in contract award.
Notethat a relational link indicates some relationship between the Accept Proposal for CoreContract and Accept Proposal for Options UOBs. Note also that this description is stillpartial in that it does not indicate what happens when the negotiations do not succeed.For example, in most situations, the contract award depends upon contractor acceptanceof the terms of the funding agency, which may require the contractor to resubmit theproposal as a part of the negotiation process. Such information can be easily represented40in IDEF3 as additions to the current schematic or a decomposition of Award Contract.Note that there is nothing about the schematic that requires that the contract be awarded.The contract award would be forced only if a constrained precedence link (in the “left toright” direction) had been used to connect the fan-in OR junction with the AwardContract UOB.Not all combinations of junctions represent genuine process logics.
In particular, anXOR fan-out junction may not be followed by a fan-in AND junction in the fashionillustrated in Figure 3-27, since this would represent an inconsistent process, one thatcould not possibly be activated.EvaluateCostProposalReceiveProposal12X&EvaluateTechnicalProposalAwardContract43Figure 3-27Invalid XOR/AND Structure ExampleIn Figure 3-27, after the Receive Proposal UOB, an XOR junction leads to twoUOBs. This indicates that only one UOB—either Evaluate Cost Proposal or EvaluateTechnical Proposal— will be realized on any given activation of the schematic.Consequently, the Award Contract UOB could never be realized because the requirementthat both UOBs preceding the AND junction be realized in the same activation can neverbe met. Note that such schematics may nonetheless be useful, as the AS-IS process beingcaptured may involve an undetected inconsistency.
In the situation characterized inFigure 3-27, perhaps contracts were never awarded; thus, the IDEF3 schematic identifiedan organizational problem and enabled conflict resolution. This type of structure is nevercorrect in a TO-BE description of some proposed system, organization structure, orprocess. In either case, however, the description validation process should identifystructures of this type as IDEF3 schematic errors.UOB DecompositionsElaborations capture and structure detailed knowledge about processes.
If the UOBrepresented by a box in a given schematic is highly complex, it may be useful todecompose the UOB explicitly into its component UOBs. The way this is represented inIDEF3 is that the original box is correlated with another IDEF3 schematic which41represents an “exploded” description of the UOB, providing a further level of descriptivedetail about the UOB. This schematic is known as the decomposition of the originalUOB box. Decompositions allow the user to capture descriptions at varying levels ofabstraction.
Decompositions enable users to apply the “divide and conquer” principle—apowerful mechanism for managing complexity. By applying this principle repeatedly, itis possible to structure a process description to any level of detail. Decomposition alsoprovides the ability to model the same process from different knowledge sources ordifferent points of view. This is possible because IDEF3 allows the same UOB to have anumber of different decompositions, or “views.” This capability is also useful in domainsituations where a given process involves multiple functional organizations.As noted, a UOB decomposition is just another IDEF3 process schematic. In Figure3-28, the use of decompositions is illustrated by an example from the domain of contractsmanagement. The decomposed UOB box 3, which refers to the UOB Receive andActivate Contract, is called the parent UOB box.
Where there is no danger of ambiguity(i.e., where no other box refers to the same UOB), the indicated UOB can also be calledthe parent UOB. Each decomposition of the parent box is a child decomposition. Eachchild decomposition is given a label and a unique number identifying it as one ofpotentially several decompositions of the parent UOB.
The UOB boxes in adecomposition may have subsequent decompositions. (As seen in the figure,decompositions demand a special reference numbering scheme that is explained in thenext section. For the moment, note that the rightmost digits in each UOB box is the UOBnumber. Moving to the left, the other two numbers in the UOB box provide additionalinformation to the reader of an IDEF3 schematic.)42Receive andActivateContract3OrganizeTeam&3.1.7ReceiveContract3.1.6&ActivatePlan3.1.11Set UpSubcontracts3.1.8&ConstructPlanHold Kickoff Meeting3.1.103.1.9Figure 3-28Decomposition 3.1 of the UOB Receive and Activate ContractMultiple view decompositions may be consolidated into an objective view.
The viewpresented in Figure 3-29 is an example of an objective view of the UOB Hold Kick-offMeeting. This is the view perceived by a neutral observer of the Kick-off Meetingprocess. However, the project manager of the contract will have a different perspective ofthis process; therefore, IDEF3 enables him to express his viewpoint via an alternativedecomposition of the UOB. The project manager’s decomposition of the UOB HoldKick-off Meeting is shown in Figure 3-30.43Hold Kick-offMeeting3.1.10ReviewProposal10.1.16&ReviewSOW&10.1.17Decide onFinal PlanDetermineAssignmentsCloseMeeting10.1.1910.1.2010.1.21ReviewDraft Plan10.1.18Figure 3-29Decomposition 10.1 of Hold Kick-off Meeting UOBHoldKick-offMeeting3.1.10CallMeetingto OrderNegotiatePositionsCloseMeetingEnsureContractSatisfaction10.2.1210.2.1310.2.1410.2.15Figure 3-30The Project Manger’s View DecompositionUOB Reference Numbering SchemeA UOB box number is assigned to each UOB box in an IDEF3 Process Description.In general, however, a single IDEF3 description can be extremely complex, containingmany UOB boxes, many of which can have multiple decompositions.
In such schematics,the simple assignment of numbers to boxes, though sufficient for uniquely identifyingeach box, may not provide enough information. In particular, a single UOB box numberconveys no contextual information about that UOB, i.e., information about where it fits inthe overall process description. To provide this information, a more robust numbering44system may be used in IDEF3 schematics. These more informative designators areknown as reference numbers. Specifically, at the top level in a hierarchy ofdecompositions, a box’s UOB number and its reference number are identical. At lowerlevels of a decomposition, the reference number of a UOB box B consists of three distinctnumerals separated by periods.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
