Resource-oriented Consistency Analysis of Engineering Processes

∗

Bernhard Bauer, Thomas Eisenbarth, Christoph Frenzel and Benjamin Honke

Programming Distributed Systems Lab, Institute of Computer Science, University of Augsburg, Augsburg, Germany

Keywords:

Ontologies, Method Engineering, Process Management, Enterprise Knowledge Management.

Abstract:

A number of popular engineering processes and methodologies emerged over the past years which attracted

interest in research and industry. For process enactment, enterprises have to match requirements of engineering

processes with existing resources. Therefore, it has to be analyzed if employees have sufﬁcient skills or if

infrastructure has sufﬁcient capabilities to match the requirements of a situational process. Both, maintaining

a skill and resource database and matching requirements against this database are an enormously challenging

and time-consuming task. Additionally, this matching has to be carried out regularly as employees join and

leave the company and skills change over time. Based upon a formal, logical base, we present an approach that

combines ontological and metamodeling technical spaces and enables an automatic analysis of engineering

processes regarding the existence of necessary resources.

1 INTRODUCTION

Today, a reasonable number of standardized soft-

ware engineering methodologies, such as the V-

Model XT (Friedrich et al., 2008) or the automotive-

speciﬁc methodology of AUTOSAR (AUTOSAR

Consortium, 2011), and reference processes, such as

SPICE (Dorling, 2007) or CMMI (CMMI Product

Team, 2011), exist for various domains. They usually

deﬁne engineering methods by combining process

knowledge about input/output products and required

resources, such as technical infrastructure (e.g., tools

and laboratories) and human skills (e.g., roles and re-

sponsibilities). Usually, enterprises can choose from

a variety of skills and a large number of infrastructure

components providing lots of capabilities, which can

be used to fulﬁll project-speciﬁc requirements and to

put processes into action.

Matching the requirements of engineering pro-

cesses with existing enterprise resources is a people-

intensive and error-prone task. It is not only neces-

sary to have in-depth domain knowledge about skills,

which are necessary to fulﬁll certain roles and re-

sponsibilities, but also innovative methodologies of-

ten create new resource demands. Additionally, re-

sources and skills in a company change frequently due

to shifting business and IT requirements, staff ﬂuctua-

∗

Grateful acknowledgement is due to the DFG (German

Research Foundation) for their support of the project BU

809/7-2 SEMPRO

making this paper possible.

tion, and employee training. Therefore, matching the

necessary resources of a process with the available re-

sources in a company has become a regular task in or-

der to decide whether a development process can be

executed.

In this paper, we present an approach for the auto-

matic resource-oriented analysis of engineering pro-

cesses w.r.t. the required resources of a process and

available resources in a company. This is achieved

through the utilization of semantic technologies, es-

pecially logical reasoning. Therefore, we combine

two models, which are expressed in two separate

Technical Spaces (TSs): process models are normally

represented in the Metamodeling Technical Space

(MMTS), whereas a model of the existing resources is

expressed in the Ontological Technical Space (OTS).

Both models are linked via a bidirectional mapping

which translates between both TSs. In contrast to

complex resource planning approaches, our resource

analysis approach is supposed to offer a fast and

lightweight evaluation, if a company has, in princi-

ple, the necessary resources to execute a given pro-

cess. That is, instead of planning the execution of

process actions, our approach validates, that at least

one resource exists for each resource requirement of a

process. This means, that we neglect time constraints

induced by, e.g., concurrently executed process ac-

tions or processes. Additionally, this focus enables

the presented approach to be used with less detailed

processes, as well. The result of the resource analy-

206

Bauer B., Eisenbarth T., Frenzel C. and Honke B..

Resource-oriented Consistency Analysis of Engineering Processes.

DOI: 10.5220/0003984302060211

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 206-211

ISBN: 978-989-8565-12-9

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

sis is a set of non-executable process actions and the

according missing resources.

Using the presented approach, companies are ca-

pable of facing the following challenges:

1. Assurance of Consistency of Particular Project

Requirements with Internal (or External) Re-

sources. Even prior to project realization, project

managers must know, whether or not a project-

speciﬁc process can be realized based on existing

