Is BPMN Suitable to Represent Software Process?

Campos, Andre L. N. C

Oliveira, Toacy C.

Instituto Alberto Luiz Coimbra de Ps-Graduao (COPPE)

Federal University of Rio de Janeiro (UFRJ)
Caixa Postal 68.511 CEP 21.941-972 RJ - Brasil
andrecampos@ufrj.br

Instituto Alberto Luiz Coimbra de Ps-Graduao (COPPE)

Federal University of Rio de Janeiro (UFRJ)
Caixa Postal 68.511 CEP 21.941-972 RJ Brasi
toacy@cos.ufrj.br

Abstract BPMN 2.0 is a widely used notation to model business

process that has associated tools and techniques to facilitate
process management, execution and monitoring. As a result
using BPMN to model Software Development Process (SDP) can
leverage on the BPMNs infrastructure to improve SDP quality.
This work presents an evaluation for using the BPMN notation
for modeling software processes.
Keywords Process modeling; BPMN;Modeling notations;
Process software; CMMI.

I.

INTRODUCTION

Software development organizations need to continuously

improve the quality of their products, while facing challenges
such as the rapidly changing technologies involved in
building and maintaining the software and the increasing
complexity of these technologies [1]. To meet these
challenges organizations seek to improve the software
development process, and consequently improve the quality
of the software they deploy. [2] [3].
In this scenario, a full understanding of practices
performed by the software team is a premise for improving
the software process. It is important to realize that practices
in software development go beyond a shallow representation
of the results related to each stage but they specify and
organize whole set of concepts such as roles, tasks,
documents and sequencing [4].
A common manner to foster comprehension is through
modelling. Modelling is a technique that allows the
representation of several interrelated concepts using a
graphical approach, which can be organized in different levels
of abstraction depending on how much detail they represent.
As a result, modelling a software process can improve process
readability, and proved to be an efficient technique for
describing and understanding the dynamic behavior and
complex systems [5].
While there are several process modeling languages that
could be used do modeling software processes, such as Aris,
and IDEF [5], SPEM 2.0 (Software & Systems Process
Engineering Meta-Model) [6] expected to become the leading
technology in this area, because it has broad tools support and
is supported by the Object Management Group (OMG), an
organization that gathers industry and academy to foster
standards such as the UML (Unified Modeling Language).
SPEM allows the specification of process elements such as
activities, roles and work products. Thus, software processes
in SPEM are represented as graphs of process elements that
are connected to denote activity sequences, work products
consumption and roles allocation.

Although SPEM has great potential with regards to

software process representation, it does not provide concepts
or formalism for modeling process behaviour precisely.
Consequently, SPEM fails to address process execution,
optimization and simulation [7] [8], which are important
activities in processes management. On the other hand, the
Business Process Management (BPM) discipline attempts to
design, monitor, configure, enact and analyze processes, and
for this objective many tools and techniques were developed
throughout the past decades.
Given that Software Development Processes can be
viewed as Business Processes [9], it would be beneficial to
leverage on the Business Process Management discipline,
tools and techniques and improve how SDPs are conducted.
At the heart of BPM is the explicit representation of processes
characteristics through a modeling notation, more specifically
with BPMN (Business Process Model and Notation) [10].
Once processes are defined, they can be subject to analysis,
improvement, and enactment.
Considering that BPMN is a widely used notation and was
matured over the years to incorporate several tools and
techniques [11], it would be beneficial if the Software
Development community could leverage on such maturity to
improve quality in software systems. For that reason this
work presents the use of the Business Process Modeling
Notation (BPMN) to represent a Software Development
Process. We have focused our assessment on analyzing the
modeling aspects of OpenUp, a well-documented version for
the Unified Process.
This work will consider the possibility of understanding
the process software by Business Process Modeling Notation
(BPMN). Section 2 addresses the process software in general
and issues of quality. Section 3 deals with BPMN notation.
Section 4 explains about an experiment involving process
software modeling using BPMN, and section 5 discusses the
results of that experiment. Finally, section 6 makes some
conclusions about the article and possible future work.
II.

SOFTWARE PROCESS

Considering the amount of standards, models and methods

