Business Process Implementation for IT Professionals phần 10 ppt

24.3 Description The workflow implementation is based on the development of a logical model and a physical model that incorporate the characteristics of the business process, workflow en

24.3 Description

The workflow implementation is based on the development of a logical model and a physical model that incorporate the characteristics of the business process, workflow enactment products, the computing infrastructure, and the workforce that will perform the tasks The design of the models forms most of the activities in step 6 Once the models have been completed, the remainder of the step is concerned with programming the workflow engine and testing the configuration using the scenarios

Because the workflow is not concerned with the internals of the tasks, initially each dialog can be considered to be a task The issue then is to determine which tasks can be combined for the purpose of the workflow implementation In making that determination,

it is useful to note two differences between tasks and dialogs:

§ Tasks can have more than one entry point The particular entry point is selected by the workflow instance information available at task start time

§ Tasks can have more than one role performer That means the transition between roles does not necessarily imply a timebreak and a given

member of the workforce can perform multiple roles as required

Other characteristics generally are the same for both tasks and dialogs If dialogs are to

be combined into a larger task, there must be no need to track the transition from one dialog in the task to another If such a need exists, the dialogs cannot be combined

An example of a task being defined from multiple dialogs is illustrated in Figure 24.1, which shows a portion of a dialog map In that example, D2 is defined as a separate dialog from D1 because it has an input from other than D1 D3 is an independent dialog because it is in a role different from that of D1 D4 is an independent dialog because it already exists, having been defined during another process implementation

Figure 24.1: Task definition

It is possible to combine all four dialogs into one workflow task That assumes that the given role conditions have been met:

§ No inherent timebreak exists between D1 and D2 (e.g., D1 is used to

take a telephone order, and D2 is used to determine the credit status and associated discount of the customer)

§ The human user is capable of performing both roles

In addition, there must be no need for the workflow service to track the ending of D1 and the start of D2

If tasks consisting of multiple dialogs are to be used, there must be some mechanism for transferring information and control between dialogs independent of the workflow

system That is accomplished by defining and implementing an infrastructure service on the task computing platform that can communicate with the termination actions of the dialog instead of using those actions to communicate with the workflow service If the platform service is designed properly and can be programmed with the identification of the dialogs the task comprises, none of the actions of a dialog has to change, regardless

of whether or not it is communicating with the task platform service or the workflow service

For reuse considerations, if multiple dialogs are combined into a task, they should not be implemented as a single dialog That may be tempting because it could eliminate the task platform service, but in the long run it is not an efficient practice

Once the tasks have been defined, a workflow map can be constructed This map is essentially the same as the dialog map except for the following:

§ Instead of dialog interconnections, task interconnections are shown

§ Instead of roles, appropriate workforce units are shown These units still can be characterized as roles if desired, but because of the possible

combination of process roles, these task roles must be considered to be

a different type of entity

An example of a workflow map is shown in Figure 24.2 A workflow map is used in the development of the logical and physical models Although similar in form to the process and dialog maps, the workflow map has some important differences

Figure 24.2: A workflow map

§ The roles (organizational work groups) are not presented in bands but

are provided by annotations to each task That format is needed because multiple work groups may be used to perform a given task, such as is the case with T0 In addition, the physical location of each work group should

be included and the same work group may be in multiple locations, such

as Organization B, which performs T2 That organization and location

information is necessary for the development of the logical model

§ The emphasis is on the task transitions, not on the performers Even

though tasks T0, T6, T7, and T8 are all performed by work group C in

Chicago, no attempt is made to show that by the position of the tasks in the map, as is the case for the process and dialog maps

§ The task map also should contain the data elements and values used to determine the transitions between tasks when there is a choice The

transition from T1 is to T2 if element W has a value greater than or equal

to 5, and it is to T5 if W has a value less than 5 That also holds true for the transition from T4 using element F

§ The task map may contain artifact tasks that are not reflected in either

the process maps or the dialog maps For example, what occurs if

element F has a value other than 0 or 1 when T4 completes? That is an obvious error condition and should be accommodated in the task map For a value other than 0 or 1, the next task is an exception-handling one

on a supervisor’s desk That requires an update of the task map but

should not require a change in the process or dialog maps, because the operating assumption is that the implementation is error free

§ Other information should be made available in the task map as available That would include such items as the task load (number of invocations

per unit time) and the QoS agreements between organizations

responsible for different tasks