resources. By applying our resource-based analy-

sis, an automated and detailed consistency evalu-

ation becomes possible. Therefore, project teams

with ﬁtting skills can be arranged more purpose-

fully.

2. Assurance of Standard Compliance According to

Existing Resources. Process improvement frame-

works, such as SPICE or CMMI, deﬁne the avail-

ability of particular artifacts and the execution of

dedicated activities. This often neglects that all

activities are enabled and executed by resources,

which must exist, too. By applying the automated

resources analysis, the feasibility (often also re-

ferred to as consistency) of all activities and the

artifacts can be ensured.

3. Provision of a Company- or Customer-speciﬁc

Resource Delta Analysis. By applying a

company-wide resource analysis, it is possible

to determine missing resources in a company to

reach a particular compliance level or some other

resource-related goal.

2 FOUNDATIONS

As Process Models (PMods) often lack semantical

knowledge, our approach combines beneﬁts of the

MMTS and the OTS (cf. (Kurtev et al., 2002)) as in-

troduced in the following sections.

2.1 Ontological Technical Space

Originally designed for knowledge representation,

semantic technologies are built upon logical struc-

tures, which are used by specialized reasoning soft-

ware to check for consistency and to infer new facts.

These knowledge representations are called ontolo-

gies, which in turn describe entities and relations in

a speciﬁc domain (Uschold and Gruninger, 1996).

Accepted standards deﬁned by the W3C include

Resource Description Framework (RDF), which is

used for conceptual description and modeling of in-

formation. Web Ontology Language (OWL) and

the subsequent version OWL 2 are languages for

more powerful knowledge description in ontologies

as well (Grau et al., 2008).

A number of popular modeling tools for ontolo-

gies such as Prot

e, NeOn Toolkit or KAON for in-

tuitive deﬁnition of information and relations within a

ontology exist. Subsequently such tools were heavily

used to build large ontologies. Related technologies,

standards, and tools for this knowledge representa-

tion quickly emerged, and established this branch of

research area as a well-recognized area of computer

science over the past years.

2.2 Method Engineering and the

Metamodeling Technical Space

In software engineering, Method Engineering (ME)

is a discipline, which concerns the design and man-

agement of product development from the inception

of a product to its maintenance. ME intends to pro-

vide contingent ways of thinking, i.e., methods, which

realize concrete products, artifacts, or other deliver-

ables, in an appropriate way (Henderson-Sellers and

Ralyt

e, 2010). Several methods and their outcomes

are combined in the course of an project-speciﬁc sit-

uational process, afterwards.

For structuring relevant facets of a method, au-

thors, such as Mirbel et al. (Mirbel and Ralyt, 2005),

introduced the term Method Chunk (MC). Ac-

cording to the meta model, which was proposed

by Henderson-Sellers et al. (Henderson-Sellers and

Gonzalez-Perez, 2008) (cf. 1 (a)), a MC aggregates

different types of method fragments. Originally, a

MC was deﬁned to consist of a product fragment

to deﬁne relevant information objects, and a process

fragment to describe the steps for manipulating infor-

mation in a required manner. However, various au-

thors (cf. (Harmsen, 1997; IEEE Computer Society

Press, 2001)) have recognized the need for additional

fragments to detail a method considering its required

resources, such as roles (i.e., human-related factors)

and tools (i.e., infrastructure-related factors). For ex-

ample, in the well-known model deﬁnition language

Business Process Modeling Notation (BPMN) 2 (Ob-

ject Management Group, 2011), resources could be

expressed by using swimlanes. Although, this way to

model resource requirements is not capable of com-

plex skill deﬁnitions and lacks further semantics.

3 APPROACH

In a nutshell, our approach for analyzing the feasibil-

ity of processes is the following: given a model of

Resource-orientedConsistencyAnalysisofEngineeringProcesses

207

b) a)

Method Component

Resource FragmentProcess Fragment Product Fragment

Method Chunk Method Fragment

refers_to

requires

Cardinality

Resource Reference

Figure 1: Meta model for method components according to (Henderson-Sellers and Gonzalez-Perez, 2008) extended by

Resource Fragment.

the process and a semantic model of the available re-

