CONTEXT-BASED PROCESS LINE

Vanessa Nunes, Claudia Werner

COPPE/UFRJ – Systems Engineering and Computer Science Program

Rio de Janeiro, RJ - P.O. Box 68511 - Brazil

Flavia Maria Santoro

NP2Tec and Postgraduate Information Systems Program – UNIRIO

Av. Pasteur 458, Urca – Rio de Janeiro, RJ – Brazil

Keywords: Business Process Line, Context, Process Dynamic Adaptation.

Abstract: Complexity and dynamism of day-to-day activities in organizations are inextricably linked, one impacting

the other, increasing the challenges for constant adaptation of the way to organize work to address emerging

demands. In this scenario, there are a variety of information, insight and reasoning being processed between

people and systems, during process execution. We argue that process variations could be decided in real

time, using context information collected. This paper presents a proposal for a business process line cycle,

with a set of activities encapsulated in the form of components as central artefact. We explain how

composition and adaptation of work may occur in real time and discuss a scenario for this proposal.

1 INTRODUCTION

Organizations search for continuous development in

order to adapt to the highly competitive market.

Complexity and dynamism of day-to-day activities

are inextricably linked, increasing the challenges for

constant adaptation of the way to organize work to

address emerging demands. When it comes to

information systems, we observe that market is

demanding systems to be quickly developed and

able to evolve and adapt to new situations in

everyday life (Grisogono, 2006).

A process-aware information system (PAIS) can

be defined as “a software system that manages and

executes operational processes involving people,

applications, and information sources on the basis of

process models" (Dumas et al., 2005). According to

La Rosa (2009), PAIS are becoming pervasive in the

business environment and system focus has shifted

from the data-driven approaches to a more holistic

notion of a business process. Several authors note

that the systematic reuse and adaptation can also be

applied to business processes (Montero et al., 2007).

Within this scenario, La Rosa (2009) states that the

decision associated with a variation point in a

process is placed at design time; thus not based on

data values available when the process is performed.

Moreover, there is a variety of information and

reasoning handled among people and systems,

during process execution that characterizes specific

situations such as work requirements changes. We

called these events “context”. The concept of

"context" emerges as an approach to support the

discussion of business issues and thereby optimize

the adaptation of work processes in real time, using

context information collected.

We propose to implement this view within a

process line approach and this paper aims to

describe a business process line cycle which has a

set of activities encapsulated in the form of

components. We argue thereafter how adaptation of

work processes and the derivation of PAIS may

occur in real time.

2 PAIS WITHIN A PROCESS LINE

APPROACH

Process Line is a set of process components,

organized to represent common and variants parts

(set of activities) within a specific domain, that can

be reused and combined, according to rules to

compose and adapt processes dynamically

277

Nunes V., Werner C. and Santoro F. (2010).

CONTEXT-BASED PROCESS LINE.

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

277-282

 SciTePress

(Rombach, 2006; Washizaki, 2006). A process

component is an encapsulation of information and

behaviours under a certain granularity level (Gary

and Lindquist, 1999), (Fusaro et al., 1998). Process

Line Engineering involves the use of models,

procedures, architecture and technology that build,

operate and manage a process line, such as software

product line (SPL) (Clements and Northrop, 2001).

Process Family Engineering (PFE) is an

approach (Bayer et al., 1995) that aims to enable the

production of processes, where each product is a set

of processes enabled at a certain time. It produces a

system that evolves at runtime, where the features

are processes, and contains all the family features.

Montero et al. (2007) present the Business

Family Engineering (BFE) to explore the feasibility

of adapting SPL techniques to Business-Driven

Development (BDD), oriented to reuse processes,

across different businesses. BFE can be defined as: a

set of software systems driven by business processes

where each product of the family has a set of

common processes and a set of variable processes.

They concluded that PFE is useful for managing

single businesses, however not for a set of

businesses (BFE). Rombach (2006) presents SPPL

(software product and process line) engineering

where artifacts and processes (organized in

similarities and differences) can be chosen based on

a set of product and process requirements and

constraints. Washizaki (2006) proposes a process-

tailoring technique which intends to solve problems

with component-based approaches by building a

Process- Line Architecture (PLA) in order to derive

project-specific processes, combining and reusing

core processes and variants for a particular domain.

We propose to use context information as a way

of supporting recognition and composition of

processes, improving a process line use and

management. The concept of context used is based

on Dey et al. (2001) which represents any

information that can be used to characterize the

situation of an entity. Its importance is due to the

ability to provide greater meaning to work, facts,

artifacts, and decisions taken in business process.

The more the perception of context is improved, the

greater is the support for activities implementation in

a work process, as well as the specification and

development of systems that support the work.

Dynamic adaptation of processes is one of the