related to software process, we can realize how difficult could
be understand what a software process is. For example,
there are the ISO 9.000, MIL-STD-498, IEEE 1074, CMMI,
Extreme Programming, Scrum, Adaptive Software
Development, Crystal, OPEN, RUP, OOSP, and others
standards or guides to good practices, which are called,
sometimes, "software process" [12] [13].

However, it is important to understand the differences

between those standards and models, and their goals. In this
paper, standards and models are arranged in four classes, as
seen in Figure 1:

activities. Moreover, these models do not clarify what

artifacts would be produced and consumed.
B. Software Process Models
In order to represent more details on software processes
there are the Software Process Models. A Software Process
Model typically specifies the activities, roles and documents,
organized on a specific order to maximize the team output.
Process models are commonly organized as light-weight, such
as SCRUM and XP and heavy-weight (or prescriptive), such
as UP.
Scrum deals mainly with the aspects of project
management for software development. The work is
performed incrementally by a self-organized development
team. Each increment or round, called Sprint, begins with the
planning of that round and ends with a review of this round.
The functionalities to be implemented are recorded in a
particular artifact, the backlog. The customer decides, from
the backlog, which features will be built in the next Sprint.
There is a specific profile, the Scrum Master, which is
responsible for solving problems that could interrupt the work
[16].

Figure 1.The process software and its relation to standards and models.

1.

Models for software life cycle.

2.

Software process models.

3.

Models for software process improvement.

4.

Software processes.

It is noteworthy that the conceptual framework presented

in Figure 1 does not represent the complete set of existing
standards and models, but models that exemplify these
standards by referencing some of the most cited in academic
literature.
A. Models for software lifecycle
Over the years, with increasing complexity of software
development, there were proposed structures dictating how
development should work. The goal was to increase
efficiency and effectiveness. These organizational structures
came to be called "model for software life cycle".
Several structures have been proposed. For example, the
"waterfall model" has a set of steps leading to the
development and maintenance of software, which occur
sequentially. The "prototype model" has the idea of building
the software increasingly using software prototyping, which
facilitates the correct identification of customer requirements,
and where the prototype may or may not be discarded along
the way. The "spiral model" is a form of incremental
construction, where the risk is monitored and treated
throughout the software development [14] [15].
Typically most models for software life cycle is that they
define a set of common features such as: major stages and
steps; the general line of what should be done; and some brief
description about the flow of time between these steps.
However, they do not detail these steps in activities, and do
not clearly specify the actors who would perform these

Extreme Programming (XP) is aimed at application

development best practices. The XP has 22 practices to be
performed by various roles during the process of developing,
producing and consuming devices recommended by this
model. Among the practices are: planning game, small
releases, customer tests, pair programming, continuous
integration, among others [16].
The OPEN is an initiative of the public domain, processoriented, to support software development, in particular
object-oriented development. In this model the roles and
activities are defined as well as artifacts. The work is oriented
for components such as internships, languages, producers,
work units and work products [17].
The Unified Process (UP) or unified process, was first
described in 1999 by Jacobson, Booch and Rumbaugh, also
known as Rational Unified Process (RUP), having been
created in the Rational company. With the acquisition of
Rational by IBM in 2002, the terms Unified Process and
Rational Unified Process are registered by IBM, who also
created the name IRUP (IBM Rational Unified Process). This
model defines roles and activities for the development of
software, including recommended artifacts, and seeks to
support the production of high quality software [18].
It is possible to realize that the software process models
have in common a concern with the sequence between stages,
activities and steps. Still, there is an indication of the profile
that performs the activities and the artifacts to be produced
and consumed throughout the process.
C. Models for Process Improvement
Software process improvement models are standards and
capability maturity models focused on processes to achieve
high quality software, reducing cost and time, and increasing
productivity. [19]. Some of the more often cited standards and
models will be considered bellow.

The methods of improvement CMMI and MPS.BR are