The workflow map is used in the development of an example logical model in Section 24.3.4.3

24.3.2 Task environment

Figure 24.3 illustrates the position of a task in a workflow environment The interfaces between the task (dialogs) and the role performer were discussed in Chapter 23, which dealt with the human interface, and in Chapter 21, which discussed action mapping The other interfaces are specific to the workflow environment and need further explanation

Figure 24.3: Task workflow environment

In general, all information exchanged between the workflow service and the task goes through the workflow client The client represents the workflow service on the platform where the task is resident For improved clarity of discussion and to avoid an unduly complex figure, direct interfaces are shown for status information and instance data exchanges

Status information is exchanged between the task and the workflow engine that is responsible for tracking the state of each workflow instance The information consists of

at least the following:

§ The ID of the user assuming responsibility for the task;

§ Time responsibility is assumed;

§ Time of completion;

§ Completion status (normal or error)

The workflow client selects an available workflow instance task from the task list either automatically according to some predetermined criteria or under guidance of the user as indicated by the client-user interface In the latter case, the client must contain a human interface that facilitates the manual task selection The software needed to execute the task is launched automatically by the client through the use of the facilities available from the platform infrastructure (e.g., operating system calls) The initiation is indicated by the client-task interface and is specified during the development of the physical model (described in Section 24.3.4.4)

In many cases, the client must also be aware of the termination of the task For example,

it may need to add the task back to the user task list for later processing when additional information becomes known to the user (probably through a paper mechanism) This type of task termination (suspension) is quite common It also might be necessary to assign the task to another performer if, for some reason, the original performer is unable

names as needed The updated instance data are then available to the remaining tasks Defining this type of data mapping is also part of the development of the physical model

24.3.3 Engineering guidelines

The initial guidelines for the design and development of a workflow implementation are presented in this and the following sections The specific recommendations are based on current practice and projections as to the probable evolution of the technology Their real value, however, is an indication of the types of considerations and analysis that must be performed to realize an effective workflow implementation

§ Use a single workflow system, if possible

§ Do not assign more than 100 users to a workflow engine

§ Do not assign more than 10 distinct processes to a workflow engine

§ Avoid partitioning a process across workflow engines, if possible

§ If the load requires more than one workflow engine, run the entire

process in each engine and split the users between them

§ Some code may have to be written to utilize product APIs for

incorporating legacy systems, worklist management, and desired human interfaces Do not be intimidated by this need In many ways, it can be a strength, not a weakness

§ Before beginning the workflow design, make sure the process to be

implemented has been defined in sufficient detail, including activities,

data, roles, organizations, and measurement metrics If not, a return to step 1 and the process spiral is indicated

It may not always be possible to conform to all those guidelines in developing a specific design If that is the case, careful attention must be paid to the testing of the workflow to ensure that it will operate as designed

24.3.4 Design considerations

There are five major considerations in the specification and implementation of a workflow service: load analysis, topology analysis, the logical model, the physical model, and the deployment procedure

Except for the deployment procedure, each aspect is examined in detail in the following sections, along with examples that illustrate the concepts The deployment aspect is addressed in Chapter 26, which considers the deployment of the entire process

implementation, including the workflow portion

24.3.4.1 Load factors

The purpose of the load analysis is to determine the major load factors for use in the logical model design step Three load factors must be estimated for each complete workflow If different portions of the workflow have significantly different values in any of the factors, they should be documented independently The reason for this will become clearer during the topology analysis Table 24.1 lists some examples of load rules

Table 24.1: Examples of Load Rules

Number of simultaneous workflow

instances

<50 50 to

100

>100 Number of tasks in the workflow <20 20 to 40 >40 Percentage of tasks needing

24.3.4.2 Topology analysis

Activities of the workflow are partitioned according to geographical location or

organizational unit The sequencing of activities between them is also determined in this analysis For purposes of this discussion, the following assumptions are made

§ Different organizational units and geographical locations are relatively independent of one another for the purposes of workflow design and implementation

§ Individual workflow activities are always performed in one

organizational unit Independence in this context implies that each organizational unit or location requires its own workflow engine because of administration and other needs that must be met on an individualized basis If this need for independence is not necessary in

a particular circumstance, the locations or organizational units should

be combined for the purpose of the following analysis

Figure 24.4 illustrates three different types of topology constructs The circles represent all tasks assigned to a location or business unit for a given workflow The entire workflow map should be analyzed for each occurrence of those constructs In most cases, the map is easily partitioned into a small set of the topological constructs

