Graphical (iconic) interfaces with multiple windows usually are defined in conjunction with drag-and-drop movement of data from one window to another. The use of video also is growing more common. The design of specific interfaces is the province of human factors experts who specialize in the identification of effective means of human-machine interaction. Although the display of those data is crucial to the success of the final implementation, the most that can be accomplished from an overall methodology standpoint is to ensure that a specific spiral and associated steps are defined for that activity. A thorough discussion of the approaches used in interface design is well beyond the scope of this presentation. The emphasis instead is on the assurance that the data will be available to the human role performer when it is needed. 17.5.1 Description The human interface is the mechanism that permits the exchange of data between the human role performer and cluster store. As such, it is associated with the cluster and not with an individual dialog. If a dialog terminates but the cluster remains active with other dialogs, the data in the human interface could remain even though they were utilized in the terminated dialog. That continuity facilitates the transfer of data between dialogs from a human perspective as well as from an automated one. The human role performer could control the availability of data, or the data could be controlled through an automated means by suitable definition of the actions that read and write data to the interface. Unfortunately, the cluster orientation somewhat complicates the design of the interface because it requires that the designer accommodate any data that could be presented using any reasonable compound scenario. Management of a large amount of data becomes a significant design factor in addition to the usual emphasis of the aesthetics of look and feel, which is the traditional approach. Because of some of its inherent limitations another complication is the use of Internet browser technology to provide the interface instead of a proprietary implementation using products such as Motif for a UNIX-based solution or Microsoft Windows for a PC-based solution. 17.5.2 Prototype The human interface spiral prototypes are used to show the SMEs and end users how the interface operates and to determine how effective they will be in a production environment. Many different types of prototypes can be utilized for that activity; the specific ones are determined by the designers and users involved. Usability testing using an associated prototype is a common technique to ensure that the proposed interface can be used without generating a large number of mistakes or confusion on the part of the user. The human interface prototypes usually are not directly transferable to the final implementation. The design principles can be transferred, but the implementations usually are different. 17.6 Spiral 5: Workflow The purpose of the workflow spiral is to develop the workflow imple- mentation for the business process being addressed. The workflow implementation provides the connection between the process dialogs and any other dialogs needed in their support from a technical or business perspective. It determines when, where, and by which role performers the dialogs will be addressed. Although workflows are defined on a dialog abstraction level, actions used to exchange data between the dialog and the workflow manager need to be defined. That could result in several spirals being revisited. In general, however, the workflow design is based on the dialog definitions. 17.6.1 Description The workflow specification utilizes the definition of the process and support dialogs to determine the tasks that are the unit of functionality for the workflow. Tasks consist of one or more dialogs, depending on the control and reporting requirements needed for the workflow. Frequently, workflow design activities result in changes to the process map and its defined dialogs. That occurs for the same reasons that the specification of the actions also results in the same types of changes. The need to define the intent of the process using technical constructs frequently identifies areas where the process map does not provide sufficient guidance as to how the implementation should proceed. In addition, alternative ways of providing the same result as specified by the process map occur with regularity. Those alternatives can result in more efficient and effective implementations, but they need to be reflected back to the process map so the business SMEs can be assured that nothing has been lost by the changes. To provide a complete workflow specification, information as to the available workforce, task scheduling, routing methods, and monitoring requirements also must be specified. Examination of those needs also may indicate changes to the process map and dialogs. Once the workflow information has been programmed into the process specification tool of the workflow engine being utilized, simulation of the workflow is utilized to determine the operational characteristics of the workflow. The results of that simulation almost always are different from those of the simulation performed on the business process. This is because the definition of the workflow process contains a great deal more information than is usually made a part of the process map. For example, the simulation may reveal bottlenecks caused by staffing characteristics and not by the inherent characteristics of the process flow. The workflow implementation also needs to be tested using the scenarios defined for the process. That ensures that no inherent process functions have been compromised by the workflow representation and implementation. If testing shows that problems do exist, they may be able to be corrected by changes in the workflow, or just as likely they may need changes to the process map. 17.6.2 Prototype A workflow prototype is used as part of the development of the workflow specification and to ensure that all the needed information is available. The prototype uses stubs for the tasks if they are not available. All other information needed by the workflow is programmed into the workflow engine. 17.7 Spiral 6: Assembly The assembly spiral is concerned with the integration of all the components necessary to implement a process, as well as the testing and evaluation of the resultant implementation. Although some of the external software components that consist of all or part of a COTS product or a legacy system may be stubbed because of access difficulties, the remainder of the implementation is consistent with that of the final product. The elements that are integrated during spiral 6 are: § The dialog infrastructure, including common support actions; § The cluster store; § The final human interface designs; § Implementation-specific actions that have been defined for the dialog; § The workflow engine and associated program; § The client platform; § The software components required by the actions; § The server platform(s); § The system software; § The network that connects the client and server platforms; § Other support software. Prior to the integration of those elements, the specified software components must be implemented if they are not already available. It is anticipated that most of the components will be available and that only a small number of them will need to be developed for a given project. For the initial projects developed using this methodology, that assumption may not be true and a significant number of software components may need to be implemented. 17.7.1 Description Spiral 6 is used to assemble, demonstrate, and evaluate the operational characteristics of the process implementation. If problems are encountered, the malfunctioning components are identified, and, depending on the cause, one or more spiral types are invoked and utilized to determine and implement the proper changes. The initial transversal of spiral 6 is utilized to create an assembly prototype that behaves in an operational sense exactly like the final system. Some components may be stubbed because they have not yet been implemented or the use of an operational system is deemed to be critical in this phase. However, the characteristics of the implemented software components are maintained by the stubs (e.g., delays, data types). Subsequent iterations of the spiral are used to fine tune the system characteristics and determine if changes are warranted. Fine tuning in this context includes the following: § Launch criteria changes; § Error handling and recovery procedure changes; § Minor modifications of the screen or other aspects of the human interface design; § Rehoming of specific action transactions; § Addition of statistical or management actions; § Changes in the specific dialogs that are coresident on the workstation. Any of those tuning changes requires the appropriate spiral(s) to be invoked to maintain the integrity of the development and ensure that the appropriate information is maintained for later use in the operations-oriented improvement spiral. 17.7.2 Prototype The assembly prototype defined for spiral 6 has a structure and functionality that are as close to the deployed process as can be obtained without producing the final deployable implementation. This prototype is the last chance for the stakeholders to correct any problems before deployment. While it is relatively expensive to correct a problem found in this spiral compared with fixing problems detected in earlier spirals, it is much less expensive than performing corrections in the field. Because the assembly prototype and the final deployable product are relatively close in structure and function, enumerating the differences and similarities between them helps place each in perspective. The assembly prototype has the following characteristics relative to the deployable product: § It runs on the same hardware and software platforms as the deployable product. § Distribution of functionality among servers is the same as the deployable product. § For all specified software components currently available, the actual components are used. § For all other components, stubs with the same interface characteristics are used. § The network protocols are the same as those that will be used in the deployable product. § The network topography may be different from that of the deployed product. § Some network management, recovery, and error handling needed in the deployed product may not be implemented. § All human interfaces are completely implemented. § The workflow implementation is fully operational. § Complete documentation may not be available. The assembly prototype also can be the vehicle for initial acceptance testing, training of users, and capacity testing. The use of the previously defined scenario set is the basis for acceptance testing. Once the assembly prototype has been evaluated and accepted by the users, there is no opportunity to make additional changes until actual deployment. Thus, it is important to ensure that the assembly prototype is evaluated and tested in as many ways as possible. 17.8 Spiral 7: Improvement The purpose of spiral 7 is to: § Deploy the implementation by provisioning all the necessary components on those platforms that have been identified as participating in the implementation; § Finalize and implement the support functions such as documentation, network or service management, and security; § Determine the procedures by which the implementation will be made available to the affected users (mostly the responsibility of the project management methodology); § Monitor the operation of the implemented process by using the capabilities of the workflow engine and, depending on the results, identify and implement changes that can improve the operation of the implementation. The improvement spiral is also used as the initial mechanism to address changes to the process that arise because of business needs that occur independently of the process operation. That would include such items as regulatory changes, new product offerings, competitive responses, and changes to the organizational structure of the enterprise because of acquisitions or divestitures. 17.8.1 Description The deployment functions of spiral 7 require significant cooperation with the project management methodology because it is that methodology that is responsible for the scheduling of the deployment and the notification of availability to selected users. It is also responsible for the dissemination of any documentation to the end users, operations personnel, and the help desk, if one is to be utilized. The monitoring and evaluation function generally is accomplished through the information obtained by the workflow engine during its normal operation. The data obtained include timing of all the workflow tasks and components as well as any specific data selected by the workflow designers. The operational data can be used in conjunction with the simulation results obtained during the associated development spirals to determine what improvements are possible or feasible. Improvements may be identified that will not be implemented because they are too costly in absolute terms or for the improvements that would be obtained. When process changes are required because of business needs not directly related to the operation of the process, the invocation of the spirals needed to effect the change is considered to be through the operation of the improvement spiral. That is done because the needed changes may not require alterations to the process map or dialogs that would be assumed if the initial development entry point was used. That assumption also provides the desirable continuity between the development and maintenance phases of the implementation. It is useful to assume that both phases utilize the same fundamental methodology. 17.8.2 Prototype The prototype is the operational process implementation. As such, it is not a true prototype, but to the extent that it needs to be monitored and changed, it can be viewed in somewhat the same light as the prototypes associated with the other spirals. 17.9 Summary Each spiral covers a major aspect of a process implementation. The spirals are connected in such a way that the effect of a change, regardless of the spiral in which it occurs, can easily be determined for all spirals. That prevents a change from causing an undetected (until deployment) problem in another area of the implementation. Each spiral also incorporates the same general approach, which helps to integrate the different spirals into a unified methodology. Every spiral will be traversed many times during an implementation Although an initial order is defined for discussion purposes, the actual order will differ considerably over the course of the development. In fact, there is no specific order to the spirals after the initial startup of the implementation. Revisiting any spiral does not mean that a problem has occurred. It only means that additional information needs to be incorporated in the implementation. For staff experienced with other types of methodologies, that can be a difficult transition to make. Each step in the methodology is examined in detail in the next nine chapters. To some extent, the overall operation of the methodology as defined by the spirals is hidden during those presentations. To maintain as clear an understanding as possible, the reader should remain cognizant of the placement of each step in the methodology as its functions and requirements are defined. Selected bibliography Boehm, B. W., et al., “Software Requirements Negotiation and Renegotiation Aids: A Theory- W Based Spiral Approach,” Proc. 17th Internatl. Conf. Software Engineering, Seattle, Apr. 23–30, 1995, pp. 243–253. Boehm, B. W., “A Spiral Method of Software Development and Enhancement,” IEEE Computer, Vol. 21, No. 1, 1988, pp. 61–72. Viravan, C., “Lessons Learned From Applying the Spiral Model in the Software Requirements Analysis Phase,” Proc. 3rd IEEE Internatl. Symp. Requirements Engineering, Annapolis, MD, Jan. 6–10, 1997, p. 40. Chapter 18: Step 1: Define/refine process map 18.1 Purpose Step 1 contains the requirements determination portion of the PRIME methodology. It is designed to provide an initial set of requirements prior to starting the remainder of the implementation. The initial requirements will change and be refined as the activities of the methodology are invoked. The basic unit of consideration in this step is the process. If multiple processes are to be considered simultaneously because they are closely related, each process is still handled independently. The connection between the processes is the identification of common identical (or nearly identical) sets of process steps and interconnection points. Determination of the requirements is accomplished from a business perspective. The focus is on the process, which is represented by the process map and its associated information, including information flows, scenarios, business rules, and operational characteristics. The operational characteristics include the following items: § Performance; § Security; § Throughput; § Recovery and exception handling; § Statistics; § Tracking and logging; § Costs; § Role characteristics. For simplicity, references to the process map are assumed to also include that associated information. The process map is used as the main communication vehicle with the business stakeholders to ensure that the process accomplishes the intended business goals and objectives. Although some amount of work in that area may have been performed before step 1 is invoked, the rigorous analysis process and creation of an affiliated prototype as part of the step activities help to derive considerable additional information about the process and its component steps. The technical perspective focuses on the ability of the process map to be translated into a structure that is implementable using available technology. The analysis is started in step 1 and continues throughout the methodology. If, during any phase of this analysis, it is determined that the implementation is impractical or impossible, step 1 must be revisited and the process map changed appropriately. If the business process already exists and is in operation in the enterprise, it is usually suggested that the current operation of the process be documented in an “as-is” process map before starting the process reengineering or development of the “to-be” process map. The to-be map documents the process as the enterprise wants it to operate. If several as-is processes exist because relatively independent organizations of the enterprise have developed local versions of the process, it usually is not worth the effort to document all those variations. In that situation and the case in which the process is new, the implementation starts with the to-be map. The discussion that follows assumes that the to-be map is being developed, although many of the concepts could be applied to the as-is map if it is useful to perform that exercise. 18.2 Preconditions The information and resources that must be available prior to invoking step 1 depend on the entry path utilized: § Initial entry point: Process definition (high level); organizational commitment; resource allocation (SME time); § From step 2, “Identify dialogs”: Detailed process map; set of scenarios; initial dialog determination; process prototype; questions or problems concerning process; § From step 3, “Specify actions”: Detailed process map; set of scenarios; dialog determination; process prototype; initial action specification; action prototype; questions or problems concerning process; § From step 6, “Determine workflow”: Detailed process map; set of scenarios; dialog determination; process prototype; initial action specification; action prototype; initial workflow specification; workflow prototype; questions or problems concerning process; § From step 8, “Deployment and operation”: Operational process implementation; process measurements and statistics; all implementation information. 18.3 Description This description of step 1 assumes that the step was entered from the initial entry point because that requires the most effort and associated activities. If that is not the case, the process map already exists, usually along with a considerable amount of other information, and is expected to be altered in some fashion. When that type of entry occurs, the existing process map information is valid, but it must focus more on the specific difficulties that caused the step to be revisited. That may require fewer or different personnel at the sessions than indicated in Section 18.3.1. In addition, the activities should accommodate the additional information available. That may lift some restrictions given for the initial development of the process map (e.g., the restriction against discussion of existing system functionality). 18.3.1 Facilitated sessions With those caveats in place, the step description continues. The initial development of the process map is usually performed in a series of facilitated sessions. The sessions should include the following participants: § A set of business SMEs who collectively can address all aspects of the process; § A facilitator familiar with the process approach to requirements gathering; § A methodologist knowledgeable in the entire PRIME methodology who can determine if the sessions are producing acceptable results; § Technical SMEs who will implement the defined process. Because not all of the information discussed will be documented, it is necessary to have a set of development personnel who can get a feel for the process and what it is intended to accomplish. Several rules should be followed during the sessions to obtain a version of the map that truly represents the desired process. There are others, but only the major principles that need to be followed are listed here. 1. Specify only the activities that are desired, not the means of current implementations. Statements such as “then system X is used to obtain data Q” are not allowed. It easily could be that system X is the problem, and its functioning should not be allowed to influence the process specification. Connection of the process to available functionality occurs later in the implementation. 2. For the same reasons, do not make references to CRT screen layouts or data formats. They tend to unduly influence the process specification process; as in the case of legacy systems, they may be a problem, not the solution. 3. Develop high-level scenarios prior to the process map so they can be used in the development of the map. Although scenarios developed after the map is formulated still have significant value, more value is obtained if they are available prior to the start of map development. Scenarios help determine the scope and general characteristics of the process, which can greatly facilitate the process specification activities. 4. Eliminate protracted discussions about inconsequential items. There is a tendency to argue over names and wording. The problem should be noted and the session continued. Because they are easier, these types of discussions often substitute for ones with real content. 5. The same SMEs should participate throughout the process development. Substitutions cause a lack of continuity and can be the source of inefficiency and unnecessary controversy. This rule is sometimes difficult to enforce, but it needs to be forcefully addressed. 6. The map must be available in readable form as its development progresses. That can be accomplished via paper or projection. Pattern recognition is an important part of the map development, and the current state of the map is necessary to provide the means of that type of informal analysis. 7. Develop the map as a flat, one-level diagram. Do not utilize a decomposition procedure, such that there is a series of maps, each with increasing detail. Although the flat-map principle is controversial, the author feels that the advantages far outweigh the disadvantages (e.g., map size). § Specification of a high-level map with supersteps that represent other steps in a lower level map can hide a significant amount of the detail necessary to determine if the process map adequately represents the process. § It facilitates use of the human ability for pattern recognition. § Coordinating all the maps needed for a given process can require a significant amount of configuration management time. § Deciding the appropriate number of levels can evoke considerable discussion and is an unnecessary distraction. § Maintaining a consistent level of abstraction throughout the map is facilitated. § It is easier to apply the analysis rules outlined in this and later chapters. Depending on complexity, development of the process map can take several weeks. It is not desirable to force the sessions to an early conclusion, because the result represents the basic requirements of the resultant implementation (both manual and automated functions). Once the process map had been specified to the satisfaction of the business SMEs, the map (requirements) is considered to be sufficiently complete and stable so that the design and implementation effort may continue. It is, of course, almost certain that changes to the requirements will become evident at subsequent spirals and steps in the methodology. When that occurs, step 1 will be revisited, so the changes can be accommodated and agreed to by all stakeholders. 18.3.2 Process map structure To facilitate the following discussion, a continuing example is used based on the process map shown in Figure 18.1. The map provides an adequate degree of complexity while not overburdening the reader with detail. Figure 18.1: Example of a process map. The process map represents the process by defining the functionality or activities of a set of discrete steps. The steps are placed in precedence order by connecting lines that indicate the allowable paths through the process. The steps are placed on the map in rows; each row represents a role that has been assigned to perform the activities of that step. A step cannot be in two rows (roles) simultaneously. An organization may also be assigned to the rows as shown, but that is an optional designation and is not needed for the proper functioning of the step. In many cases, the order of the steps is somewhat artificial and could be changed without affecting the operation of the process. From an implementation perspective, such changes sometimes are necessary for efficiency or because of the availability of information. As a part of the map structure, each step must have the associated information flows defined. The flows represent the information needed to perform the defined activities of the step and should conform to the models and principles presented in Chapter 11. The direction of each flow must be indicated, along with the datastore that is the source or sink for that information. The datastore could also be cluster store when the data are not persistent. Incorporation of information flows into the map is illustrated in Figure 18.2. Figure 18.2: Step information flows. In Figure 18.2, the information flows are shown by the thick lines at a 45-degree angle to the step, and the arrows indicate the direction of the flow. The numbers indicate the identification of the flow. The datastore names have been omitted for clarity. Even with that omission, the diagram is getting quite crowded and difficult to read, which is why it is suggested that the information flows be documented separately from the map. If too many information flows are defined for a step, the step should be partitioned to reduce the complexity. As a rule of thumb, if there are more than four different data flows, the step should be split. Such a split will not change the implementation but should make it easier to understand the process from the business perspective. In the example map, there are no places where that needs to be addressed. Once the information flows have been determined, it is possible to analyze the complete structure to determine its consistency. 18.3.3 Consistency checks Two checks are part of the initial consistency examination. The first is to determine if the outputs of each step are used later in the process and if not, where and why they are needed. The second check is to determine if all the information needed in a step is available when that step is reached. The first check is relatively easy to perform on a static basis using a dataflow (information flow) diagram. The second check requires the use of scenarios and animation techniques and must be performed on a dynamic basis (addressed in Section 18.4). The output information analysis is accomplished by reordering the steps according to the availability of the information in the information flows. If information is available from sources other than previous process steps, it will not alter the map structure for the purposes of this analysis. The resultant step reordering for the example is shown in Figure 18.3 and is a form of the classical dataflow diagram (precedence is based on data availability). Figure 18.3: Diagram of step information flow. Figure 18.3 illustrates some problems that might become evident during this analysis. Process steps 2 and 12 do not appear to have successor steps from an information perspective, and there is no indication that they are end steps. Other potential problems, which are not illustrated in the figure, could be steps in an order different from that shown on the original process map or steps that are precedence connected but should not be. There may not be a problem associated with any of those constructs, but they do indicate areas that need to be investigated. On the basis of a reexamination of the specified information flows and discussions with the SMEs as to the intent of the steps in question, any questionable areas should be considered and changes made as necessary. In this case, it is discovered that some information flows are indeed missing and that process step 2 should precede step 6, and step 4 (not 12, as might be assumed at first glance) should precede step 11 from an information perspective. The information flows that were added may have been inadvertently left out, or an activity necessary for the step may have been omitted along with its needed information flow(s). Note that step 12 still does not have a successor step. That may be because IF6 is used in another process and is not needed in this process. The step information precedence diagram is then updated by adding the three missing information flows. That results in the diagram in Figure 18.4, which would then be used for any additional analysis. The added flows also would be reflected in the original process map, which is the basis for the ongoing implementation. That is shown in Figure 18.5, where asterisks indicate added flows. Figure 18.4: Updated step information flow diagram. Figure 18.5: Revised process map. In addition to the information flow changes, some steps in the original process map also may be reordered to agree with the information flow reordering, if the SMEs deem that doing so is appropriate (e.g., step 3 performed before step 2, as permitted by the information flows). For the purpose of the example, it is assumed that the original order of the steps remains. This type of analysis may need to be repeated several times during the map specification. Any change may give rise to other changes, and long cascades of changes are not uncommon during step 1 (or other steps of the methodology). 18.4 Prototype A process prototype is utilized as an aid to verify the business requirements represented by the process map. The prototype is an embodiment of the map along with the [...]... partition information Timebreak partitions must conform to the appropriate rules Update the repository as required 5 Identify all convenience partitions in the process map Mark each partition with a unique identifier that includes the previous partition information Convenience partitions must be documented as to the reasons for their definition Update the repository as required 6 Specify final partition... transition partitions in the process map Mark each partition with a unique identifier that includes the previous partition information Input transition partitions must conform to the appropriate rules Update the repository as required 4 Identify all timebreak partitions in the process map This activity requires significant knowledge about the intent of the process Mark each partition with a unique identifier... partition with a unique identifier Organization partitions must conform to the appropriate rules Update the repository as required 2 Identify all role partitions in the process map Mark each partition with a unique identifier that includes the organization partition information Role partitions must conform to the appropriate rules Update the repository as required 3 Identify all input transition partitions... partition information Investigate each resultant lowest level partition to ensure that it meets the rules specified for the final partitions A lowest level partition is any partition that has not been split into additional partitions 7 Define each lowest level partition to be a dialog This task is merely an administrative one, but it does signify the transition from a purely business- based view of the process. .. operation of the process when it is implemented 19.3.2 Role partitions Once the organization partitions have been identified or determined not to be useful, the process steps are partitioned by role These partitions conform to the rules for all partitions and a rule that states that role partitions cannot cross role boundaries A role partition is the fundamental partition, all other partitions are refinements... number of steps that can be performed by a single role without transitioning to another role Figure 19.2: Example of role partitioning 19.3.3 Input transition partitions Each role partition is then partitioned to agree with the following input transition rule: A transition into a partition can occur to only one given step that is defined to be the initial step of the partition An exemption to this rule... executed Information developed in prior steps may be of use in the reinvocation of this step § Process prototype; § Scenario definitions; § Process step operational information; § Other applicable information gathered during process definition All that information should be available from a repository used to contain all the information identified during the development of the process and any preceding process. .. them That means it is not necessary to perform PS9 immediately after PS8 In fact, different role per- formers could perform each step, depending on the specifics of the process parameters, the circumstances or the business event initiating the instance, and the eventual workflow design Figure 19.4: Example of timebreak partitioning 19.3.5 Convenience partitions Partitioning is performed for convenience... additional details and analysis The information may indicate that further refinement of the process and its representation is necessary Chapter 20: Step 3: Specify actions 20.1 Purpose Step 3 activities decompose the process steps in each dialog into atomic units of business functionality These atomic units are the business actions (defined in Chapter 13) required to perform the specified functionality... guidance or background information in addition to those items explicitly listed in this section § Process map with marked dialogs; § Dialog map; § Scenarios; § Data elements from logical data model; § For each dialog: o Unique identifier; o Functional description; o Initiation criteria; o Initial operational specifications as available: performance, security, throughput, number of performers and assignment . results if performed) should be sufficient to demonstrate the suitability of the process definition and the ability to proceed. 13. Enter process map specifications into repository. All information. Example of role partitioning. 19.3.3 Input transition partitions Each role partition is then partitioned to agree with the following input transition rule: A transition into a partition can occur. of timebreak partitioning. 19.3.5 Convenience partitions Partitioning is performed for convenience using the following criterion. A partition may be split into smaller partitions when there