a fine-grained process modelling experiment at british airways

SOFTWARE PROCESS—Improvement and Practice, Vol. 3, 105–131 (1997)

A Fine-grained ProcessModelling Experiment atBritish Airways†

Jim Arlow1, Sergio Bandinelli2, Wolfgang Emmerich3*,and Luigi Lavazza4

1British Airways Plc, TBE (E124), Viscount Way, Hounslow, UK Research Section2ESI, Parque Tecnologico, 204, 48170 Bilbao, Bizkaia, Spain3City University, Computer Science, Northampton Square, LondonEC1V 0HB, UK4Politecnico di Milano and CEFRIEL, Via Emanueli 15, 20126 Milano,Italy

We report on the experimental application of process technology that we did at BritishAirways (BA) as part of the GOODSTEP project. The goal of GOODSTEP was to enhanceand improve the functionality of an object database management system (ODBMS) to yielda platform suited to the construction of process-centred software engineering environments(PSEEs). These enhancements were exploited and validated by the construction of theGOODSTEP framework for PSEE construction, which includes the SPADE software processtoolset. We used the process modelling language SLANG to model BA’s C11 class librarymanagement process, and we constructed an experimental PSEE based on SPADE. BArequired processes to be automated at a finer degree of granularity than that of toolinvocation. We have demonstrated that SLANG and SPADE offer the basic mechanisms formodelling these fine-grained processes. We have also shown that it is feasible to generatetools for dedicated processes and integrate them within a SLANG model so as to facilitatefine-grained process automation. However, our experience highlighted some open problems.For instance, SLANG process models are tuned to efficient enactment, thus containing verydetailed process fragments. These are not the most appropriate representations for humanstrying to understand the process model. Although the airline did not deploy the PSEE in itsproduction environment, the experiment proved beneficial for BA because the modellingactivity itself uncovered serious flaws in the existing process. 1997 John Wiley & Sons, Ltd.

Softw. Process Improve. Pract., 3, 105–131 (1997)

No. of Figures: 13 No. of Tables: 0 No. of References: 46

KEY WORDS: software process modelling experiment; process-centred software engineering environment

†This work has been partly funded by the CEC within ESPRIT-III project 6115 (GOODSTEP). The work was done while W.*Correspondence to: Wolfgang Emmerich, City University,

Computer Science, Northampton Square, London EC1V 0HB, Emmerich was with University of Dortmund (Germany), andS. Bandinelli was with CEFRIEL (Italy).UK. e-mail: weKacm.org

CCC 1077-4866/97/020105-27$17.50 Contract grant sponsor: CECContract grant number: ESPRIT III project 6115 (Goodstep) 1997 John Wiley & Sons, Ltd.

Research Section J. Arlow, S. Bandinelli, W. Emmerich and L. Lavazza

who is in charge of maintaining the design,1. INTRODUCTIONimplementation and documentation of reusableC11 class libraries. SLANG was used to capture,During the past decade, a great deal of research

has been devoted to process technology. Process model and improve the class library developmentand maintenance process.modelling languages have been defined in order

to specify software processes on a formal basis. The process was not only modelled, but alsosupported with a customized PSEE, the BritishExamples of these languages are extensions to

programming languages (e.g. extensions of Ada Airways SEE. This PSEE integrates the SPADEprocess engine with tools for the development(Sutton et al. 1990) and Prolog (Peuschel et al.

1992)), Petri net based approaches (FUNSOFT of Booch class diagrams, C11 class interfacedefinitions, C11 class implementations and class(Emmerich and Gruhn 1991) and SLANG

(Bandinelli et al. 1993b)) and multi-paradigm documentations. These tools were generated withthe GENESIS cool construction toolset (Emmerichapproaches integrating several high-level descrip-

tions (ESCAPE (Junkermann 1995) and SOCCA et al. 1997a). The integration of tools and processmodel was done in a way that facilitates process(Engels and Groenewegen 1994)). Process model-

ling environments have been constructed for these guidance at a finer level of granularity thantool invocation.languages so as to edit, simulate, analyse, enact

and evolve process models. Examples include SPADE and GENESIS were developed in theGOODSTEP project (GOODSTEP Team 1994). TheMerlin (Peuschel and Schafer 1992). SPADE

(Badinelli et al. 1993a), Melmac (Deiters and Gruhn experiment reported here was also carried outwithin that project so as to validate the GOODSTEP1990) and Marvel (Barghouti and Kaiser 1990). A

central component of these environments is a tools. Section 2 briefly describes the GOODSTEPproject. Section 3 outlines the goals of our processprocess engine that interprets a process model. A

number of attempts have been made to build modelling experiment. It is followed by a discussionof the baseline of the experiment, i.e. the existingenvironments that, in addition to process modelling

components, include tools for the actual software process at British Airways, the BA SEE tools thathave been generated and the SLANG processdevelopment. These tools are integrated with the

process engine so as to provide services for process modelling language. Section 5 presents the waythe process modelling experiment was conductedautomation and to inform the engine about process-

relevant events that they have captured. Such and the results specific to the problems of BritishAirways. Section 6 discusses the implications ofenvironments are known as process-centred software

engineering environments (PSEEs). the lessons we learned for process modelling andprocess-centred environments in general. Finally,While development of process technology has

attracted a vast amount of effort, only a small we indicate in Section 7 open research problemshighlighted by our experience and indicate how ouramount of attention has been paid so far to the

industrial application of the facilities developed. current work contributes to the problems identified.A notable exception is Dinkhoff et al. (1994), whereFUNSOFT nets have been applied to large-scalebusiness processes in the area of real estate 2. THE GOODSTEP PROJECTmanagement. The nature of these business pro-cesses, however, is considerably simpler than those GOODSTEP (GOODSTEP Team 1994) brought

together European expertise in the areas of data-of software processes.The contribution of this paper is an account of bases and software engineering. GOODSTEP

started in September 1992 and was successfullythe experience that we gained when we appliedthe SLANG process modelling formalism and completed in November 1995. The project delivered

an advanced database management system and athe SPADE environment to the modelling andenactment of a software process in an industrial development framework for the construction and

customization of PSEEs.setting, namely at British Airways (BA). BA is alarge software developer in the UK, with some The baseline of the project was an existing

European object-oriented database product: O22000 IT staff. To increase productivity and quality,BA have founded a group called Infrastructure (Bancilhon et al. 1992). Rather than developing aSoftw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

106

Research Section Process Modelling Experiment at British Airways

new system from scratch, GOODSTEP enhancedand improved O2. The choice of an object-orienteddatabase management system as a starting pointfor the project derives from the inadequacy ofrelational database systems for engineering appli-cations, which has been recognized for some time(Maier 1989).

We have shown in Emmerich et al. (1993a) thatthe O2 product was well adapted to meeting the Figure 1. Components developed in GOODSTEPrequirements (Emmerich et al. 1993b) for storingprocess and product data of a PSEE. O2’s schemadefinition language supported the fine-grained

resided on the pages it was managing. Situationsdefinition of documents and relationships amongoccurred with small objects where the page-levelthem; O2 provided a query language and a metaconcurrency control revealed conflicts even thoughschema that are necessary primitives for thethe concurrent transactions were accessing disjointimplementation of process reflexivity (Bandinellisets of objects, just because they resided by chanceet al. 1993a); O2 also supported the transactionson the same page. Conflicts caused transactionthat are required for the preservation of integrityabortions and even deadlocks, causing loss ofof documents and process information in the faceefficiency and requiring specific code to manageof hardware or software failure and for low-levelspurious deadlocks. To avoid such conflicts, O2concurrency control. Finally, O2’s client/serverwas extended with object-level concurrency control.architecture provided limited support for distri-Concurrency control is, by default, still based onbution.page locks. As soon as a conflict occurs, however,O2, however, did not fulfil all requirements forthe concurrency control switches to object-levelthe construction of PSEEs. In order to accomplishlocking. The features of the extended version ofthe construction of SPADE on top of O2, it had toO2 delivered by GOODSTEP were extensivelybe extended with facilities for schema updates,exploited in the construction of SPADE, asprimitives for version management, and con-described in Bandinelli et al. (1995a).currency control based on objects rather than disk

These ODBMS extensions were then exploitedpages, that were used as secondary storage unit.for the development of a framework for theThe implementation of reflexive capabilities inconstruction of PSEEs of which a coarse-graineda process modelling language with a static typeoverview is displayed in Figure 1. That frameworksystem requires the ability to create new types inconsists of two components, the SPADE softwarethe database schema as well as to change existingprocess toolset with the process modelling languagetypes during the enactment of the process, possiblySLANG and the GENESIS tool construction toolset.migrating the existing instances to the new typeGENESIS includes a compiler for the GOODSTEPdefinitions, or compiling at run-time newly createdTool Specification Language (GTSL). SPADEor changed methods. Schema update facilities thatexploits the extended ODBMS for storing processaddress these requirements (Ferrandina et al. 1994,models and process states. GENESIS generates1995) were introduced in O2 by GOODSTEP andODBMS schemas and applications that are usedare now part of the O2 product.to create and modify software documents.The early phases of GOODSTEP have also

