IMPROVING THE CONSISTENCY OF SPEM-BASED

SOFTWARE PROCESSES

Eliana B. Pereira, Ricardo M. Bastos, Michael da C. Móra

Faculty of Informatics, Pontifical University Catholic of Rio Grande do Sul, Porto Alegre, Brazil
{eliana.pereira,bastos, michael}@.pucrs.br

Toacy C. Oliveira
COPPE Department, Federal University of Rio de Janeiro, Rio de Janeiro, Brazil
[email protected]

Keywords: Software Process Metamodel, Process Checking, SPEM, Well-Formedness Rule.

Abstract: The main purpose of this paper is to improve the consistency of Spem-Based Software Processes through a
set of well-formedness rules that check for errors in a software process. The well-formedness rules are based
on the SPEM 2.0 metamodel and described using the Unified Modeling Language - UML multiplicity and
First-Order Predicate Logic - FOLP. In this paper, the use of the well-formedness rules is exemplified
using a part of the OpenUP process and the evaluation of the one of the proposed rules is shown.

1 INTRODUCTION combine elements from “off-the-shelf” processes,

since they represent best practices in the software
Software development is ultimately a procedure to engineering discipline. Software process engineers
convert informal specifications, typically gathered are also assisted by Situational Method Engineering
from real world scenarios, into formal pieces of code - SME. SME recommends creating a set of method
that can be executed by machines. Such a procedure fragments or method chunks (pieces of processes)
is mainly enacted by developers that follow an where each one of these fragments or chunks
orchestrated path from analysis, through coding and describes one part of the overall method (in this
testing. Orchestration emerges from a software paper called software process). Each software
process specification that details how process project starts with a process definition phase where
elements such as roles, tasks and work products, are the method fragments or chunks are selected and
interconnected in an organized manner (Jacobson et organized to attend the specific needs related to the
al., 2001). Although developers can find off-the- project (Henderson-Sellers et al., 2008).
shelf software process specifications such as Regardless the strategy used to define a software
Rational Unified Process - RUP (Kruchten, 2000) process specification, it is important to understand
and Object-Oriented Process, Environment and the associated complexity of interconnecting the
Notation - OPEN (Open, 2006), there is no “one size process elements that will be used to maximize the
fits all” process, which means a process must be outcome of a software project. Typically a process
defined to meet each project‟s needs (Xu and specification interconnects dozens, sometimes
Ramesh, 2003). hundreds, of process elements and any inconsistency
To define a software process it is necessary to in the process will negatively impact on how
consider project‟s constraints such as team, developers perform. Inconsistent processes have
resources, technology and time-to-market, to create several forms. For example, inconsistency may
the fabric of interconnected process elements that appear when a task requires information that is not
will guide software development (Jacobson et al., produced by any other task; when two or more work
2001). Typically, software process engineers products duplicate information; or even when tasks
are sequenced in cycles. These problems are hard to 2 RELATED WORK
identify if no automated approach is adopted.
According to (Hug et al., 2009), as software Several papers have focused on defining software
processes are based on process models, which are process from a process metamodel. Some
directed by concepts, rules and relationships, a approaches (Puviani, 2009), (Habli and Kelly,
metamodel becomes necessary for instantiating these 2008), (Serour and Henderson-Sellers, 2004),
process models. Meta-modeling is a practice in (Bendraou et al., 2007) propose solutions using well
software engineering where a general model known metamodels such as OPF or SPEM, while
(metamodel) organizes a set of concepts that will be others define their own process metamodels
later instantiated and preserved by specific models (Wistrand and Karlsson, 2004), (Gnatz et al., 2003),
(instances). In this scenario, a software process (Ralyte et al., 2006).
metamodel could represent basic interconnection In (Puviani, 2009), (Serour and Henderson-
constraints that should hold after the metamodel is Sellers, 2004), (Wistrand and Karlsson, 2004) and
instantiated (Henderson-Sellers and Gonzalez-Perez, (Ralyte et al., 2006) the authors consider
2007), thus minimizing inconsistencies. An metamodels to define method fragments, method
evidence of the importance of metamodels for chunks or method components. Although they differ
software processes is the existence of metamodels in terminology, fragments, chunks or components,
such as Software & Systems Process Engineering represent small elements of a software process. This
Meta-Model Specification - SPEM 1.1 (OMG, approach is known as Situational Method
2002), OPEN Process Framework - OPF (Open, Engineering - SME, which is a subset of the Method
2006), among others. Recently the Object Engineering - ME discipline. According to
Managements Group – OMG issued a new version (Henderson-Sellers et al., 2008), SME provides a
of its standard for Process Modeling, namely SPEM solid basis for creating software process. Chunks,
2.0, which offers the minimal elements necessary to fragments or components are typically gleaned from
define any software process (OMG, 2007). best practice, theory and/or abstracted from other
Although the SPEM 2.0 metamodel represents a processes. Once identified and documented, they are
great advance in software process specification and stored in a repository, usually called method base
consistency, its use is not straightforward. SPEM 2.0 (Henderson-Sellers and Gonzalez-Perez, 2007).
defines several concepts using the UML class In (Bendraou et al., 2007) the authors propose an
diagram notation and represents several constraints extension to SPEM 2.0 to address the lack of the
with natural language. For example, SPEM 2.0 “executability” of this metamodel. The objective of
allows the specification of a Task that does not the extended metamodel is to include a set of
consume, produce and/or modify any Work Product. concepts and behavioural semantics. In (Habli and
This is clearly an inconsistency once a Task has a Kelly, 2008) the authors present a process
purpose, expressed in terms of creating or updating metamodel that embodies attributes to facilitate the
Artifacts (Work Products) (Kruchten, 2000). automated analysis of the process, revealing possible
In order to improve the consistency of the failures and associated risks. The metamodel allows
software processes instantiated from SPEM 2.0 this associating risks to the activities and mitigates them
paper proposes a set of well-formedness rules to before they are propagated into software product.
check for the software processes consistency. The Gnatz et al. (2003) also propose a metamodel to
focus of this paper is only the consistency of the define software process. The authors are mainly
roles, work products, tasks and their relationships. interested in performing process improvement
Each well-formedness rule expresses a condition together with static and dynamic tailoring
that must be true in all software process instances. (adjustment) of process models.
To create the well-formedness rules we have started Though process metamodels are used by many
our work by redefining some relationships in the research groups, the software process consistency
SPEM 2.0. For those more elaborated well- issue is not widely explored. Most works lack rules
formedness rules we have used FOLP. to check the consistency of the created software
The paper is organized as follows: Section 2 processes. Specifically related to the software
presents the related works. Section 3 describes the process consistency some few works might be found
SPEM 2.0. Section 4 presents some packages of in the literature. Bajec et al. (2007), which describe
SPEM 2.0. In Section 5, the consistency well- an approach to process configuration, present some
formedness rules are shown. Section 6 evaluates constraint rules in their work to constrain some
some well-formedness followed by the conclusions. aspects of the software process construction. The
authors decompose their rules in four subgroups: no resources, actions only consuming resources,
process flow rules, structure rules, completeness actions only producing resources and actions
rules and consistency rules. The completeness rules modifying a resource that they were not consuming.
and consistency rules are related to this work since There are also rules to trace dependencies through a
these rules are derived from a process metamodel. process. These rules are: checking if resources
According to (Bajec et al., 2007), the completeness required by an action are produced in an earlier
rules help to check whether a software process action and checking if produced resources are
includes all required components. To the authors consumed by at least one action.
these rules can be specified in a simple manner using Besides the studies above, we consider our work
attributes in the metalink class, which is equivalent similar to the works about UML model consistency.
to multiplicities in the association relation in UML. Although, usually, these works are interested in
An example of the completeness rule in (Bajec et al., consistency issues between the various diagrams of
2007) is that each activity must be linked with an UML specification they also consider the UML
exactly one role. The consistency rules are language and the consistency aspect. Additionally,
considered by the authors similar to completeness in their majority, they describe formal approach
rules. Their goal is to assure that the selection of the (Lucas et al., 2009), what we have also been done.
elements to a process is consistent. While
completeness rules only apply to elements that are
linked together, consistency rules deal with 3 SPEM 2.0
interdependency between any two elements. An
example of the consistency rule is each artifact
The SPEM 2.0 metamodel is structured into seven
depends on at least one production activity.
packages. The structure divides the model into
Hsueh et al. (2008) propose an UML-based logical units. Each unit extends the units it depends
approach to define, verify and validate software upon, providing additional structures and
processes. The authors consider UML as the
capabilities to the elements defined below. The first
modeling language to define the processes and work
package is Core that introduces classes and
with class diagram to model the process static
abstractions that build the foundation for all others
structure, the state diagram to model the process
metamodel packages. The second package, the
element‟s behavior and the activity diagram to Process Structure, defines the base for all process
model the process sequence. For the process models. Its core data structure is a breakdown or
structure they describe a process metamodel based
decomposition of nested Activities that maintain
on UML 2.0 and present some rules in Object
lists of references to perform Role classes as well as
Constraint Language - OCL. Conceptually, that
input and output Work Product classes for each
work is related to this one as it considers a process
Activity. The Managed Content package introduces
metamodel and some formalized rules to help model concepts for managing the textual content of a
verification. However, there are some important
software process. The Process Behaviour package
differences. In (Hsueh et al., 2008), the correctness,
allows extending the structures defined in the
completeness and consistency of a process are
Process Structure package with behavioural models.
verified by only checking the class multiplicities. All
However, SPEM 2.0 does not define its own
their OCL rules are CMMI-related rules and are behaviour modelling approach. The Method Content
used to verify if the software process meet the package provides the concepts to build up a
requirements of CMMI.
development knowledge base that is independent of
Atkinson et al. (2007) propose using an existing
any specific processes. The Process with Methods
Process Modeling Language - PML to define
package specifies the needed concepts to integrate
process. Although the authors do not consider a
the Process Structure package and Method Content
metamodel they present a set of rules related to the package. Finally, the Method Plugin package allows
process consistency. They also present a tool, managing libraries and processes.
pmlcheck, used to check a process before performing
SPEM 2.0 is expressed using MetaObject
it. Basically, the consistency rules implemented in
Facility - MOF 2.0 meta-modeling language. Figure
pmlcheck are related to the actions (the tasks of
1 shows the use of MOF 2.0 and UML 2.0 for
SPEM 2.0) and resources (the work products of
modelling and defining SPEM 2.0. The Figure
SPEM 2.0). Rules to check errors related to action shows different instantiation layers of the formalism
requirements are implemented. These types of rules
used for the SPEM 2.0 specification. MOF is the
check four errors: actions consuming and producing
universal language that can be used on any layer, but
in our case MOF is instantiated from the M3 layer In SPEM 2.0 the main structural elements for
by SPEM 2.0 on the M2 layer. The UML 2 meta- defining software processes are in the Process
model itself, as depicted on the right-hand side of Structure package. In this package, processes are
the M2 layer, instantiates MOF defined on M3 layer represented with a breakdown structure mechanism
in the same way. Finally, process models can be that defines a breakdown of Activities, which are
instantiated using the M1 layer. In Figure 1, comprised of other Activities or leaf Breakdown
“Method Library” is shown as an example of a Elements such as WorkProductUses or RoleUses.
concrete instance of SPEM 2.0. In that sense, SPEM Figure 2 presents the Process Structure metamodel.
2.0 defines process elements such as Tasks and The ProcessPerformer, ProcessParameter.
WorkProducts as well as relationships among them ProcessResponsabilityAssignment and
whereas Method Library provides the concrete WorkProductUseRelationship classes are used to
instance to these elements. express relationships among the elements in a
software process. The WorkSequence class also
represents a relationship class. It is used to
represents a relationship between two
WorkBreakdownElements in which one
WorkBreakdownElement depends on the start or
finish of another WorkBreakdownElement in order
to begin or end. Another important process element
which is not defined in the Process Structure
package is the Task. This element is defined in the
Process with Methods package which merges the
Process Structure package. A task describes an
assignable unit of work. In the Process with Methods
package the class that represents the task element is
the TaskUse class which is a subclass of the
WorkBreakdownElement class of the Process
Figure 1 - Specification Levels Structure package. Figure 3 shows the relationships
The consistency well-formedness rules proposed for the TaskUse class which are defined in the
were defined in the M2 layer. They are based on the Process with Methods package.
elements and relationships of the Process Structure Basically, the TaskUse class has relationships
and Process with Methods packages. In Figure 1 we with the same elements as the Activity class. Figure
have also represented how our proposal is located in 3 also shows that both the TaskUse class as well the
the instantiation layers. In the left-hand side of the RoleUse and WorkProductUse classes have,
M2 layer, the sSPEM 2.0, which stands for respectively, relationships with TaskDefinition,
conSistent SPEM 2.0, has all content of SPEM 2.0 RoleDefinition and WorkProductDefinition classes.
more our consistency well-formedness rules. The These classes are defined in the Method Content
sSPEM 2.0 is also an instance of MOF and it may be package and are used in the Process with Method
instantiated using the M1 layer. In Figure 1 the Package by the merge mechanism.
“Consistent Method Library” is shown as an All software process may use the concepts
instance of the sSPEM 2.0. It means that the defined in the Method Content by creating a
“Consistent Method Library” has concrete instances subclass of Method Content Use class and reference
of the elements and relationships of the SPEM 2.0 it with a subclass of Method Content Element class.
which were checked using the consistency well- The Method Content Element and Method Content
formedness rules of the sSPEM 2.0. Use classes are defined, respectively, in the Method
Content package and Process with Methods package.
All software process may use the concepts defined
4 PROCESS DEFINITION in the Method Content by creating a subclass of
Method Content Use class and reference it with a
This section explores the main SPEM 2.0 packages subclass of Method Content Element class. RoleUse,
and introduces our proposal for process checking. WorkProductUse and TaskUse are subclasses to the
Method Content Use class and RoleDefinition,
4.1 Process Structure in the SPEM 2.0 WorkProductDefinition and TaskDefinition are
subclasses to the Method Content Element class.
 Figure 2 - Process Structure Metamodel