goals for the use of process lines due to the fact that

when organization´s processes are well known, it is

possible to make changes at runtime in order to

adapt to new situations. So, we define the concept of

process line based on context as process

components, organized to represent common and

variants parts (set of activities) within a specific

domain that can be reused and combined, according

to rules and based on changes in the context of

people, systems and environments, to compose and

adapt processes dynamically. Next section describes

the details of the proposal.

3 A CONTEXT-BASED PROCESS

LINE

The approach for the context-based process line

engineering, depicted in Figure 1, was structured

similarly to the SPL phases (Clements and Northrop,

2001; Kang et al., 1990) and previous proposals by

Barreto (2007), Rombach (2006), and Schnieders

(2006). As Rombach (2006) stated, we would, by

means of a domain engineering process, create a

generic (set of) process(es) that capture the

commonalities and variabilities across a domain.

Domain Engineering comprises Analysis, Design

and Implementation of the domain. It is achieved

through two possible scenarios: first when there is a

need to establish a process line, and second when

requirements, needs and goals change, promoting

the evolution of the process line. In both scenarios,

these information, as well as process models and/or

reference models, serve as input.

The three possible inputs for domain analysis

originated from two approaches (Washizaki, 2006):

bottom-up and top-down. In the first, organization

process models are used to create the process line. In

the other, it starts from scratch, based on reference

models,to form new processes. We adopted the so

called meet-in-the-middle, combining both two

(Jaufman and Münch, 2005).

3.1 Context-based Process Line Phases

Domain Analysis aims to generate, the semantic

relationships between the concepts used in the

business processes, and thus make possible the use

of them in organization. From the understanding of

the concepts it is possible to identify context

information considered relevant to describe the

actions that occur, while performing work activities.

The element "context model" provides an explicit

representation of contextual knowledge that is being

captured. According to Nunes et al. (2009),

determining the information necessary for the

composition of the context is not a trivial activity

because it depends on the situation. External factors

such as artifacts produced, discussions, messages

exchanged and actions taken are relatively simple to

be identified and caught.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

278

Application Analysis

Domain ImplementationDomain Analysis Domain Design

Requirements /

Needs / Goals

Process Architecture

Context and

composition

Rules

Activi

Variation

points

Commonalities

Context

Repository

Actual Context

Requirements /

Needs / Goal

Cut Feature

model

Application Design

Composed

process

Application Implementation

Implemented

composed process

A A

Process

components

model

A A

Context and

composition Rules

Context Definitions

Process

models

repository

Reference

models

A A

Process components

model

A A

Feature

model

Context

model

Domain

model of

knowledge

Figure 1: Context-based process line engineering approach.

However, individual aspects (interests, goals,

experiences, etc.) are difficult to carry out. Also, to

increase the awareness about the context and make it

also computationally interpretable, it must be

represented in a formal language. Finally, based on

concepts and context understanding, and

organization’s requirements, needs and goals it is

possible to define the features that represent domain

characteristics of a process.

Domain Design is the most important phase of

process line, since activities and processes are

identified, i.e. what is core and what may vary

(target for changes). The basic process (template) is

defined, both from organization process models, and

from reference models. For each process it is

necessary to identify the commonalities and

variation points and identify where a component

begins and ends. The outcome of this phase is

components containing activities invariants and

variants, internal properties and interfaces with other

components, and composition rules.

Domain Implementation involves building

process architecture and context repository from the

artifacts generated in the design. The architecture

provides the elements, patterns, and framework for

any level of detail (Barreto, 2007). The architecture

is implemented to be used in the composition and

adaptation of processes, according to the

composition and context rules established.

In Application Engineering phase, the process is

effectively implemented and is ready to run and

adapted at run time. First, in Application Analysis,

from the current context, and the specific current

requirements that must be met, the features are

selected for the new process to be composed. The

outcome is the feature model, containing only the

selected features.

In Application Design, based on the selected

features and the existing similar projects contexts,

process components are selected to be combined

within the architecture The composed process

consists in a new component that can be also reused

in compositions and adaptations of processes. Thus,

it is incorporated into the process architecture.

Finally, in Application Implementation the

process is implemented, for example as a process-

aware information system, so as to be systematically

managed by context mechanisms.

This proposal supports the analysis of user’s

context responsible for the process and the team that

understands the needs of the projects process. But, to

increase the context perception it is necessary to

specify the contextual knowledge, represent it in a

standard model and make it accessible to all

involved (Nunes et al., 2009). A context

management model integrated within the process

line is described as follows.

3.2 Context Management

in Process Line

Figure 2, based on Nunes et al. (2009), presents a

model for the cycle of capturing, storing, reasoning,

and retrieving of context.

CONTEXT-BASED PROCESS LINE