extended the O2 ODBMS with basic primitives forversion management of composite objects (Delobeland Madec 1993). This feature, which is also 3. GOALS OF THE EXPERIMENTavailable in the current O2 product version, makesprocess modelling easier and more effective. The goals for this experiment were manifold and

can be considered from the points of view ofOriginally, not only client/server communi-cation, but also concurrency control, which technology providers and technology users.

The motivation of the technology providers inimplements ACID transactions, were page-basedsince the server was not aware of the objects that this experiment was to evaluate process technology 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 105–131 (1997)

107


in an industrial setting. The goals of the experiment 4.1. Existing BA Library Development Processare reflected in the following questions:

The Infrastructure group has created a processFeasibility: Is it feasible with the language primi- handbook entitled Standard Development and Releasetives available in SLANG and GTSL (the GOOD- Procedures. It elaborates on the process to be usedSTEP Tool Specification Language) to lower the for class library development and maintenance.level of granularity of process models, in order to The handbook suggests, in a rather informalimprove process automation? manner, the various actions to be taken for classScalability: Is SLANG sufficiently scalable to handle library development and maintenance. It identifiescomplex processes such as those that occur in a number of document types, including Boochindustrial practice? Are the resulting process mod- class diagrams, C11 class interface definitions,els of any use for supporting communication C11 class implementations, class documentation,among the developers involved? Makefiles, configurations for dynamic linkage andUser acceptance: Does the resulting process model the like.provide developers with sufficient freedom to Different developers in Infrastructure have differ-express their creativity, or does it impose strict ent roles. Some developers are programmers respon-constraints that could make the development sible for implementing and documenting classesharder and less productive? in particular libraries. To date, one developer is aPerformance: Is the enactment of a fine-grained QA engineer, who is in charge of approving newprocess fast enough, or does it slow down users or changed libraries. A librarian administers themore than it helps? different versions contained in library configur-

ations.The main motivation of technology users was to Infrastructure identified two main problems withunderstand what process technology can do for their approach to process management. The firstthem. They were interested in: problem is that their informal definition of theprocess easily leads to misunderstandings. TwoProcess understanding: The Infrastructure groupInfrastructure developers, who have worked in thewanted to check whether, after having worked forsame office for two years, discovered a serioustwo years on the maintenance of class libraries, itmisunderstanding of a key concept defined in thehad reached a common (i.e. consistent) understand-handbook when we discussed their process in aing of the process.meeting. It turned out that they did not have aProcess improvement: The group knew the flaws inshared understanding of the semantics of a librarytheir process and wanted to remove them. Theyconfiguration in beta test as opposed to developmentwere curious to see how formal process modellingmode. The second problem is mentioned in thecould help.following quote from Infrastructure members:Process automation: Several tasks of the group were

done manually and the group was fascinated bythe idea that an environment customized to their ‘Within Infrastructure, we have had to applyparticular needs might automate a relevant part an excessive amount of effort to establishof the work. change control procedures, but these pro-

cedures are only partially effective as theyare not enforceable by our current toolset. AsBA’s stock of reusable components grows,4. BASELINE OF THE EXPERIMENTthe problems of effective change control willbecome more and more pronounced.’ (ArlowIn Section 4.1 we discuss the problem space, i.e.et al. 1994)the library development process to be modelled

and automated. We then discuss the technologyAn obvious approach to enforcing change controlavailable for solving the problem. In Section 4.2

we discuss the GENESIS tool generation facility procedures is to model them with a processmodelling language and to guide the process bythat has been developed in GOODSTEP, and in

Section 4.3 we discuss the facilities available in subsequently enacting the model constructed. Thisrequires development tools to be integrated intoSPADE for process modelling and enactment.

Softw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

108


the process environment in such a way that tools 4.2.1. Specification of Tools in GTSLGTSL specifications of environments use the object-cannot be abused in order to circumvent theoriented paradigm to define the tools and docu-modelled process. Moreover, the integration ofments. The use of object-oriented concepts istools and process has to be fine-grained, at leastmotivated by the fact that tool specifications canpartially, so that the process model can react tobecome considerably complex and need to bethe execution of individual tool commands, ratherproperly structured to keep such complexity man-than complete tool sessions. The reason for this isageable. Moreover, a number of properties re-that document contents defined in earlier stagesoccur in different parts of tool specifications. Usingdetermine documents to be produced in laterobject-oriented principles, these properties can bestages. In the BA process, a class icon included inspecified in abstract specification components anda Booch design requires creation of documents forare then inherited by more concrete components.a C11 class interface definition, a C11 method

Due to the heterogeneity of the different staticimplementation and class documentation. As docu-and behavioural concerns of tools, it is impossiblements are generally considered as first class processto find a unique formalism that expresses thesemodelling concepts, the process model should atconcerns at an appropriate level of abstraction.least be notified about document creation, if notInstead, we separate the different concerns andbe responsible for the creation itself. Therefore, aoffer the most appropriate formalism for each oftool command for the creation of a componentthem. We integrate these different formalisms intoof one document, for which an inter-documenta domain-specific multi-paradigm language that usesconsistency constraint requires the creation ofrule-based, object-oriented and imperative con-another document, might have to be integratedcepts.with the process model.

A GTSL environment specification is structuredWe modelled the BA class library developmentinto a number of tool configurations. Each of theseand maintenance process with SLANG. Then aconfigurations consists of a number of classes thatdedicated set of tools tailored towards the particulardefine the different node types occurring in project-needs of Infrastructure was generated. This toolset wide abstract syntax graphs (Emmerich et al.

was integrated with the SLANG process model 1993b). Different sections are provided to defineto enforce the process and to support process properties of a class such as attributes, abstractautomation at the required levels of granularity. syntax and semantic relationships. Static semantics

and inter-document consistency constraints ofdocuments are specified in a semantic rule section.The available operations to modify graph nodes

4.2. Tool Specification and Generation using are defined in a method section. The invocation ofGENESIS operations from commands and the availability of

commands are specified as patterns in interactionThe need for rapid tool construction through a sections. Multiple inheritance enables properties fromtool generator is motivated by the observation superclasses to be reused in subclasses.given above that enforcement of process definitions,such as change control procedures, require process 4.2.2. Integration Facilities in GTSLsensitive tools to be used. Process sensitive tools Tools generated from GTSL specifications can notinteract with a process model through a joint only be used through a user interface. They alsocommunication protocol, and thus contribute to offer services to their environment. These servicesthe implementation of a process model. can be used for tool integration purposes and, in

A flexible tool construction mechanism is particular, for the integration of tools with arequired to develop tools for use with particular process model. We distinguish between generic andprocess models. GTSL was defined as a high-level tool-specific services. GTSL defines about 20 genericlanguage to accomplish rapid tool customization services, examples of which are the creation of aand construction. Tools for the BA SEE have been document of a particular type, opening a particulargenerated from GTSL specifications (Emmerich et version of a document or the computation of a

printable representation of a document. Generical. 1997a). 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 105–131 (1997)

109


services are supported by any tool generated from Tool envelopes only initiate the startup of a tooland obtain the result of its execution.a GTSL specification and are implemented by the

GTSL run-time system. Tool-specific services arespecified by the tool builder. They are declared in 4.2.3. Architecture of Tools

The GTSL compiler GENESIS generates tools thattool configurations (Emmerich 1996b) and specifiedin the same style as tool commands. store the documents they work upon as composite

objects in the O2 ODBMS. Therefore the GTSLEvents allow the tool to inform the environmentabout certain incidents. An event can either be a compiler translates GTSL specifications into O2

schemas that implement the structure and therequest or a notification. A request is sent to theprocess engine, which either grants the request or operations available for objects representing

abstract syntax graph nodes. A high-level overviewrejects it. Requests are used in interactions of BASEE tools to ask the process engine for the of the tool architecture is displayed in Figure 2.

Rectangles represent processes and arrows denotepermission necessary to perform certain activities.A notification informs the receiver about a certain inter-process communication.

Tools generated by GENESIS are integrated inaction, but does not await its response.As examples, consider the service and event several dimensions. They all store their documents

in one central database server. The database isdeclarations from the Booch and INT tool configur-ations given below. The first declaration is a request exploited for data integration, concurrency control

and version management. Tools also communicatethat asks the process engine for permission tocreate a new library. The request is used in a with a Display Server to implement group editing

facilities so that users see modifications that concur-condition in the interaction that implements thetool command for creating a new library. The rent users perform with a shared document version.

Finally, tool services are invoked via the ToolTalksecond declaration is a specific service of the classinterface editor for the creation of an inheritance message server. Likewise tools communicate events

that they have detected to the external world usingrelationship between two C11 class interfacedefinitions. It is invoked from the Booch editor as that message server.soon as a user creates an inheritance relationshipin the diagram and then the relationship will also

4.3. SLANG and SPADEbe reflected in the affected C11 class interfacedefinitions. SPADE (Software Process Analysis, Design and

Enactment) is a project that was carried out atTOOL CONFIGURATION Booch; CEFRIEL and Politecnico di Milano for the purpose

EVENT of developing a process modelling language – i.e.CrLibraryRequest(name:STRING):ERROR; a language to describe software processes – and. . .

a computer-based environment supporting theEND CONFIGURATION Booch.execution of processes according to their models.