based on ISO 15504. They propose adherence to best
practices of progressive levels, each level adds a new set of
practices that should be added to any set of practices already
adopted. Thus, over a period of time, the organization can
develop all practices, reaching the maximum level of the
guide [23] [24].
The improvement models, in general, consolidate and
standardize concepts and vocabulary, have the desirable
processes in general, usually the big steps, but do not
determine activities, timeliness, or artifacts. They provide
references, a mirror in which the organization can see itself
and identify what needs to be improved.
D. Process software
The software process of an organization is the standard
model of the development process and software maintenance,
including activities to be performed, the artifacts produced
and consumed, and the actors involved. This model serves as
a basic infrastructure that can be used in its original state or
adapted to meet a given project [9]. It is possible that the
organization has some processes more standardized, more
suited to different types and sizes of projects. These standard
models are instantiated for a project, and the team seeks to
work so they are compliant to the model instantiated.
At some point it is important to verify that the work of the
team is adhering to the process instantiated for the project.
Otherwise, all efforts made earlier to define a process suitable
work, have been in vain.

The objectivity, clarity and ease of understanding of

BPMN notation [5], is probably the reason why BPMN has
become one of the most widely used notations for modeling
work processes [26].Moreover, BPMN notation is open,
standardized and maintained by the OMG [10]. Thus, this
work uses the BPMN notation as a tool for modeling and
clarification the software process.
BPMN has basically tasks elements, connecting elements,
elements of organization, and data elements of artifacts, as
shown in Table 1. The major elements of the notation are
used to represent the workflow and the information used by
process. However, elements "Pool", "Lane" and "Milestone"
are used to organize the others elements.
TABLE 1.BASIC ELEMENTS OF THE NOTATION "BPMN" (NOT EXHAUSTIVE).

BPMN

In 2002 a group called Business Process Management

Initiative (BPMI) started to develop a standard for graphic
representation of processes. That same year a formal standard
for the representation of processes was published, the XML
Process Definition Language (XPDL), by Workflow
Management Coalition (WfMC). Because of the interest and
rapid adoption of BPMN by the market, in 2006 the Object
Management Group (OMG) incorporated this pattern and is
now its official maintainer. First, the notation BPMN did not
have a formal language to support it, and moreover the pattern
XPDL lacked a defined graphical representation. Then, the
OMG also incorporated the standard XPDL and went on to
join BPMN and XPDL, so that new versions of both standards
are published in sync [25].Currently, the BPMN notation

Gateways

III.

The primary objective of the notation is to be

understandable by people, but also has a formal structure that
supports this notation. This facilitates its processing, or
"understanding," by machine. Actually, previous work
demonstrated that the use of BPMN notation for process
modeling achieves the goal of representing knowledge about
work processes in an easily understandable way for people
[5].

Tasks (Activities)

The ISO 15504 is a standard maintained by ISO with the

support of the SPICE (Software Process Improvement and
Capability Determination). This standard helps in improving
the process by diagnosing the current situation and proposing
improvement plans, which can be done in a maturity model,
that is, assessing the adequacy of the organization to a level at
one set of requirements or practices [22].

represents the state of the art in process modeling and

workflow modeling language [11].

Events

The ISO 12207 is a standard maintained by ISO

(International Organization for Standardization) establishing a
high-level architecture of the software process, with a set of
processes and relationships between these processes, which in
turn point to a set of activities. It, however, does not
determine any temporal sequence for the activities. [20] [21].

Organization

Connectors

Data

IV.

A BPMN process is made up of BPMN objects, like

activities, events, gateways, data, connectors, pools, and
lanes.
Tasks are single activities, and suprocess are groups of
activities. Events represent occurrences in process, like the
start, the end, or just a fact happened during the process. An
activity can be a task or a subprocess. A gateway is a routing
object, and can represents splits and joins in work flow. Data
objects and data store represents information used and
produced in process. The connectors are used to denote
control flow (sequence), interaction between processes
(message), and link between artifacts and activities
(association). Finally, pools and lanes objects are used to
organize the others BPMN objects [10].
BPMN, besides allowing the representation of processes
in a manner understandable by people from different areas of
an organization, also has the support of a formal model that
allows the execution of that processes modeled in a workflow
engine, for example. Still, makes possible to exchange
processes models between different tools and technologies.
[27].
However, BPMN notation provides other benefits. One of
these benefits is the possibility of simulation. The simulation
is a useful tool for exploring the operation of a system. A
model that represents certain main attributes is analyzed to
demonstrate the results of an alternative or courses of action.
That's possible in BPMN utilizing the XML Process
Language Definition (XPDL), which can be generated from
BPMN models [28].
All of these capabilities of BPMN notation could be
eventually applied to software development processes, if
BPMN would suitable to represent software process.

