METHOD MANUAL BASED PROCESS GENERATION AND

VALIDATION

Peter Killisperger

Competence Center Information Systems, University of Applied Sciences - M¨unchen, Germany

Advanced Computing Research Centre, University of South Australia, Adelaide, Australia

Georg Peters

Department of Computer Science and Mathematics, University of Applied Sciences - M¨unchen, Germany

Markus Stumptner

Advanced Computing Research Centre, University of South Australia, Adelaide, Australia

Thomas St¨uckl

System and Software Processes, Siemens Corporate Technology, M¨unchen, Germany

Keywords:

Software process, Instantiation, Automation.

Abstract:

In order to use software processes for a spectrum of projects they are described in a generic way. Due to the

uniqueness of software development, processes have to be adapted to project speciﬁc needs to be effectively

applicable in projects. Siemens AG has started research projects aiming to improve this instantiation of pro-

cesses. A system supporting project managers in instantiation of software processes at Siemens AG is being

developed. It aims not only to execute instantiation decision made by humans but to automatically restore

correctness of the resulting process.

1 INTRODUCTION

Explicitly deﬁned software processes for the devel-

opment of software are used by most large orga-

nizations. At Siemens, business units deﬁne soft-

ware processes within a company-wide Siemens Pro-

cess Framework (SPF) (Schmelzer and Sesselmann,

2004). Because of their size and complexity, they are

not deﬁned for projects individually but in a generic

way as reference processes for application in any soft-

ware project of the particular business unit.

Due to the individuality of software development,

reference processes have to be instantiated to be ap-

plicable in projects. That is, the generic description

of the process is specialized and adapted to the needs

of a particular project. Until now, reference processes

are used as general guideline and are instantiated only

minimally. A more far reaching instantiation is de-

sirable, because manual instantiation is error-prone,

time consuming and thus expensive due to the com-

plexity of processes and due to constraints of the SPF.

Siemens deﬁned an improved instantiation to com-

prise tailoring, resource allocation and customization

of artifacts. The latter is the individualization of gen-

eral artifacts for a project and their association with

ﬁles implementing them.

In order to reduce effort for instantiation consider-

ably, tool support has to be extended. We have devel-

oped a ﬂexible architecture for systems that execute

instantiation decisions made by humans and automat-

ically restore correctness of the resulting process. We

deﬁne a process to be correct when it complies with

the restrictions on the process deﬁned in a method

manual. A method manual is a meta model deﬁning

permitted constructs in a process, derived from orga-

nizational restrictions (e.g. SPF).

In this paper we describe the developed archi-

tecture for instantiation systems executing decisions

256

Killisperger P., Peters G., Stumptner M. and Stückl T. (2009).

METHOD MANUAL BASED PROCESS GENERATION AND VALIDATION.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

256-261

DOI: 10.5220/0002014102560261

 SciTePress

made by humans and restoring correctness of the re-

sulting process. We show the implementation of the

architecture for instantiation of a reference process of

a particular business unit of Siemens AG.

The paper is structured as follows: Section 2 dis-

cusses related work. Section 3 describes the devel-

oped instantiation approach and its architecture. A

case study describing the implementation of the ap-

proach at Siemens AG follows in Section 4. In Sec-

tion 5 we evaluate our approach and draw some con-

clusions in Section 6.

2 RELATED WORK

Instantiation of processes to project speciﬁc needs

has been subject to intensive research in recent years.

In early software process approaches it was thought

that a perfect process can be developed which ﬁts

all software developing organizations and all types of

projects (Boehm and Belz, 1990). It was soon rec-

ognized that no such process exists (Basili and Rom-

bach, 1991), (Osterweil, 1987). Due to the dynamics

of software development, every project has individual

needs. Therefore, the description of a general process

(i.e. the reference process) has to be adapted.

Early approaches to overcome this problem have

been developed e.g. by (Boehm and Belz, 1990)

and (Alexander and Davis, 1991). Many different