TOOL CONFIGURATION INT; . . .SERVICE CrInheritance(inh from : STRING;

visibility : STRING;virtual:BOOLEAN):ERROR;

. . .END CONFIGURATION INT.

The GTSL language and, in particular, its eventsand services are therefore powerful facilities forspecifying tools that are customized for use withparticular process models. They accomplish processautomation at a much finer degree of granularitythan the tool envelopes suggested by Valetto andKaiser (1995), because multiple events and services

Figure 2. Architecture of tools generated by GENESIScan be exchanged during the execution of a tool.Softw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

110


Two major results of this project were the SLANG the transition is enabled to fire. The action specifieshow output tokens are computed.(Spade LANGuage) process modelling language

and the SPADE-1 PSEE.Places: A place defines a template for a persistentrepository of tokens. Each place has a name, which4.3.1. Specification of Process Models in SLANG

We restrict ourselves to a rather concise description is a unique identifier within the activity, and atype (which has to be a subtype of the predefinedof SLANG, as the main purpose of this paper is

to describe the experience of using SLANG. A class Token). A place can only contain tokens ofits class type (or of any of its subclasses).more detailed account of SLANG is provided in

Bandinelli et al. (1993a, 1993b, 1994).SLANG is a high-level Petri net language that Arcs: SLANG offers different kinds of arcs, with

intuitive semantics: normal arcs, represented byhas been adapted for software process modelling.Transitions (represented as rectangles) model solid lines, read-only arcs represented by dashed

lines, and overwrite arcs, represented by lines withelementary process actions. Places (represented ascircles) record the process state by storing tokens. double headed arrows. Arcs can be labelled by a

weight, indicating the number of tokens flowingTokens are distinguishable and have a type that isdefined by a class contained in the SLANG type along the arc at each transition firing. An asterisk,

‘*’, indicates that as many tokens as possible flowhierarchy (see Figure 3). Arcs connecting places withtransitions and transitions with places determine through the arc when the transition fires.the consumption and production of tokens whentransitions fire. The overall SLANG net defining a Tokens: Process data are represented by objects,

instances of subclasses of Token. Therefore, eachprocess model is hierarchically structured intoactivities. At the top of the hierarchy there is a token is typed and carries structured information

that can be accessed through the methods defined instarting activity called root activity, an example ofwhich is shown in Figure 5. the corresponding class. Tokens represent different

kinds of process data in the process model,including process products and by-products (sourceTransitions: The execution of a transition is atomic,

in the sense that no intermediate state of the code, executable code, design documents, specifi-cations etc.), resources and organizational processtransition execution is visible outside the transition.

Each transition is associated with a guard and an aspects (such as roles, skills, human resources,computing resources etc.), and process model andaction. The guard is a predicate indicating whether

Figure 3. SLANG type hierarchy

1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 105–131 (1997)

111


state (for example, activity definitions, activity SLANG activities: Activities are the modularizationunits provided by SLANG. An example showinginstances, class definitions etc.). The latter feature

allows SLANG to provide computational reflection, activities is provided in Figure 5. According tothe principles of information hiding, an activityand therefore offers the means to build meta-

models, i.e. to model the manipulation and evol- definition has an interface and an implementationpart. The activity interacts with other activitiesution of the model itself (Bandinelli et al. 1993a).through its interface, while the implementationpart remains hidden. An activity interface contains:SLANG type hierarchy: The SLANG class hierarchy

contains a set of predefined, process-independent I A set of interface transitions, including startingclasses that are part of the language definition and events and ending events. Activity executioncannot be modified. The classes that are part of a starts when any of the starting transitions firesspecific process model are represented by a sub- and terminates with the firing of one of thegraph of the generalization hierarchy whose root ending transitions.is ModelType (see Figure 3). Since SPADE is built I A set of interface places, including input places,on the object-oriented database management sys- which play the role of arguments of an activity,tem O2 (Deux 1991), it was a natural choice to output places, which contain the activity results,define the SLANG type system after that provided and shared places, whose contents can be usedby O2. to exchange data with the calling activity.

An example class in the BA model is class Library I A set of interface arcs, connecting interfacedisplayed in Figure 4. It has a name and contains places and interface transitions.a design document (BDiag) in the form of a Booch

Activity invocation is represented graphically bydiagram. As different library configurations haveembedding an activity interface in a SLANG net.to be managed Library inherits from CMItem, whichFor instance, Figure 5 (showing the root activity ofprovides attributes and operations for manipulatingthe BA model) includes invocations of activitiesconfiguration items, including revision and versionSessionManager, AccessControl, ConfManagement, andnumbers and methods to derive new revisionsVersionManager. When a starting transition fires, aand versions.new instance of the activity (called active copy) iscreated. Active copies are executed in parallel. Forinstance, two tokens in place LoginMsg would causethe starting transition of activity Session Managerto fire twice, thus creating two instances of thatactivity. These active copies are executed in parallelwith the root activity. When an ending transitionfires, it deposits the resulting tokens into someoutput places (e.g. SessionManEnd), belonging tothe calling activity, then the terminated active copyis deleted (together with the tokens still contained,if any).

4.3.2. Integration Facilities in SLANGBesides normal places, SLANG includes user places.The contents of a normal place can change onlybecause of a transition firing. User places, instead,change their contents as a consequence of eventsoccurring in the user environment. When a processrelevant event is generated (e.g. through a tool),the event is captured and a token with theinformation about the occurred event is insertedin the user place(s) associated with that event.

Figure 4. Example type definition Normal places are graphically represented bySoftw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

112


Figure 5. SLANG net showing root activity of BA process model

a single circle, user places are represented by parList. The epilogue contains the code to beexecuted after the external action termination. Adouble circles.

Events having effects only in the process model predefined variable called extResult contains theresults of the external action and together with theexecution are modelled by means of regular (or

white) transitions (represented by white rectangles). input values may be used to determine thetransition output.Events involving also effects in the user environ-

ment (e.g. launch a tool or change a tool state) are The execution of a black transition is not atomic:the prologue and the epilogue are executed incalled black transitions and are represented as

filled rectangles. different moments, separated by the time necessaryfor the external action to complete. In the mean-A black transition action contains the invocation

of an external action (typically a tool service while, other transitions can fire.request). The action body is actually split in two

4.3.3. Architecture of SPADEdistinct parts called prologue and epilogue. TheThis subsection provides an overview of theprologue sets up the conditions for invokingarchitecture of SPADE-1, the first full-fledgedthe external action. In particular, the predefinedimplementation of the SPADE PSEE. SPADE-1 isvariable extAction has to be given a string value,structured as indicated by Figure 6:which indicates the external program to be

executed, or specifies the service to be requested. I The process enactment environment (PEE) con-tains the process engine and the object-orientedIf required, object parameters for the external

action may be specified in the predefined variable repository of the process-centred environment. 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 105–131 (1997)

113


Figure 6. SPADE architecture

The process engine is responsible for the Process Enactment Environment The process enact-ment environment is the run-time support thatexecution of the SLANG process model.

I The user interaction environment (UIE) is com- drives the execution of the process model. It iscomposed of a multi-threaded process engine andposed of external tools contained in the develop-

ment environment. The users (or process agents) an O2 object database (Deux 1991). O2 has a client-server architecture where the server managesinteract with the process through the tools in

the user environment. persistent storage (page management, concurrencycontrol etc.) and clients are in charge of compu-I The SPADE communication interface (SCI)

behaves as a communication bus, connecting tations (method execution, class or code compi-lation etc.). Process data (tokens) are stored in theSLANG interpreters in the PEE and tools in

the UIE. The SCI also provides facilities for O2 database, thus the SPADE process engine is anO2 client, which uses the O2 run-time system asconverting the communication protocol defined

for the PEE into a specific protocol comprehen- the backbone for the execution of the SLANGinterpreters. During process execution, each processsible by a given tool in the UIE.


114


engine executes one or more SLANG interpreter parsing and unparsing the data contained in thefiles. DB-system based tools use structured datathreads, each managing a set of active copies.stored in the database used by the process enact-ment environment. They are database clients andUser Interaction Environment The user interaction

environment is composed of the tools used by they share data definitions contained in the DBschema. In SPADE-1, DB-system based tools shareprocess agents to perform their work. SPADE-1

provides a general mechanism to integrate these class definitions in the O2 database schema andare able to exchange database objects of arbitrarytools in the process environment. The level of

integration that can be achieved depends essentially complexity and granularity.on the characteristics of the tool; tool generation

SPADE Communication Interface The SPADE com-facilities allow the construction of custom toolsmunication interface is responsible for the com-achieving the required degree of integration.munication between the user interaction environ-Tools are seen by the SPADE-1 environment asment and the process enactment environment. Theservice-providers that can possibly share data withglobal architecture of SPADE-1 is represented inthe process engine; a tool exhibits a control interfaceFigure 6. The SCI acts as a communication serverindicating the offered services and a data interfaceused by two kinds of clients:specifying the structure of used data. The differ-

ences among tools are basically given by the I PEE clients – they are SLANG Interpreters thatgranularity of the offered services (the control use the SCI as a means to communicate andintegration dimension) and the level of agreement interact with the ‘outside world’, i.e. the UIE.on the view of shared data (the data integration I UIE clients – they are tools in the UIE whichdimension). provide services and notifications of relevant