Figure 24.4: Types of topology constructs

If all the tasks for a workflow map can be assigned to a single location, organizational

unit, or task role, the map is said to be a simple linear construct, as is the case for the

first diagram in the figure Other linear constructs can be formed from either a sequence

or a parallel flow, as illustrated in the other diagrams of the linear flow section of Figure 24.4 If there is a feedback path somewhere in the workflow map, the construct is called

a feedback flow The flow constructs can be combined to define a workflow that is sometimes referred to as a combination flow

24.3.4.3 Logical model

The results of the load analysis and topological analysis can now be used to determine the configuration of the logical model That is accomplished by first defining a series of simple configurations, as shown in Figures 24.5 through 24.8 Each configuration has an associated series of rules whose applicability can be obtained from the results of the two analysis steps given in Section 24.3.4.2 The rules determine under what circumstances that configuration is applicable As necessitated by the workflow map, the simple

configuration diagrams can be combined to form a more complex one

Figure 24.5: Single-engine configuration

Figure 24.6: Two or more load-sharing engines

Figure 24.7: Two or more chained engines

Figure 24.8: Hierarchical engine configuration

After those rules have been applied to a workflow map, the basic topological constructs

of the workflow are obtained The results of the topological analysis for the workflow map

in Figure 24.2 are shown in Figure 24.9 The only concern of this analysis is the

transition from organizational unit to organizational unit or from geographical location to geographical location Note that each transition in the figure is to a different organization

or location Along with the load data, that provides the information needed to define the logical model

Figure 24.9: Topology analysis example

The logical model obtained from the workflow map in Figure 24.2 and the topological analysis shown in Figure 24.9 is presented in Figure 24.10 For the purpose of this figure, because only a small number of tasks are shown, it is assumed that the load can justify the number of individual engines indicated The major design feature indicated by this design is the use of a workflow engine that serves as a manager of several other engines That was indicated because of the complexity of the interactions, as shown in the topology analysis Other designs also could have been utilized, depending on the exact load data, the capabilities of the products that will be used in the physical model, and the experience and knowledge of the designer

Figure 24.10: Example of a logical model

As indicated in Section 24.3.3, the simplest logical model configuration possible should

be used However, for large, complex processes with heavy utilization and participation

by many organizational units, that is not always possible The approach presented here

is applicable whether a simple result or a complex one is needed

For simplicity, the load-sharing engines can be combined into a single box and labeled a

workflow enactment service That makes the diagrams easier to follow when a large

number of instances are required Thus, in all logical model diagrams, boxes can be labeled as workflow enactment services which consist of one or more load-sharing managers, depending on the number of simultaneous instances required

24.3.4.4 Physical model

The physical model is produced by programming the selected workflow engine with the process, dialog, and workforce information in accordance with the configuration of the logical model Some of the information needed for the physical model, such as the names and locations of the dialog functionality, are not known until step 7, when all the parts of the development are assembled During the initial invocation of step 6, unknown functionality can be “stubbed” until it has been specified in later steps Subsequent invocations of this step receive most, if not all, of the functionality information

Because the physical model can be implemented in a test environment prior to actual deployment, it is not necessary at this time to integrate the workflow products with the production computing infrastructure That will be accomplished during the deployment phase in step 8 However, the physical design should always be performed with the eventual deployment environment in mind

24.4 Prototype

The prototype in step 6 is the workflow prototype, which is the implementation of the workflow physical model into the selected workflow product set with the task functionality stubbed in an appropriate fashion The purpose of the prototype is to animate the

workflow using the scenarios to determine if the workflow definition meets the intent of the original business process

The operation of the prototype would be of interest to the business and technical

stakeholders as an overall indication of how the business process implementation will operate

24.5 Activities

The 11 activities in step 6 are listed according to the sequence diagram in Figure 24.11 All the activities in this step are oriented toward the implementation of a workflow that will meet the intent of the original business process This step will be revisited whenever it is determined in a succeeding step that some change needs to be made in some aspect of the workflow definitions

Figure 24.11: Activity sequence diagram

The following are brief descriptions of each of the individual activities needed to produce the results expected from this methodology step All these activities must be considered whether step 6 is being invoked for the first time or as a result of a change in another step If it is being revisited, many of the activities will be very simple and fast They cannot, however, be skipped because there is always the chance that they will be needed to respond to the change