279

Equipe de

desenvolvimento

Repositório

de contexto

Contexto

organizacional

Contexto de projetos

similares

Contexto atual

Contexto

atual

Disciplina

Balanceamento

Colaboração

Processo

redefinido para o

projeto

Visualização de contexto

Contexto

Repositório

processos

Processo definido

para o projeto

Processo executado

Visualização de processo

Visualização de redes sociais

Repositório

de redes

sociais

Métricas de redes sociais

Colaboração na

execução do projeto

Informações de contexto

Informações de processos

Informações de redes sociais

Process context

Process

context

association

Context

Inference

mechanisms

Monitoring and

management

mechanisms

Adaptations rules and suggestions

Repositório

de contexto

Contexto

organizacional

Contexto de projetos

similares

Contexto atual

Contexto

atual

Disciplina

Balanceamento

Colaboração

Processo

definido para o

projeto

Visualização de contexto

Repositório

processos

Linha de processos

Informações de contexto

Gerente de projeto

Retrieving

mechanisms

Context

capturing

mechanisms

Context and

composition

Rules

Context

Repository

Context

model

Work

environment

Executor’s

context

…

Group’s

context

Environment’s

context

System’s

context

Context visualization

Process visualization

Project

Manager

In Domain Analysis, the domain model can be

elaborated, by using conceptual maps like those

proposed by Abels et al. (2006) used in this work:

Project, Task, Phase, Resource, Machine, Event,

Risk, Objective and Result. In order to construct the

context model we used Nunes et al. (2009) context

ontology model including the following context

information: problem size, problem complexity,

client relationship, business relevance, objective,

requirements stability, team experience, group

working experience and team proximity.

In order to perform project management

activities, methodologies for requirements elicitation

activity are listed: Observation, Protocol Analysis,

Scenarios, Interview, JAD, Prototyping, Quality

Function Deployment, and Social Analysis.

In Domain Design, Figure 4 shows the work

process with its commonalities and variabilities.

Variation points (dotted line activities) can be

customized by the avaliable components (variants)

based on dependency rules shown in Table 1.

Cliente

requisition

Elicitate

requirements

Estimate size

and effort

Estimate time

and cost

Analyse risks

Plan project

lifecycle

Plan

implementation

Project

planned

Variation point

Figure 4: Core process with variation activities.

Table 1: Rules.

Feature model

rules

Interview requires Social Analysis

JAD excludes Interview

Composition

rules

Observation goes before Interview

Scenarios goes before Prototyping

Social Analysis goes before Prototyping

and Scenarios

Context

Definition

Collaborative organization environment:

group working experience = high, team

experience >= medium

Complex development: problem size =

high, problem complexity – high, client

relationship <= medium

Context rules

Collaborative organization environment

implies JAD

Complex development implies

Prototyping and Interview

The process components model (Figure 5)

represents internal properties (incomes, outcomes,

data, etc), process behavior and state transitions,

implementation scheme, and interfaces.

In the Domain Implementation, the process

architecture extends the infrastructure presented by

Gatti et al (2010), which establishes an activity

context-aware architecture to support knowledge

management in processes.

Observation

Interview

Protocol

Analysis

JAD Prototyping

Scenarios

Social

analysis

Quality

Function

Deployment

Figure 5: Process components model.

Thus, having the context-based process line

created, for each new project, the organization can

use the composition mechanism, creating new

process through context interpretation.

In Application Design the mechanism helps the

project manager to make up the requirements

elicitation activity, composing the four techniques as

shown in Figure 6. The mechanism suggested

applying Social Analysis, Scenarios and Prototyping

in this sequence. The project manager also decides

to parallelize the interview activity with the Social

Analysis. In the Application Implementation, the

project manager decides to use a BPMS to automate

the process and starts to run.

During its execution, he/she realizes that the

team has gain synergy and people are working more

collaboratively. The automated mechanism also

recognizes this situation by the context information

continually collected. The project manager decides

to adapt the process substituting the Interview

technique by JAD. The automated mechanism also

realizes that the Social Analysis technique is not

needed anymore, but he/she decides to maintain it

because the client and also the team happened to like

this approach. The adapted process goes as shows

Figure 7 and the context monitoring continues.

Client

requisiton

Estimate size

and effort

Analyse risks

Estimate time

and cost

Plan project

lifecycle

Plan

implementation

Project

planned

Perform social

analysis

Perform

interview

Present

scenarios

Set up

prototyping

Elicitate requirements

Figure 6: Composed process.

CONTEXT-BASED PROCESS LINE

281

Client

requisiton

Estimate size

and effort

Analyse risks

Estimate time

and cost

Plan project

lifecycle

Plan

implementation

Project

planned

Perform social