With respect to the control dimension, tools can events to the SCI and (through the SCI) tobe classified into two broad classes: black-box tools the PEE.and service-based tools. Black-box tools offer a single Communication between the SCI, the tools andservice that takes an input and produces some the process enactment environment is based onoutput. The action can be performed with or the message passing paradigm (Reiss 1990) andwithout user intervention, however there is no follows the SCI Protocol. This protocol defines away to control the execution of the tool (there is connection procedure, an addressing mechanismonly one service which can be requested, and the and a message format. During the connectiononly event recognized by the process environment procedure SCI clients declare their type (UIE clientis the termination of the tool). Examples of black- or PEE client) and receive their address. Tools thatbox tools are UNIX programs such as vi and cc. are able to communicate through the SCI protocolService-based tools provide several services, which are directly connected to the SCI, while other toolscan be requested individually. Integration of ser- can be connected to the SCI through a sort ofvice-based tools can be obtained easily through gateway (that we call bridge). The former tools arethe mechanism of message passing; tools send given an address consisting of a unique integermessages to a message server that forwards them identifier, the latter are identified by a pair ofto the recipient tools according to a given criterion. integers: the first indicating the bridge, and theThis mechanism, originally proposed by Reiss for second indicating a tool in the set of tools connectedthe FIELD environment (Reiss 1990) is becoming to that bridge.very popular and has been used in several commer- The message format defines different messagecial products (including DEC FUSE (Digital Equip- types (requests, replies, notifications). Messagesment Corporation 1992), HP SoftBench (Gerety can contain only unstructured data. The SCI1990), and SUN ToolTalk (Sun Microsystems 1991)). message format is modelled after those proposed byWith respect to data integration, we also dis- the commercial message-based tool environments.1tinguish two broad classes: file-system based toolsand DB-system based tools. File-system based tools

1 Actually, an open specification defining abstract, framework-are only able to exchange data with other tools inneutral message interfaces for CASE tools was defined bythe form of files in the file-system. Each tool reads Sunsoft, DEC, SGI and HP, and was submitted as a joint draftto ANSI X3H6 (recently renamed NCITS) (continued over)and writes data on files and is responsible for


115


PEE clients can request two kinds of services can be sent through the SCI to people andtools interested in the file update.from the SCI: configuration and integrated service-

based tool invocation. The configuration serviceallows SLANG interpreters to modify the behaviourof the SCI at enactment-time. For instance, a client 5. THE EXPERIMENTcan declare the kinds of messages that it is willingto receive; it has to specify a pattern (composed The BA experiment is the first case study whereof a tool address and a message name) and will the SPADE environment was used to model andthen receive the matching messages, as tokens, enact an industrial-scale process model with thein a user place of the activity that issued the purpose of becoming the ‘heart’ of a PSEE. Theconfiguration request. experiment had a total duration of nine months

PEE clients can also ask for the invocation of an starting in November 1994. Three parties partici-integrated service-based tool. The invoking SLANG pated: CEFRIEL, where the process model wasinterpreter provides the command to be executed developed; University of Dortmund, where devel-(a command uniquely identifies a tool and a opment tools were generated and integrated intoservice) and the name of the host computer on the BA SEE, and BA’s Infrastructure group, fromwhich the tool must be executed. When the SCI whom the process was elicited.receives an invocation request message from a It is worthwhile noting that the skills of BASLANG Interpreter, it invokes the tool on the Infrastructure engineers were not sufficient tospecified host and, in case of successful invocation, exploit SLANG nets for process modelling. Thereturns the tool identifier in the message reply, thus development effort was, therefore, mainly carriedenabling further direct reference to the same tool. out full time by two Master students at CEFRIEL

A typical communication fragment is the follow- and the University of Dortmund, who were super-ing: vised by experts in process modelling. When

the development started, the students and their1. A process interpreter PI sends a configurationsupervisors had a sufficient degree of knowledgemessage to the SCI, indicating that it is willingof the languages to be used.to receive ‘SaveFile’ messages arriving from

In this section, we discuss the experiment wetool with identifier T.conducted at British Airways from different per-2. The user issues a SaveFile command throughspectives. Section 5.1 discusses the elicitation andthe editor T. The editor does not immediatelymodelling of an enactable process model. Theexecute the command: instead, it sends aprocess model identifies a number of documentmessage to the SCI indicating the requesttypes. The tools to be generated, therefore, have to(‘SaveFile’) with its identity T.include tools for the production of these document3. The SCI uses its internal configuration tablestypes. The generation of tools is discussed into decide which process interpreter is interestedSection 5.2. Section 5.3 discusses the integration ofin the request, then forwards the message toprocesses and tools. In each subsection we explainthat interpreter. In this case the message isthe approach taken during the experiment and thesent to interpreter P, and stored in a placeresults obtained.whose name is ‘SaveFile’.

4. The process environment processes the request(for example it checks the user’s permission to 5.1. Process Elicitation and Modellingmodify the involved file). Then a message issent to tool T containing the request to save

5.1.1. Approachthe file or a warning to be displayed explaining The starting point for process modelling was thewhy the file cannot be saved. Other messages BA process handbook. It provided an appropriatescenario from which other information regarding

and approved on 21 January 1997 with the name of CASE Tool roles, responsibilities and library structure couldIntegration Messages. The SCI protocol was not designed to be be elicited during the first (kick-off) meeting. Fromcompliant with the X3H6 proposal, however it would be there, process elicitation and modelling proceededrelatively easy to make it compliant with the standard or todevelop a X3H6 bridge. in a parallel and incremental way.Softw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

116


We started the formalization of the process in is SessionManager, whose definition is displayed asthe net shown in Figure 8. Whenever a user startsthe kick-off meeting using state transition diagrams,

a notation Infrastructure members were familiar the Booch editor, the editor will notify a start-upevent to the process model, which will appear aswith. The result of this discussion is shown in

Figure 7. It was during the development of this a token on place LoginMsg. This token enablesStartSM, which will eventually fire, thus creating astate transition diagram that the two participating

Infrastructure members discovered the misunder- new active copy of activity SessionManager. Acomponent of the token identifies the user who hasstanding mentioned in Section 4.

The modelling activity continued by enriching logged into the environment and this component isfired on place Owner. From there on, the activitythe state chart with other context information

regarding roles, library attributes, access restrictions awaits messages from the user interaction environ-ment. These will appear as tokens on placesetc. The state transition diagram was then for-

malized in a complete process program written in MsgFromSS or MsgFromBE. After the net has donesome consistency checks on the message andSLANG and in a protocol specification for the

messages exchanged with tools through the SCI. approved the message, the message tokens willappear on place UserMsg. Consequently, transitionsAn important result that evolved from the

development of this state transition diagram was are in conflict over these tokens and guardsare used to determine the transition that fires.the requirement that one developer should be

responsible for a complete library and that only DispatchToCM, for instance, fires if the guard ident-ifies the message as a configuration managementone developer at a time should work on a library.

This implied that the granularity of documents message and transfers it to the place CMRequestfrom where it is consumed by the ConfManage-considered by the process model had to be at the

level of libraries rather than individual classes. ment activity.The SLANG net modelling the BA process is

structured into five activities, containing in all 505.1.2. ResultsThe whole process model developed for the experi- places and 65 transitions. The graphical net top-

ology covers five pages in printed form. The sizement consists of five activities, the root activity(displayed in Figure 5), plus four other activities of the textual representation that includes the code

for all token types and the different messages isinvoked by the root.One of the activities invoked by the root activity about 4 KLOC.

Figure 7. State transitions during library management


117


Figure 8. Refinement of activity SessionManager (Figure 5)

Although the size of the model is fairly small it 5.2. Tool Specificationtook a Master student, who had undergone trainingon the notation and its use for process modelling 5.2.1. Approach

The process elicitation exercises revealed thatbefore he started, four months to complete themodel. This effort might seem high at first glance. integrated tools for one graphical document type

(Booch diagrams) and three textual documentIt has to be noted, however, that the effort wasneeded for process elicitation, formalization of a types (C11 class interface definitions, C11 class

implementations and class documentations) wouldlogical process model, transformation of that logicalmodel into a process program that integrates tools be needed. These tools were engineered in a

syntax-driven way using GTSL. We started theat a fine granularity, and the testing of theintegrated environment. specification of each tool by defining the context-

free syntax. Extended and normalized BNFsWe doubt that the effort would be considerablysmaller with any other process programming (ENBNFs) were used for the languages supported

by the textual tools.language. Hence, the lesson to be learned is thatcoding enactable process programs that integrate An initial GTSL class hierarchy was derived

from these syntax specifications. For each of thetools at a fine level of granularity is expensive andthat the cost effectiveness of fine-grained process textual tools, the ENBNF syntax definition was

translated into a hierarchy of GTSL classes usingmodelling whose aim is to derive an enactableprocess program has yet to be proved. a similar strategy as in the interpreter designSoftw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

118


pattern discussed in Gamma et al. (1993). This of a new relationship in the Booch class diagramis reflected automatically in the C11 class interfacetranslation was automated by an ENBNF compiler