1 Define tasks using the dialog map Use the dialog map as a base to

determine which, if any, dialogs can be combined into workflow tasks If dialogs from different process roles are combined, new workflow roles

have to be defined to accommodate the merged responsibilities

2 Create a workflow map After the tasks have been defined, a workflow

map can be defined The workflow map serves as the vehicle for defining the operational characteristics of the tasks and the workforce that will

perform them It is also used to program the workflow engine with the

sequence information

3 Perform a load analysis Determine the amount of activity that each task

must support The load analysis is used to help determine the logical

model of the workflow implementation

4 Perform a topology analysis Examine the workflow map for topological

structures that will help determine the logical model of the workflow

implementation

5 Define a logical model The logical model contains the structure of the

workflow engines used in implementing the process The logical model also indicates the tasks supported by each workflow engine, their

geographical location, and the organizations supported

6 Define task list processing for each workflow role There are many ways

that the next task to be addressed can be selected from those available for a given role The most common way is to allow the role performer to select the task from a list displayed by the workflow client Another

possibility is to automatically select the next task using the task

characteristics and predefined business rules that contain the selection criteria Some workflow clients allow a great deal of flexibility in selection, while others require a significant amount of custom programming

7 Develop a physical model Program the selected workflow products using

the logical model and the workflow map as the main inputs If multiple

workflow engines are required, they need to be connected using the

same protocols that would be used in the deployed configuration The

same network configuration does not have to be used, however As part

of the engine programming, access to the required task and external

functionality needs to be defined The functionality does not need to be integrated if it is unavailable or if immediate access is cost prohibitive

However, a configuration as close to the one that will be deployed is

desired

8 Animate the workflow prototype using the scenarios Once the physical

model has been implemented, it becomes the workflow prototype The

scenarios are used to animate the prototype and ensure that the

workflow reflects the intent of the original business process This type of testing can also find problems with either the logical or the physical

model so they can be corrected before the integration phase

9 Demonstrate the workflow prototype to stakeholders Arrange a

facilitated 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 step 6, the stakeholders must determine if the workflow

definitions, functionality, and relative sequences meet the needs of the

business process being implemented

10 Obtain necessary approvals If approvals are needed to continue beyond

step 6, they need to be obtained before proceeding The workflow

prototype, the opinions of the stakeholders, and the hard deliverables

from this step (task specifications, workflow map, logical model, physical model) should be sufficient to demonstrate the suitability of the action

definitions and the ability to proceed

11 Enter new or updated workflow specifications into repository All

information obtained as a result of step 6 should be entered into a

repository where it is available for future needs Because maintenance is considered an integral part of the methodology, this information may be needed for a considerable length of time and may be useful to individuals other than those involved in the initial development

24.6 Linkages to other steps

Step 6 must be invoked whenever there is a needed change to any aspect of the

workflow specification Changes could result from the activities in any step of any spiral and consequently cause a direct transition to step 6 or to other steps that may be

affected (e.g., step 1) before this step is reentered The exact transition sequence depends on the circumstances If the changes are relatively small, the time required for a reinvocation of this step or previous ones should be relatively quick

The usual transition to step 6 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 workflow definition The definition of the actions also can have

a significant effect on the design of the workflow Therefore, step 6 should be reinvoked after step 3 has completed, to consider any possible effect on workflow definition Changes in actions concerned with error recovery, for example, could affect the design

of the workflow even if the definitions of the process dialogs remain unchanged

If the results of step 6 do not require the business processes or dialog definitions to be reexamined, the normal transition from this step is to step 7, where all the individual parts of the development are integrated and assembled into a working implementation

If step 6 raises questions concerning the process map or dialog definitions, then a

transition to step 1 must be made and the process spiral reiterated until those questions are resolved

24.7 Postconditions

Step 6 is completed 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 logical and physical models (prototype) of the workflow have been

implemented and are available for demonstration

§ Appropriate animation of the workflow prototype using the scenarios has been

performed and the results verified

§ The business and technical stakeholders have been involved as needed

§ All relevant workflow information has been entered into the appropriate

repository and updates verified

§ All necessary approvals have been obtained

At the normal conclusion of step 6, all affected business and technical stakeholders must agree that the workflow, as it is currently defined and represented, is the best that can be accomplished prior to actual use As necessary, changes may be made after the

implementation and improvement spirals have been invoked as additional information is obtained

Selected bibliography