analysis

Present

scenarios

Set up

prototyping

Elicitate requirements

Perform

JAD

Figure 7: Adapted process.

5 CONCLUSIONS AND FUTURE

WORK

This paper aimed to describe a proposal for process

line engineering, based on product line engineering

and introducing the manipulation of context to

address the issue of evolution and adaptation of

processes at run time.

The handling of context information is made

through the extension of the model proposed by

Nunes et al., (2009), which was adapted to support

the concepts described in process line. The

architecture described in Gatti et al. (2010) is being

adapted to implement the proposed model. We are

also conducting studies to identify the best

representation of context information, such as

features and ontologies.

ACKNOWLEDGEMENTS

Flávia Maria Santoro is partially supported by CNPq

(Brazil) under the grant 305404/2008-3.

REFERENCES

Abels, S. et al., 2006. PROMONT – A Project

Management Ontology as a Reference for Virtual

Project Organizations. In On the Move to Meaningful

Internet Systems 2006: OTM 2006 Workshops. pp.

813-823. http://dx.doi.org/10.1007/11915034_105

[Accessed January 20, 2010].

Barreto, A., 2007. Uma Abordagem para Definição de

Processos de Software Baseada em Reutilização,

Universidade Federal do Rio de Janeiro / COPPE.

Bayer, J., Buhl, W., Giese,C., Lehner, T., Ocampo, A.,

Puhlmann, F., Richter, E., Schnieders, A., Weiland, J.,

and Weske, M, 1995. Process family engineering.

Modeling variant rich processes. Technical report.

Chen, G., Kotz, D., 2000. A Survey of Context-Aware

Mobile Computing Research, Dartmouth College. In:

http://portal.acm.org/citation.cfm?id=867843.

Clements, P., Northrop, L., 2001. Software Product Lines:

Practices and Patterns 6th ed., In:

http://www.informit.com/store/product.aspx?isbn=020

1703327.

Dey, A., Abowd, G., Salber, D., 2001. A conceptual

framework and a toolkit for supporting the rapid

prototyping of context-aware applications. Human-

Computer Interaction, 16(2-4), 97-166.

Dumas, M., Aalst, W.V.D., Hofstede, A.T., 2005. Process-

aware information systems: Bridging People and

Software through Process Technology, John Wiley

and Sons, NY, USA.

Fusaro, P., Visaggio, G., Tortorella, M., 1998. REP -

ChaRacterizing and Exploiting Process Components:

Results of Experimentation. In Proceedings of the

Working Conference on Reverse Engineering

(WCRE'98). IEEE Computer Society, p. 20. In:

http://portal.acm.org/citation.cfm?id=837006.

Gatti, L.A., Santoro, F.M., Nunes, V.T., 2010. An Agent-

Based Architeture for Knowledge Management in

Context-Aware Business Processes. Computer-

Supported Cooperative Work in Design 2010.

Grisogono, A., 2006. Success and Failure in Adaptation.

In International Conference on Complex Systems

(ICCS2006).

Jaufman, O., Munch, J., 2005. Acquisition of a project-

specific process. In 6th International Conference on

Product Focused Software Process Improvement,

PROFES 2005, June 13, 2005 - June 18, 2005. Oulu,

Finland: Springer Verlag, pp. 328-342.

Kang, K. et al., 1990. Feature-Oriented Domain Analysis,

CMU-SEI. In: http://www.sei.cmu.edu/domain-

engineering/FODA.html.

La Rosa, M., 2009. Managing variability in process-aware

information systems. In:

http://eprints.qut.edu.au/20531

Montero, Pena, Ruiz-Cortés, 2007. Business Family

Engineering: Does it make sense? II Congreso Español

de Informática (Cedi 2007), (Actas de los Talleres de

las Jornadas de Ingeniería del Software y Bases de

Datos (Tjisbd)), 34-40.

Nunes, V.T., Santoro, F.M. & Borges, M.R.S., 2009. A

context-based model for Knowledge Management

embodied in work processes. Inf. Sci., 179(15), 2538-

2554.

Rombach, D., 2006. Integrated Software Process and

Product Lines. In Unifying the Software Process

Spectrum. pp. 83-90. In:

http://dx.doi.org/10.1007/11608035_9.

Schnieders, A., 2006. Variability mechanism centric

process family architectures. In Engineering of

Computer Based Systems, 2006. ECBS 2006. 13th

Annual IEEE International Symposium and Workshop

on. p. 10 pp.

Washizaki, H., 2006. Building software process line

architectures from bottom up. In 7th International

Conference on Product-Focused Software Process

Improvement, PROFES 2006, June 12, 2006 - June

14, 2006. Amsterdam, Netherlands: Springer Verlag,

pp. 415-421.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

282