EVALUATION OF BPMN IN PROCESS SOFTWARE

The objective of this study was to investigate the

possibility of representing a software process through a
BPMN model, and also to observe impacts on the process
underststandability. Our goal was not to compare two or more
different methods of modeling, but was trying to understand if
the BPMN notation
would be applicable for
modeling software processes.
A. Evaluation method
For this reason, we conducted two evaluations in
sequence. The first evaluation was conducted in an academic
environment, and the second evaluation was conducted in real
environment.
The first phase involved five subjects from academic
setting, on Federal University of Rio de Janeiro. These
subjects were students of master's and doctoral degree from
that university. They didnt have experience with the BPMN
notation.
The second phase was conducted in a real environment at
the Oswaldo Cruz Foundation, an important public health and
research institution in Brazil. Ten professionals of this
organization participated in the experiment. These
professionals belong to the Systems team, and already have
experience with other process modeling notations, but they
didnt have experience with the BPMN notation.
The evaluation involved a software process modelling
activity, aiming at a possible future deployment of this model
in the development environment at the organization. Criteria
were established to analyse the modeled process.
The study was based on the following steps for each
phase:
1.

Brief training in BPMN, only for explaining the

notation;

2.

Modeling the software process so that each

participant could model a part of the work;

3.

Questionnaire, based on predetermined criteria;

4.

Analysis of results.

B. Chosen Software model

Although the work could be conducted based on any
process model, it was determined the use of Unified Process
(UP) as a reference, so that it would be possible to integrate
the parts subsequently made by each participant. However,
deploying the UP can be a challenge for organizations that do
not have a structured process of software, or are small
businesses. In this case, as a process had not been yet
effectively structured and explicit, the UP would be a
challenge.
To meet this challenge, the model OpenUP (Open Unified
Process) was created. This is an Open Source initiative
derived from the Unified Process, minimalist, extensible, and
can become a common denominator for software projects
[29]. It is considered a lightweight model and easier to
implement than the UP, but keeps your most important

aspects, such as iterative development and incremental

construction of software [30]. Because of these characteristics
we chose to use OpenUP as a reference in our work.
C. Criteria for evaluation
Aspects were analysed to demonstrate the applicability of
the BPMN notation for modeling software processes, or to
indicate this possibility. We have selected a set of criteria
based on previous work in this area such as [31] [32] [5], and
can be seen in Table 2. Thus, we used criteria defined by that
work.

macro process Inception. Finally, we can see the

breakdown of the Start project sub-processes in Figure 4.

Figure 2. The four macro process of OpenUP.

The questionnaire was prepared using the Likert scale, in

which the items to the responses vary with a given intensity
level, and the categories are arranged equally spaced with the
same number of categories for all items [33]. The evaluation
was performed considering the following four categories: 1 Strongly Disagree, 2 - Having to disagree, 3 - I tend to agree,
4 - I totally agree.
TABLE 2.SET OF CRITERIA USED IN THE SURVEY.

Figure 3. Macro process Inception.

D. The evaluation
Participants have performed the modeling of the software
processes in a complementary manner, so that parts of
OpenUP were modeled by different participants, and then
these parts were integrated into a single model. This was done
both in phase 1 and phase 2. Complexities of the model were
considered so that the modeling was performed at three levels
of abstraction. These abstraction levels provided a
comprehensive understanding, but at the same time a detailed
comprehension of the software process.
Modeling at different levels of abstraction may be
observed in figures bellow. Figure 2 shows the general level
of the model, showing only the four macro processes of
OpenUP (Phases). In Figure 3 we can see a breakdown of the

Figure 4. Sub-Process "Start project", from "Inception".

It is possible to notice in the second layer in model shown

in Figure 3 that in addition to the activities, roles, and

sequencing, the data produced and consumed are represented

too. Artifacts data are represented by the notation BPMN
Data Object element. Some Data Objects in this figure are:
Glossary, Use Cases, Vision Document, and Software
Requirements, among others.

software process, because they deal more directly with the