sources within a company or department, we utilize

semantic technologies, especially logical reasoning,

in order to come up with infeasible MCs and the re-

spective missing resources. Therefore, both MMTS

and OTS need to be integrated via a mapping. 2 de-

picts an overview of the concept with its three build-

ing blocks: PMod, Resource Ontology (ROnt), and a

mapping between these two worlds.

3.1 Process Model

The metamodel of Henderson-Sellers et

al. (Henderson-Sellers and Gonzalez-Perez, 2008)

does not consider the deﬁnition of resource re-

quirements for MCs. Therefore, we extended the

metamodel with a Resource Fragment (RF) as shown

in 1 (b). The additional fragment indicates, that the

selection of a MC is affected by resource-related

factors, as well. Similar to product and process

fragments, the RF is a container that holds detailed

resource-related information, which in turn depend

on the applied process deﬁnition metamodel. Put

simply, an RF contains various resources, which are

necessary to support the realization of the assigned

MC. The information about resources is twofold:

on the one hand, the RF holds an Resource Refer-

ence (RR) which represent speciﬁc roles or tools,

and, on the other hand, an RR provides a cardinality

attribute to indicate the required quantity of the

respective resource. For example, a method such as

double-blind review needs two roles of the same type

to realize the four-eyes principle.

The left part of 2 shows the PMod, which repre-

sents a concrete process on a syntactical level in the

MMTS, in the context of our approach. The process

is realized using MCs, which are composed of three

types of method fragments. Because of space limi-

tations, we solely depict RRs, which are assigned to

the respective MC via a not shown RF using a re-

quires relation. The RR symbols show both, the car-

dinality as a hash symbol # on top and the name of

the resource below. Note that, for clarity reasons, we

are distinguishing between roles, i.e., employees with

speciﬁc skills, and tools, i.e., infrastructural capabil-

ities. However, since the approach presented here is

generic regarding the concrete method deﬁnition lan-

guage, this is not a requirement for a potential method

deﬁnition approach.

3.2 Resource Ontology

The right part of 2 depicts the ROnt, i.e., a model of

the resources within a company or department repre-

sented in the OTS. On the one hand, this model con-

ceptualizes company-internal resources, and builds up

a resource taxonomy of skills and infrastructural capa-

bilities. On the other hand, it also comprises the re-

source pool of the company, i.e., concrete employees

and infrastructure. By putting both in one ontology,

it is possible to assign each employee to the skills he

or she has and, respectively, assign each tool to the

capabilities it provides.

The resource taxonomy is a hierarchical deﬁnition

of the skills and capabilities that exist within a com-

pany. Thereby, skills refer to concrete knowledge, ca-

pabilities, or access rights an employee might have,

e.g., tax law knowledge, project management skills,

or access rights to personnel ﬁles. In order to come up

with a reasonable taxonomy of the skills, they should

be categorized and aggregated to umbrella terms. For

instance, the skills Java programming and C program-

ming are classiﬁed under the skill programming lan-

guages. The same ideas apply to the taxonomy of ca-

pabilities. A capability refers to a functionality of in-

frastructure components within the company. The in-

formation for building the resource taxonomy can be

gathered from experiences or knowledge of experts,

or from bodies of knowledge like (Abran et al., 2005).

The resource pool is a collection of concrete

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

208

Resource Taxonomy

Role A

Role B

requires

Tool A

Role A

Role B

≡

Metamodeling Technical Space Ontological Technical Space

Resource Pool

Skill

Skill A

Skill B

Capability

Cap A

Cap B

Staff

PPS A

Infrastructure

PPS B

hasSkill

hasCapability

∧

Skill A

Skill A Skill B

Cap A

∧

Mapping

Staff

Tool

Resource OntologyProcess Model

Method

Chunks

Resource

Fragments

Tool A

requires

Figure 2: Concept of the resource-oriented analysis of processes.

members of staff and instances of tools (depicted as

hexagons in 2) within the company or department.

For instance, there can be a representation of the real

employee Bob and the Laboratory X. Each member of

staff and tool is linked to the skills and capabilities it

provides via a hasSkill or hasCapability relationship,

respectively. This allows the concrete speciﬁcation of