we generated for that purpose. definition. The class interface tool is specified using75 GTSL classes.The generated GTSL classes were then elaborated

further in order to specify the relevant static The C11 method implementation editor sup-ports programming of methods, which have beensemantics rules and inter-document consistency

constraints. These were expressed in a rule-based identified during the C11 class interface design.This editor is integrated with the C11 classformalism from which the GTSL compiler created

an incremental rule interpreter in a way discussed interface editor in a way that any changes to, forinstance, a method signature are automaticallyin Emmerich et al. (1995).

We then added tool commands to each class for reflected in the implementation. We needed 130GTSL classes to specify the C11 methodediting, analysing and browsing through docu-

ments. Editing commands were specified for the implementation tool.The class documentation editor implements theexpansion of non-terminal placeholders into tem-

plates containing concrete lexemes and nested British Airways documentation standard, whichrequires a description for any method within aplaceholders and the expansion of terminal place-

holders into identifiers. In addition, editing com- class together with an example of its application.The editor is also integrated with the C11 classmands for free textual input were specified. Analy-

sis commands allow users to find usages of interface editor, so that stubs are generated foreach method identified in the class interface andany declaration in order to allow change impact

analysis. Browsing commands support users to users only have to complete these stubs. OS/2 IPFhypertexts and HTML files are generated fromopen and locate documents based on semantic

relationships between identifiers. class documentations without requiring furtheractions of the developer. These two representationsenable users of a class library to access docu-5.2.2. Results

The user interface of the BA SEE provides four mentation as on-line help facilities with standardbrowsers, i.e. without having to use the BA SEE.types of windows (shown in Figure 9). These

windows are for the four different tools of the The documentation tool was easiest to specify andit needed only six GTSL classes.SEE: the Booch class diagram editor (upper left);

the C11 class interface editor (upper right); the A research assistant exclusively working on theproject needed four months altogether to specifyC11 method implementation editor (lower right),

and the class documentation editor (lower left). the classes of the four tools. The average size of aclass specification was approximately 170 LOCThe Booch class diagram editor enables users to

decompose libraries hierarchically into categories and we extensively used inheritance to avoidduplication of properties.and classes. A category is a set of related classes

and/or nested categories. Top-level categories rep-resent libraries. Different types of relationships are

5.3. Integration of Tools and Processsupported to facilitate inheritance, aggregation andreference relations between classes. The Boocheditor was specified using 20 classes. 5.3.1. Approach

The C11 class interface editor supports syntax-directed editing of C11 class definitions. The Specification of the integration Process-sensitive

events, such as the creation of a new library, areeditor includes structure-oriented and free textualediting facilities that enforce syntactic correctness captured by tools and the process model needs to

be informed about them. This means that, from aof class definitions. Moreover, the editor checksfor correctness of the C11 static semantics while modelling perspective, GTSL events are associated

with SLANG user input places. Likewise, thethe user edits and visualizes errors by underlining.Checking is done incrementally and transparently invocation of tool services of a particular tool has

to be expressed in the process model. Duringto the user. The C11 class interface editor hasbeen specified in a way that it is integrated with modelling this means that some of the black

transitions are associated with GTSL services.the Booch editor so that, for instance, the creation 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 105–131 (1997)

119


Figure 9. User interface of BA SEE tools

From an architectural point of view, the SCI has a semantic point of view the meaning of messagesand their parameters must be defined as well asbeen successfully employed for implementing the

association of GTSL events with user input places the actions that they cause.as well as for implementing black transition occur-rences that invoke GTSL services. An event declared Architecture of the integration We considered differ-

ent architectures for the integration of SPADE’sin the Booch editor specification is transformedinto a Sun ToolTalk message, which is then sent PEE with the UIE. In particular, the decisions we

had to make were:via the ToolTalk bridge to the SCI. The SCItransforms the message into tokens, which include I whether to exploit the SCI as a software busthe message data, and user input places are marked for the exchange of messages among tools, orwith these tokens. Vice versa, a black transition to use another bus (e.g. ToolTalk);causes the SCI to create a message that is then I whether to integrate the PEE with all the toolstranslated into a Sun Tooltalk message created by or with just a subset of them, leaving thethe ToolTalk bridge. Receipt of the message by the integration of the others to be done ‘outside’Booch editor causes the GTSL run-time system the process.to invoke the service that is associated withthe message. In the case of the BA experiment these possible

choices determined three different architecturalThe tools and the process model have to agreeon some common message protocol. This involves alternatives.

The first alternative, which we refer to as thesyntactic and semantic concerns. From a syntacticpoint of view, tools and process model have to ‘Star’ architecture, was to link all tools to the SCI,

as shown in Figure 10. This choice means that theagree on the messages and their parameters. FromSoftw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

120


Figure 10. ‘Star’ architecture

design relies on the SCI as the software bus documentation editor were locally integrated withthe Booch editor through a ToolTalk based messagesupporting message exchange among the four

BA tools. server, as shown in Figure 11.After the ToolTalk bridge was released the finalThe star architecture was rejected because it

unnecessarily complicated the process model. In ‘bridged architecture’ was established, as shownin Figure 12. In this case, all the messages flowingfact the criteria to be used in handling messages

should have been coded in the process model. among the tools are observed by the bridge –which is itself a ToolTalk tool – but only thoseThis is not a problem in general, since the PEE

has to know messages that represent events in the important to the process are forwarded throughthe SCI to the PEE. Note that in this last case theUIE in order to react properly. In our specific case,

however, the PEE is interested only in messages design of the tools is cleaner, since they do notneed to take into consideration the interaction withconcerning the management of whole libraries, not

data (like class interfaces) at a finer granularity. In the SCI. In fact, they are not even aware of itsexistence. This is obviously obtained at the expenseother words, the interface, implementation and

documentation editor could be integrated in a of building the bridge, which is, however, inde-pendent from the specific tools and process, andstatic way among themselves, without involving

the process environment. can therefore be reused as it is in other applications.The last task in the definition of the model wasWe refer to the second alternative as the

‘mediated architecture’. This architecture exploits to develop an appropriate communication protocolbetween the process engine and the Booch editor.an observation we made during the initial process

elicitation, i.e. that the granularity of responsibility A first version of this protocol took into accountonly services for session management and accessat British Airways are class libraries rather than

individual classes. As class libraries are defined in control. Then the protocol was extended to capturethe semantics of class library management at BAthe Booch editor, there is no need for integrating

the editors for the other three document types and the first enactable process model prototype wasdemonstrated in a meeting with BA Infrastructurewith the process model. We, therefore, initially

integrated the Booch editor directly with the SCI. members. The availability of an enactable prototypeat this meeting proved very useful and triggeredThe interface editor, implementation editor andvaluable feedback from Infrastructure members.


121


Figure 11. Mediated architecture initially adopted in the BA experiment

5.3.2. Results 6.1. Experience of Technology ProviderFor the British Airways process model, an informal The technology provider’s concern was to assessprotocol specification has been defined that includes the process modelling and automation capabilities22 different messages. of both SLANG and its support environmentAn example is the create message in Figure 13. SPADE.Messages like this are sent from the Booch classdiagram editor via the ToolTalk bridge to the SCI 6.1.2. Modelling communication with toolsand then appear as tokens on user input places. The process modelling language was deliberatelyLikewise SLANG black transitions send messages designed to have two very simple and powerfulto the Booch editor to invoke services. means for modelling communication between pro-

cess and tools: black transitions and user places.These two basic mechanisms made it feasible tomodel virtually any interaction policy, providedan appropriate message protocol had previously6. LESSONS LEARNEDbeen agreed.

6.1.2. Managing complex policiesThis section summarizes the lessons learned fromthe perspective of both the technology provider The BA experiment showed that process policies

can reach high levels of complexity in industry.and the technology user.Softw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

122


Figure 12. SPADE architecture

6.1.3. Abstraction mechanisms and activity interfacesSLANG provides abstraction mechanisms thatfacilitate the hiding of complexity at lower levelsof the process model. The activity SessionManager(see Figure 8), for instance, is completely inde-pendent from the access policy, which is hiddenin the AccessControl activity (see Figure 5) and in

Figure 13. Example message definition the definition of owner data. In other circumstances,however, relevant behavioural information remainshidden in the activity implementation, too. ThePolicy implementation has an impact on tools, on next transition that will fire in SessionManagerthe communication protocol between tools and after DispatchToAC has occurred will either beon the process model fragment managing thatLoginAccepted or Registered, Unregistered or Logg-protocol. To avoid dealing with this additionaledOut. This, however, is not evident from justcomplexity at the process level, higher level com- reviewing the SessionManager activity or the root

munication primitives should be introduced in activity. To resolve this problem, activity interfacesthe process modelling language. The trade-off, should not only be defined from a structuralhowever, might be that the introduction of new viewpoint, but should also provide a behaviouralcommunication primitives could complicate the perspective. Such a perspective would have tocurrent simple communication mechanism. show, at the activity invocation level, that marking 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 105–131 (1997)

123


ACRequest leads to a token at ACAnswer and that resented by Infrastructure’s process handbook, andin the ‘Observed Process’ (Bandinelli et al. 1995b),marking CMRequest produces a token on CMAnswer.