approaches have been proposed since then. For ex-

ample, the situational method engineering approach

(ME) (Brinkkemper,1996) emphasizes bottom-up as-

sembly of project speciﬁc methods from fragments,

requiring very detailed fragment speciﬁcations. In

contrary to ME, approaches like SLANG (Bandinelli

and Fuggetta, 1993) regard processes as programs,

enacted by machines (Feiler and Humphrey, 1993).

Although much effort has been put into improving

the adaption of software processes to project speciﬁc

needs, none has become accepted in industry as the

standard so far. An important reason is the variety

of processes used. For instance, (Yoon et al., 2001)

developed an approach for adapting processes in the

form of Activity-Artifact-Graphs. Since the process

is composed of activities and artifacts, only the oper-

ations ”addition” and ”deletion” of activities and ar-

tifacts are supported as well as ”split” and ”merge”

of activities. Another example is the V-Model (BMI,

2004), a process model developed for the German

public sector. It offers a toolbox of process mod-

ules and execution strategies. The approach for de-

veloping a project speciﬁc software process is to se-

lect required process modules and an execution strat-

egy. Due to these dependencies on the Meta mod-

els, none of the existing approaches offers a complete

and semi-automated method for instantiating Siemens

processes.

Since the main purpose of Siemens software pro-

cesses is to offer high level guidance for humans,

adaptation approaches for business processes are also

of interest. Approaches for processes and workﬂows

of higher complexity are often restricted to only a

subset of adaptation operations. For instance, conﬁg-

urable EPCs (C-EPCs) (Rosemann and van der Aalst,

2007) enable customization of reference processes.

However, the approach only allows activities to be

switched on/off, the replacement of gateways and the

deﬁnition of dependencies of adaptation decisions.

(Armbrust et al., 2008) developed an approach for

the management of process variants. A process is

split up in stable parts and variant parts. The pro-

cess is adapted by choosing one variant at the start of

a project. Although the need for further adaptations

during the execution of the process has been identi-

ﬁed, no standardization or tool support is provided.

(Allerbach et al., 2008) developed an approach

called Provop. Processes are adapted by using change

operations which are grouped in Options. Options

have to be predeﬁned and can be used to adapt pro-

cesses, but they do not guarantee correctness.

Existing tools (e.g. Rational’s Method Composer

(RMC) (IBM, 2008)) provide only minimal support

in instantiation. Decisions made by humans have to

be executed mostly manually. Approaches have been

developed making the user aware of inconsistencies

(Kabbaj et al., 2008), but the actual correction of the

process is still left to humans.

3 META MODEL BASED

ARCHITECTURE

In order to improve current situation, we propose an

architecture for instantiation systems that execute in-

stantiation decisions made by humans and automati-

cally restore correctness of the resulting process.

The actual changes in the process are executed

by elemental operations on the process. Examples

are ”Deleting an Activity” and ”Association of a Re-

source with an Activity”. Existing tools allow to per-

form those changes but they do not restore correctness

of the resulting process.

For example: An activity a

is connect by an con-

trol ﬂow to an activity a

which in turn is connected

by an control ﬂow to an activity a

. If a project man-

ager wants to delete a

in most existing tools he re-

moves a

from the process . Additionally, he has to

take care of restoring correctness e.g. establish the

METHOD MANUAL BASED PROCESS GENERATION AND VALIDATION

257

Operation

+name

+executeImplementations()

Implementation

+sequenceOfOperators[]

+checkConditions()

+executeOperators()

Operator

+name

+execute()

Condition

+conditionStatement

+evaluateConditionStatement()

+context

+implementations

ProcessElement

+name

+type

+...

ProcessInstance

+name

+...

+parameter

+elements

Method

Manual

Figure 1: Architecture for Instantiation Systems.

broken control ﬂow between a

and a

, take care of

affected information ﬂows and resource connections.

This task is further complicated by additional restric-

tions on process modeling, e.g. ’an artifact can only