the abilities of the company’s resources. Furthermore,

there can be concepts, which deﬁne a speciﬁc set of

skills or capabilities, respectively. They are called

Predeﬁned Property Sets (PPSs) and depicted as el-

lipses in 2. For instance, a concept software archi-

tect can deﬁne that an assigned employee has both a

programming language skill and project management

skill. This way, it is possible to represent company-

speciﬁc job titles. Actually, PPSs can be seen as short-

cuts for skill assignment by assigning a member of

staff to them instead of single skills.

All in all, the ROnt acts as a skill database for hu-

man resources and, additionally, contains equipment

and tools including their respective capabilities. This

knowledge base is developed for a company once, and

has to be kept up to date. Subsequently, it can be ex-

ploited in our approach to validate the feasibility of

processes from a resource-oriented point of view.

3.3 Mapping

In order to exploit the ROnt for a feasibility analy-

sis of a process, a translation between the RRs in the

PMod and the skills and capabilities in the resource

taxonomy is necessary. This is provided by the map-

ping depicted in the middle of 2. It is a separate on-

tology and, therefore, technically belongs to the OTS.

The basic idea of the mapping is to deﬁne a RR as an

aggregation of concepts from the resource taxonomy,

i.e., skills or capabilities.

A mapping between concrete RRs and concrete

skills or capabilities is represented as an ontological

equivalence. Each RR is represented as a distinct con-

cept in the mapping. Thereby, the matching between

RRs in the OTS and in the MMTS can be based on,

e.g., name equality. Now, the ontological RR is de-

ﬁned to be equivalent to either an employee with a set

of skills or a tool with several capabilities. An exam-

ple of a mapping is:

software architect is equivalent to Staff

and hasSkill software

architecture

and hasSkill project management .

To enable the usage of the resource taxonomy in the

mapping, it imports the whole ROnt. Hence, no spe-

ciﬁc matching between skills and tools in the map-

ping, and in the resource taxonomy is necessary be-

cause both reside in the OTS.

In general, the set of skills and capabilities for a

RR is interpreted as a conjunction, i.e., the employee

or tool has to have all stated skills or capabilities.

However, depending on the expressiveness of the uti-

lized ontology language, this simple semantics can

be extended by more complex structures like disjunc-

tions. This allows to express a logic like a require-

ments engineer has a skill in use cases or user stories.

Note that the mapping deﬁnes a translation for RRs,

hence, the cardinalities for the RFs are neglected.

The mapping can be seen as the deﬁnition of a

matching between the RRs, i.e., RFs, of a speciﬁc

method deﬁnition language and the resource taxon-

omy of a company. Hence, the approach of decou-

pling both PMod, and ROnt allows reusing the com-

pany’s body of knowledge for analyzing the feasibil-

ity for processes independently from the used method

deﬁnition language. It is solely necessary to deﬁne the

mapping once for each combination of method def-

Resource-orientedConsistencyAnalysisofEngineeringProcesses

209

inition language and resource taxonomy. Note that,

however, it has to be ensured that the names of the

RRs in the language are unique, i.e., no two different

RRs have the same name.

3.4 Ontology-based Resource Analysis

Once the ROnt,i.e.existing resources within a com-

pany or department, and the mapping are deﬁned as

outlined above, this knowledge can be exploited to

analyze the feasibility of a project-speciﬁc situational

PMod w.r.t. the required resources of contained MCs.

Thereby, the deﬁnition of the ROnt and the mapping

in the OTS turns out to be an enormous advantage

due to reasoning which enables the automation of this

task.

The algorithm for computing feasibility of process

models works as follows: Given some PMod, it re-

turns the set of MC–RR pairs, which cannot be ful-

ﬁlled by any employee or tool from the resource pool.

In a nutshell, it checks whether each and every MC in

the process deﬁnition can be executed, i.e., whether

there are enough resources in the resource pool for

the RF assigned to the MC. Speciﬁcally, the feasi-

bility is analyzed by querying all resources from the

resource pool, i.e., staff or tools, which match the re-

quired RRs of the RF and comparing their count with

the cardinalities.

In order to gather the number of resources, which

match a RR, the algorithm queries the ROnt. Behind