Basu, A., “Metagraph Transformations and Workflow Analysis,” Proc 30th Hawaii Internatl

Conf System Sciences, Wailea, HI, Jan 7–10, 1997, Vol 4, pp 359–366

Gokkoca, E., et al., “Design and Implementation of a Distributed Workflow Enactment

Service,” Proc 2nd IFCIS International Conference on Cooperative Information Systems,

Kiawah Island, SC, June 24–27, 1997, pp 89–98

Karnath, M., and K Ramamritham, “Failure Handling and Coordinated Execution of

Concurrent Workflows,” Proc 14th Internatl Conf Data Engineering, Orlando, FL, Feb 23–

27, 1998, pp 334–341

Kwan, M M., “Dynamic Workflow Management: A Framework for Modeling Workflows,” Proc

30th Hawaii Internatl Conf System Sciences, Wailea, HI, Jan 7–10, 1997, Vol 4, pp 367–

376

Orwig, R., D Dean, and L Mikulich, “A Method for Evaluating Information Systems from

Workflow Models: Results from a Case Study,” Proc 31st Hawaii Internatl Conf System

Sciences, Wailea, HI, Jan 6–9, 1998, Vol 4, pp 322–331

Schuster, H., S Jablonski, and C Bussler, “Client/Server Qualities: A Basis for Reliable

Distributed Workflow Management Systems,” Proc 17th Internatl Conf Distributed

Computing Systems, Baltimore, May 27–30, 1997, pp 186–193

Van Der Aalst, M P., “Modeling and Analyzing Interorganizational Workflows,” Proc 1998

Internatl Conf Application of Concurrency to System Design, Fukushima, Japan, Mar 23–26,

1998, pp 262–272

25.1 Purpose

PRIME is an assembly methodology That requires an assumption that most of the functionality required to implement a process should already be available from previous developments The major need then is to assemble the process-independent

functionality with elements that provide the process-specific needs Steps 1 through 6 have shown how the functionality in the form of actions, dialogs, tasks, and reusable software components can be defined and designed so that they can be used in any process as needed The process-specific elements with which that functionality is

combined comprise the workflow, the human interface, and the infrastructure The dynamics of the assembly approach is illustrated in Figure 25.1 All the elements, both process independent and process specific, must be integrated with a computing

environment that provides the resources necessary for their operation

Figure 25.1: Assembly dynamics

The purpose of step 7 is to take all the elements that have been defined and developed

in steps 1 through 6 and assemble them into a complete structure that:

§ Provides an effective implementation of the original business process;

§ Can be managed so it continues to meet the needs of the business as

changes are encountered;

§ Has a form that can be efficiently deployed into the enterprise computing

environment

An effective assembly procedure should resemble the construction of a jigsaw puzzle All the pieces should have a form that fits with the form of the connecting pieces There should be no need to force-fit any piece, nor should there be any need to reshape a piece The picture that results when the puzzle is completed is independent of the shape

of the puzzle pieces If the parts being assembled are structured (formed) properly, they should go together easily, regardless of the process (picture) being implemented

Steps 1 through 6 have produced parts with the proper structure Step 7 puts them all together and produces an implemented process

25.2 Preconditions

The following items are required to be available before work on the activities in step 7 can be initiated It is assumed that any result from an earlier step or spiral can be used to provide guidance or background information

§ Human interface design;

§ Workflow design and prototype;

§ Task specifications;

§ Action specifications;

§ Dialog specifications;

§ Mapped external software components;

§ Databases utilized;

§ Internal software components needed by the actions;

§ Computing test environment;

§ Scenarios

25.3 Description

The assembly activities are similar to the functions performed in traditional system integration when all the software modules are brought together and integrated with the platform hardware and systems software, databases, and the communications network The major differences are in the types of entities utilized, the order in which integration occurs, and the action that is taken when a problem is encountered

25.3.1 Integration elements

In step 7, the elements being integrated are the actions, dialogs, tasks, workflow, and infrastructure services; integration occurs in approximately that order As necessary, each element must be assembled from its component parts before being integrated with the other entities into the automation environment The automation environment forms the framework on which integration occurs If a problem is encountered in any of the assemblies or integration into the automation environment, the reason must be

ascertained and the appropriate methodology step invoked to provide a solution That could be any previous step, since a problem with the business process map or any other specification easily can be encountered at this point

The use of previous steps to formulate the changes necessary to fix problems