It is important to consider that both models role allocations. As a result, using a process
presented in Figure 2 and Figure 3 had some metamodel can be cumbersome as the user must deal
multiplicities modified from the SPEM original with several concepts to represent a process.
metamodel. This is so because these models already According to (Atkinson et al., 2007), the errors in a
represent models of sSPEM 2.0 and include some software process are most often introduced by a
well-formedness rules proposed in this paper (which modeller and related to syntax or typographical
will be explained in Section 5). mistakes that affect the process consistency. A
modeller might, for example, make a simple error by
connecting a work product that still was not
produced in the software process as an input in a
task. It would break a dependency because the task
was expecting an unavailable work product.
To avoid errors in a process we propose checking
it before enactment. Process checking is the activity
of verifying the correctness and the consistency of a
process. In this paper, process checking is made
from a set of well-formedness rules specified from
the SPEM 2.0 metamodel. The well-formedness
rules are associated with the metamodel classes and
Figure 3 - Relationships of the TaskUse Class relationships which represent the process elements
and their relations. Every instance of process
4.2 Errors in a Software Process elements and relationships that have one or more
associated well-formedness rules is checked. If
We consider that errors in a process are motivated violated, error messages appear. In the next section,
mainly by the following two reasons: (1) process we explain our well-formedness rules. Some rules
metamodels are typically specified with UML class are expressed using UML multiplicity and others,
diagrams, which are only capable of representing which involve more elements and/or express more
simple multiplicity constraints. As a result they need elaborated rules, are described in FOLP.
an external language such OCL or Natural Language
to represent complex restrictions. As with SPEM
2.0, most constraints are represented in Natural 5 PROCESS CHECKING
Language, which can lead to interpretation errors;
and (2) software process metamodels are usually In this section we describe a set of well-formedness
composed by several elements as they must rules related to software process correctness and
represent activity workflows, information flows and consistency. We propose using these rules for
process checking. The well-formedness rules from software process. (Rule #4); 2) Tasks must have
this research were defined considering the concepts input and/or outputs in terms of work products and
defined in the Process Structure and Process with must be performed by roles. (Rules #1, #2 and #5);
Methods packages of SPEM 2.0 metamodel. and 3) Roles need perform tasks. (Rule #3).
Although the Method Content package has also Since not all well-formedness rules could be
important concepts for software process it only expressed through UML diagrammatic notation we
defines reusable content which is used through the introduced first-order predicate logic (FOLP). To
classes of the Process with Methods package. write the rules, we first translate the classes,
relationships and attributes of SPEM 2.0 metamodel
5.1 Well-Formedness Rules into predicates and logical axioms. Due to space
constraints, the translation is not detailed here. We
As the SPEM metamodel is represented by UML assume that each class and attribute of the
class diagrams we consider that many constraints metamodel represents a predicate. For example, the
already exist in this metamodel through the ProcessPerformer class and its attributes
multiplicity used between the classes. The following linkedRoleUse and linkedTaskUse are expressed
rule is one that is already defined in the SPEM 2.0 using the following predicates:
metamodel and constraints process multiplicity: a processPerformer(x) where x is a instance of a
Process Performer must be associated to exactly one ProcessPerformer. (P1)
TaskUse. There is a “linkedTaskUse” relationship linkedRoleUse(x, y) where x is a instance of a
between TaskUse and Process Performer classes. ProcessPerformer and y is a instance of RoleUse. (P2)
The multiplicity is constrained to have only one linkedTaskUse(x, y) where x is a instance of a
relationship. ProcessPerformer and y is a instance of TaskUse. (P3)
Considering all multiplicities defined between The composition relationship which is a special
the classes of the Process Structure and Process with type of UML association used to model a "whole to
Methods packages we have noted that its parts" relationship is represented in FOLP with
inconsistencies may be introduced into a software the predicate part-of(x,y). In this predicate, x is an
process. For example, it is possible create tasks that instance of part and y represents its whole.
are not performed by anybody because a TaskUse Considering the properties defined in UML for this
can be associated to 0..* ProcessPerformers. This type of association the following logic axioms are
type of error could be introduced by an oversight defined:
that may hinder enactment since every task must be
performed by at least one agent (human or ∀x  part-of(x,x) (A1)
automated agent). ∀x,y (part-of(x,y)   part-of(y,x)) (A2)
To solve the problem above and others similar to ∀x,y,z (part-of(x,y) part-of(y,z)  part-of(x,z)) (A3)
it, we have started our work by redefining some ∀x,y,z (part-of(x,y)   part-of(x,z)) (A4)
relationships in the SPEM 2.0 metamodel. The
Some additional predicates that express usual
modified relationships define the rules shown in
relations in a software process were also created.
Table 1. In this Table, each rule contains a
Such predicates are needed as they are reused for
numeration to ease its identification.
many different well-formedness rules. For example,
Table 1 - Relationships modified in SPEM 2.0 the following predicates represent, respectively, a
A TaskUse must be associated to at least one work product that is produced by a task and the
ProcessPerformer. (Rule #1) dependency relationship between two work
A ProcessParameter must be associated to exactly one products. Dependency relationships are used to
WorkProductUse. (Rule #2) express that one work product depends on another
A RoleUse must be associated to at least one work product to be produced in a software process.
ProcessPerformer. (Rule #3) ∀x,y,z((taskUse(x)workProductUse(z)processParameter(y)
A WorkProductUse must be associated to at least one direction(y,‘out’)parameterType(y,z)part-of(y,x))
ProcessResponsabilityAssignment. (Rule #4) taskProduce(x, z)) (P4)
A TaskUse must have at least one ProcessParameter.
(Rule #5 ) ∀z,x,y((workProductUse(x)workProductUse(y)
The classes and relationships that represent the (workProductUseRelationship(z) kind(z,‘dependency’)
source(z, x) target(z, y))) dependency(x, y)) (P5)
rules above are depicted in Figure 2 and Figure 3.
Basically, the rules presented define: 1) Work Similar predicates also exist for the modification
products need to have roles assigned to it in a and consumption relations of the work products by
the tasks in a software process. Such relations are association represented by the part-of predicate.
obtained just replacing the value of the constant These relationships are expressed using UML
‘out’ of the direction predicate by ‘in’ or ‘inout’. classes and attributes and consequently, need to be
When the ‘in’ value is used we have the predicate represented by other predicates and constrained by
taskConsume(x, z) (P6) and when the ‘inout’ value is new rules.
used we have the predicate taskModify(x, z) (P7).
Table 2 – First Well-Formedness Rules to WorkProducts
Activities have the same relations of input and
output (production, consumption and modification) ∀x,y (composition(x,y)  composition(y,x)) (Rule # 6)
with work products, so we have considered similar ∀x,y (aggretation(x,y)   aggretation(y,x)) (Rule # 7)
predicates to these elements (P8, P9 and P10). ∀x,y (dependency(x,y)   dependency(y,x)) (Rule # 8)
Work products also may assume other types of ∀x  composition(x,x) (Rule # 9)
relationships, in addition to the dependency ∀x  aggretation(x,x) (Rule # 10)
relationship. In the SPEM 2.0 metamodel these types ∀x  dependency(x,x) (Rule # 11)
of relationships are „composition’ and „aggregation’. ∀x,y,z (composition(x,y)   composition(x,z))
Both relationships express that a work product (Rule # 12)
instance is part of another work product instance. A second important group of consistency well-
However, in the composition relationship the parts formedness rules to the WorkProductUse written in
lifecycle (child work products) are dependent on the FOLP are shown in Table 3.
parent lifecycle (parent work product). The Table 3 - Second Group of Well-Formedness Rules to
composition and aggregation predicates just replace WorkProducts
the value of the constant „dependency’ of the kind
predicate by „composition’ or „aggregation’ (P11, ∀x (workProductUse(x)  y (processParameter(y)
P12 and P13). direction(y, ‘out’) parameterType(y, x))) (Rule #13)
The composition, aggregation and dependency ∀x,y(taskProduce(x,y)r,w,z(roleUse(r)processPerf
relationships between work products are transitive omer(z)linkedTaskUse(z,x)linkedRoleUse(z,r))pro
relations. The logical axioms bellow formalizing this cessResponsabilityAssignment(w)linkedRoleUse(w,r)
property: linkedWorkProductUse(w,y)))) (Rule #14 )
∀ x,y,t (workProductUse(x)  dependency(x,y) 
∀x,y,z(composition(x,y)composition(y,z) taskProduce(t,x)  taskConsume(t,y)) (Rule #15)
 composition(x,z)) (A5)
∀x,y,z(aggretation(x,y)aggretation(y,z) The well-formedness rules above establish: 1)
 aggretation(x,z)) (A6) Work products must be produced by at least one task
∀x,y,z(dependency(x,y)dependency(y,z) in a software process. (Rule #13); 2) At least one
 dependency(x,z)) (A7) responsible role by the work product must be
associated in its production tasks. (Rule #14); and 3)
Considering the predicate and logical axioms If a work product has dependencies in terms of other
above the first consistency well-formedness rules to work products these dependencies must be input in
WorkProductUse were expressed in FOLP. They are its production tasks. (Rule #15)
presented in the Table 2 and define: 1) A work The last group of well-formedness rules are
product may not be the whole in a relationship related to TaskUses sequencing. To establish the
(composition, aggregation or dependency) if one of tasks sequence from SPEM 2.0 metamodel the
its parts represent its whole in another relationship WorkSequence class and its linkKind attribute are
or represent its whole by the relation transitivity. used. It is possible using the following values in
(Rule #6, #7 and #8); 2) A work product may not sequencing between TaskUses: finishToStart,
represent the whole and the part in the same finishToFinish, startToStart and startToFinish.
relationship (composition, aggregation or Some predicates and logical axioms related to
dependency). (Rules #9, #10 and #11); and 3) A precedence between the tasks were created. Initially,
work product that represents the part in a to capture the concept of successor and predecessor
composition relationship may not represent part in task we have defined the predicates pre-task(t1, t2)
another relationship of this type. (Rule #12) and pos-task(t2, t1), where t1 and t2 are TaskUse
Note that the well-formedness rules above define instances and indicate, respectively, t1 as predecessor
the same properties that logical axioms of the part-of task of t2, or, inversely, t2 as successor task of t1. The
predicate. However, the well-formedness rules are predicates pre and pos-task are transitive and
necessary once the relationships between the work asymmetric relations. The following logical axioms
products are not expressed using the UML establish these properties to these relations:
 products (inputs and outputs). All information
∀(t1, t2) (pre-task(t1, t2) pos-task(t2, t1)) (A8)
shown in the Figure 4 is based on the OpenUP
∀(t1, t2, t3) (pre-task(t1, t2) pre-task(t2, t3)  pre- process except the Rule Test which was introduced
task(t1, t3)) (A9) by us only for this evaluation. Originally, in
∀(t1, t2) (pre-task(t1, t2)  pre-task(t2, t1)) (A10) OpenUP, the Analyst is also responsible for the
∀ t1  pre-task(t1, t1) (A11) Vision work product.
Based on the predicates and logical axioms
related to precedence between tasks we have defined
new consistency well-formedness rules. These rules,
shown in Table 4, define: 1) The tasks sequencing
must not have duplicated sequences. (Rule #16) 2)
Work Products must be produced before they are
consumed. (Rule #17) and 3) The dependencies of a
work product must be produced before it in a
software process. (Rule #18)
The well-formedness rule #16 shown in the
Table 4 is only to startToFinish transition. Consider
the same rule to the following transitions:
startToStart, finishToFinish and startToFinish.
Table 4 - Well-Formedness Rules to Process Sequence
Figure 4 - Inception Iteration of the OpenUp
∀x,x1,x2((taskUse(x1)taskUse(x2) (workSequence(x)
predecessor(x, x1) sucessor(x, x2) linkKind(x, One of the tasks of Figure 4 (Develop Vision) is
‘startToFinish’)))y(workSequence(y)predecessor also represented with a UML object diagram, which
(x,x1) sucessor(x,x2) linkKind(x, ‘startToFinish’))) is shown in Figure 5. The object diagram show the
(Rule #16) class instances of the SPEM 2.0 used to create tasks,
∀x, y (taskConsume(x, y)  x2 (taskProduce(x2, y) work products, roles and their relationships in a
pre-task(x2, x))) (Rule #17) software process. In Figure 5 letters are used to
∀ x,y (dependency(x,y)  t1, t2 (taskProduce(t1, x) facilitate its understanding. The letter A indicates the
taskProduce(t2, y) pre-task(t2,t1))) (Rule #18) WorkProductUse classes used to create the objects
Vision and Glossary. The letter B represents the
objects 01 and 02, which are instances of the
ProcessParameter class. These kinds of objects
6 EVALUATION OF THE WELL- represent the inputs and outputs to the task objects.
FORMEDNESS RULES In Figure 5, the object that represents a task is
represented by the DV (Develop Vision) identifier.
This section presents a process checking example This object is an instance of TaskUse class and is
using a part of the OpenUP process. The section also indicated in the Figure 5 by the letter C. The objects
evaluates one of the well-formedness rules proposed representing instances of the RoleUse class are
in this paper. The main goal is demonstrate that the indicated in Figure 5 by the letter D. Finally, the
predicates and logical axioms used in the well- letters E and F represent, respectively, objects of the
formedness rules really express the intended ProcessResponsabilityAssignment (object 01 and 02)
meaning. and ProcessPerformer classes (object 02). The
instances of the ProcessResponsabilityAssignment
6.1 Process Checking Example are used to define roles as responsible for work
products and the instances of the ProcessPerformer
To present a process checking example we have are used to link roles as performer to the tasks.
considered the Inception Iteration of the OpenUP As seen, all process information of this example
process, which is shown in Figure 4. In this Figure, may be represented using classes and relationships
above the dash line, the activities and tasks of the of the SPEM 2.0. It means that the used process is
iteration are represented. Additionally, some compliance with the SPEM 2.0 metamodel. Another
information about activities sequence is also shown. fact that shows the consistency of the used process is
Below the dash line, the tasks of the Initiate Project the validation result of the object diagram found in
activity are detailed in terms of roles and work
the case tools like Rational Software Modeler. This t::= „02‟ t is the Process Parameter „02‟ with
validation result is error free. direction equal to „out‟ and
However, as mentioned in Section 4, not all need parameterType equal to „Vision‟
information in a software process can be expressed z::= „02‟ z is the ProcessPerformer „02‟ with
using only the UML language. Thus, when we carry linkedRoleUse equal to „Analyst‟ and
linkedTaskUse equal to „Develop
out the checking in the same process using our well- Vision‟
formedness rules it presented errors indicating some w::= „01‟ w is the
inconsistencies. The first inconsistency of the ProcessResponsabilityAssignment „01‟
software process used in this example is in the task with linkedRoleUse equal to „Rule
Develop Vision. As seen in Figure 4, the task Test‟ and linkedWorkProductUse equal
Develop Vision produces the work product Vision to „Vision‟
which has as responsible role the role Rule Test.
We have evaluated the task Develop Vision
This role does not perform the task Develop Vision
which presents an error in the software process. The
and this fact violates the Rule #14 which defines that
formalization of the Rule #14 is the following:
at least on responsible role of a work product must
participate of their production tasks. Another ∀x,y(taskProduce(x, y)  r, w, z (roleUse(r)
problem can be seen in the task Plan Project. Note processPerfomer(z)linkedTaskUse(z,x)linkedRoleU
that this task has as mandatory inputs the work se(z,r))processResponsabilityAssignment(w)linkedR
products Use Case, Use Case Model and System- oleUse(w,r)linkedWorkProductUse(w,y))))
Wide Requirements which are not yet produced in This rule uses the taskProduce(x, y) that is
the software process when this task is performed. represented by the following sentence in FOLP:
This inconsistency violates the Rule #17.
∀x,y,t((taskUse(x)workProductUse(y)processParam
eter(t) direction(t, ‘out’) parameterType(t, y)) part-
of(t, x))  taskProduce(x, y))

Initially we have evaluated the taskProduce(x,y).

Considering the variables of Table 5 we have:
taskUse(DV)::= T
workProductUse(Vision)::= T
ProcessParameter(02)::= T
direction(02, „out‟)::= T
parameterType(02, Vision)::= T
part-of(02, DV)::= T
taskProduce(Criar DV, Vision)::= T
Figure 5 - Object Diagram to the Develop Vision Task
Then:
∀ x,y,t ((T T  T  T  T)  T)  T)
6.2 Evaluation of the Well-Formedness ∀ x,y,t (T  T)::= T
Rules
Predicate taskProduce(DV, Vision) evaluates to
We have evaluated our well-formedness rules True. Once the task Develop Vision produces the
expressed in FOLP to check their correctness. Since work product Vision the expected value was True.
the amount of rules presented in this paper is vast Considering Rule #14 we have:
and due the space constraints, we present only the roleUse(Analyst)::= T
evaluation of rule Rule #14. processPerformer(02)::=T
To start the evaluation we have created some linkedRoleUse(02, Analyst)::= T
variables and assigned values for them. Each linkedTaskUse(02, DV)::= T
variable represents an object of the object diagrams processResponsabilityAssignment(01)::=T
shown in Figure 5. Table 5 lists the variables and linkedWorkProductUse(01, Vision)::= T
values used to this evaluation. linkedRoleUse(01, Analyst)::= F

Table 5 - Variables used in the First Evaluation Then:

∀x, y ( T  r, w, z (T T T T) T F T)))
x::= „DV‟ x is the TaskUse „Develop Vision‟
∀x, y ( T  r, w, z (F))
y::= „Vision‟ y is the WorkProductUse „Vision‟
∀x, y ( T  F)::= F
r::= „Analyst‟ r is the RoleUse „Analyst‟
 The value to the Rule #14 is False. This value Atkinson, D. C., Weeks, D. C. and Noll, J. Tool Support
was expected once the values assigned to the for Iterative Software Process Modeling. Information
variables generate one inconsistency in the software and Software Technology, 493-514, 2007.
process as already shown in the Subsection 6.1. It Bajec, M., Vavpotic, D. and Krisper, M. Practice-Driven
Approach for Creating Project-Specific Software
suggests that the theory of the Rule #14 is valid. Development Methods. Information and Software
Although we have not detailed the evaluation of Technology, 345-365, 2007.
the Rule #17, the value returned to this evaluation is Bendraou, R., Combemale, B., Cregut, X. and Gervais, M.
False. It also indicates that the theory of this rule is P.Definition of an Executable SPEM 2.0.In: 14th Asia-
valid. Pacific Software Engineering Conference, 2007.
Gnatz, M., Marschall, F., Popp G., Rausch A. and
Schwerin W. The Living Software Development Process.
Available from: http://citeseerx.ist.psu.edu/viewdoc/sum
7 CONCLUSIONS mary?doi=10.1.1.60.3371, 2003.
Habli, I. and Kelly, T. A Model-Driven Approach to
In this paper, we have proposed well-formedness Assuring Process Reliability. In: 19th International
rules that allow finding errors in a software process Symposium on Software Reliability Engineering, 2008.
before it is enacted. By noting inconsistencies in the Henderson-Sellers, B. and Gonzalez-Perez, C. A Work
process, we believe it is possible for modellers to Product Pool Approach to Methodology Specification
and Enactment. Journal of Systems and Software, 2007.
refine a process model until it is free of
Henderson-Sellers, B., Gonzalez-Perez, C. and Ralyté, J.
inconsistencies. Comparison of Method Chunks and Method Fragments
The proposed well-formedness rules were based for Situational Method Engineering.In: 19th Australian
on SPEM 2.0 metamodel. To define them we have Conference on Software Engineering, 2008.
modified multiplicity constraints and for the more Hsueh, N. L., Shen, W. H., Yang, Z. W and Yang, D. L.
elaborated rules which could not be expressed only Applying UML and Software Simulation for Process
with UML, we have used FOLP. Definition, Verification and Validation. Information and
Several research directions, which we are Software Technology, 897-911, 2008.
working on, have been left open during this paper, Hug, C., Front, A., Rieu, D. and Henderson-Sellers, B. A
and here we emphasize two of them. First, more Method to Build Information Systems Engineering
well-formedness rules considering others process Process Metamodels. The Journal of Systems and
Software, 1730-1742, 2009.
elements and consistency aspects need to be
Jacobson, I., Booch G., Rumbaugh J. The Unified
provided. Related to this, preliminary studies
Software Development Process, Addison Wesley, 2001.
suggest two important facts: (1) other process Kruchten, P. The Rational Unified Process: An
elements and relationships must be included in the Introduction. NJ: Addison Wesley, 2000.
SPEM 2.0 metamodel and (2) the OCL language Lucas, F. J., Molina, F. and Toval, A. A Systematic Review
does not support the definition of all well- of UML Model Consistency Management. Information
formedness rules needed to guarantee consistency. and Software Technology, 1631-1645, 2009.
For example, the well-formedness rules to check OMG, Sofware Process Engineering Metamodel - SPEM
cycles in a software process, which involve 1.1. Available from: http://www.omg.org/, 2002.
temporary aspects, may not be expressed using OMG, Sofware Process Engineering Metamodel - SPEM
OCL. This fact has been the motivation to use FOLP 2.0. Available from: http://www.omg.org/, 2007.
in this paper. Secondly, with regard to automatic Open. Available from: http://www.open.org.au, 2006.
support, the prototype of a tool prototype is being Puviani, M., Serugendo, G. D. M., Frei, R. and Cabri G.
developed. This will support the definition and Methodologies for Self-organising Systems: a SPEM
tailoring of SPEM-based software processes. Approach. In: International Conference on Web
Furthermore, a process checking, which implements Intelligence and Intelligent Agent Technology, 2009.
Ralyté, J., Backlund, P., Kuhn, H. and Jeusfeld M. A.
the well-formedness rules, will be provided.
Method Chunks for Interoperability. In: 25th Int.
Conference on Conceptual Modelling, 2006.
Serour, M. K. and Henderson-Sellers, B. Introducing
ACKNOWLEDGEMENTS Agility – A Case Study of SME Using the OPEN. In: 28th
Computer Sof. and Applications Conf., 2004.
Wistrand, K. and Karlsson, F. Method Components
Study financed by Dell Computers of Brazil Ltd.
Rationale Revealed. In: Lecture Notes in Computer
with resources of Law 8.248/91. Science, Vol. 3084/2004, 2004.
Xu, P., Ramesh, B. A Tool for the Capture and Use of
Process Knowledge in Process Tailoring, In: Proc. of
REFERENCES Hawaii Int. Conference on System Sciences, 2003.