the scenes, this query matches the RR in the MMTS

to the RR concept in the mapping, i.e., the OTS. As

outlined in 3.3, this can be done using name equality.

Subsequently, this concept can be translated via the

mapping into either an employee with a given set of

skills or a tool with a speciﬁc set of capabilities. Us-

ing logical reasoning, the resource pool can now be

queried for all resources, i.e., staff or tools, which ful-

ﬁll this deﬁnition. The resulting resources are counted

and their number returned to the algorithm.

The result of the algorithm is, that all infeasible

MCs with the respective RRs, that cannot be fulﬁlled

by the resources in the resource pool, are marked as

infeasible in the given PMod. This information can

be utilized by the user to either redesign the process,

e.g., replacing the infeasible MCs, planning a train-

ing program for developing the missing skills, or pur-

chase new or improve the available tools. Note, that

the current algorithm does not provide the speciﬁc re-

sources from the resource pool, which can perform a

given MC. However, it is straightforward to exploit

the ROnt and mapping for this task, as well.

4 DISCUSSION AND RELATED

WORK

The need to conceptualize enterprise knowledge has

been identiﬁed some time ago (Fox and Gruninger,

1998). However, most of this work focuses on ei-

ther the MMTS or OTS only. On the one hand,

methodological frameworks were developed to ag-

gregate the particular interests of a company, such

as applied processes, resources, guidelines, or prod-

ucts, and to beneﬁt from available information in

future projects. Some approaches are used to val-

idate new PMods, or to evaluate the feasibility of

projects by comparing company-speciﬁc capabilities

with project-speciﬁc needs (Gruhn, 1991; Hug et al.,

2008). They validate regarding deadlocks, availabil-

ity of artifacts, or the reachability of dedicated goals

based on the static structure of PMods. While those

approaches do validate the availability of human or in-

frastructural resources through simple structural syn-

tactical checks (e.g., comparing identiﬁers), most of

them neglect the advantages of incorporating seman-

tic knowledge and formal deﬁnition of such.

There has been work done presenting an interest-

ing possibility to advance ways to model resources

within graphical notation languages (BPMN 2 in

this case). Although, it covers humans resources

only (Cabanillas et al., 2011).

On the other hand, some approaches exclusively

focus on the need for managing company-internal or

-external resources using semantic technologies (cf.

(Fadel et al., 1994; Dorn et al., 2007; Hepp and Ro-

man, 2007)). Although, these approaches provide

frameworks for managing resources, to the best of our

knowledge, none of these relates engineering PMods

with ontological resource management.

Through loose coupling between MMTS and

OTS, existing PMods and ontologies can be used

without expensive modiﬁcation or information loss.

Besides the deﬁnition of the mapping, efforts can be

reduced to a minimum, and well-known design prin-

ciples can be used in both TSs. The application of

reasoning techniques reduces the efforts to search for

particular resources manually. By determining the ca-

pabilities and skills of a speciﬁc resource concept in

the ontology, all available resources of a company can

be classiﬁed automatically, which provides project

managers with most recent information about avail-

able resources and bottlenecks regarding the needs of

some project. Even monitoring activities may bene-

ﬁt from our approach: as the capabilities of particu-

lar resources can automatically be inferred, resource

ﬂuctuations, i.e., changes in the resource pool, di-

rectly inﬂuence actual projects by propagating rele-

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

210

vant changes to project managers, which are respon-

sible for a respective mapped process fragment.

5 CONCLUSIONS

In this paper, we proposed an approach to analyze en-

gineering processes regarding their feasibility based

on a semantically-deﬁned resource ontology. We suc-

cessfully evaluated our approach in a separate case

study, which we removed here due to space limita-

tions. Our approach demonstrated, that process mod-

els from the MMTS can be combined with seman-

tical knowledge from the OTS to assure, that pro-

cess resource demands are met. Furthermore, reason-

ing within a formal resource ontology reduces efforts,

which normally are necessary to manage highly ﬂuc-

tuating company resources. We presented two pos-

sibilities of deﬁning skills for resources and deﬁned

a matching approach between the TSs. While most

similar approaches allow deﬁnition and consideration