be created by one activity’.

In order to execute instantiation decision and re-

store correctness, the framework must consider the

environment in which a change is performed. For ev-

ery change of a speciﬁc process step instance s the

context of that change is the set of instances and rela-

tionships connected to s. The abstract description of

these entities and relationships for a particular type of

process step is what we call the scope description of

an operation. The scope description can be applied to

the method manual of the process which generates all

contexts an operations can be executed in.

Example: If milestones have restrictions on the

type of entity they can succeed and precede, correct-

ness depends on the preceding and successive element

of the milestone. Thus, the scope description is: Type

of predecessor and type of successor.

Entities and relationships inﬂuencing the way an

operation has to be executed depend on the deﬁnition

of the operation (i.e. changes on a process instance in

order to instantiate it). Therefore the scope descrip-

tion of each operation has to be deﬁned by an human

expert. We propose the following procedure:

1. Identify restrictions on classes of entities of the

method manual directly affected by the operation.

2. Identify classes of entities allowed in the process

having a relationship with the classes of entities

directly affected by the operation.

3. Identify restrictions on related classes of entities

which might be breached by execution of the op-

eration.

From the scope description, all individual contexts

can be automatically generated. Every context has

to be associated with an particular implementation

which executes an operation in this explicit context.

However, not every context requires an individual im-

plementation that is only applicable in this particular

context. From this follows that a number of contexts

can be associated with one implementation.

The approach described above is a general frame-

work for instantiation of processes and is not re-

stricted to Siemens processes or a particular process

deﬁnition language. The way the framework is im-

plemented in detail depends on the requirements of

the applying organization and on the method manual

of the process which led to the developed of architec-

ture described in Figure 1.

The class ProcessInstance corresponds to a

project-speciﬁc software process. A process instance

is created by copying the reference process for a par-

ticular project.

Instances of the class ProcessEntity are the ele-

mental building blocks of a ProcessInstance. They

can be of different types. Examples of the type ”Ac-

tivity” are ”Develop Design Speciﬁcation” or ”Imple-

ment Design”. Entities and thus process instances are

adapted to project speciﬁc needs by running instances

of Operation on them.

The class Operation correspond to instantiation

operations. How an operation is executed on entities

depends on the context in which the affected entities

are nested in the process instance. Thereforeinstances

of Operation can be associated with more than one in-

stance of Implementation. When an Operation is exe-

cuted, the Implementation which relates to the context

at hand is executed.

For ﬁnding an Implementation that relates to a

speciﬁc context Operation.executeImplementations()

calls Implementation.checkConditions() for each of

its implementations. If ”true” is returned, the correct

implementation has been found.

The actual process adaptations are carried out by a

sequence of operators (squenceOfOperators[]) which

ICEIS 2009 - International Conference on Enterprise Information Systems

258

execute the actual changes in the process instance.

Operators are elemental actions which create, update

and removeentities of a process instance. The entirety

of operators is stored in a repository. Their number is

not ﬁxed but can be further extended if necessary.

A context consists of one or several elemental

Condition-instances. An examples of a condition is

<self.source.isType() = ’Activity’> (type of source

element is an activity). In order for a context to be

true, all conditions associated with the context have to

be evaluated true. They do not have to be deﬁned by

humans and their number is limited. Conditions are

elemental statements about states and relationships of

elements. The method manual deﬁnes the set of al-

lowed statements for elements of a process instance.

Conditions are therefore automatically derived from

the method manual. In the next section, the proposed

architecture is implemented for a reference process of

a business unit at Siemens AG.

4 CASE STUDY

The reference process of the particular Siemens busi-

ness unit covers the whole lifecycle of a software

product. It is similar to a workﬂow but its focus is

to be read and understood by human.

The process used in this article is simpliﬁed be-

cause of space limitations. Figure 2 gives an overview

of the allowed classes of elements.

Entities are of the classes StartEvent, ManualAc-