People who were not involved in the process represented by what process agents thought theactual process was. In addition, the modellingmodelling experiment did not find the enactable

process model easy to understand. During process activity had to be very detailed in order to obtainan enactable process representation. This facilitatedelicitation it was necessary to use simple state

transition diagrams (like the one shown in Figure 7) discussions on solid grounds and prompted theremoval of ambiguities in the process model.to communicate with process stakeholders. Actu-

ally, this did not surprise us, since SLANG wasinitially conceived to support process enactment. 6.2.2. Process ImprovementThe BA experience showed, however, that it is The process modelling activity highlighted flawsimportant to provide different views, which may in the process, thus offering an opportunity torequire different levels of abstraction, different improve the process. In some cases, the introductionways of structuring the process model and different of process technology naturally leads to changingformalisms to express them. This evidence supports the process during modelling. To a certain degree,the claims of Deiters (1993) and Junkermann (1995). this process improvement was achieved by the BAHowever, there are no satisfactory answers as yet experiment. However, to reduce the inherent riskto the problem of maintaining consistency of views it is advisable to apply process technology toduring both modelling and enactment. already stable and well understood processes.

6.1.4. Performance issues 6.2.3. Process AutomationThe enactment experience has shown that, during Although process automation has initially beenprocess model execution, the process engine is idle perceived as a fascinating idea, not all processesfor most of the time. The engine works as a are amenable to complete automation. Automatedreactive system, which wakes up whenever a processes are less adaptable to unforeseen situ-process-relevant event occurs. This observation ations, and, as pointed out above, their executionseems to support the argument that performance may introduce some performance overhead. Thus,issues are not relevant in process engines. However, while established administrative processes are bet-fine-grained tool integration implies that the pro- ter suited to process automation, less clearlycess engine becomes active during interactions of defined creative processes can only be supportedusers with tools. To avoid low user acceptance of by, for example, providing guidelines or helpsuch an environment, response times less than a information on demand.second have to be achieved. Being a pre-commercialprototype, the BA SEE has very reasonable perform- 6.2.4. Reference for future procurementsance characteristics with response times between The British Airways Infrastructure group has0.5 and 2 seconds on a SparcStation-20. However, gained insights from this process elicitation andthe environment would need to be re-engineered modelling exercise into the state-of-the-art in pro-to be used as a commercial development environ- cess technology and software engineering environ-ment in industrial applications. Much of the over- ments. These insights have led them to adopt thehead introduced in the process engine execution BA SEE as a reference point for functionalityis due to the evolution mechanisms provided by expected from off-the-shelf software engineeringthe SPADE environment. tools.

6.2. Experience of Technology Users7. FUTURE WORK

6.2.1. Process understandingMuch process understanding was gained through The BA experiment highlighted several issues

that are currently the subject of several researchthe process modelling process. The use of a formalprocess modelling language has led to the removal initiatives. This section describes these issues, and

relates them to our current and future work.of inconsistencies in the ‘Official Process’, rep-Softw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

124


7.1. The Industrial Context of the Experiment of the experiment served as a feedback toactually improve Italtel’s Quality Manual. TheThe industrial context plays a fundamental role in experiment at BA Infrastructure did not havethe level of success that can be achieved in an a direct link to any internal improvement actionexperiment such as the one reported in this paper. and although the experiment served to raiseIn order to highlight the relevance of the industrial the level of understanding of some developmentcontext, we briefly compare this experiment with processes and the environment was installed,a previous process improvement experiment in it was not used in actual development.which the same process modelling language

(SLANG) was used. The previous experiment was This comparison shows that the industrial contextcarried out at the Business Unit Telecommuni- in which a process improvement experiment iscations for Defense (BUTD) of Italtel, a large Italian carried out is a decisive factor for its success.telecommunication company (Bandinelli et al. Specifically, the definition, development, tailoring1995b). Here are the main differences: and introduction of process technology cannot be

addressed in isolation from a broader processI The experiment objectives. The main objective ofimprovement programme, having the necessarythe Italtel experiment was to enhance the levelmanagement commitment.of process understanding by reconciling the

During recent years process improvement modelsprocess agents’ view of the process and the(such as CMM (Humphrey 1989), ISO-15504 (alsoofficial process definition, represented by theknown as SPICE) (ISO/IEC 1997b), BoostrapQuality Manual. The British Airways experi-(Kuvaja et al. 1994) etc.) and process technologyment was focused on providing process support,have developed in independent ways. They addressand, where possible, process automation. In thiscomplementary aspects of process improvementlatter case, an improved process understandingand each need other support integrated processwas also obtained as a side-effect.improvement. Process technology needs to becomeI The scope of the experiment. Consistently withmore mature to be able to support highly maturethe experiment objectives, at Italtel BUTD onlysoftware organizations and improvement modelsthe process model was developed. Although itneed to rely on process technology in order towas a formal model, it did not include details,make process improvement more efficient andwhich are necessary for process enactment,effective. Synergy between these two approachessuch as integration with development tools.is not fully explored yet and deserves furtherThe formal SLANG process model served toresearch and experimentation.call attention to some deficiencies in the process

definition. At BA Infrastructure the SLANGprocess definition needed to be enriched with 7.2. Process Life Cyclethe appropriate code for tool integration so thatthe model could be enacted by the process The life cycle of a process resembles a software

development cycle. The first step, as for anyengine.I The organizations’ process maturity. Being in the other software, should be to develop the process

requirements. A specific process requirement lang-defence domain, Italtel BUTD must complywith security and quality control procedures. uage could be used to elicit process information

from the various process agents in order to detectIt is periodically assessed for compliance withinternational standards, such as NATO AQAP- inconsistencies and misunderstandings among

them at an early state. Languages that are simple13, MIL-STD 2167A and ISO 9000-3. Thus, therewas a pre-existing process quality culture in and easy to understand, such as state charts, might

be used during this phase. It might also beBUTD. The Infrastructure group at BA did nothave this process culture and processes were necessary to reconcile different process perspectives

elicited from different process stake holders. Thatonly documented in brief before the experiment.I Integration of the experiment in a broader process reconciliation should then determine a consistent

logical model of the software process.improvement action. The improvement of theQuality Manual of Italtel BUTD was part of a The transition from the logical software process

model to a process program that is used forcontinuous improvement action and the results 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 105–131 (1997)

125


enacting development is not fully understood. We which SPADE process programs can react to events,however, is limited by the ability of the UIE tobelieve that the logical model and the process

program are quite different entities. The process capture those events that should trigger processreactions. For instance, some integrated develop-program has to address issues, such as tool

integration and distributed execution, which should ment environments (such as DEC FUSE) do notalways request permission to perform an action,not be taken into account during process analysis.

The result of the initial process programming stage or they do not notify some events. In these cases,the process environment has limited visibility toshould be a process architecture of the enacted

process. It has to identify the main building blocks the user environment and cannot always react toevents occurring in the user environment. Aof the process program, the tools involved and

the primitives and protocols used for integrating solution to this problem has been attempted inProvence (Barghouti and Krishnamurthy 1995).process and tools.

The stage of the software process development Provence is built on top of a patched operatingsystem that generates event data from operatingprocess that has gained most attention is process

programming. Most process languages explicitly system calls. As soon as a certain pattern of UNIXsystem calls is recognized the Marvel processsupport the definition of executable process models.

Process support environments are centred around engine is notified of an event. While this approachseems promising for environments that rely on theinterpreters for these languages and support their

development, enactment and evolution. UNIX file system, it almost certainly fails for toolsthat are built on database systems, which mightIt is very likely that different formalisms are

used for identifying these different perspectives of not use the operating system for secondary stor-age management.requirements, architecture and coding. In order to

provide an incremental and intertwined perspective In any kind of process, inconsistencies withindocuments are generally tolerated by the tools.on the meta process and allow for traceability

decisions taken during process analysis, process Developers either explicitly perform checks tofind inconsistencies or tools implicitly check andarchitecture and process programming it is

important that these formalisms be integrated. visualize inconsistencies. At specified points intime, for instance before baselining or translatingHence the problems are similar to those in the

software process itself. It needs to be investigated, a document, developers remove inconsistencies.Similar considerations might be applicable to thehowever, whether solutions that have been

developed for products can also be applied to the software process itself.Process technology should, therefore, contributeprocess modelling itself.

techniques and tools that inform engineers howthey are performing with respect to a prescribed

7.3. Support for Process Deviations process rather than restricting them to only thoseactivities that are in-line with the process defined.One of the lessons that we have learned is that

software engineers are reluctant to have themselves Currently, we see two different approaches totolerate inconsistencies on the process level; thestrait-jacketed by a strict process model indicating

what they should do, and how and when they modelling of allowable deviations and compliancechecks.should do it. This has led us to believe that

strict enforcement of prescribed processes is too The SENTINEL PSEE (Cugola et al. 1996) toleratesdeviations during process enactment. SENTINELrestrictive and will not be accepted in industry.

This problem leads to two separate considerations. process descriptions are composed of a behaviouraland an intentional part. SENTINEL supports pro-First, the process support style can be pro-active or

reactive, the latter allowing more freedom in the cess enactment according to its behavioural descrip-tion, but it allows humans to deviate from thatdevelopment process and being, therefore, more