flow temporarily, activities, and artifacts produced and
consumed.

It's not possible to present in this work more than 40

BPMN diagrams produced by this work in its two phases,
then processes in Figures 1, 2 and 3 are just a sample of that
work.
E. Modeling Effort
The modeling task has consumed a total of 300 hours of
work, considering the time committed by each participant.
But, beyond the total hours, we consider necessary to
establish a mechanism to help us scale the effort, so that
would make the work comparable to other similar studies
conducted in the future.
Thus, we have established the number of elements used in
the models as a manner to represent the modelling effort in
our experiment. Since the BPMN notation is supported by a
formal language based on XML standard, and that the models
can be exported to XPDL (Process Definition Language)
which is a standard maintained by the Workflow Management
Coalition (WfMC), it was possible to develop a Java
application to do the automatic counting of elements used in
modeling, as shown in Figure 3.
Figure 2. Count of BPMN elements.

About 12% of the modelling effort (an estimated 36 hours

of modeling work) has been devoted to the organization,
while the remaining 88% (an estimated 264 hours of
modeling work) was dedicated to the representation itself. It
is noteworthy that most of the model was constructed to
represent the actual software development related work,
which can be seemed in Figure 4.

Figure 3.Screen of software developed to analyse BPMN models.

The models constructed by participants of the experiment

were analysed by the software element count. The elements
considered in the measurement were the Pools, Lanes, Events,
Data Objects, Gateways, and Activities, as we have
considered these the most important ones. After processing all
models in two pahses, we found a total of 1508 elements, as
can be seen in Figure 2.
For the purposes of this work, the elements "Pool" and
"Lane" were considered elements of organization. The others
elements types, like Tasks, Events, Data, Gateways
and Connectors, were considered more representative of

Figure 4.Relationship between organization and representation.

F. Threats to validity of evaluation

In empirical research it is important to make sure that the
data is correct and that we can get a good understanding of

these data. This concern is the threat of data validity. So here

we report some evidence of potential threats to validity [34]
[35].
Despite the efforts involved in this work, there are some
threats to validity that must be mentioned. The first threat to
be mentioned refers to the little training provided on the
BPMN notation. Originally, we thought that the concepts of
process modeling would be enough, but during the study we
found that this was insufficient, and that affected the way the
questionnaire was completed.
Another threat concerns to the relationship of the group of
participants. The components of the first group were students
of same institution, and components of second group are
professionals from the same team. In both cases they could
exchange information outside the study environment. So they
could be influenced by each other.

start activities, for instance. Then, if we analyse these events

and its types, we can realize the complexity of activities flow
in the process. That complexity could represent a level of
difficulty to implement the process.
Finally, the models represented 83 lanes and 99 pools.
These elements are used to represent the processes separation
and the actors presence in process. Using lanes as an
example of analysis, the counting of this element tell us
something about how much the process is actor-centred, or
actor-dependent.
So it is possible that analysis performed from the simple
counting of elements, and proportion of use of each element
in the models, can reveal important information about the
quality of the software process modeled.
H. Questionnaire analysis

Still, a threat to consider is the fact that only a software

development process has been modeled for each group,
despite its size. Also, because of the requirement of working
hours to perform the experiment and the relatively limited
availability of institutions willing to spend this time, the
experiment was conducted in only one academic environment
and in only one real working environment.
We believe that the amount of data generated by this work
is appropriate and adequate for an initial study, and that
replicating this result is an obvious next step.
V.

RESULTS

G. Counting of elements
The mere counting of elements allows us to compare the
relative use of BPMN elements during the process modeling
software. The analysis of these relationships allows a
qualitative assessment of the model, even by logical
deduction.
For example, note that the modelers did not use the object
"gateway" even once in first phase, and used just 8 gateways
in second phase. The gateways elements can be used for:
1.
2.
3.

Exceptions treatment (improving reliability of

process);
To express decisions to be made (improving
intelligence in process);
To represent different ways to do something
(improving flexibility to process).

These issues were addressed shortly, or even not been