encountered during integration automatically ensures referential integrity between all the development entities, from requirements to implemented software In addition, it provides

a structured way to ensure that all the ripples caused by a change are addressed The effect of even a seemingly tiny change can be considerable and produce a complex progression of other changes needed to compensate all the interwoven parts

Maintaining the integrity of the development components as changes are made in the later stages is a major problem in current methodologies, because that aspect generally

is not considered part of the methodology That leaves regression testing as the major way to determine that the changes do not have unexpected side effects, which is

inefficient and considerably less effective than using PRIME PRIME provides

component integrity as an integral part of the methodology

It is not the intent of this presentation to prescribe exactly how these assembly activi ties are to be defined or performed That depends on the personnel and tools utilized The main object is to illustrate that the components can be integrated in a reasonably efficient manner and that an assembly methodology provides capabilities that do not exist in other types of methodologies

Figure 25.2: Automation environment elements

§ The enterprise computing infrastructure provides the interconnectivity

between all the platforms that must communicate with each other and the common services such as transaction management, security, and

database management systems, directory, and systems management

resident on infrastructure servers

§ The client platform hardware and system software provide the

environment for software that is resident on the client platform and

includes the computing hardware, operating system, file structure, and

human interface devices and drivers

§ The action execution environment provides the environment for

executing the actions in accordance with the rules defined in Chapter 13 Each dialog has an associated action execution environment

§ The dialog execution environment provides the environment for

executing and controlling the cluster of dialogs and includes the cluster store and control, a means for activating appropriate sets of actions as

defined in Chapter 20, and the means for controlling the human interface

§ The task execution environment provides the means for integrating

multiple dialogs into tasks and includes the means for transitioning

between dialogs without invoking the workflow engine

§ The workflow environment provides the means for transitioning between

tasks using the rules and task map programmed into a workflow engine

It also includes the workflow client, monitor, and alert/alarm mechanism

§ The application server platform hardware and system software provide

the environment for software that is resident on the application server

platform and includes the computing hardware, operating system, and

file structure

§ The external software components provide the means for accessing

reusable functionality using predefined message pairs as specified by the actions The characteristics needed for this type of software were

outlined in Chapters 14 and 22

All the computing environment elements are process independent and can be used to implement any process All of them must be designed from a system engineering

perspective so they interoperate properly and provide an effective means for process implementation

There generally are two different implementations of the computing environment One is

for initial integration and testing purposes and is referred to here as the test environment

The other is utilized for deployment and production operation and is referred to as the

operational environment Step 7 uses the test environment Step 8 (Deploy and operate),

described in Chapter 26, uses the operational environment Both environments,

however, should consist of the same types of elements, although the number of

individual elements and their configuration may vary, depending on circumstances

25.4 Prototype

In step 7, the prototype is the implemented process produced by the assembled

components integrated into the test environment It is a prototype in the sense that it exists in a test environment and not in the operational environment However, the test environment mimics the characteristics of the operational environment That facilitates the deployment of the system and ensures that the initial assembly is compatible with the deployed implementation

25.5 Activities

The nine activities in step 7 are arranged according to the diagram in Figure 25.3 The activities can be performed either manually or automated with an appropriate tool, if available However, it is strongly recommended that automated tool support be used because it greatly increases the effectiveness and efficiency of the activities

Figure 25.3: Activity sequence diagram

The following are brief descriptions of each of the individual activities needed to produce the results expected from this methodology step All these activities must be considered whether step 7 is being invoked for the first time or as a result of a change in another step If it is being revisited, many of the activities will be very simple and fast They cannot, however, be skipped because there is always the chance that they will be needed to respond to the change

1 Assemble all actions into the test environment That is accomplished by

linking the dialog units defined for each action into the action execution environment of the associated dialog This environment also provides a means for individually executing an action so its operation can be

verified That requires that access is available to the building blocks and capability units specified by the action If that cannot be accomplished

immediately, stubs can be utilized until the actual functionality is

available

2 Assemble all dialogs into the test environment That is accomplished by

linking each dialog, which consists of the means for activating its set of actions, to the cluster store and control forming the dialog execution

environment They also must be linked to the human interface

implementation through the client platform environment functionality If

an automated dialog is involved, it can be implemented on a server

platform instead of a client platform In that case, except for the human interface, all the elements shown for the client platform are still needed

3 Assemble all tasks into the test environment That is accomplished by

