Business Process Implementation for IT Professionals phần 9 doc

10. Demonstrate action prototype to stakeholders. Arrange a session with the stakeholders to observe the operation of the initial or revised prototype and determine the conformity of the prototype operation to the needs of the business and the individual stakeholders. At the end of this step, the stakeholders must determine if the action definitions, functionality, and relative sequences meet the needs of the business process being implemented. That involves comparison of the animation of the process steps with the animation of the actions. Because the functionality and other specifications of both the process steps and actions are available, this comparison certainly is possible, although somewhat subjective at this point. If the two are not compatible, the actions or process steps must be reexamined to determine the cause. Assuming that the comparison produces an agreement between the two, the larger question, which is the same for all prototype uses, must be addressed: Given a feeling for the process implementation that the action prototype provides, do the associated process steps really meet the underlying business need? As the prototypes become more sophisticated and closer to the final product, that question becomes easier to answer. However, it is desirable to get an answer at the earliest possible time to reduce rework and save development time. Even at this early stage, some feelings for the implementation can be obtained and the question at least asked, if not answered. If and when the answer to the question is “No,” the process spiral must be reinitiated and the difficulties resolved before continuing. 11. Obtain necessary approvals. If approvals are needed to continue beyond step 3, they need to be obtained before proceeding. The action prototype, the opinions of the stakeholders, and the hard deliverables from this step (action templates, prototype animation results) should be sufficient to demonstrate the suitability of the action definitions and the ability to proceed. 12. Enter new or updated action specifications into the repository. All information obtained as a result of step 3 should be entered into a repository where it is available for future needs. Because maintenance is considered an integral part of the methodology, the information may be needed for a considerable length of time and may be useful to individuals other than those involved in the initial development. 20.6 Linkages to other steps Step 3 must be invoked whenever a change is needed in the set of actions or their specifications. Changes in the action set could result from activities in any step of any spiral and consequently cause a direct transition to this step or to other steps that may be affected (e.g., step 1) before this step is reinvoked. The exact transition sequence depends on the circumstances. If the changes are relatively small, the time required for a reinvocation of step 3 should also be relatively quick, although all the activities would need to be utilized at least once during invocation of this step. The usual transition to step 3 is directly from step 2, where the dialogs are identified and specified. The initial specification or changes to the specification of the dialogs always require an analysis of the needed actions. There are three possible transitions from step 3 upon its completion. One is to step 4, where mapping of the actions to available software components is considered. The second is to step 5, where the human interfaces are designed and developed. The third transition is to step 6, which occurs when the action specifications affect the workflow design. All those subsequent steps can be performed in parallel, although changes in any step may require step 3 to be reinvoked with subsequent reinvocations of steps 4, 5, and 6. If step 3 raises questions concerning the process map or dialog definitions, a noncompletion transition to step 1 must be made and the process spiral reiterated until those questions are resolved. A number of reinvocations of step 1 almost certainly will be made from step 3 because the increased level of detail made available through the step activities will uncover process and dialog problems. 20.7 Postconditions Step 3 is complete and may be terminated for a given development when the following information and conditions are present as a result of the current step invocation. § All step activities have been considered at least once. § As complete a set of actions as possible with available knowledge has been defined for each dialog. § A determination of which existing actions can be reused has been made. § An action prototype is available. § A completed action template is available for each action. The software component information is not required. § Appropriate animation of the action prototype has been performed and the results verified. § The business and technical stakeholders have been involved as needed and agree with the results of the action animation. It is not necessary that the business-oriented stakeholders review the action definitions (they are considered part of the detailed design). § All relevant action information has been entered into the appropriate repository and updates verified. § Any necessary approvals have been obtained. At the conclusion of step 3, all affected stakeholders must agree that the action animation, as it is currently defined, accurately depicts the intended operation of the process. The results of this step may indicate that further refinement of the process is necessary. Chapter 21: Step 4: Map actions 21.1 Purpose The purpose of step 4 is to map the action specifications of a dialog to the physical entities that will implement them. Actions with an automated class are mapped to existing software components, and those with a human class are mapped to a policy, procedure, or other instructional publication, which may be paper based or in a machine- readable form. The goal is to map all the actions to existing entities to reuse as much of the available software and instructional material as possible. If no existing entities can be utilized to implement one or more parts of an action, then specifications for them must be developed so they can be implemented and used for the current process development as well as future ones. The activities in step 4 map the parts of the automated actions to existing or proposed physical components that have the needed functionality. Transactions are mapped to sharable (external) software components, while support functions are mapped to software components (internal) that are not shared but that can be reproduced and changed to fit the specific needs of the action. External software components are accessed with request messages and reply with a corresponding response message. The message pairs, as well as the software component functionality, must conform to the requirements of the action. Unless specifically stated, the message pair specification is considered part of the software component it accesses. Internal software components are accessed through any mechanism that is supported by the action execution environment (e.g., sub-routine calls). Existing components are analyzed to determine how much of the functionality needed by the action specifications can be met through their use. The definition of external software components includes available COTS products and legacy systems as well as functionality developed specifically for the process implementation. New or augmented software components are then proposed to provide required transaction functionality not covered by existing ones. A similar procedure is utilized to obtain the functionality required by the support functions. The provisioning of any proposed internal or external software component is subject to management approval, and their availability depends on the resources allocated. In a similar fashion, other activities in this step map the human action(s) to existing instructional publications (policies, practices, and procedures). In essence, they are a form of the business rules utilized by the enterprise. Existing publications are analyzed to determine how much of the functionality of new human actions can be met by existing policies, practices, and procedures. New or augmented publications are then proposed for functionality not covered by existing policies, practices, and procedures. 21.2 Preconditions The following conditions must exist before work on the activities of this step can be initiated. It also is assumed that, in addition to the items explicitly listed in this section, any result from an earlier step or spiral can be used to provide guidance or background information. § Filled-in action specification form for each action. Because the software component information is added in this step, this information does not have to be included in the form, although it may be available when this step is reinvoked. § Existing external software component documentation from the repository. § Existing internal software component documentation from the repository. § Existing business rule (policy, practice, and procedure) documentation from the repository. § Existing enterprise standards documentation from the repository. § Infrastructure architecture specification and as-built configuration from the repository. § The list of all actions that have been previously considered during the examination of other dialogs and that are already mapped to software components. These do not have to be remapped but can be utilized as defined. This information is in the repository. § Any information that would significantly affect the implementation or use of proposed components. This type of information could include possible relationships, restrictions, and operational needs. This information is obtained, but not utilized, from previous steps and is documented in the repository. 21.3 Description Step 4 has three fundamental aspects related to the mapping function. The first is to provide the initial mapping between the actions that form the logical design of the dialog and the physical components (automated or manual) that will be used for its implementation. The mapping may be to existing components or to proposed components when there is no suitable existing component. The second aspect is to analyze the proposed set of action mappings over all the available process dialogs. This analysis is designed to ensure that a consistent set of mappings is obtained for the process. Because it is possible that different development personnel will be performing this step for different dialogs, this analysis is necessary to ensure that the overall results are compatible. As this step is revisited for each dialog in the process, the number of available dialogs increases until the entire process can be considered. The third aspect of step 4 is provision of information to the associated project management methodology by identifying (1) any functionality that is needed but that does not yet exist and (2) any opportunities to provide a more cost-effective implementation by changing the definition or provisioning of existing external software components. This type of proposal needs careful attention to the configuration management aspects of the components. The latter result is one mechanism through which component provisioning can change without altering the design or implementation of the process. The mapping of the automated actions is discussed first, followed by a discussion of the human actions. Although there are some similarities between the two, each needs to be discussed in its own context. 21.3.1 Initial mapping Mapping of the automated actions is performed on an action-by-action basis using the specifications for each action that were developed in step 3 (Specify actions). For every part of an action, existing or proposed software components with the same functionality are identified and then used in implementation of the process. It should be noted that the use of the term physical component implies only that such functionality has been developed and provisioned or is proposed to be developed and provisioned. It does not necessarily imply a specific deployment configuration. For example, the provisioned functionality for a given action transaction could actually be implemented on multiple platforms. The actual platform employed in a specific use of the transaction might depend on a large number of operational characteristics, such as load, time of day, and platform operational status. Such a deployment structure does not affect the mapping process. To provide an effective mapping between the components of the actions and the available physical components, it may be necessary to manipulate the actions in two different ways. § Decompose an action into multiple actions so that a mapping can be made to existing components that have only a part of the functionality or data of the original action. § Combine actions to utilize a legacy system or COTS product external component. Although that somewhat compromises the underlying concept of an action, it does permit the use of large functional components when necessary. In the extreme, all the actions in a dialog could be combined, and the legacy system or COTS product could become the implementation of the entire dialog. If either or both of those changes are utilized, it will be necessary to reiterate the logical design spiral to ensure that the changes have not affected another part of the process functionality and that the new actions have been properly defined and documented. The use of physical components that are proposed to be created or changed in some way to provide the required functionality must be referred to the project management methodology. The purpose of such referral is to determine the allocation of enterprise resources, both for deployment and to provide new or changed physical components. One result of that allocation is that some actions with an automated class may be changed to a human class on an initial or permanent basis. Changes of that sort require that step 3 and the logical design spiral be reinvoked. A possible result could be to postpone the implementation of the process until the needed physical components are provisioned. That would then suspend the use of the PRIME methodology for the development of that process until such time as the required physical components have been provisioned and are available. This is another function of the project management methodology. Recommendations to reprovision existing components can result from a number of conditions: § A mismatch in the logical specifications for a component, usually an action transaction, and the properties of the physical component to which it is mapped. Although the functionality of the physical component may be appropriate, such characteristics as throughput, response time, and error detection may not be in sufficient agreement with the logical transaction needs. § The result of the project management review of the mappings as specified in this step. Criteria such as component maintenance costs, error rates, and new recommended functionality would enter into this decision, as would the needs of other processes or dialogs that were also mapped to this component. § Replacement of a legacy system with a set of reusable components that would then be available for future projects. For the human actions, mapping again is performed on an action-by-action basis. The major difference lies in the physical components used for the mapping. In the case of automated actions, the components are software. In the case of human actions, the components are textural instructions (either on paper or in machine-readable form). Again, it should be noted that the use of the term physical component implies only that such functionality has been developed or is proposed to be developed. It does not necessarily imply a specific deployment con- figuration. For example, a provisioned transaction could actually be implemented by multiple human performers. The actual configuration employed in a specific use of the transaction might depend on a large number of operational characteristics, such as load, time of day, and location operational status. That deployment structure does not affect the mapping process. Human actions also require an interface to the automation system to exchange information with the automated actions. The development of that interface is discussed in Chapter 23. The design of such an interface does not replace the need to map the human actions to appropriate instructional material. The material could be made a part of the human interface, if desired, or it could be implemented separately. That is the province of the interface designer. As with the automated actions, to obtain an effective mapping, it may be desirable to decompose an action into multiple actions so a mapping can be made to existing components. If that is done, it is necessary to reiterate over the logical design spiral to ensure that the changes have not affected another part of the process functionality and that the new actions have been properly defined and documented in the repository so they can be utilized by other processes and dialogs. 21.3.2 Mapping analysis Two vehicles are utilized as a framework for analyzing the action mappings. The first is a modification of the logical design prototype originally defined for the logical design spiral. Each prototype of interest is supplemented by the additional information resulting from the mapping activities of this step. That includes information such as timing and other operational characteristics of the physical components. Although the prototype is still referred to as the logical design prototype after having been augmented with the information needed in this step, it contains considerably more information than that required by the logical design spiral. One advantage to utilizing the same prototype form for both the logical design spiral and the physical design spiral is the ease of traversing between the spirals as project management decisions are incorporated in the logical design or multiple what-if studies are performed. The second analysis vehicle is, conceptually, a three-dimensional matrix called the analysis matrix. The columns are dialogs, the rows are actions, and the layers are the attributes of the action parts and mapped physical components. Figure 21.1 is an example of the matrix. Any face or other related group of cells can be examined as a unit for the purposes of pattern matching. Although use of the matrix can be accomplished manually for relatively small processes, an automated tool assist usually is necessary for practical business processes. Figure 21.1: Analysis matrix structure. The analysis matrix has two basic purposes. Its first purpose is to analyze, for each dialog or set of dialogs in a process, the specific external software components utilized by the individual transactions. An examination of that information can determine if the mappings of all the actions are consistent with each other. For example, assume one action utilizes an external component that retrieves customer information from database A. Assume that a second action utilizes an external component (most likely in another dialog but possibly in the same dialog) that retrieves the same customer information from database B. There may be a good reason why the process requires the same information from two different physical locations, but that could be a problem if the information in the two components is not concurrent. A remapping may be necessary if it is desired that identical information be obtained from the same source. If multiple sources for the same information are needed, it also may indicate that an explicit process is necessary to keep the two sources concurrent to some specified degree (it will be necessary to investigate that possibility whether or not a remapping is performed). That new process could be defined independently of the current process or incorporated into it. The specific disposition depends on the individual circumstances involved and the characteristics of the relevant data. The internal software components used to implement the action support functions are analyzed in the same way to ensure the required degree of consistency for the process. 21.3.3 Project management methodology information The second use of the analysis matrix is to enable the estimation of the resources required for the development of the defined process as well as for an initial estimate of the development costs of the software components and other functionality that currently does not exist. Although this estimation procedure is performed by the project management methodology, the source data required are developed in this step. 21.4 Prototype The logical design prototype continues to be utilized in this step. It is updated with the operational information obtained from the mapped functionality so the characteristics of the actions as implemented in the prototype can be updated accordingly. After the updates have been made, the entire suite of scenarios should again be used to animate the prototype to ensure that the mappings are appropriate to the correct functioning of the dialog as perceived by the business and technical SMEs as well as other stakeholders of interest. 21.5 Activities The 14 activities in this step are arranged according to the diagram in Figure 21.2. The activities can be performed either manually or with an automated tool as available. If automated, the matching processes utilized in this step usually require the use of a knowledge-based approach. Figure 21.2: Diagram of activity sequence. The activities for any specific action can be performed in parallel with those for any other action, depending on the resources available (development personnel and tool support). 1. Augment action specifications with infrastructure information as needed. Augment action specifications (transaction and support functions) with applicable infrastructure information. This information is utilized during the matching process to determine the acceptability of the available physical components in areas other than process functionality. An example would be the database utilized by an external component. 2. Determine if an existing software component provides the needed transaction functionality. Using a suitable matching process, determine if any level of agreement exists between the requirements of the transaction part of the action and an existing software component. (Note: Actions that were identified in methodology step 3 as essentially identical to existing actions do not have to be considered in this activity; they were mapped previously and the results placed in the repository. The previous match does need to be documented in the repository, however. If no match at any level of agreement exists, go to activity 4.) If a match exists at some level, document the match and its characteristics. For, example, it may be determined that an exact functionality match exists but that the operational characteristics are not exact. The software component could then be used with some sacrifice in resultant capability. If the match is considered close enough, then that fact, along with the discrepancy in operational needs, should be documented. 3. Decompose remaining actions into less complex actions if possible. For an action transaction that does not have a suitable match to an existing external software component, attempt to decompose it into two or more less complex actions to help facilitate a possible mapping. Repeat activities 1 through 3 for the decomposed actions. When this activity is no longer feasible, terminate it and continue step processing. A successful decomposition is not likely, but it does occur often enough to make the attempt worthwhile. 4. Determine if the updated action set can utilize existing functionality. Depending on the results of the resource allocation, determine if changes to the action specifications can result in additional utilization of existing functionality (e.g., legacy system or COTS product). That may involve changing the operational requirements of the actions or splitting or combining actions. Changes to the process map or dialog definitions also could be a means to achieve additional mappings. If there is a possibility that such changes could be effective, then the necessary spirals and steps need to be reinvoked. 5. Propose new or augmented external software components as needed. For any action transactions that were neither mapped during activity 2 nor decomposed during activity 3, propose new or augmented software components. A specification of the functionality needed along with the necessary access (message pair) specification must be developed. Document the mapping that results between the transactions and the proposed new external software component. 6. Determine the suitability of existing internal software components. Using a matching process, determine if any level of agreement exists between the requirements of each support function and the physical characteristics of any internal software components that exist in the repository. (Note: Actions that were identified in methodology step 2 as essentially identical to existing actions do not have to be considered in this activity; they were mapped previously and the results placed in the repository.) If a match exists at some level between an existing internal software component and the action support function, document the match and its characteristics. For example, it may be determined that there is a close but not exact functionality match. The component could then be used with some changes. Any level agreement along with the needed changes should be documented. For any support functions that do not have a suitable map to an existing software component, attempt to identify fragments of existing components. When this activity is no longer feasible, terminate it and continue step processing. 7. Propose new or augmented internal software components as needed. For any support functions that were not mapped at some level to existing components, propose new or augmented components that can be used to implement the functionality. Document the mapping that results between the support functions and the proposed internal software components as well as the specifications of the proposed components. 8. Determine if an existing instruction document provides needed information. Examine available instructional material to determine if such material can be utilized as is or adapted for the needs of the action. 9. Propose new or augmented instructional material as needed. From the action specification, determine the characteristics of the needed instructional material and propose the format and contents of such material. 10. Analyze the action set over all available dialogs. Populate the analysis matrix with the data from each available process dialog and its included actions. If it is desired to address multiple processes concurrently during this step, the matrix should consist of all the dialogs belonging to the entire set of processes under consideration. Examine the analysis matrix to determine if any of the following conditions exists: Multiple transactions that retrieve the same information from different physical components using the same or similar request and response data; Multiple transactions that perform the same operation but have different request or response data; Transactions that perform the same operation using the same physical component but differ in the amount of information specified in the request or response. If any of those conditions surfaces, it must be examined and reconciled if necessary. The exact procedure for accomplishing that depends on the nature of the problem and cannot be generalized. Usually, however, the resolution requires that a remapping be performed by returning to the mapping activities of the step. It is also possible that it will require a reinvocation of the logical design spiral and possibly the process spiral. 11. Update logical design prototype and animate using scenarios. Present the augmented logical design prototype to the stakeholders in a facilitated session to determine if the action functionality, characteristics, and sequences still meet the requirements of the business processes. Depending on the results, return to the mapping activities of the step and, if necessary, revisit the process and or logical design spiral to resolve any remaining difficulties. 12. Convey new or changed functionality needs to the project management methodology. The need for new or changed software or instructional material that results from step 4 must be presented to the management methodology so available resources can be utilized as efficiently and effectively as possible. That may result in the postponement or elimination of some needed functionality, which in turn may cause any aspect of the process to change. Such changes must be processed through the appropriate spirals and steps of the methodology. The analysis matrix information can be used by the project management methodology to provide an initial estimate of the costs involved for any proposed new or changed functionality. 13. Obtain necessary approvals. If approvals are needed to continue beyond step 4, they need to be obtained before proceeding. The action prototype, the opinions of the stakeholders, and the hard deliverables from this step (updated action templates, new functionality specifications, instructional needs specifications) should be sufficient to demonstrate the suitability of the action definitions and the ability to proceed. Approvals also may depend on the availability of sufficient resources to provide the requested development. Conditional or partial approval may require alterations in the development, including the changing of some action classes from automated to human. Other what-if changes also could be proposed that would require utilizing previous steps to analyze the effect of such proposed changes. Eventually, if the project is to proceed, approval has to be given using some set of conditions, either the original set or one containing some alterations based on available resources. 14. Enter the updated action specifications (including mapping information) into the repository. Identify those actions that were already in the repository upon entering step 4. Every action in a dialog should now have its defined functionality (1) mapped to existing or proposed physical components or (2) marked as previously existing and mapped during the consideration of actions in previous process implementations. The information on the action templates should now be complete. 21.6 Linkages to other steps Step 4 must be invoked whenever there is a change in an action other than a deletion. Because a deletion does not require a mapping, it is not necessary for this step to consider that event. Some changes in needed action characteristics (e.g., response time) can result from the activities in any spiral and consequently cause a direct transition to this step in addition to other steps that may be affected. A change in the automated/human characteristic of an action probably would not cause a direct transition to this step but require step 3 to be invoked first. The usual transition to this step is directly from step 3, where the automated actions are identified. Other sequences depend on the specific circumstances involved. The transition from this step to other steps depends on the type of results incurred. For those dialogs that have all their actions successfully mapped with no changes to the actions, the transition from this step is directly to step 7, where the integration of all the implementation components is performed. Step 7 is not started, however, until all the necessary components are available (steps 5 and 6 completed normally in addition to step 4). In addition, although it is not a direct part of the PRIME methodology, a transition to step 4(a) also is made. Step 4(a) is concerned with the design and implementation of the software components that were determined to be needed in step 4. Step 4(a) also includes the creation or update of new instructional material. If any actions are changed as a result of the activities in step 4, a transition to step 1 or 3 must be made so the changes can be put into their proper context. The specific step to which the transition is made depends on the particular change or set of changes that must be performed. 21.7 Postconditions Step 4 is complete and may be terminated for a given development when the following information and conditions are present as a result of the current step invocation: § All step activities have been considered at least once. § The mapping of all transactions used in an automated action to existing or proposed external software components has been completed. § A brief description of each proposed external software component is available. § The mapping of the support functions required by an action to existing or proposed internal software components has been completed. § A brief description of the changes required for the use of an existing component is available. § A brief description of each proposed new or augmented internal software component is available. § The mapping of all human transactions used in an action to existing or proposed instructional material has been completed. § The list of all actions that have been considered previously during the examination of other dialogs and that are already mapped to existing components is available. Of course, they do not have to be remapped but can be utilized as defined. § Any information that would significantly affect the implementation and use of proposed software components is documented. That could include possible relationships, restrictions, and operational needs. § A completed action specification form is available for each action. The software component information is now required. § Using the scenarios, animation of the action prototype with the updated operational information has been performed and the results verified. § The business and technical stakeholders have been involved as needed and agree with the action mappings as demonstrated through the augmented logical design prototype. § All relevant action information has been entered into the appropriate repository and updates verified. Any necessary approvals have been obtained. At the conclusion of step 4, all affected stakeholders must agree that the action animation, as it is defined using existing components, accurately depicts the intended operation of the process. The results of step 4 may indicate that further refinement of the process is necessary. It is not necessary that the business-oriented stakeholders review the action mappings because they are considered part of the detailed design. Selected bibliography [...]... functions that must be performed to achieve a suitable result Based on the performance characteristics of humans and those of computers, each function can be assigned to either a human performer or an automated performer The availability of suitable technology and infrastructure for the support of any automated functions also must be available The unit of functionality must be appropriate for this approach... Atlanta, Oct 12– 16, 199 2, pp 1254–1258 Dearden, A.M., and M D Harrison, “Impact and the Design of the Human- Machine Interface,” IEEE Aerospace and Electronics Systems, Vol 12, No 2, 199 7, pp 19 25 Fitts, P M., “The Information Capacity of the Human Motor System in Controlling the Amplitude of Movement,” J Experimental Psychology, No 47, 195 4,pp 381– 391 Hartson, H R., and E C Smith, “Rapid Prototyping... Report TR- 89- 42, Virginia Polytechnic Inst and State University, 198 9 Hefley, W E., et al., “Integrating Human Factors With Software Engineering Practices,” Proc Human Factors and Ergonomics, Vol 1, 199 4, pp 315–3 19 Landay, J A., and B A Myers, “Interactive Sketching for the Early Stages of User Interface Design,” Proc ACM CHI 95 Conf Human Factors in Computing Systems, Vol 1, Denver, May 7–11, 199 5, pp... information is implicitly incorporated into the following discussion 24.2 Preconditions The following items are required to be available before work on the activities of step 6 can be initiated It also is assumed that any results from an earlier step or spiral can be used to provide guidance or background information § Process map with dialog designations § Dialog map and prototype § Scenarios § For each dialog:... complet e and documented for the dialog or group of dialogs of interest § The logical design prototype augmented with the completed interface design is available for demonstration § Usability objectives for the interface are documented § The business and technical stakeholders have been involved as needed § All relevant interface information has been entered into the appropriate repository and updates... or functionality when the business needs change (e.g., the addition of a new line of business) The second entry comes from PRIME step 4 and occurs when a needed component for a process implementation is not available The requirements for the required functionality and access method are passed between the two methodologies Those two input sources represent the links to the enterprise and process- based... comprehensive set of information necessary to produce SMEs in this area Rather, it presents the type of information that is utilized in the design of human interfaces and illustrates how that design is integrated into PRIME 23.2 Preconditions The following items are required to be available before work on the activities in step 5 can be initiated § Role performer characteristics for the dialog, including... MacKenzie, I S., “Fitts’ Law as a Research and Design Tool in Human-Computer Interaction,” Human-Computer Interaction, Vol 7, No 7, 199 2, pp 91 –1 39 Mantei, M M., and T J Teorey, “Cost/Benefit Analysis for Incorporating Human Factors in the Software Lifecycle,” Communications of the ACM, Vol 31, No 4, 198 8, pp 428–4 39 Mayhew, D J., “Managing the Design of the User Interface,” Proc ACM CHI 94 Conference on... the entities of interest For simplicity, except for the control aspects of building blocks, the infrastructure elements needed for an actual implementation are not explicitly shown Building blocks contain a class of functionality An example would be that of an inventory building block that contains all functionality specific to inventory control Components provide a cohesive set of functionality related... result of a stable condition Figure 23.4: Feedback applied to the human interface As an example, consider the following inventory situation The input information is the quantity of an item ordered At this time, there is no feedback information, so the activating signal is the amount of the order for a given item that the human enters into the system The system compares that value with the number available . 21.2 Preconditions The following conditions must exist before work on the activities of this step can be initiated. It also is assumed that, in addition to the items explicitly listed in. necessary if it is desired that identical information be obtained from the same source. If multiple sources for the same information are needed, it also may indicate that an explicit process is. activities 1 through 3 for the decomposed actions. When this activity is no longer feasible, terminate it and continue step processing. A successful decomposition is not likely, but it does