easily accepted. Secondly, it might be appropriate description, provided that the process is stillin the boundaries established by the intentionalto allow deviations from the ideal reference model

of the process. description. During deviations the system keepstrack of the progress of the process, registering allSLANG and SPADE can support the pro-active

and reactive styles equally well. The degree to the state changes and the operations that are


126


performed. When a reconciliation is needed, infor- requiring heterogeneity in data representation tobe resolved.mation on all the data that have been potentially

‘polluted’ by the deviation – and that might need These problems are not new. They have beenaddressed in a number of distributed systemto be repaired – are calculated by reasoning on

the deviation history. infrastructures, for instance the Common ObjectRequest Broker Architecture (CORBA) definedIn Emmerich et al. (1997b), a process actually

performed is said to be compliant if it conforms to by the Object Management Group. Use of thisarchitecture might be advantageous for thethe modelled process. An approach for checking

compliance to process through inconsistency analy- implementation of events and services that areused for communication between process andsis between documents is suggested. The suggestion

is based on the observation that standards for tools. Using CORBA, events and services can beimplemented as parameterized synchronous, orsoftware processes, such as ISO-12207 (ISO/IEC

1995) or the forthcoming ISO-15288 (ISO/IEC deferred synchronous, or asynchronous operationexecution requests, rather than as messages that1997a), require relevant process information to

be documented in management reports, minutes, are exchanged. The signatures of these operationsare defined in an Interface Definition Languageprogress reports and the like. Hence, compliance

rules can be expressed in terms of relationships (IDL) rather than in untyped messages. Complianceof both processes and tools to the interfaces canthat must hold between these process state docu-

ments and the product documents. Object-oriented be checked statically at compile time or dynamicallyat run-time. The different activation strategiestechniques to specify the document type structure

and event-condition-action languages for the defi- included in the CORBA standard define how toolsor process engine should respond to multiplenition of compliance rules are being explored.

The problem of process deviation has been concurrent communication requests. CORBA hasbeen explicitly designed to support heterogeneoustackled by several researchers, who proposed

different techniques to manage inconsistency. Wolf environments where components are implementedin different programming languages and can beand Cook proposed compliance checks based on

event trace comparison (Cook and Wolf 1995), running on different hardware and operatingsystem platforms, hence resolving all the heterogen-while in APPL/A (Sutton et al. 1994) exception

handling is used to deal with exceptional situations. eity problems.While CORBA seems to provide better support

than message based systems for the integration of7.4. Interoperability and Distribution in PSEE tools with process engines, a number of questionsArchitectures remain open. CORBA defines the lower level

primitives for distributed operation invocationIn our experiment, development of the messageprotocol for the integration of process model with that we have sketched above; in addition the

CORBAservices and CORBAfacilities specificationtools took a very considerable amount of time.The most important reason for this was the absence also standardize solutions to higher-level problems

that commonly occur in distributed systems. Theof a high-level protocol specification against whichthe implementation in both the process model and problems addressed in these specifications include

naming and trading, security, licensing, con-the tools could be checked in an automated manner.In general, the integration between tools and currency control, transaction management and

event notification. It is interesting to identify thoseprocess engines faces problems that are commonto a number of distributed systems. For instance: CORBAservices that are needed in a distributed

PSEE architecture and to see whether the specifiedcommunication between tools and process synch-ronization of messages has to be considered; services are sufficient for PSEEs. It is quite likely

that they are not sufficient and that they will haveconcurrent messages might be arriving at theprocess engine from several tools; tools processes to be adapted to PSEE architectures. Emmerich

(1996a, 1997) reports on the results of initialmight not be available and may have to belaunched; communication can be disturbed by slow investigations concerning the size of the gap

between what higher-level services are needed inor unavailable networks; and tools and processengine might be running on different platforms a PSEE architecture and the features that are


127


actually defined in the CORBAservices and COR- Special attention will be devoted to the deploymentplans, whose objectives will be:BAfacilities specifications.

I to define the scope of the experiment, that isto decide which parts of the process to model7.5. Removing Barriers for Acceptance in

Industry and enact first;I to carry out a suitable training programmeProcess technology has little popularity in the because, for the first time, SLANG and SPADEsoftware industry. Among the causes of this limited will be used in an industrial environment byacceptance are: teams lacking any SLANG/SPADE expert, and

initial training will be of crucial importance.I limited empirical evidence of the costs andbenefits provided by the process-centred The cost of setting up and running a process-approach to software development, since pre- centred software development environment willcise, quantitative cost/benefit evaluations are be measured, and the resulting benefits will bestill missing; carefully assessed, at least on a qualitative basis.I perceived risk of adoption, since process tech-nology is relatively new and sophisticated.

As far as SLANG and SPADE are concerned, past 8. SUMMARYindustrial applications at the Italian telephoneoperator Italtel (Bandinelli et al. 1995b) and at BA We have reported on the experimental application

of process technology at British Airways (BA). Wewere just experiments carried out with the objectiveof testing the technical features of the process used SLANG to model BA’s C11 class library

management process, and we constructed anmodelling language and of the PSEE. What we neednow is a small set of industrial trial applications experimental process-centred software engineering

environment based on SPADE and incorporatingconcentrating on the definition of a path to process-centred development, including process modelling, tools specified in GTSL and developed by means

of GENESIS.deployment and usage.This is exactly the objective of the ESPRIT In this experiment, SPADE was used for the first

time to enact part of an industrial process. TheProject 23768 DOOR (Developing Object Orientedapplications Rapidly), which is currently in its experiment was successful, since it demonstrated

that SPADE can actually support a real industrialinitial phase.2 DOOR aims at demonstrating thesuitability and cost effectiveness of GOODSTEP process and as the environment is used for a

reference point in future procurements at BA.technology to build industrial software appli-cations. In particular, DOOR will use SLANG and Nevertheless, some issues were also highlighted

that are not satisfactorily dealt with by PSEEs andSPADE in two different industrial contexts: thesoftware production environment for automation therefore deserve additional research.

The existence of a process life cycle was recog-systems of Mannesmann Datenverarbeitung, andthe power system environment of ENEL (the major nized. The process needs support in all its phases,

which are much like those of software development.Italian utility company).DOOR will define a process for modelling, SPADE proved suitable for supporting the low-

level design and coding phases, but the enactabledeploying and using the GOODSTEP processtechnology. The technology will have to be inte- process model was too detailed in itself to improve

process understanding by the BA personnel.grated within the existing technical, managerial,organizational and cultural environment. This Moreover, we recognized the need to support

process deviations as engineers might have toclearly implies the identification of possible risksand the corresponding risk management actions. deviate from the model if a situation arises that

was unforeseen in the process model. Adaptingthe process model in these occasions is not reallyan alternative to deviations, given the effort it

2 DOOR is carried out by a consortium including three takes to implement and test a change.organizations formerly belonging to the GOODSTEP consortium,namely Engineering, the University of Frankfurt, and CEFRIEL. Finally, from an architectural perspective theSoftw. Process Improve. Pract., 3, 105–131 (1997) 1997 John Wiley & Sons, Ltd.

128


Bandinelli, S., Fuggetta, A. and Grigolli, S. 1993b. Processneed was recognized for an investigation of howmodeling-in-the-large with SLANG. In Proceedings of thethe integration of tools and process engines in aSecond International Conference on the Software Process,PSEE can be specified and coded at appropriate Berlin, Germany, IEEE Computer Society Press, pp. 75–83.

levels of abstraction. The message based approachchosen in this experiment was inappropriate. Bandinelli, S., Fuggetta, A., Lavazza, L., Loi, M. and

Picco, G.P. 1995b. Modeling and improving an industrialsoftware process. IEEE Transactions on Software Engineer-

ACKNOWLEDGEMENTS ing, 21, (5), 440–454.

We are indebted to a number of people. Alfonso Barghouti, N.S. and Kaiser, G.E. 1990. Multi-agent rule-Fuggetta, Carlo Ghezzi, Wilhelm Schafer and Rob- based software development environments. In Proceed-

ings of the Fifth Annual Knowledge-Based Software Assistanterto Zicari provided the support within GOOD-Conference, pp. 375–387.STEP to undertake the experiment we reported

about. Alain Ainsworth pointed us to the problemsBarghouti, N.S. and Krishnamurthy, B. 1995. Using eventof the BA Infrastructure group. Mark Phoenix contexts and matching constraints to monitor software

provided us with valuable insights into daily processes. In Proceedings of the 17th International Conferencedevelopment practice at British Airways. Antonio on Software Engineering, Seattle, Washington, ACM Press,

pp. 83–92.Carzaniga and Giovanni Vigna made fundamentalcontributions to the implementation of SPADE-1.

Cook, J.E. and Wolf, A.L. 1995. Automating processRiccardo Rodriguez refined the BA process withdiscovery through event-data analysis. In Proceedings of

SLANG to a degree that it could be enacted. Jorg the 17th International Conference on Software Engineering,Brunsmann designed and implemented most of Seattle, Washington, ACM Press, pp. 73–92.the integration between the Booch tool and the