tivity, AutomaticActivity, Milestone, Artifact, Hu-

man, System and splits and joins of the types And,

Or and Xor. They are connected by ControlFlow, In-

formationFlow and ResourceConnection. A method

manual has been deﬁned on the basis of the Siemens

Process Framework (SPF) and on speciﬁc regula-

tions of the business unit. It describes restrictions on

classes and their relationship by using OCL (OMG,

2006).

Operations required for instantiation of the refer-

ence process have been deﬁned by experts of the busi-

ness unit. In the following we focus on one example

by describing how the scope description of the opera-

tion Creating a Resource Connection is deﬁned.

The operation Creating a Resource Connection is

deﬁned as follows: An existing Resource (res) is as-

sociated with an existing Activity (act) by a Resource-

Connection (rc) of the type ExecutesRC, Responsi-

bleRC or ContributesRC. The user has to select the

Resource (res), Activity (act) and the type of the Re-

sourceConnection (rc).

For deﬁning the scope description of the operation

the procedure described in section 3 was used:

1. Identify restrictions on classes of entities of the

method manual directly affected by the opera-

tion.

Creating a ResourceConnection can affect restric-

tions on Flow, ResourceConnection, ExecuteRC, Re-

sponsibleRC and ContributeRC since ResourceCon-

nection has a superclass and subclasses. The method

manual contains the following restrictions for these

classes:

context ExecuteRC

inv: (self.source.oclIsKindOf(Human)

and self.target.oclIsKindOf(ManualActivity))

or (self.source.oclIsKindOf(System)

and self.target.OclIsKindOf(AutomaticActivity))

context ResponsibleRC

inv: self.source.oclIsKindOf(Human)

inv: self.target.oclIsKindOf(Activity)

context ContributesRC

inv: self.source.oclIsKindOf(Human)

inv: self.target.oclIsKindOf(ManualActivity)

In case of ExecuteRC, Human can only be associated

with ManualActivity and System can only be asso-

ciated with AutomaticActivity. In case of Responsi-

bleRC and ContributeRC, only Human can be associ-

ated with ManualActivity or AutomaticActivity.

From this follows that how a new ResourceCon-

nection has to be created depends on the kind of Re-

sourceConnection to be created, the kind of Activity

and the kind of Resource. Thus a ﬁrst part of the

Scope Description is:

rc.isType()

res.isType()

act.isType()

2. Identify classes of entities allowed in the pro-

cess having a relationship with the classes of

entities directly affected by the operation.

By analyzing the statements extracted in step 1 it is

identiﬁed that the classes Activity, AutomaticActiv-

ity, ManualActivity, Human and System have a rela-

tionship with the classes identiﬁed in 1. (Activity has

no explicit restrictions deﬁned in the method manual).

context AutomaticActivity

inv: self.incomingCF->size()=1

inv: self.outgoingCF->size()=1

inv: self.executesRC->size()=1

inv: self.responsibleRC->size()=1

inv: self.contributesRC->empty()

context ManualActivity

inv: self.incomingCF->size()=1

inv: self.outgoingCF->size()=1

inv: self.executesRC->notEmpty()

inv: self.responsibleRC->notEmpty()

inv: self.responsibleRC->size()<=1

context Human

inv: self.incomingCF->empty()

METHOD MANUAL BASED PROCESS GENERATION AND VALIDATION

259

ManualActivity

AutomaticActivity

AndSplit

AndJoin

XorSplit

XorJoin

OrSplit

OrJoin

StartEvent

EndEvent

Milestone

Artifact

HumanParticipant

System

ControlFlow

InformationFlow

ResourceConnection

ExecutesRC

ResponsibleRC ContributesRC

InputIF

UpdateIF

OutputIF

Element

+name: String

+id: String

+incomingCF []: ControlFlow

+outgoingCF []: ControlFlow

+inputIF []: InputIF

+updateIF []: UpdateIF

+outputCF []: OutputIF

+executesRC []: ExecutesRC