of human resources only, our approach allows deﬁni-

tion of all kinds of resources.

Our future research will focus on resource-

oriented planning and scheduling of engineering pro-

cess. Therefore, we plan to analyze control ﬂow

mechanisms of workﬂows to provide more detailed

assertions about timing behavior or to optimize costs

based on existing resources. That way, more so-

phisticated analyses of the processes’ resource factors

should help to efﬁciently tailor processes not only re-

garding their application scenarios, but also consider-

ing available resources. By considering the average

processing time of MCs gathered from workﬂow en-

gine logﬁle analysis as well as resource existence, we

plan to expand our approach to provide sophisticated

resource scheduling functionalities.

REFERENCES

Abran, A., Moore, J. W., Bourque, P., and Dupuis, R., edi-

tors (2005). Guide to the Software Engineering Body

of Knowledge. IEEE Computer Society Press.

AUTOSAR Consortium (2011). AUTOSAR. Ofﬁcial web-

site of the AUTOSAR development partnership.

Cabanillas, C., Resinas, M., and Ruiz-Cort

es, A. (2011).

Towards the deﬁnition and analysis of resource as-

signments in BPMN 2.0. International Conference on

BPM.

CMMI Product Team (2011). CMMI. CMMI Main page

managed by SEI.

Dorling, A. (2007). Spice: Software process improvement

and capability determination. Software Quality Jour-

nal, 2(4):209–224.

Dorn, J., Naz, T., and Pichlmair, M. (2007). Ontology de-

velopment for human resource management. In Stary,

C., Barachini, F., and Hawamdeh, S., editors, Knowl-

edge Management Innovation Technology and Cul-

tures, pages 109–120. World Scientiﬁc Publishing Co.

Pte. Ltd.

Fadel, F. G., Fox, M. S., and Gruninger, M. (1994). A

generic enterprise resource ontology, pages 117–128.

IEEE Comput. Soc. Press.

Fox, M. S. and Gruninger, M. (1998). Enterprise modeling.

AI Magazine, 19(3):109–121.

Friedrich, J., Hammerschall, U., Kuhrmann, M., and Sih-

ling, M. (2008). Das V-Modell XT. Springer.

Grau, B. C., Horrocks, I., Motik, B., Parsia, B., Patel-

Schneider, P., and Sattler, U. (2008). OWL2: The

Next Step for OWL. Journal on Web Semantics,

6(4):309 – 322.

Gruhn, V. (1991). Validation and veriﬁcation of software

process models. In Endres, A. and Weber, H., editors,

Software Development Environments and CASE Tech-

nology, pages 271–286. Springer.

Harmsen, A. F. (1997). Situational method engineering. Re-

quirements Engineering, 5(9):167–78.

Henderson-Sellers, B. and Gonzalez-Perez, C. (2008).

Comparison of Method Chunks and Method Frag-

ments for Situational Method Engineering, pages

479–488. IEEE Computer Society.

Henderson-Sellers, B. and Ralyt

e, J. (2010). Situational

Method Engineering: State-of-the-Art Review. Jour-

nal Of Universal Computer Science, 16(3):424–478.

Hepp, M. and Roman, D. (2007). An ontology framework

for semantic business process management. Informa-

tion Systems Journal, pages 1–18.

Hug, C., Front, A., and Rieu, D. (2008). A process engi-

neering method based on ontology and patterns. In

ICSOFT (ISDM/ABF)’08, pages 29–36.

IEEE Computer Society Press, editor (2001). Model driven

process engineering.

Kurtev, I., Bezivin, J., and Aksit, M. (2002). Technological

spaces: An initial appraisal. In Editors, editor, Lan-

guage, volume 2002, pages 1–6.

Mirbel, I. and Ralyt, J. (2005). Situational method engineer-

ing: combining assembly-based and roadmap-driven

approaches. Requir. Eng., 11:58–78.

Object Management Group (2011). Business process model

and notation. OMG document.

Uschold, M. and Gruninger, M. (1996). Ontologies: Princi-

ples, methods and applications. Knowledge Engineer-

ing Review, 11:93–136.

Resource-orientedConsistencyAnalysisofEngineeringProcesses

211