Cugola, G.P., Di Nitto, E., Fuggetta, A. and Ghezzi, C.process model. Elisabetta Di Nitto, Anthony Fink-1996. A framework for formalizing inconsistencies inelstein and Carlo Montangero explained the impor-human-centred systems. ACM Transactions on Softwaretance of deviations to us. Finally, Stephen Morris Engineering and Methodology, 5(3); 191–230.

helped us to improve the presentation of this paper.Deiters, W. 1993. A View-based Approach to SoftwareProcess Management. PhD thesis, University of Dortmund,Department of Computer Science.REFERENCES

Deiters, W. and Gruhn, V. 1990. Managing softwareArlow, J., Phoenix, M. and Pryce, B. 1994. The Britishprocesses in MELMAC. ACM SIGSOFT Software Engineer-Airways Application Scenario for GOODSTEP. Deliver-ing Notes, 15, (6), 193–205. Proceedings of the fourth ACMable ESPRIT Project GOODSTEP 26P, Commission ofSIGSOFT Symposium on Software Development Environ-the European Union, DG III.ments, Irvine, Cal.

Bancilhon, F., Delobel, C. and Kanellakis, P. 1992. BuildingDelobel, C. and Madec, J. 1993. Version management inan Object-Oriented Database System: the Story of O2. O2. Technical report, O2-Technology.Morgan Kaufmann.

Deux, O. 1991. The O2 System. Communications of theBandinelli, S., Baresi, L., Fuggetta, A. and Lavazza, L.ACM, 34, (10).1995a. Experiences in implementation of a process-

centered software engineering environment using object-Digital Equipment Corporation. 1992. DEC-FUSE manual.oriented technologies. Theory and Practice of Object SystemsDigital Equipment Corporation.(TAPOS), 1, (2), 115–131.

Dinkhoff, G., Gruhn, V., Saalmann, A. and Zielonka,Bandinelli, S., Fuggetta, A. and Ghezzi, C. 1993a. ProcessM. 1994. Business process modeling in the workflowmodel evolution in the SPADE environment. IEEEmanagement environment LEU. In Loucopoulos, P.Transactions on Software Engineering, 19, (12), 1128–1144.(ed), Proceedings of the 13th Entity-Relationship Approach,number 881 in Lecture Notes in Computer Science,Bandinelli, S., Fuggetta, A., Ghezzi, C. and Lavazza, L.Springer, pp. 46–63.1994. SPADE: an environment for software process

analysis, design and enactment. In Finkelstein, A.,Kramer, J. and Nuseibeh, B., (eds), Advances in Software Emmerich, W. 1996a. An architecture for viewpoint

environments based on OMG/CORBA. In Vidal, L.,Process Technology, Research Study Press Limited,pp. 223–247. Finkelstein, A., Spanoudakis, G. and Wolf, A. (eds), Joint


129


Proceedings of the SIGSOFT ’96 Workshops, ACM Press, database system. In Proceedings of the 20th InternationalConference on Very Large Databases, Santiago, Chile,pp. 207–211.pp. 261–272.

Emmerich, W. 1996b. Tool specification with GTSL. InProceedings of the 8th International Workshop on Software Ferrandina, F., Meyer, T., Zicari, R., Ferran, G. andSpecification and Design, Schloss Velen, Germany, IEEE Madec, J. 1995. Schema and database evolution in theComputer Society Press, pp. 26–35. O2 object database system. In Proceedings of the 21st

International Conference on Very Large Databases, Zurich,Emmerich, W. 1997. CORBA and ODBMSs in viewpoint Switzerland, pp. 170–181.development environment architectures. In Orlowska,M. (ed), Proceedings of the 4th International Conference on Gamma, E., Helm, R., Johnson, R. and Vlissides, J. 1993.Object-Oriented Information Systems, Brisbane, Australia, Design patterns: abstraction and reuse of object-orientedSpringer. design. In Nierstrasz, O. (ed.), ECOOP ’93 – Proceedings

of the 7th European Conference on Object-Oriented Program-Emmerich, W., Arlow, J., Madec, J. and Phoenix, M. ming, Kaiserlautern, Germany, volume 707 of Lecture Notes1997a. Tool construction for the British Airways SEE in Computer Science, Springer, pp. 406–431.with the O2 ODBMS. Theory and Practice of Object Systems.3 (3), 213–231. Gerety, C. 1990. HP SoftBench: a new generation of

software development tools. HP Journal. 41 (3), 48–58.Emmerich, W., Finkelstein, A., Montangero, C. andStevens, R. 1997b. Standards compliant software develop- GOODSTEP Team. 1994. The GOODSTEP project: generalment. In ICSE Workshop on Living with Inconsistency, Bos- object-oriented database for software engineering pro-ton. cesses. In Ohmaki, K. (ed.), Proceedings of the Asia-

Pacific Software Engineering Conference, Tokyo, Japan, IEEEEmmerich, W. and Gruhn, V. 1991. FUNSOFT nets: a Computer Science Press, pp. 410–420.petri-net based software process modeling language. InProceedings of the 6th International Workshop on Software Humphrey, W. 1989. Managing the Software Process.Specification and Design, Como, Italy, IEEE Computer Addison Wesley.Society Press, pp. 175–184.

ISO/IEC. 1995. International Standard, Information Tech-Emmerich, W., Jahnke, J.-H. and Schafer, W. 1995. Object nology Software Life Cycle Process. ISO 12207.oriented specification and incremental evaluation ofstatic semantic constraints. Technical Report 24, ESPRIT-

ISO/IEC 1997a. Draft Systems Engineering Standard.III Project GOODSTEP, http://www.dbis.informatik.ISO 15288.uni-frankfurt.de/REPORTS/GOODSTEP/GoodStep

Report024.ps.gz.ISO/IEC 1997b. Software Process Improvement and Capa-bility dEtermination. International Standardisation Organ-Emmerich, W., Kroha, P. and Schafer, W. 1993a. Object-isation.oriented database management systems for construction

of CASE environments. In Marik, V., Lazanksy, J.Junkermann, G. 1995. A dedicated process design langu-and Wagner, R.R. (eds), Database and Expert Systemsage based on EER-models, statecharts and tables. InApplications – Proceedings of the 4th International ConferenceProceedings of the 7th International Conference on SoftwareDEXA ’93, Prague, Czech Republic, volume 720 of LectureEngineering and Knowledge Engineering, Rockville, Mary-Notes in Computer Science, Springer, pp. 631–642.land, Knowledge Systems Institute, pp. 487–496.

Emmerich, W., Schafer, W. and Welsh, J. 1993b. DatabasesKuvaja, P.J., Simila, J., Krzanik, L., Bicego, A., Saukkonenfor software engineering environments – the goal hasS. and Koch, G. 1994. Software Process Assessment andnot yet been attained. In Sommerville, I. and Paul, M.Improvement – The Bootstrap Approach. Blackwell,(eds), Software Engineering ESEC ’93 – Proceedings of theOxford, UK.4th European Software Engineering Conference, Garmisch-

Partenkirchen, Germany, volume 717 of Lecture Notes inMaier, D. 1989. Making database systems fast enoughComputer Science, Springer, pp. 145–162.for CAD applications. In Kim, W. and Lochovsky, F.H.(eds), Object-Oriented Concepts, Databases and Applications,Engels, G. and Groenewegen, L. 1994. SOCCA: specifi-Addison Wesley, pp. 573–582.cations of coordinated and cooperative activities. In

Finkelstein, A., Kramer, J. and Nuseibeh, B. (eds), SoftwareProcess Modelling and Technology, Research Studies Press, Peuschel, B. and Schafer, W. 1992. Concepts andTaunton, UK, pp. 71–102. implementation of a rule-based process engine. In

Proceedings of the 14th International Conference on SoftwareEngineering, Melbourne, Australia, IEEE Computer SocietyFerrandina, F., Meyer, T. and Zicari, R. 1994.

Implementing lazy database updates for an object Press, pp. 262–279.


130


Peuschel, B., Schafer, W. and Wolf, S. 1992. A knowledge- Sutton, S.M., Heimbigner, D. and Osterweil, L. 1990.based software development environment supporting Language constructs for managing change in process-cooperative work. International Journal for Software Engin- centred environments. ACM SIGSOFT Software Engineer-eering and Knowledge Engineering, 2, (1), 79–106. ing Notes, 15, (6), 206–217. Proceedings of the 4th ACM

SIGSOFT Symposium on Software Development Environ-ments, Irvine, Cal.Reiss, S. 1990. Connecting tools using message passing

in the FIELD program development environment. IEEESoftware, July, 57–67.

Valetto, G. and Kaiser, G. 1995. Enveloping ‘persistent’tools for a process-centred environment. In Schafer, W.Sun Microsystems. 1991. Solaris/Moracsa Open Windows:(ed.), Proceedings of the 4th European Workshop on SoftwareThe ToolTalk Service, Sun MicroSystems, Inc.Process Technology, Nordwijkerhout, The Netherlands, vol-ume 913 of Lecture Notes in Computer Science, Springer,Sutton, S., Heimbigner, D. and Osterweil, L. 1994.pp. 200–204.APPL/A: a language for software process programming.

ACM Transactions on Software Engineering and Methodology,4, (3), 221–286.


131

a fine-grained process modelling experiment at british airways

Documents