+responsibleRC []: ResponsibleRC

+contributesRC []: ContributesRC

Flow

+id: String

+source: Element

+target: Element

Activity

Resource

Event

Split

Join

Figure 2: Classes of Process Entities and their Relationship.

inv: self.outgoingCF->empty()

inv: self.inputIF->empty()

inv: self.updateIF->empty()

inv: self.outputIF->empty()

context System

inv: self.incomingCF->empty()

inv: self.outgoingCF->empty()

inv: self.inputIF->empty()

inv: self.updateIF->empty()

inv: self.outputIF->empty()

inv: self.responsibleRC->empty()

inv: self.contributesRC->empty()

The actually affected properties of the classes are de-

termined through the types of attributes of class Ele-

ment (all four classes are subtypes of Element).

3. Identify restrictions on related classes of enti-

ties which might be breached by execution of

the operation.

By examining the statements from step 2, we can ig-

nore all which are not affected by the creation of a

ResourceConnection.

The number of ExecutesRC and ResponsibleRC

an AutomaticActivity can be associated with is re-

stricted to 1 and no ContributesRC are allowed. Since

these values are static, they do not have inﬂuence on

the way a new ResourceConnection is to be created.

We can ignore restrictions on ExecutesRC, since

ManualActivity does not have a maximum number. A

ManualActivity is only allowed to have either zero or

one ResponsibleRC. Therefore the number of exist-

ing ResponsibleRC has to be taken in consideration.

Since the operation is deﬁned to deal with an instance

of Activity (act) and not ManualActivity, we abstract

to the former.

For Human Resources there are no restrictions re-

garding Creating a ResourceConnection.

System is not allowed to have ResponsibleRC and

ContributeRC associated with it. Since these restric-

tions are static, they can be neglected.

In conclusion the Scope Description of the opera-

tion Creating a Resource Connection is:

rc.isType()

res.isType()

act.isType()

act.responsibleRC.size()

From the Scope Description all possible contexts can

be computed. In the case of the operation Creating

a Resource Connection each combination of all types

of rc, res, act and the number of responsibleRC of act

is regarded as individual context.

Because of space restrictions we cannot detail all

contexts and their implementation for Creating a Re-

source Connection, but make use of a use case:

A resource connection ResponsibleRC (rc) has to

be created between the ManualActivity (act) and the

Human (res). The Activity (act) has another Re-

sourceConnection (rc2) of the same class and one of

the class ExecutesRC.

The speciﬁc context for execution ”Creating a Re-

sourceConnection” in this situation is therefore:

rc.isType() = ResponsibleRC

res.isType() = Human

act.isType() = ManualActivity

act.responsibleRC.size() = 1

The implementation of the Basic Instantiation Opera-

tion for this context is:

delete (rc2)

create ResponsibleRC (act, res)

Since ManualActivity is only allowed to have one Re-

sponsibleRC associated, ﬁrst, rc2 is deleted and then

a new ResponsibleRC (rc) created.

ICEIS 2009 - International Conference on Enterprise Information Systems

260

5 EVALUATION

A prototype of a system for instantiating the refer-

ence process of a Siemens business unit available in

an extended version of XPDL 2.0 (WFMC, 2005) has

been developed. The operations ”Inserting an Activ-

ity” and ”Deleting an Activity” have been chosen for

testing. The architecture has been implemented ac-

cordingly.

For the operation ”Inserting an Activity” the sys-

tem computed 43 contexts from the method manual

and created for each context an instance of Implemen-

tation. Experts deﬁned a sequence of operators for

executing the insertion of an activity. Each implemen-

tation was executed with this sequence. The resulting

process instances were checked by a debugger-class

regarding their conformity to the XML-based method

manual. The tests showed no violations of the result-

ing process instances.

For the operation ”Deleting an Activity” the same

procedure was chosen. The system identiﬁed 49 con-

texts and created the corresponding instances of Im-

plementation. After executing all implementations