addressed by modelers. Therefore, that software process
model could be better elaborated.
In this work, the modelers represented 747 data elements.
Attention to the data elements enables us understanding how
much knowledge-intensive is the process. Knowledgeintensive processes are, perhaps, more relevant than others.
On other hand, if we analyse the relationship between
activities (tasks) and data elements, it is possible to assess
how much effort is required to process certain amount of data.
Moreover, the modelers represented 189 events. The
events elements are used to represent certain conditions that
Figure 5.Assessment criteria for participants.

The questionnaire was responded based on Likert scale, as

previously explained. The options to answer in each question
were: 1 - Strongly disagree, 2 - Having to disagree, 3 - I tend
to agree, 4 - I totally agree. The subjects responded in each
phase, and their responses were compiled. The answers were
grouped by issues as shown in Figure 5.
We have three questions more related to the capacity of
representation of BPMN, which are questions 7, 8 and 9. For
question 7 the responses were 3 (I tend to agree) by both
groups. For question 8 the answers were 3 (I tend to agree)
by first group and 2.5 (between I tend having to disagree
and I tend to agree) by second group. For question 9 the
response were 2 (Having to disagree) by first group and 3
(I tend to agree) by second group.
In general, it is possible to realize a trend of the groups to
agree that BMPN is suitable for modeling this type of
processes. This result could recommend the commitment of
efforts to use the BPMN notation for modeling software
processes.

Actually, we found this behavior in almost all issues,

including the 2, 4, 5, 6, 7, 8 and 9. In these cases, we observed
that the absence of specific training on the BPMN notation,
appointed in questions 4 and 5, accounted for some loss of
reliability in relation to other issues. Probably, some of the
responses were influenced by lack of knowledge of the
BPMN notation, which in turn could allow do more than the
participant thought possible.
However, we noticed an unusual behaviour in the analysis
of questions 1 and 3. These issues had a much smaller
difference between the level of agreement and the amount of
justification, if compared to other issues. Furthermore, as
previously discussed, the participants were able to modeling a
complex software process, using 3 layers of representation
and all actors and data necessary, based on OpenUP model.
So, we analysed the explanations to find clues to this
behaviour.

The question 6 is related to usability and questions 4 and 5

are related to learning. There is a dependency between
Learning and Usability, so if the notation is unknown by
participants they cannot be able to use that in its full potential.
This relationship was evident in responses 4, 5 and 6. The
participants, in both groups, understood that it is not possible
to obtain good results without training in BPMN notation.
Consequently, they found that complex software processes
cannot easily be modeled using the notation BPMN.
However, the participants believe that the BPMN notation
could to receive improvements to better represent the
software process. This can be seen in the responses for
questions 1, 2 and 3, relating to completion of that notation,
that is, how complete is the notation to modeling this kind of
process. The first group was more optimist, giving score 3 to
these questions, while the second group have scored 2 to these
issues. It is not an "I totally agree", but this may indicate that
the BPMN notation needs improvement, perhaps extensions,
to be more complete for modeling software processes.
We realize that the scores to questions 1, 2, 3 and 6,
assigned by the second group were particularly lower than the
scores of the first group to the same issues. Based on these
scores would be natural to expect that the second group had
failed to correctly model the OpenUP process. Howerver,
besides low rating for "Usability" and "Completion of
notation", the participants were able to modeling a complex
software process, using 3 layers of representation and all
actors and data necessary. This caused curiosity, and so we
decided to obtain additional information regarding this
phenomenon. We apply a new questionnaire where
participants, only the second group, should transcribe a
simple explanation for each question answered as 1 Strongly Disagree and 2 - Having to disagree.
It was supposed that the issues with high agreement would
have little justification, and that the issues with low
agreement had many justifications. In Figure 6 is possible to
observe the relation between level of agreement and the
perceptual of subjects who explained their answers.

Figure 6. Explanations for answers of kinds "Strongly Disagree" and "Having

to disagree".

After reviewing the explanations, we conclude that the

group had a concern about the impact of research in relation
to their daily work. This group of participants in a real

company, had working for a long time with another notation

for process modeling. Maybe if the answers were very
positive about the BPMN notation, it was possible that they
would be obliged to change notation. This presumed threat
may have reduced the percentage of agreement for questions
1 and 3, and increases the rate of explanations for these
issues.
VI.

CONCLUSION

This work presents the fundamental concepts related to

