-
COLE DE TECHNOLOGIE SUPRIEURE UNIVERSIT DU QUBEC
THESIS PRESENTED TO COLE DE TECHNOLOGIE SUPRIEURE
IN PARTIAL FULFILLEMENT OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY
Ph. D.
BY CARLOS MONSALVE
REPRESENTATION OF BUSINESS PROCESSES AT MULTIPLE LEVELS OF
ABSTRACTION (STRATEGIC, TACTICAL AND OPERATIONAL) DURING THE
REQUIREMENTS ELICITATION STAGE OF A SOFTWARE PROJECT, AND THE
MEASUREMENT OF THEIR FUNCTIONAL SIZE WITH ISO 19761
MONTREAL, NOVEMBER 5 2012
Carlos Monsalve, 2012
-
This Creative Commons licence allows readers to download this
work and share it with others as long as the author is credited.
The content of this work cant be modified in any way or used
commercially.
-
BOARD OF EXAMINERS
THIS THESIS HAS BEEN EVALUATED
BY THE FOLLOWING BOARD OF EXAMINERS Mr. Alain April, Thesis
Supervisor Software Engineering and Information Technology
Department at cole de technologie suprieure Mr. Alain Abran, Thesis
Co-supervisor Software Engineering and Information Technology
Department at cole de technologie suprieure Mr. Kamal Al-Haddad,
President of the Board of Examiners Department of Electrical
Engineering at cole de technologie suprieure Mr. Pierre Bourque,
Member of the jury Software Engineering and Information Technology
Department at cole de technologie suprieure Mr. variste Valry Bvo,
External Evaluator Centre de formation en technologies de
linformation at Sherbrooke University
THIS THESIS WAS PRENSENTED AND DEFENDED
IN THE PRESENCE OF A BOARD OF EXAMINERS AND PUBLIC
ON OCTOBER 3, 2012
AT COLE DE TECHNOLOGIE SUPRIEURE
-
ACKNOWLEDGMENTS
First, I would like to express my utmost thanks to Dr. Alain
April, my thesis supervisor, and
Dr. Alain Abran, my thesis co-supervisor, for their motivation,
guidance, time and support.
Their advice continuously opened new opportunities to improve
the outcomes of this
research; without their patient support this research would have
never been executed.
Thanks to the members of my board of examiners for their time
and effort to review this
thesis and to provide me with their feedback.
I am grateful to Mohamed Yassine Katiri, Tarik Ben Jillali,
Linda Kang, Saadeddine Rachidi,
Oscar Snchez, and Yaneth Sabogal, students of the cole de
technologie suprieure, for
their support in the execution of this research. Special thanks
to all my colleagues, volunteers
and experts who participated in the various research activities
conducted as part of this
research. Thanks to the following organizations and their
personnel who contributed to the
execution of this research: TMQ Group, Intgratik and
Experts-Conseils CEP Inc.
My foremost gratitude to my employer: Escuela Superior
Politcnica del Litoral (ESPOL) for
its academic and financial support for this research.
Finally, I would like to thank my family and friends, especially
Pa, my wife, who
unconditionally accepted the sacrifice of changing our lives
during these last four years to
support me with her daily love and sympathy.
-
REPRESENTATION OF BUSINESS PROCESSES AT MULTIPLE LEVELS OF
ABSTRACTION (STRATEGIC, TACTICAL AND OPERATIONAL) DURING THE
REQUIREMENTS ELICITATION STAGE OF A SOFTWARE PROJECT, AND THE
MEASUREMENT OF THEIR FUNCTIONAL SIZE WITH ISO 19761
Carlos MONSALVE
RSUM
Cette thse vise dabord apporter une aide et un soutien aux
ingnieurs de logiciels et aux analystes daffaires afin quils
puissent mieux modliser les processus daffaires lorsque ces modles
sont destins la spcification des exigences logicielles et assignes
la mesure de la taille fonctionnelle la seule fin que ces personnes
puissent estimer correctement tout projet. Quant la thse, elle-mme,
elle vise un but prcis: contribuer la reprsentation des processus
d'affaires lorsquils sont utiliss au moment de la phase
d'licitation des exigences logicielles. Pour atteindre ce but, deux
objectifs de recherche ont t clairement dfinis: 1. Proposer une
nouvelle approche de modlisation qui gnre des modles de
processus
daffaires qui doivent tre utiliss dans une activit dlicitation
des exigences logicielles. Mentionnons que l'approche de
modlisation ne devrait pas augmenter de manire significative la
complexit des notations graphiques utilises pour reprsenter les
processus d'affaires, pour peu que cette approche doive permettre
la participation active des diffrents acteurs impliqus dans un
projet de logiciel typique pour reprsenter, de faon cohrente et
structure, leurs besoins et leurs contraintes.
2. laborer une procdure afin de pouvoir mesurer la taille
fonctionnelle dune application logicielle partir des modles de
processus daffaires. Cette procdure de mesure doit respecter la
norme COSMIC ISO 19761; cette marche suivre doit pouvoir tre
applique indpendamment de la notation graphique utilise pour
reprsenter les processus d'affaires.
Afin datteindre le premier objectif, cette thse propose une
nouvelle approche de modlisation (surnomme BPM+) qui offre la
possibilit de modliser des processus daffaires selon trois niveaux
d'abstraction: 1) le niveau stratgique, 2) le niveau tactique et 3)
le niveau oprationnel. partir dune revue de la littrature, une
version a priori de BPM+ a t conue. Cette version a priori a t
ensuite amliore la suite dune tude de cas dans le milieu
industriel. Cette dernire est devenue plus performante lorsque nous
lavons soumise aux analyses ontologiques pour lensemble des
concepts des exigences logicielles et que des enqutes scientifiques
ont t labores auprs dexperts concerns. Finalement, une version
rvise du BPM+ a t propose. Cette version rvise a t par la suite
value par une deuxime tude de cas. La version finale de BPM+ a donc
t fonde sur plusieurs confirmations et preuves obtenues partir de
diverses sources.
-
VIII
Quant au second objectif, la procdure de mesure a t labore
partir dune comparaison analytique entre les spcifications de
COSMIC et celles des notations graphiques slectionnes pour cette
recherche (i.e. BPMN et Qualigram). Cette comparaison a permis de
dfinir un ensemble de lignes directrices de modlisation pour le
type de logiciels daffaires. La comparaison analytique a permis
galement de dfinir un ensemble de rgles de correspondance entre les
concepts des notations graphiques et les concepts de COSMIC. En
outre, les lignes directrices de modlisation ont t adaptes pour le
type de logiciels en temps rel. La procdure de mesure a t value en
comparant ses rsultats ceux qui ont t obtenus dans des tudes de cas
de rfrence. Les rsultats obtenus par cette recherche dmontrent ce
qui suit: 1. BPM+ permet de gnrer des modles de processus daffaires
qui reprsentent, de faon
cohrente et structure, les besoins des diffrents acteurs
impliqus; 2. La notation Qualigram est mieux adapte la conception
de BPM+. De surcrot, la
notation Qualigram est plus facile dutilisation pour les parties
prenantes qui ne sont pas impliques en informatique, tandis que
BPMN est plus facile pour celles qui sont impliques en
informatique;
3. La procdure de mesure a t applique avec succs en utilisant
deux diffrentes notations graphiques: Qualigram et BPMN. Celle-ci a
galement t mis en application avec succs deux types diffrents de
logiciels: le type de logiciels d'affaires et le type de logiciels
en temps rel;
4. La prcision de la procdure de mesure a t en conformit avec
toutes les rgles de la norme ISO /IEC 19761.
Mots-cls: modlisation des processus d'affaires, exigences
fonctionnelles, l'analyse de reprsentation, Qualigram, BPMN, mesure
de la taille fonctionnelle, COSMIC, ISO/IEC 19761, points de
fonction.
-
REPRESENTATION OF BUSINESS PROCESSES AT MULTIPLE LEVELS OF
ABSTRACTION (STRATEGIC, TACTICAL AND OPERATIONAL) DURING THE
REQUIREMENTS ELICITATION STAGE OF A SOFTWARE PROJECT, AND THE
MEASUREMENT OF THEIR FUNCTIONAL SIZE WITH ISO 19761
Carlos MONSALVE
ABSTRACT
This thesis aims at helping software engineers and business
analysts to better model business processes when those models are
meant to be used: for software requirements specification, and for
functional size measurement purposes. The research goal of this
thesis is to contribute to the representation of business processes
for its use during the requirements elicitation stage of a software
project. To achieve this goal, two research objectives are clearly
defined: 1. To propose a novel modeling approach that generates
business process models intended
to be used in a software requirements elicitation activity. The
modeling approach should not significantly increase the complexity
of the modeling notations used to represent the business processes;
and it must allow the active participation of the various
stakeholders involved in a typical software project in order to
represent, in a consistent and structured way, their needs and
constraints.
2. To develop a procedure to measure the functional size of a
software application from the business process models representing
it. This measurement procedure should be compatible with the COSMIC
ISO 19761 standard; and it should be able to be used independently
of the modeling notation used to represent the business
process.
To achieve the first objective, this thesis proposes a novel
modeling approach (coined BPM+) that models business processes at
three levels of abstraction: strategic, tactical and operational.
An a priori version of BPM+ was designed based on the findings of
the literature review. This a priori version was iteratively
refined through a pilot case study in industry, a series of
ontological analyses, and a survey of experts. As a result, a
reviewed version of BPM+ was proposed. The reviewed version was
evaluated through a second case study in industry. Therefore, the
design of BPM+ has been based on a triangulation of evidences
obtained from various sources. To achieve the second objective, the
measurement procedure was developed from an analytical comparison
between the specifications of COSMIC and those of the modeling
notations selected for this research (i.e. BPMN and Qualigram).
This analytical comparison helped to define a set of modeling
guidelines for the business application software domain. The
comparison also allowed defining a set of mapping rules between the
modeling notations constructs and the COSMIC concepts. In addition,
the modeling guidelines were adapted for their application to the
real-time software domain. The measurement procedure was evaluated
by comparing its measurement results to those obtained in COSMIC
reference case studies.
-
X
The research results demonstrate that: 1. BPM+ allows generating
business process models that represent in a consistent and
structured way the needs of various stakeholders. 2. Qualigram
notation is better suited to BPM+s design. In addition, Qualigram
notation is
preferred to be used for non-IT stakeholders, while BPMN is
preferred for IT stakeholders.
3. The measurement procedure was successfully applied using two
different notations: Qualigram and BPMN, and in two different
software domains: the business application domain and the real-time
domain.
4. The accuracy of the measurement procedure is in conformity
with all the rules of the ISO 19761 standard.
Keywords: business process modeling, software requirements,
representational analysis, Qualigram, BPMN, functional size
measurement, COSMIC, ISO 19761, function points.
-
TABLE OF CONTENTS
Page
INTRODUCTION
.....................................................................................................................1
CHAPTER 1 LITERATURE REVIEW
.........................................................................13
1.1 What is a business process?
.........................................................................................15
1.2 Business process management and its support systems
...............................................17
1.2.1 What is business process management?
................................................... 18 1.2.2
Business process management support systems
....................................... 19
1.3 Business process model and modeling
........................................................................22
1.3.1 What is a business process model?
........................................................... 23
1.3.2 Popular BPM notations
.............................................................................
24
1.3.2.1 Business Process Model and Notation (BPMN)
........................ 25 1.3.2.2 Event-driven process chains
(EPC) ........................................... 27 1.3.2.3 Petri
Nets
....................................................................................
28 1.3.2.4 Unified Modeling Language (UML)
......................................... 29
1.3.3 Qualigram notation
...................................................................................
30 1.4 What elements of a business process to represent?
.....................................................33
1.4.1 The need of BPM perspectives in a BPM project
..................................... 34 1.4.2 Business process
perspectives presented in the literature .........................
36
1.5 BPM at multiple levels of abstraction (MLA)
.............................................................39
1.5.1 Theoretical foundations
............................................................................
40 1.5.2 MLA and its use in business process-oriented approaches
....................... 42
1.5.2.1 MLA in management-oriented approaches
................................ 42 1.5.2.2 MLA in BPM notations
and methods ........................................ 43 1.5.2.3 MLA
in BPM research proposals
.............................................. 47
1.6 BPM and software requirements elicitation
.................................................................50
1.6.1 The references for requirements elicitation
.............................................. 51 1.6.2 Proposed
approaches to BPM for software requirements elicitation ........
53
1.6.2.1 i* based approaches
...................................................................
53 1.6.2.2 UML based approaches
.............................................................. 55
1.6.2.3 BPMN based approaches
........................................................... 57
1.6.2.4 Approaches based on other BPM notations
............................... 58 1.6.2.5 Methodological
approaches .......................................................
58
1.7 An ontology based theory of representation
................................................................60
1.8 BPM and functional size
measurement........................................................................63
1.8.1 The COSMIC FSM method
......................................................................
64 1.8.2 Functional size measurement from business process models
using
COSMIC
...................................................................................................
65 1.9 Summary
......................................................................................................................66
CHAPTER 2 RESEARCH METHODOLOGY, ACTIVITIES AND EXPECTED RESULTS
..................................................................................................69
-
XII
2.1 Research methodology and expected results
...............................................................69
2.1.1 Definition phase
........................................................................................
69 2.1.2 Planning phase
..........................................................................................
69 2.1.3 Operation phase
........................................................................................
73 2.1.4 Interpretation phase
...................................................................................
77
2.2 Design of the case studies
............................................................................................77
2.3 Research methodology for the representational analyses
............................................83 2.4 Research design
of the survey
......................................................................................88
2.5 Methodology for developing the FSM from BPM procedure
.....................................92
2.5.1 Business application software domain
...................................................... 92 2.5.2
Real-time software domain
.......................................................................
93
2.6 Summary of the research methodology
.......................................................................95
CHAPTER 3 BUILDING THE BPM+ APPROACH
......................................................99 3.1 The
BPM+ a priori version
..........................................................................................99
3.1.1 The BPM+ strategic level of abstraction
................................................. 103 3.1.2 The
BPM+ tactical level of abstraction
................................................... 106 3.1.3 The
BPM+ operational level of abstraction
............................................. 109
3.2 The pilot case study
...................................................................................................112
3.2.1 Details of the research design
.................................................................
113 3.2.2 Results
.....................................................................................................
114
3.2.2.1 Results related to Qualigram notation
...................................... 114 3.2.2.2 Results related
to BPMN .........................................................
118
3.2.3 Comparison of the BPM notations
.......................................................... 121
3.2.4 Interpretation and summary of the results
.............................................. 122
3.3 Refining the set of BPM+ modeling concepts
............................................................127
3.3.1 Mapping results and analysis
..................................................................
129
3.3.1.1 A SWEBOK insight into the BWW representation model
...... 131 3.3.1.2 A BABOK insight into the BWW representation
model ......... 134 3.3.1.3 A BWW representation model subset for
SRE ........................ 137 3.3.1.4 Qualigram and BPMN
mappings ............................................. 138
3.3.2 Discussion of the results
.........................................................................
141 3.4 A survey of practitioners with experience
.................................................................143
3.4.1 The research propositions
.......................................................................
143 3.4.2 Data analysis
...........................................................................................
145 3.4.3 Conclusion
..............................................................................................
157
3.5 The BPM+ reviewed version
......................................................................................159
3.5.1 The BPM+ strategic level of abstraction
................................................. 162 3.5.2 The
BPM+ tactical level of abstraction
................................................... 165 3.5.3 The
BPM+ operational level of abstraction
............................................. 167
3.6 Case study with a Canadian forensic engineering company
......................................168 3.6.1 Details of the
research design
.................................................................
169 3.6.2 Results
.....................................................................................................
173
3.6.2.1 Results related to the number and scope of the levels of
abstraction
................................................................................
173
-
XIII
3.6.2.2 Results related to the modeling requirements for each
level of abstraction
............................................................................
175
3.6.2.3 Results related to the BPM notations
....................................... 179 3.6.3 Interpretation
and summary of the results
.............................................. 181
CHAPTER 4 MEASURING FUNCTIONAL SIZE FROM BUSINESS PROCESS MODELS
WITH COSMIC FSM METHOD
..........................................185
4.1 Introduction
................................................................................................................185
4.2 The business application software domain
................................................................186
4.2.1 Results obtained with Qualigram notation
.............................................. 186 4.2.1.1 Modeling
guidelines for Qualigram .........................................
187 4.2.1.2 Mapping and measuring based on Qualigram
......................... 192
4.2.2 Results obtained with BPMN notation
................................................... 195 4.2.2.1
Modeling guidelines for
BPMN............................................... 196 4.2.2.2
Mapping and measuring based on BPMN ...............................
199
4.2.3 Deriving notation-independent BPM guidelines and mapping
rules ...... 201 4.3 The real-time software domain
..................................................................................204
4.3.1 Modeling guidelines for the real-time software domain
......................... 205 4.3.2 Mapping and measuring
..........................................................................
207
4.4 Discussion of results
..................................................................................................209
4.4.1 Business application software domain
.................................................... 209 4.4.2
Real-time software domain
.....................................................................
226
4.5 Summary
....................................................................................................................230
CONCLUSION
..................................................................................................................233
ANNEX I LIST OF APPENDICES ON CD-ROM
..................................................249
LIST OF BIBLIOGRAPHICAL REFERENCES
..................................................................251
-
LIST OF TABLES
Page
Table 1.1 Comparison of business process management support
systems ........................22
Table 1.2 Compendex and Inspec citations of most common BPM
notations ...................25
Table 1.3 Perspectives of a business process model
..........................................................37
Table 1.4 MLA in business process-oriented management approaches
............................43
Table 1.5 MLA in BPM notations
......................................................................................46
Table 1.6 MLA in BPM research proposals
.......................................................................50
Table 2.1 Definition phase
.................................................................................................70
Table 2.2 Planning phase: BPM+ modeling approach
........................................................71
Table 2.3 Planning phase: FSM from BPM procedure
......................................................72
Table 2.4 Operation phase: development of BPM+
............................................................74
Table 2.5 Operation phase: development of FSM procedure
.............................................76
Table 2.6 Interpretation phase
............................................................................................78
Table 2.7 Previous similar empirical research work
..........................................................91
Table 2.8 Overview of the limitations and validity threats
................................................97
Table 3.1 Representation of strategic-level BPM+ modeling
concepts in Qualigram and BPMN notations
........................................................................................104
Table 3.2 Representation of tactical-level BPM+ modeling
concepts in Qualigram and BPMN notations
........................................................................................108
Table 3.3 Representation of operational-level BPM+ modeling
concepts in Qualigram and BPMN notations
........................................................................................111
Table 3.4 SRE relevant concepts found in the SWEBOK and BABOK
..........................130
Table 3.5 Representation mapping of the BWW representation model
based on selected SWEBOK concepts
............................................................................131
Table 3.6 Interpretation mapping of the BWW representation model
based on selected SWEBOK concepts
............................................................................132
-
XVI
Table 3.7 Set of BWW representation model concepts that based on
the SWEBOK better fits the SRE context
................................................................................133
Table 3.8 Representation mapping of the BWW representation model
based on selected BABOK concepts
...............................................................................134
Table 3.9 Interpretation mapping based on selected BABOK
concepts ..........................135
Table 3.10 Set of BWW representation model concepts that based
on the BABOK better fits the SRE context
................................................................................136
Table 3.11 Mappings between the BWW representation model,
selected SWEBOK concepts and selected BABOK concepts
.........................................................137
Table 3.12 Comparison of the completeness of BPMN and Qualigram
to represent the subset of the BWW representation model concepts
selected for the SRE context
..............................................................................................................139
Table 3.13 Focused representation mappings of BPMN and Qualigram
based on the subset of the BWW representation model concepts
selected for the SRE context
..............................................................................................................140
Table 3.14 Participants BPM experience
...........................................................................145
Table 3.15 Participants SRE experience
............................................................................146
Table 3.16 Most important benefits of modeling at multiple
levels of abstraction ............147
Table 3.17 Level of abstraction according to type of stakeholder
.....................................148
Table 3.18 Contingency table for the higher level of abstraction
......................................149
Table 3.19 Usefulness of Qualigram's types of models at the
strategic level of abstraction
........................................................................................................151
Table 3.20 Need of the types of models at the strategic level of
abstraction .....................152
Table 3.21 BPM notation preferences according to the type of
stakeholder......................152
Table 3.22 Aggregated BPM notation preferences according to the
type of stakeholder ..153
Table 3.23 Pearson Chi-square test of independence: groups of
stakeholders vs. BPM notation preference
...........................................................................................154
Table 3.24 Importance of the need of BPM constructs to represent
things .......................155
Table 3.25 Importance of the need of BPM constructs to represent
actions ......................156
-
XVII
Table 3.26 Importance of the need of BPM constructs to represent
relationships and dependencies
....................................................................................................156
Table 3.27 Summary of survey results
...............................................................................157
Table 3.28 BPM+ aspects reviewed during the research activities:
Part A ........................160
Table 3.29 BPM+ aspects reviewed during the research activities:
Part B ........................161
Table 3.30 Reviewed version of strategic-level BPM+ modeling
concepts .......................163
Table 3.31 Reviewed version of tactical-level BPM+ modeling
concepts .........................166
Table 3.32 Reviewed version of operational-level BPM+ modeling
concepts ..................168
Table 3.33 Profiles of the company participants
................................................................170
Table 3.34 Meeting activities conducted during the case study
.........................................171
Table 4.1 Rules for mapping between COSMIC and Qualigram
.....................................193
Table 4.2 Measurement results based on Qualigram: Business
application The C-Registration system (GELOG-ETS, 2008)
...................................................194
Table 4.3 Mapping between COSMIC and BPMN version 1.2
.......................................199
Table 4.4 Measurement results based on BPMN version 1.2:
Business application The C-Registration system (GELOG-ETS, 2008)
...........................................201
Table 4.5 Rules for mapping between COSMIC and BPM notation
...............................204
Table 4.6 Measurement results: Real-time domain
..........................................................208
Table 4.7 Comparison of the measurement results: C-Registration
System ....................210
Table 4.8 Summary of measurement differences using Qualigram
Notation: C-Registration System
..........................................................................................215
Table 4.9 Rules for mapping between COSMIC and Qualigram: final
version ..............217
Table 4.10 Comparison of the final measurement results:
C-Registration System ............218
Table 4.11 Summary of measurement differences using BPMN:
C-Registration System
..............................................................................................................222
Table 4.12 Mapping between COSMIC and BPMN version 1.2: final
version .................224
Table 4.13 Rules for mapping between COSMIC and BPM notations:
final version .......225
-
XVIII
Table 4.14 Final measurement results: Real-time domain
.................................................230
-
LIST OF FIGURES
Page
Figure 0.1 Business process perspectives
..............................................................................9
Figure 1.1 Description of a business process
.......................................................................17
Figure 1.2 The PAIS life cycle
............................................................................................21
Figure 1.3 Qualigram pyramid
............................................................................................31
Figure 1.4 Graphical forms of the Qualigram notation
.......................................................32
Figure 1.5 BPM lifecycle and organization's stakeholders
..................................................35
Figure 1.6 Perspectives as layers of a business process
......................................................36
Figure 1.7 Representational analysis
...................................................................................61
Figure 1.8 Generic flow of data attributes from a functional
perspective ...........................65
Figure 2.1 Action research: cyclical process model
............................................................80
Figure 2.2 From a real-world domain to its representation in a
BPM notation ...................84
Figure 2.3 Methodology for the SWEBOK focused representational
analyses ..................86
Figure 2.4 Questionnaire structure and severity levels
........................................................89
Figure 2.5 Methodology for the business application software
domain ..............................93
Figure 2.6 Methodology for the real-time software domain
................................................94
Figure 2.7 Research methodology summary: development of the BPM+
approach ............95
Figure 2.8 Research methodology summary: development of the FSM
procedure ............96
Figure 3.1 BPM+ levels of abstraction
...............................................................................102
Figure 3.2 Pilot case study: Qualigrams relational model
................................................114
Figure 3.3 Pilot case study: Qualigram's macroscopic model
...........................................115
Figure 3.4 Qualigram's detailed model of the Procurement
business process ...................116
Figure 3.5 Qualigram's tactical model of the Payment Management
procedure ...............117
-
XX
Figure 3.6 BPMN Level 1 model without lanes of the Procurement
business process .....119
Figure 3.7 BPMN Level 1 model with lanes of the Procurement
business process ..........121
Figure 3.8 BPMN Level 2 model of the Management of a registered
customer payment procedure
...........................................................................................122
Figure 3.9 Qualigram's tactical level of Payment Management
procedure (sales at the counter business process)
.................................................................................125
Figure 3.10 Qualigram's tactical model of the Deposits
Management procedure (sales at the counter business process)
...........................................................................126
Figure 3.11 Participants demographics (profession & BPM
experience) ..........................146
Figure 3.12 Participants demographics (profession & SRE
experience) ...........................147
Figure 3.13 Types of stakeholders to whom it is more important
to communicate BPM at a higher level of abstraction
.........................................................................150
Figure 3.14 Usefulness of Qualigram's types of models at the
strategic level of abstraction
........................................................................................................151
Figure 3.15 BPMN vs. Qualigram preferences
...................................................................154
Figure 3.16 Participants and levels of abstraction
...............................................................173
Figure 3.17 Macroscopic model: Forensics Company
........................................................175
Figure 3.18 Strategic level of abstraction: detailed model of
the budgeting business process
..............................................................................................................176
Figure 3.19 Tactical model of the budgeting business process
...........................................178
Figure 3.20 BPMN tactical model of the budgeting process
...............................................180
Figure 4.1 Qualigrams top level model of the C-Registration
System ............................188
Figure 4.2 Qualigram model of the Login procedure
........................................................191
Figure 4.3 Qualigram model of the Add Professor procedure
...........................................192
Figure 4.4 Qualigram model of the Delete Schedule
procedure........................................195
Figure 4.5 BPMN model of the Select Courses functional process
...............................197
Figure 4.6 BPMN model of the Modify Professor functional process
..........................198
-
XXI
Figure 4.7 Application of the mapping rules to the Close
Registration functional process
..............................................................................................................200
Figure 4.8 Top-level Qualigram model of the Rice Cooker
Controller ............................206
Figure 4.9 Qualigram model of the Adjust Temperature procedure
..............................207
Figure 4.10 Applying the mapping rules to the Set Target
Temperature procedure ........208
Figure 4.11 Qualigram model of the "Delete a schedule"
functional process revisited ......216
Figure 4.12 BPMN model of the Delete Student functional process
...............................220
Figure 4.13 Applying modeling guideline QRT9 to the "Set Target
Temperature" functional process
.............................................................................................228
Figure 4.14 Measuring the "Adjust Temperature"functional process
.................................229
-
LIST OF ABREVIATIONS ACIS International Association for Computer
and Information Science ARIS Architecture of Integrated information
Systems BABOK Business Analysis Body of Knowledge BPD Business
Process Diagram BPEL Business Process Execution Language BPM
Business Process Modeling BPMI Business Process Management
Initiative BPMN Business Process Model and Notation BPMO Business
Process Modeling Ontology BPMS Business Process Management System
BPQL Business Process Query Language BSC Balanced Score Card BWW
Bunge-Wand-Weber CR TS Ethics Committee for Research COSMIC Common
Software Measurement International Consortium CP Cumulative
Percentage CPM Cyclical Process Model E Entry (data movement) EPC
Event-driven Process Chain ERP Enterprise Resource Planning system
FP Functional Process FPA Function Point Analysis
-
XXIV
FSM Functional Size Measurement FT Formal Tropos FUR Functional
User Requirement IADIS International Association for Development of
the Information Society IDEF Integrated Definition methods IEC
International Electromechanical Commission IEEE Institute of
Electrical and Electronics Engineers IFPUG International Function
Point Users Group IIBA International Institute of Business Analysis
IJSEKE International Journal of Software Engineering and Knowledge
Engineering ISO International Organization for Standardization IT
Information Technology IWSM International Workshop on Software
Measurement KA Knowledge Area KCPM Klagenfurt Conceptual Pre-design
Model LoA Logic of Actions MLA Multiple Levels of Abstraction NDG
No Data Group OMG Object Management Group PAIS Process Aware
Information System R Read (data movement) RAD Role Activity
Diagram
-
XXV
SBPM Semantic Business Process Management SCOR Supply Chain
Operations Reference model SERA Software Engineering Research,
Management and Applications SRE Software Requirements Elicitation
SRS Software Requirements Specifications SWEBOK Software
Engineering Body of Knowledge UML Unified Modeling Language UML AD
UML Activity Diagram W Write (data movement) WS-BPEL Web Services
Business Process Execution Language WFMS Work-Flow Management
System WSEAS World Scientific and Engineering Academy and Society X
Exit (data movement) XML Extensible Markup Language XPDL XML
Process Definition Language YAWL Yet Another Workflow Language
-
LIST OF SYMBOLS Chi-square statistic CFP COSMIC Function Point i
Absolute difference between two quantities of data movements of
type i TOTAL Total absolute difference between two measurements CFP
Absolute difference between two COSMIC functional size measurements
F Frequency Freq. Frequency df Number of degrees of freedom N
Number of respondents % Percentage p Probability of obtaining a
test statistic (p-value)
-
INTRODUCTION
Motivation and problem context
Business process management is a promising domain to bring
business processes efficiencies
into organizations; early publications (Elzinga et al., 1995;
Zairi, 1997; Zairi and Sinclair,
1995b) as well as recent publications (Dixon and Jones, 2011;
Smith and Fingar, 2007;
Spanyi, 2003) have recognized it. Many frameworks,
methodologies, modeling notations and
tools proposing systematic analysis, design, monitoring and
improvement of business
processes have arisen during the last decade. Not only there is
a growing academic
enthusiasm about these topics, but vendors and consultants are
also proposing business
process management solutions to address the opportunities of
this market. Industrial studies
show that most organizations see a high importance in adopting
and using business process
management approaches for their organizations: 93% according to
Dwyer (2006, p. 6), 52%
according to Harmon and Wolf (2010, p. 13), and over 59%
according to Casewise Systems
(Casewise, 2011, p. 1). In addition, most organizations are
considering doing more in the
near future in various types of activities related to business
process management (Harmon
and Wolf, 2010). Therefore, these industrial studies show
increased adoption of some sort of
business process management within organizations. Moreover, a
recent Gartner study
(McDonald and Aron, 2011) reports that business process
improvement has been consistently
identified as one of the top business expectations of IT over
the past five years.
At the center of business process management are the business
processes and their modeling.
Business processes are often informal and part of an employees
experience and
competencies. It has been discovered, over the years, that
business processes need to be
represented formally (i.e. modeled) for many reasons. It may be
required to document them,
understand them, communicate them, automate them, or improve
them (Curtis, Kellner and
Over, 1992; Harmon and Wolf, 2011). Business process models are
also used, by software
engineers and business analysts, for eliciting the software and
system requirements of
information systems (Demirors, Gencel and Tarhan, 2003; Eriksson
and Penker, 2000;
-
2
Georgakopoulos, Hornick and Sheth, 1995; Green and Rosemann,
2000; IIBA, 2009; List
and Korherr, 2005; Mayr, Kop and Esberger, 2007; Mili et al.,
2009). A software
requirements elicitation activity requires a good communication
between software engineers
and all the stakeholders (Abran et al., 2004; Wand and Weber,
2002). For representing and
communicating software requirements expressed by different
groups of stakeholders,
conceptual modeling is considered as a valid approach, and
business process modeling
(BPM) is one of the popular techniques for performing conceptual
modeling (Davies et al.,
2006; List and Korherr, 2006). Therefore, in practice, BPM is
also often used as part of the
software requirements specifications (SRS) document.
A software development project is highly dependent on the
quality of the software-
requirements elicitation, analysis, specification, and
validation activities (Abran et al., 2004;
Wand and Weber, 2002). If the SRS has a poor quality, then it is
likely that the software
development project will face difficulties. Therefore, it is
necessary to successfully model the
business processes if they are meant to be used as part of the
SRS.
In addition, a SRS is typically used by software engineers as
the source of information for
measuring the functional size of the software to be developed.
Functional size measurement
(FSM) provides valuable information for estimating the effort
required to develop the
measured software. Based on that estimation, software managers
can successfully plan
resources and estimate costs for the software project (Abran,
2010). Since BPM can be used
to elicit the software and system requirements, then a business
process model may be a
valuable source of information for FSM.
In this context, this thesis addresses two problems associated
to the development of business
process models for software requirements elicitation. The first
problem is related to the
necessity of generating business process models that contribute
to the success of the software
development project; and the second problem is related to the
feasibility of using business
process models for measuring the functional size of the software
that supports (or might
support) the business process modeled.
-
3
The need for generating high-quality business process models
A high-quality software requirements elicitation activity
depends on a good communication
between software engineers and end-users for an active
participation of all the stakeholders;
the result should be a high-quality SRS document (Abran et al.,
2004; Wand and Weber,
2002). Modeling business processes that can be successfully used
and shared within an
organization requires, among other things, the commitment of the
top executives and the
active participation of all the stakeholders in sharing a common
vision of the business
processes (Becker, Rosemann and von Uthmann, 2000; Sedera et
al., 2004).
Unfortunately, for many organizations business process
management is a departmental
initiative (Harmon and Wolf, 2010) and business processes may
not be consistently
documented: according to a recent industrial study (Harmon and
Wolf, 2010, pp. 16-17),
only 5% of the organizations always document their business
processes in a consistent way,
and only 3% of the time business process models are very
consistent with the information
systems designed to support them (p. 20). Moreover, only 13% of
the times business process
management is an organizational initiative led by top executives
of the organization (pp. 31-
32); while for 55% of the organizations it is a departmental
initiative sometimes led by
Information Technology (IT) stakeholders and, at other times, by
management stakeholders.
A model corresponds to the point of view of the modeler, and
different stakeholders require
different perspectives of the business processes being modeled
(Berger and Guillard, 2000;
Curtis, Kellner and Over, 1992; Indulska, zur Muehlen and
Recker, 2009; Lankhorst, 2005;
Smith and Fingar, 2007; Van Nuffel and De Backer, 2012; Vara,
Snchez and Pastor, 2008;
White, 2004; zur Muehlen and Ho, 2008): it is plausible, then,
that IT and management may
require different abstractions of the business processes to
better represent their specific
perspectives. For instance, management typically requires
business processes represented at a
high level of abstraction (Berger and Guillard, 2000; Van Nuffel
and De Backer, 2012),
while IT requires a more formal, rigorous, non-ambiguous and
detailed description of the
-
4
business processes because they intend to automate them (Abran
et al., 2004; Becker,
Rosemann and von Uthmann, 2000; Lind and Seigerroth, 2010;
Rosemann and Green, 2000).
Many authors report on the difficulty of choosing a single
modeling notation to allow the
effective communication and participation of all the
stakeholders (Abran et al., 2004; Curtis,
Kellner and Over, 1992; Lankhorst, 2005; Lind and Seigerroth,
2010; Van Nuffel and De
Backer, 2012). Evidence also shows that the different
stakeholders tend to use different
notations, conventions and techniques to represent their
perspectives of business processes
(Berger and Guillard, 2000; Curtis, Kellner and Over, 1992;
Indulska, zur Muehlen and
Recker, 2009; Lankhorst, 2005; Smith and Fingar, 2007; Vara,
Snchez and Pastor, 2008; zur
Muehlen and Ho, 2008). These difficulties often create
inefficiencies and duplications when
each stakeholder uses his own notation, resulting in numerous
communication problems,
causing rework, project delays, costs overruns and failure.
Other authors have observed that current BPM notations are
highly complex in their attempt
to satisfy the different modeling perspectives required by
different stakeholders (Indulska,
zur Muehlen and Recker, 2009; Recker et al., 2009). This growing
complexity has been
reported, and corroborated empirically by several authors as one
of the key reasons why a
modeling notation might not be able to produce effective models
(Indulska, zur Muehlen and
Recker, 2009; Mendling, Reijers and Cardoso, 2007; Wand and
Weber, 2002), hindering the
use of the notations and the possibility to reach a common
understanding of the resulting
models. Despite their growing complexity, BPM notations are
still not able to satisfy all the
modeling needs required by different stakeholders. As an
example, the most popular current
BPM notations lack the constructs to appropriately represent all
the different requirements of
an information system (Lapouchnian, Yu and Mylopoulos, 2007;
List and Korherr, 2006;
Pavlovski and Zou, 2008; Vara, Snchez and Pastor, 2008).
Solutions to this problem (i.e. satisfying the various modeling
needs required by different
stakeholders) have to provide the means for a consistent way of
modeling various business
process perspectives. Ideally, the solution should be simple and
should not significantly
-
5
increase the complexity of the BPM notations, thereby allowing
the business process models
to be easily understood and used by different stakeholders.
Using business process models as a source for functional size
measurement (FSM)
The use of conceptual models for functional size measurement
(FSM) has been studied and
analyzed in the research literature. The work of Marn,
Giachetti, and Pastor (2008) offers a
survey of eleven related works, including their own. In addition
to the publications reported
in that survey, other works have also studied the use of
conceptual models for FSM (Daneva,
1999; Demirors and Gencel, 2004; Lavazza and Bianco, 2009;
Sellami and Ben-Abdallah,
2009; van den Berg, Dekkers and Oudshoorn, 2005). Most of these
previous works have
been based on the use of Unified Modeling Language (UML) (OMG,
2010) diagrams (use
case, component, and sequence diagrams), or the use of
Event-driven Process Chain (EPC)
diagrams (Scheer, Thomas and Adam, 2005) as a source of
information for FSM. However,
from all these works, only one work (Daneva, 1999) uses BPM for
FSM. One of the
conclusions of this latter work is that the application of the
counting model from a business
process model requires validation (p. 149). Therefore, there
exists only scarce research on the
feasibility of using business process models for FSM.
Purpose and research questions of this thesis
The purpose of this thesis is to contribute to the
representation of business processes during
the software requirements elicitation stage of a software
project by proposing novel solutions
to:
1. ensure business processes models that: a) take into
consideration the needs and
constraints from various stakeholders; b) represent, in a
consistent way, these needs and
constraints; c) allow easy communication of the software
requirements to the various
stakeholders; and d) can be shared among the various
stakeholders;
2. measure the functional size of a software using its business
process model representation
made during the software requirements elicitation
activities.
-
6
To achieve this research purpose, the following research
question has been formulated: How
can a business process be represented to better suit the needs
and constraints of the various
stakeholders involved in software requirements elicitation
activities? This research question
is subdivided into the following sub-questions:
1. What are the needs and constraints of the various
stakeholders that should be represented
by specific business process modeling constructs when conducting
modeling during the
software requirements elicitation activity?
2. What is the appropriate level of abstraction to represent all
these modeling constructs in a
business process model? If more than one level of abstraction is
required, then what
modeling constructs should be represented at each level of
abstraction?
3. How well do current business process modeling notations
represent these levels of
abstraction and modeling constructs?
4. What would be a proposed BPM approach for consistently
representing the various needs
and constraints at their appropriate level of abstraction?
5. If a business process model represents software functional
requirements, then can it be
used for measuring the functional size of the software it
represents? If so, is there some
notation-specific business process modeling guidelines required
to allow this
measurement?
6. What would be the set of notation-independent business
process modeling guidelines for
measuring the software functional size?
7. What would be the procedure for measuring functional size
using a business process
model?
Research goal, objectives and scope
The research goal of this thesis is to contribute to the
representation of business processes for
its use during the software requirements elicitation stage of a
software project. More
specifically, this thesis aims at helping software engineers,
business analysts, and BPM
-
7
practitioners to better model business processes when those
models are meant to be used: as
part of a Software Requirement Specification (SRS) document; and
for FSM purposes.
The two research objectives of this thesis are:
1. To propose a novel modeling approach (coined BPM+) that will
generate business
process models intended to be used in a software requirements
elicitation activity. A
measure of the success of this proposal will be that it should
not significantly increase the
complexity of the BPM notations used to represent the business
processes; and it must
allow the active participation of the various stakeholders
involved in a typical software
project in order to represent, in a consistent and structured
way, their needs and
constraints. The resulting models should be easily understood
and shared by the various
stakeholders; easing the communication between the various
stakeholders as they now
can share a common set of models.
2. To develop a procedure to measure the functional size of a
software application from its
business process model representing its underlying functional
requirements. This
measurement procedure should be compatible with the COSMIC ISO
19761 FSM
method; and it should be able to be used independently of the
BPM notation used to
represent the business process.
To achieve the first research objective the following specific
research sub-objectives are
defined:
To identify the relevant Software Requirements Elicitation (SRE)
concepts published in
the Guide to the Software Engineering Body of Knowledge (SWEBOK)
as well as in the
Guide to the Business Analysis Body of Knowledge (BABOK) that
should be considered
when modeling a business process.
To determine the appropriate levels of abstraction to represent
the relevant SRE concepts
in a business process model.
To determine the modeling concepts that should be used at each
level of abstraction.
To assess how well current BPM notations represent these levels
of abstraction.
To identify the modeling constructs required to represent the
relevant SRE concepts.
-
8
To achieve the second research objective the following research
specific sub-objectives are
defined:
To develop a set of business process modeling guidelines to
allow functional size
measurement.
To define how to identify the notion of data movements in a
business process model.
To evaluate the accuracy of this novel measurement
procedure.
The scope of this research work is limited by three factors: 1)
the type of BPM notations used
to represent the business processes; 2) the perspectives to be
modeled; and 3) the FSM
method to be used for elaborating the procedure to measure the
functional size of a software
application from its business process models. The next
paragraphs discuss each of these
factors.
As a consequence of the growing popularity of business process
management, a growing
number of BPM languages and notations have been proposed to
model business processes.
Ko, Lee and Lee (2009) have proposed classifying BPM notations
into one of the following
four categories:
1. graphical notations (e.g. Business Process Model and Notation
(BPMN));
2. execution notations (e.g. Business Process Execution Language
(BPEL));
3. interchange notations (e.g. XML Process Definition Language
(XPDL)); and
4. diagnosis notations (e.g. Business Process Query Language
(BPQL)).
Of these four categories, this thesis focuses on the graphical
notations category, because this
is typically the category of BPM notations that will allow a
software project stakeholder to
represent and communicate his business processes in graphical
form. However, the focus of
this research is not on designing a new BPM notation but on
developing a novel BPM
approach that, based on selected BPM graphical notations, will
allow to consistently
represent the needs and constraints of the various
stakeholders.
-
9
For the purpose of this thesis, a business process modeling
perspective is given by the
stakeholder who is willing to model (or who is the target of)
the business process, and the
purpose of modeling the business process (Rosemann and Green,
2000). The purpose of
modeling depends on the task the stakeholder has to perform
based on the business process
model. The rationale behind this understanding of a business
process modeling perspective is
that the same stakeholder might present different needs
according to the uses to be given to
the business process models at a specific moment of time. In
addition, for a given purpose of
modeling there might be variations of the modeling needs
according to the different types of
stakeholders involved in the project (See Figure 0.1). The
stakeholders considered for the
scope of this thesis are the software engineers and the business
analysts. The purpose of
modeling is to use business process models for software
requirements elicitation.
There are currently five FSM methods approved by the
International Organization for
Standardization (ISO/IEC, 2006; 2010). From these FSM methods
approved by the ISO, this
thesis uses the one proposed by the Common Software Measurement
International
Consortium (COSMIC): the COSMIC FSM method (COSMIC, 2009).
COSMIC has been
Figure 0.1 Business process perspectives
-
10
accepted since 2003 as international standard ISO/IEC 19761:2011
Software engineering
COSMIC: A functional size measurement method (ISO/IEC, 2011).
COSMIC was designed
to be applied in various functional domains: 1) business
application software; 2) real-time
software; and 3) a combination of the two. It is completely open
and available in multiple
languages (COSMIC, 2009). From the possible functional domains
where COSMIC FSM
method can be applied, this thesis covers the business
application and the real-time software
domains with an emphasis in the former domain.
Thesis organization
This thesis is structured in 4 chapters, the thesis conclusions,
one annex and 11 appendices.
Following this introduction, Chapter 1 entitled LITERATURE
REVIEW, presents a review
of related work and establishes the theoretical framework for
this research. The focus of the
literature review is on the identification of:
1. what has already been published that attempts to solve the
research sub-questions
formulated in this thesis;
2. issues that have not been solved by the academia, the
industry, or by other BPM research
efforts; and
3. accepted academic techniques and approaches that could
contribute to solving our
research sub-questions.
Chapter 2 entitled RESEARCH METHODOLOGY, ACTIVITIES AND
EXPECTED
RESULTS, presents the research methodology used to address the
research sub-questions. It
first introduces a clear definition of the problems and the
design of a proposal to address
them; next, it follows with the description of the research
plan, research activities and their
execution; and it concludes with the interpretation step of the
results obtained from the
execution of the research activities. The research deliverables
and outcomes are presented.
Chapter 2 also describes each of the main research
methods/techniques used during the
execution of the research activities; the overall research
design and the validity issues of each
of the research methods/techniques are presented.
-
11
Chapter 3 entitled BUILDING THE BPM+ APPROACH, presents the
development process
of the novel BPM+ approach proposed as one of the two main
contributions of this thesis. An
a priori version of this modeling approach is drawn upon the
results of the literature review
(CHAPTER 1). This a priori version is iteratively reviewed and
improved through a number
of research methods/techniques (i.e. case study,
representational analyses, and survey) until a
final version is proposed. Therefore, BPM+ is designed based on
a theoretical framework that
has been evaluated trough triangulation of evidences (Dahlander,
2005; Miller, 2008; Par,
2002; Runeson and Hster, 2009) obtained from various
sources.
Chapter 4 entitled MEASURING FUNCTIONAL SIZE FROM BUSINESS
PROCESS
MODELS WITH COSMIC FSM METHOD, presents the development process
of the
procedure to measure the functional size of a software
application from a business process
model. The FSM procedure proposed is the second main
contribution of this thesis. This
procedure is applied using two modeling notations: Qualigram and
BPMN. It is also applied
both in a business application domain context and in a real-time
domain context. Based on
the results obtained, a set of notation-independent BPM
guidelines for FSM is proposed. The
measurement accuracy is evaluated next by comparing the results
obtained to those obtained
by reference case studies published in the COSMIC
literature.
Finally, the conclusions chapter of the thesis summarizes the
main contributions of this
research, pointing out their originality. We revisit the
research sub-questions that have been
formulated, and how they have been addressed. We present also
the expected impacts of this
research work, and analyze its limitations. Finally, some
recommendations for future
research work are proposed. These recommendations aim to
motivate the undertaking of new
research or innovative applications that build on or develop the
contributions to the
knowledge generated in this research.
-
CHAPTER 1
LITERATURE REVIEW
In the literature it is possible to find multiple definitions or
conceptions of the terminology
related to this research (e.g. business process, business
process model, etc.). Therefore,
before proposing any new solution it is necessary to review and
analyze the various
definitions given to this terminology in the literature in order
to determine the definitions that
will be used as a basis in this thesis. The definition of
business process is covered in section
1.1; then, in section 1.2, we define business process
management. Finally, section 1.3
provides the definitions of business process modeling and
business process model.
Over the past 20 years, a growing number of notations for
modeling business processes have
been proposed, illustrating the growing popularity of business
process management. One of
the critical factors for the success of a BPM project is the
right selection of the modeling
notation (Bandara and Rosemann, 2005). Therefore, it is
necessary to assess the various BPM
notations currently available. Subsections 1.3.2 and 1.3.3
review some of the BPM notations
currently available.
The literature proposes various frameworks for assessing BPM
notations (Aguilar-Saven,
2004; Daoudi and Nurcan, 2007; Giaglis, 2001; Hommes and Van
Reijswoud, 2000;
Kaschek et al., 2007; List and Korherr, 2006; Luo and Tung,
1999; Nysetvold and Krogstie,
2005). The authors of each framework define the characteristics
that they consider as critical
for the assessment of a BPM notation. For example, Luo and Tung
(1999) consider critical to
assess the formality, scalability, enactment-ability, and ease
of use of a BPM notation; while
Aguilar-Saven (2004) considers critical the adaptability of a
BPM notation. These
frameworks are not contradictory but complementary. Also, it is
possible to find in the
literature various techniques and methods for assessing
particular characteristics of BPM
notations (Green and Rosemann, 2000; Indulska, zur Muehlen and
Recker, 2009; List and
Korherr, 2006; Mendling and Strembeck, 2008; Russell et al.,
2004; Sarshar and Loos, 2005;
-
14
van der Aalst, ter Hofstede and Dumas, 2005; zur Muehlen and
Rosemann, 1998). This
thesis: 1) focuses in the capability of a BPM notation to
represent specific modeling needs
and constraints, and 2) follows an assessment technique that is
based in a well-established
ontology (Rosemann et al., 2009). Section 1.7 reviews this
ontology-based assessment
technique.
Modeling a business process is not a trivial task: a business
process involves many types of
elements (e.g. activities, roles, events, etc.). Each
stakeholder presents specific needs for a
type of element that should be modeled in a business process
model. In addition, the purpose
of modeling also dictates the types of elements that should be
modeled (Luo and Tung, 1999;
Rosemann and Green, 2000). A business process model aiming at
simply documenting a
business process might look different to a business process
model that aims at the automation
of the same business process. Therefore, the correct selection
of the types of elements to be
represented by a business process model depends on the needs of
a specific stakeholder when
performing a specific task. This thesis focuses on the needs of
software engineers and
business analysts when performing requirements elicitation.
Subsection 1.6.1 present the
references used in this thesis for identifying those needs; and
subsection 1.6.2 present the
various proposals found in the literature where BPM has been
specifically used for
requirements elicitation.
The difficulty on representing all the possible required types
of elements using one single
BPM notation has been reported in the literature (Dreiling et
al., 2008; Van Nuffel and De
Backer, 2012) and multiple approaches have been proposed by
various authors as solutions to
this difficulty. Some of these approaches involve the
representation of several BPM
perspectives (see section 1.4) while others propose the use of
multiple levels of abstraction
(see section 1.5) to address this problem.
Our research does not only aim to model business processes in
order to successfully
document them as part of a SRS document, but also to use the
models generated as a basis
for measuring the functional size of the software they
represent. Therefore, it is also
-
15
necessary to review the functional size measurement (FSM) method
used in this research for
addressing our second research objective: the COSMIC FSM method
(see subsection 1.8.1);
and to review previous related work where conceptual modeling
and business process models
more specifically, have been used as a source for FSM (see
subsection 1.8.2).
1.1 What is a business process?
Many definitions of business process can be found in the
literature. Each definition varies
depending on the viewpoint of the author and depending on the
focus of the publication.
Many authors (Curtis, Kellner and Over, 1992; Davenport, 1993;
Dumas, van der Aalst and
Ter Hofstede, 2005; Green and Rosemann, 2000; Zairi, 1997) make
little distinction between
the terms process and business process. This research has
considered any definition that helps
to identify the different types of elements that contribute to a
business process.
Curtis, Kellner and Over (1992, p. 76) define a business process
as: one or more agents
acting in defined roles to enact the [business] process steps
that collectively accomplish the
goals for which the [business] process was designed. This
definition highlights the
importance of actors and their roles. Medina-Mora et al. (1992)
also place the actors at the
center of the process. Hammer and Champy (1993, p. 35; quoted in
Ko, 2009, p. 12; Lindsay,
Downs and Lunn, 2003, p. 1017) provide a more comprehensive
definition: a collection of
activities that takes one or more kinds of input and creates an
output that is of value to the
customer. A business process has a goal and is affected by
events occurring in the external
world or in other processes. One common viewpoint shared between
Curtis and Hammers
definitions is the importance placed on the business process
need to reach a goal. However,
Hammers definition brings additional viewpoints into play: the
activities, the internal and
external events, the transformation of inputs into outputs, and
the generated value. Davenport
(1993) adds the notions of time, place and structure for the
enactment of the activities:
A [business] process is simply a structured, measured set of
activities designed to produce a specified output for a particular
customer or market. It implies a strong emphasis on how work is
done within an organization, in contrast to a product focuss
emphasis on what. A
-
16
[business] process is thus a specific ordering of work
activities across time and place, with a beginning, an end, and
clearly identified inputs and outputs (Davenport, 1993, p. 5).
Another important contribution of Davenport's and Hammers
definitions is the target of the
result of the business process: it is not just the execution of
a group of activities, but aiming
at a particular customer or market. Zairi (1997, p. 64) shares
Hammers viewpoint of
considering a business process as a transformation of inputs
into outputs: an approach for
converting inputs into outputs. Green and Rosemann (2000, p. 78)
add the notion that there
is a transformation of a business-relevant object in a business
process: the sequence of
functions that are necessary to transform a business-relevant
object. Gulledge and Sommer
(2002) also contribute to the definition of a business process
highlighting the notion that a
business process crosses the functional boundaries of an
organization. Spanyi (2003, p. 24)
emphasizes the need to clearly understand the difference between
a business process (using
Davenport's definition) and an Enterprise Business Process which
is the end-to-end
(cross-departmental, and often, cross-company) coordination of
work activities that create
and deliver ultimate value to customers. More recently, Sharp
and McDermott (2009, p. 56)
add additional types of elements to the definition: a way for an
enterprise to organize work
and resources (people, equipment, information, and so forth) to
accomplish its aims. This
last definition highlights the use of two kinds of resources:
tangibles (equipments), and
intangibles (information).
In summary, from these many definitions we learn that a business
process involves many
types of elements. To be effective, a business process should
aim at a goal; it typically
includes a series of structured activities that transform inputs
into outputs bringing some
value to a customer or to the market. An activity might be
triggered by an internal or external
event, and it is executed by actors (employees) playing specific
roles and using resources
(tangibles and intangibles) of the organization. A business
process often crosses the
functional boundaries of a specific corporate function covering
organizations end-to-end. As
a result of the execution of an activity, business-relevant
objects are transformed and value
can be assessed. Figure 1.1 summarizes these findings.
-
17
With a clearer comprehension of a business process, we proceed
in section 1.2 to present the
concept of business process management and some examples of its
support systems.
1.2 Business process management and its support systems
Organizations look for enhancing their efficiency and
effectiveness to achieve their goals
(ISO, 2008); for many of them this translates into achieving
revenue improvements, which
are directly tied to customer satisfaction and performance
improvement. If each of the
business processes of the organization is optimized, then the
organization should be more
efficient and effective to achieve its goals, to satisfy its
customers, and finally to improve its
revenues. This business process approach is typically referred
in the literature by the term
business process management. In this section the definition of
business process management
Figure 1.1 Description of a business process
-
18
is first presented examining both its origin and its current
perception, and next some
examples of support systems and tools for business process
management are presented.
1.2.1 What is business process management?
The origin of business process management is related to
different management efforts that
have been proposed to bring competitiveness to the
organizations, either by improving the
quality of their products and services (Elzinga et al., 1995),
or by improving the performance
of their business processes (Zairi and Sinclair, 1995a). Most
authors agree that the
contributions of process innovation by Davenport (1993) and
re-engineering by Hammer and
Champy (1993) were the catalysts of the popularity growth of
business process management.
Business process management is neither a technology nor a type
of information system: it is
a management approach; therefore, this subsection will not
consider those definitions that
only present a clear IT-oriented point of view of business
process management.
Elzinga et al. (1995, p. 119) provide a definition of business
process management that
highlights the importance of the quality of what is done by the
organization: a systematic,
structured approach to analyze, improve, control, and manage
[business] processes with the
aim of improving quality of products and services. Zairis
definition shows more concern
for the performance of how things are done within the
organization: [Business process
management] is a structured approach to analyze and continually
improve fundamental
activities such as manufacturing, marketing, communications and
other major elements of a
companys operation (Zairi, 1997, p. 64).
Some recent definitions, for example, Recker et al. (2006, p. 2)
provide a more general
definition: a structured, coherent and consistent way of
understanding, documenting,
modeling, analyzing, simulating, executing and continuously
changing end-to-end business
processes and all involved resources in light of their
contribution to business performance.
Later, Smith and Fingar (2007) argue that business process
management is for business
-
19
people (p. 14), enabling them to gain control of the design,
implementation and
optimization of their business processes.
For this research, the term business process management is a
structured management
approach aimed at optimizing end-to-end business processes to
create value and to contribute
to the organizations goals.
As stated at the beginning of this section, business process
management is not a technology;
however, information technology can support any business process
management activity. The
next subsection (1.2.2) analyzes some examples of support
systems for business process
management.
1.2.2 Business process management support systems
When re-engineering and process innovation came into scene, at
the beginning of the 1990s,
different authors, vendors and practitioners began to support
those new management
approaches with the use of workflow management systems (WFMS)
that had been originally
developed for office automation (Dumas, van der Aalst and Ter
Hofstede, 2005; zur
Muehlen, 2004). Shortly after, the terms business process
management and business process
management system (BPMS) began to be used, the former one
sometimes mistakenly, to
refer to either legacy systems or specifically developed systems
that supported these new
management approaches. As Smart, Maddern and Maull (2009)
mention, the term business
process management has been continuously used, even after
process improvement and re-
engineering no longer were considered as relevant concepts. At
the beginning of the 2000s
there has been an increase of the interest in these latter terms
as a way to perform business
process automation. During this time frame, the expression
process aware information
system (PAIS) appeared as an attempt to lump together every
process-oriented information
system. This section reviews these business process management
support systems.
-
20
According to Georgakopoulos, Hornick and Sheth (1995, p. 119), a
workflow describes the
activities of a business process at a conceptual level. The
workflow management
technologies can support the reengineering of an existing
business process. Reengineering a
process implies the optimization of an existing business
process; therefore, monitoring and
controlling the business processes is implicit in the term. A
WFMS aims at supporting: 1)
business process modeling; 2) business process reengineering;
and 3) workflow
automation.
Smith and Fingar (2007, p. 233) argue that a BPMS enables
companies to model, deploy
and manage mission-critical business processes, that span
multiple enterprise applications,
corporate departments, and business partners. After comparing
this perception of a BPMS
with the definition of business process management given by the
same author (See
subsection 1.2.1), it is possible to find a parallelism between:
model and design; deploy and
implement; and, manage and optimize. If the organization wants
to optimize a business
process it needs some sort of monitoring and control of it.
More recently, Dumas, Van der Aalst and Ter Hofstede (2005, p.
7) propose the acronym
PAIS. It is defined as: a software system that manages and
executes operational processes
involving people, applications, and/or information sources on
the basis of process models.
Note that this definition uses the term operational process'
rather than business process. The
former term is more general, and includes any kind of process
that allows managing the
resources and activities within an organization. Because of this
more general definition,
Dumas, Van der Aalst and Ter Hofstede (2005) consider as
examples of PAIS different
systems, such as: tracking systems, collaboration systems, and
enterprise resource planning
systems (ERP). This definition is complemented with a four-phase
lifecycle named the PAIS
lifecycle: 1) [business] process design; 2) [business] process
implementation; 3) [business]
process enactment; and 4) diagnosis (See Figure 1.2). In this
definition, the diagnosis phase
corresponds to the monitoring needed to improve a business
process.
-
21
The three different business process management support systems
proposed by the authors
are compared in Table 1.1 from a lifecycle point of view. In
this table the first lifecycle phase
(modeling or design) allows for two different situations. The
first situation is the modeling or
design of a new business process: this usually is referred in
the literature as the as is
business process. The second situation is the re-modeling or
redesign of a business process
based on the results of a reengineering, optimization or
diagnosis phase. This second
situation is referred, in the literature, as the to be business
process.
For some authors these three business process management support
systems are identical. For
example, zur Muehlen (2004) sees little difference between WFMS
and BPMS. However,
other authors highlight many differences among them. For
example, Dumas, Van der Aalst
Figure 1.2 The PAIS life cycle Adapted from Dumas, van der Aalst
and Ter Hofstede (2005, p. 12),
Copyright 2005 by John Wiley & Sons, Inc., with permission
from John Wiley and Sons
Design
Implementation
Enactment
DiagnosisBusiness
Process
-
22
and Ter Hofstede (2005) present a WFMS as a subset of a PAIS
which does not include the
diagnosis phase of the lifecycle.
This thesis will avoid using the term WFMS as there is currently
no consensus among the
different authors. It will not use the term PAIS because of its
generality. This thesis will use
the term business process management system and its acronym
BPMS. It is possible to find
languages, notations and tools that are designed for each of the
four phases of the BPMS
lifecycle (See Figure 1.2). From these four phases, this thesis
focuses on the first phase (i.e.
business process design or modeling); therefore the next section
(section 1.3) will introduce
some basic concepts of business process modeling (BPM) and then
it will review some of the
most popular languages and notations that are used for this
first phase.
1.3 Business process model and modeling
Business processes are often informal and part of an employees
experience and
competencies. It has been discovered, over the years, that
business processes need to be
represented formally at each of the four phases of the BPMS
lifecycle. To represent a
Table 1.1 Comparison of business process management support
systems
Authors
Business process
management support systems
Lifecycle phases
(Georgakopoulos, Hornick and Sheth, 1995)
Work Flow Management System
Modeling Automating Reengineering
(Smith and Fingar, 2007)
Business Process Management System
Model / Design
Deploy/Implementation Manage/ Optimization
(Dumas, van der Aalst and Ter Hofstede, 2005)
Process Aware Information System
Design Implementation Enactment Diagnosis
-
23
business process, business process models are often preferred to
textual descriptions. This
research will mostly focus on the business process modeling
needs during the design phase of
the BPMS life cycle. In this section, the definition of a
business process model is presented
first, and then some of the most popular BPM notations are
reviewed.
1.3.1 What is a business process model?
A model is an abstraction of the reality (Curtis, Kellner and
Over, 1992): it represents only
those details that the modeler considers as important for the
domain he or she is working for.
Thus, a business process model is defined as an abstraction of a
real business process.
Moreover, a business process model represents those types of
elements, of the real business
process, that the modeler believes are important for a specific
perspective.
Therefore, business process modeling (BPM) is the act of
producing abstract representations
of actual business processes. In this thesis, BPM is considered
directly related to the design
phase of the BPMS life cycle. The design phase addresses
high-level concerns of a business
process. For example, stakeholders, at the design phase, will
likely document an existing
business process, design a new business process, or modify an
existent business process.
BPM might also be used during the design phase, by software
engineers and business
analysts, for gathering the software and system requirements of
information systems (Albani
and Dietz, 2006; Eriksson and Penker, 2000; Georgakopoulos,
Hornick and Sheth, 1995;
Green and Rosemann, 2000; List and Korherr, 2005; Mayr, Kop and
Esberger, 2007; Mili et
al., 2009; Recker et al., 2006). The clarification of the scope
of BPM for this thesis is needed
because at a lower level (implementation and enactment phases)
modeling the business
process might also be required. In many publications this lower
level modeling is also
referred as a business process modeling. For this thesis, we
will refer as business process
execution model any model used at the implementation or
enactment phases.
-
24
One of the critical factors for the success of a BPM project is
the right selection of the
modeling notation (Bandara and Rosemann, 2005). The next
subsections (1.3.2 and 1.3.3)
review some of the most popular BPM notations.
1.3.2 Popular BPM notations
One of the key factors for successfully modeling business
processes is the use of an
appropriate BPM notation (Sedera et al., 2004). IT and
management typically use different
notations, conventions and techniques to represent business
processes (Curtis, Kellner and
Over, 1992; Indulska, zur Muehlen and Recker, 2009; Lankhorst,
2005; Smith and Fingar,
2007; Vara, Snchez and Pastor, 2008; zur Muehlen and Ho, 2008).
Over the last 20 years, a
plethora of notations for modeling business processes have been
proposed and developed.
Based on the lifecycle phases of a BPMS (See Figure 1.2), Ko,
Lee and Lee (2009) have
proposed classifying BPM notations into one of the following
four categories: 1) graphical
notations (e.g. BPMN); 2) execution notations (e.g. BPEL); 3)
interchange notations (e.g.
XPDL); and 4) diagnosis notations (e.g. BPQL). Of these four
categor