with a ﬁrst sequence of operators, 44 resulted in a cor-

rect process. Violations of the remaining were written

to a ﬁle and solved by iteratively developing the cor-

rect sequences of operators for them.

6 CONCLUSIONS

Siemens is currently undertaking research efforts to

improve their software process related activities. Part

of these efforts is the development of a system that

supports project managers in instantiation of refer-

ence processes. The system aims not only to execute

decisions but to restore correctness of the resulting

process. Since the implementation of such a system

is organization-speciﬁc and depends on the permitted

constructs in the process, a ﬂexible architecture has

been developed and described in this paper. The ap-

proach was applied to a reference process of a busi-

ness unit at Siemens AG and its feasibility was veri-

ﬁed by the implementation of a prototype.

ACKNOWLEDGEMENTS

This work was partially supported by a DAAD post-

graduate scholarship.

REFERENCES

Alexander, L. and Davis, A. (1991). Criteria for selecting

software process models. In Proceedings of the Fif-

teenth Annual International Computer Software and

Applications Conference, pages 521528.

Allerbach, A., Bauer, T., and Reichert, M. (2008). Manag-

ing process variants in the process life cycle. In Pro-

ceedings of the Tenth International Conference on En-

terprise Information Systems, volume ISAS-2, pages

154161.

Armbrust, O., Katahira, M., Miyamoto, Y., Munch, J.,

Nakao, H., and Ocampo, A. (2008). Scoping software

process models - initial concepts and experience from

deﬁning space standards. In ICSP, pages 160172.

Bandinelli, S. and Fuggetta, A. (1993). Computational re-

ﬂection in software process modeling: The slang ap-

proach. In ICSE, pages 144–154.

Basili, V. and Rombach, H. (1991). Support for comprehen-

sive reuse. Software Engineering Journal, 6(5):303–

316.

BMI (2004). The new v-modell xt - development stan-

dard for IT systems of the federal republic of ger-

many. URL: http://www.v-modell-xt.de (accessed

01.12.2008).

Boehm, B. and Belz, F. (1990). Experiences with the spiral

model as a process model generator. In Proceedings

of the 5th Intern. Software Process Workshop ’Experi-

ence with Software Process Models’, pages 43–45.

Brinkkemper, S. (1996). Method engineering: engineer-

ing of information systems development methods and

tools. Information & Software Tech., 38(4):275–280.

Feiler, P. H. and Humphrey, W. S. (1993). Software pro-

cess development and enactment: Concepts and deﬁ-

nitions. In ICSP, pages 28–40.

IBM (2008). Rational method composer. URL:

http://www-01.ibm.com/software/awdtools/rmc/ (ac-

cessed 26.11.2008).

Kabbaj, M., Lbath, R., and Coulette, B. (2008). A deviation

management system for handling software process en-

actment evolution. In ICSP, pages 186–197.

OMG (2006). Object constraint language v 2.0.

URL: http://www.omg.org/spec/OCL/2.0/ (accessed

15.11.2008).

Osterweil, L. J. (1987). Software processes are software

too. In ICSE, pages 2–13.

Rosemann, M. and van der Aalst, W. (2007). A conﬁgurable

reference modelling language. Information Systems,

32(1):1–23.

Schmelzer, H. and Sesselmann, W. (2004).

Gesch¨aftsprozessmanagement in der Praxis: Produk-

tivit¨at steigern - Wert erh¨ohen - Kunden zufrieden

stellen. Hanser Verlag, Muenchen, 4 edition.

WFMC (2005). WFMC-TC-1025-03-10-05 Speciﬁcation

for XPDL v2.0. URL: http://www.wfmc.org (ac-

cessed: 28.11.2008).

Yoon, I.-C., Min, S.-Y., and Bae, D.-H. (2001). Tailor-

ing and verifying software process. In APSEC, pages

202209.

METHOD MANUAL BASED PROCESS GENERATION AND VALIDATION

261