software process and its improvement. During the study, we
evaluated the possibility of description of the software
through this process modeling using BPMN notation. For this,
we conducted a modeling study with two groups, the first
group in academic environment and the second group in a real
environment of an organization. After 300 hours of work and
more than40 BPMN diagrams containing 1508 objects, each
group produced in an integrated model of the software
process based on the Unified Process, according to the
adjustments recommended by the OpenUP.
The paper presents indications that the BPMN notation is
suitable for modeling software processes, but must be more
efforts to test and adapt this notation for this purpose. As
mentioned, the representation was well assessed. Responses
indicated a trend of the groups agreed that BMPN is suitable
for modeling this type of process. This result could
recommend the commitment of efforts to use the BPMN
notation for modeling software processes.
A factual evidence of the suitability of BPMN notation for
modeling processes was itself the result of work done by
participants study. All parts of a software process were
modeled using BPMN, and these parts were integrated into a
single model, where all could see the points of interface,
stakeholders, artifacts generated and artifacts consumed.
Thus, participants in both groups could have a comprehensive
and holistic view of the process of software that they
modeled.
The study showed, however, that initiatives using the
BPMN notation must be preceded by training. Even if those
involved have extensive experience with other process
modeling notations, BPMN notation has very particular
characteristics, which can be best exploited by skilled
professionals in this notation. In attempting to model a
software process using BPMN notation, the participants
understood the need to receive more investment in training for
future work, a legitimate concern because it is acting
participants in a real environment and seeks to model their
business processes.
Future studies may evaluate the impact of training in
BPMN notation on the results of process modeling software.
Can be analyzed the degree of progress reported by
participants, compared to this work. Another possibility for
future work related to this subject, would be to assess the
degree of adhesion between professional practice and the
process modeled in BPMN.
Still, this paper presented a possibility not originally
planned. We realize that it is possible to evaluate the quality

of a process model from the count and analysis of the

elements used in modeling, and their relationships. This was
not the original purpose of the work, so we do not devote
more time and resource in this approach. However, we
believe it is an interesting area for future studies.
Finally, still dealing with the possibility of future work,
this study realized the probable need to extend the BPMN
notation for use in the full process modeling software. Studies
have been conducted in this direction [36], but further studies
will explore the issue further.

VII.

REFERENCES

[1] A. M. Magdaleno, C. M. L. Werner e R. M. Araujo, Reconciling