linking the dialogs defined for a task into the task execution environment, which provides the means for transitioning between dialogs without

invoking the workflow engine

4 Assemble the workflow into the test environment The workflow engine is

programmed with the task map information, workforce characteristics,

and associated rules It is linked to the tasks through the workflow client

5 Assemble the infrastructure services into the test environment These

include the services indicated in Section 25.3.2 The assembly is

accomplished by specifying actions that interact with those services If

the use of the services is not anticipated when the actions are specified

initially, they must be added now That requires a return to step 3

(Specify actions) to properly include the actions into the dialog

specification

6 Test the implementation using the scenarios Animate the test

environment process implementation using the scenarios Verify that the implementation conforms to the intent of the original (or as modified

during development) process description If this agreement is not

adequate, then either the process description or the implementation must

be altered in some way to achieve conformity Depending on the analysis

as to what needs to be changed, the appropriate step and spiral are

invoked

7 Demonstrate the implementation to stakeholders Arrange a session with

the stakeholders to observe the operation of the implementation and

determine if their needs are being adequately met At the end of step 7, the stakeholders must agree that the implementation is suitable and that deployment can take place Although this may not be considered a

formal acceptance test based on the deployed implementation, all the

same conditions apply Unless unusual circumstances arise, if this

activity completes with no changes indicated, the formal acceptance test should pass without difficulty

8 Obtain the necessary approvals If approvals other than stakeholder

agreement are needed to continue beyond step 7, they need to be

obtained before proceeding The process implementation response to

the scenarios and the opinions of the stakeholders should be sufficient to demonstrate the ability and desirability to proceed

9 Enter results into repository All information obtained as a result of step 7

should be entered into a repository where it is available for future needs Because maintenance is considered an integral part of the methodology, this information may be needed for a considerable length of time and

may be useful to individuals other than those involved in the initial

development

25.6 Linkages to other steps

Step 7 must be invoked whenever a change has been made to the speci- fication of any action, dialog, task, workflow, or utilized computing environment element The usual transition to step 7 is directly from step 6, where the workflow is identified and specified Transitions also can be made from step 4, where the actions are mapped to software components, and step 5, where the human interface is developed, if identified changes require that only those steps be reinvoked However, step 7 cannot proceed until all the components that must be integrated are available in their updated form

The step completion transition from this step is to step 8, where the implementation is deployed and placed into production operation If the step requires changes of any type,

a previous step and spiral, depending on the nature of the change, must be invoked Consideration of changes may require many iterations of previous spirals Some of those may proceed in parallel if they address somewhat different areas There may be many changes of different types needed before the results of step 7 can be considered

satisfactory and the step completed Eventually, all the changes must come together in this step, where their compatibility can be determined

25.7 Postconditions

Step 7 is completed 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

§ A complete implementation of the process in the test environment is available

§ Appropriate animation of the implementation using the scenarios has been

performed and the results verified

§ The business and technical stakeholders have been involved in the testing

process as required

§ All relevant implementation information has been entered into the appropriate repository

§ All necessary approvals have been obtained

At the normal conclusion of step 7, all affected business and technical stakeholders must agree that the operation of the process implementation meets the needs of the business and complies with the intent of the original process specification (as amended) and is the best that can be accomplished with the current degree of knowledge As necessary, changes may be made after the improvement spiral has been invoked as additional information is obtained

26.1 Purpose

The main purpose of step 8 is to extend the methodology over the entire life cycle of the process That enables the same approach to the maintenance of the process as was used in its initial development By combining the development and maintenance aspects, the inevitable changes to the process are facilitated Changes to the process use the same activities and approach as the initial development

Step 8 also contains the activities necessary to deploy the process to achieve

operational status After that has been achieved, other activities determine when a change to a process is necessary The approach utilized is discussed here in some detail and using a series of examples

26.2 Preconditions

The following conditions are required to be available before work on the activities in step

8 can be initiated It is also assumed that any result from an earlier step or spiral can be used to provide guidance or background information

§ Process implementation that is successfully running in a test environment and that has been approved for deployment;

§ Operational profile of the implementation that includes:

o Expected availability of the system;

o Duration of background processing;

o Percentage of online-versus -background processing;

o Average transaction load expected;

o Peak transaction loads expected;

o Expected size of databases;

o Backup needs;

§ Deployment schedule;

§ Documentation and training needs for users and operational personnel;

§ Designated infrastructure (hardware and software) in place and available