software developmento models: a quasi-systematic review, The
Journal of Systems and Software, 2011.
[2] A. Fugetta, Software process: a roadmap, em Proceedings of the
Conference on the Future of Software, ICSE00, 2000.
[3] R. S. Pressman, Software Engineering: A Practitioners Approach,
McGraw-Hill, 2001.
[4] M. Niazi, D. Wilson e D. Zowghi, A maturity model for the
implementation of software process improvement: an emprirical
study, Journal of Systems and Software, pp. 155-172, 15 January
2005.
[5] A. L. N. Campos e T. C. Oliveria, Modelagem de Processos de
Trabalho e Desenvolvimento de Software: Notao e Ferramenta,
em VII Simpsio Brasileiro de Sistemas de Informao, 2011.
[6] OMG, Software Process Engineering Metamodel (SPEM) 2.0
Specification, 2008.
[7] G. Grambow, R. Oberhauser e M. Reichert, Towards a Workflow
Language for Software Engineering, em Proc. 10th IASTED Int.
Conf. on Software Engineering (SE'11), 2011.
[8] R. Bendraou, B. Combemale, X. Crgut e M. P. Gervais, Definition of
an eXecutable SPEM 2.0, em IEEE Computrer Society, Nagoya,
Japan, 2007.
[9] R. Araujo, C. Cappelli, A. Gomes Jr, M. Pereira, H. S. Iendrike, D. Ielpo
e J. A. Tovar, A definio de processos de software sob ponto de
vista da gesto de processos de negcio, 2004.
[10] Object Management Group, Business Process Model and Notation
(BPMN), 2010.
[11] M. Chinosi e A. Trombetta, BPMN: An introduction to the standard,
Computer Standards & Interfaces, pp. 124-134, 2011.
[12] D. Umphress, T. Hendrix e J. Cross, Software process in the classroom:
the Capstone project experience, Software, IEEE, pp. vol. 19,
issue 6, pp. 78 - 81, 2002.
[13] F. Guo, B. Xia e F. Xue, Analisys on software processes and
enhanecement for RUP, em Software Engineering and Service
Science, Beijing, 2011.
[14] I. Sommerville, Engenharia de Software, Pearson, 2011.
[15] R. S. Pressman, Engenharia de Software - Uma Abordagem
Profissional, McGrawHill, 2011.
[16] T. Dyba e T. Dingsoyr, Empirical studies of agile software
development: A systematic review, Information and Software
Technology, pp. 833-859, 2008.
[17] B.

Henderson-Sellers, OPEN, 2010. [Online].

http://www.open.org.au/. [Acesso em 16 12 2011].

Available:

[18] P. Kruchten, The Rational Unified Process - An Introduction, Pearson

Education, 2003.
[19] M. Niazi, D. Wilson e D. Zowghi, A maturity model for the
implementation of software process improvement: an empirical
study, Journal of Systems and Software, pp. 155-172, 15 January
2005.
[20] A. P. Freire, R. Goularte e R. P. M. Fortes, Techniques for developing
more accessible web applications: a survey towards a process
classification, 2007.
[21] ABNT NBR, ISO/IEC 12.207 - Sistemas e engenharia de software processos de ciclo de vida de software, 2009.
[22] C. von Wangenheim, A. Anacleto e C. Salviano, Helping small
companies assess software processes, IEEE Software, pp. vol. 23,
issue 1, pp. 91-98, 2006.
[23] A. C. Neto e E. W. Cazarini, A referencial model for small companies
of development software, IEE Latin America Transactions, pp.
89-95, March 2011.
[24] M. Staples, M. Nizai, R. Jeffrey, A. Abrahams, P. Byatt e R. Murphy,
An exploratory study of why organizations do not adopt CMMI,
The Journal of Systems and Software, pp. 883-895, 2007.
[25] K. D. Swenson e R. M. Shapiro, BPM in Pratice, Keith Swenson &
Robert Shapiro, 2008.
[26] v. d. A. Wil M. P., Process mining - discovery, conformance and
enhancement of business processes, Springer, 2011.
[27] S. A. White, New capabilities for process and interaction modeling in
BPMN 2.0, em BPMN 2.0 - Handbook, Future Strategies Inc.,
2011, pp. 17-32.
[28] J. Januszczak, Simulation for business process management, em
BPMN 2.0 - Handbook, Future Strategies Inc., 2011, pp. 43-57.
[29] C. Bertrand e C. P. Fuhrman, Towards defining software development
processes in DO-178B with OpenUP, Electrical and Computer
Engineering, pp. 851-854, 2008.
[30] G. Loniewski, A. Armesto e E. Insfran, An architecture-oriented
model-driven requirements engineering approach, Model-Driven
Requirements Engineering Workshop , pp. 31-28, 2011.
[31] R. d. S. Macedo e E. A. Schmitz, Ferramentas de modelagem de
processo: uma avaliao, XXXIII Simpsio Brasileiro de Pesquisa
Operacional (SBPO), 2001.
[32] C. Benedictis, D. C. Amaral e H. Rozendfeld, Avaliao dos principais
mtodos e ferramentas disponveis para a modelagem do processo
de desenvolvimento de produto, IV Congresso Brasileiro de
Gesto de Desenvolvimento de Produtos, 2003.
[33] J. W. C. Alexandre, Anlise do nmero de categorias da escala Likert
aplicada a gesto pela qualidade total atravs da teoria da resposta
ao item, Encontro Nacional de Engehnaria de PRoduo, 2003.
[34] C. Wohlin, Emprirical research methods in software engineering,
Lecture Notes in Computer Science, pp. 7-23, 2003.
[35] N. Juristo e A. M. Moreno, Basics of software engineering
experimentation, Kluwer Academic Publishers, 2001.
[36] F. Fonseca, T. Oliveira e E. Pereira, Uma extenso do BPMN para
modelagem de Processos de Desenvolvimento de Software:
BPMNt, em Simpsio Brasileiro de Sistemas de Informao
(SBSI), Bahia, Brasil, 2011.