Conference PaperPDF Available

Who Cares About Software Process Modelling? A First Investigation About the Perceived Value of Process Engineering and Process Consumption


Abstract and Figures

When it comes to designing a software process, we have experienced two major strategies. Process engineers can either opt for the strategy in which they focus on designing a process using an artefact model as backbone or, on the other hand, they can design it around activities and methods. So far, we have first studies that directly analyse benefits and shortcomings of both approaches in direct comparison to each other, without addressing the questions relevant to pro-cess engineers and which implications the selection of a particular design strategy has on the process consumption. We contribute a first controlled investigation on the perceived value of both strategies from the perspectives of process engineers and process consumers. While our results underpin the artefact-oriented design strategy to be an advantageous instrument for process engineers, process con-sumers do not evidently care about the selected design strategy. Furthermore, our first investigation performed in an academic environment provides a suitable em-pirical basis, which we can use to steer further replications and investigations in practical environments.
Content may be subject to copyright.
Who Cares About Software Process Modelling?
A First Investigation About the Perceived Value of
Process Engineering and Process Consumption
Marco Kuhrmann1, Daniel M´
endez Fern´
andez1, and Alexander Knapp2
1Technische Universit¨
at M¨
unchen, Faculty of Informatics, 85748 Garching, Germany
at Augsburg, Institute of Informatics, 86159 Augsburg, Germany
Abstract. When it comes to designing a software process, we have experienced
two major strategies. Process engineers can either opt for the strategy in which
they focus on designing a process using an artefact model as backbone or, on
the other hand, they can design it around activities and methods. So far, we have
first studies that directly analyse benefits and shortcomings of both approaches in
direct comparison to each other, without addressing the questions relevant to pro-
cess engineers and which implications the selection of a particular design strategy
has on the process consumption. We contribute a first controlled investigation on
the perceived value of both strategies from the perspectives of process engineers
and process consumers. While our results underpin the artefact-oriented design
strategy to be an advantageous instrument for process engineers, process con-
sumers do not evidently care about the selected design strategy. Furthermore, our
first investigation performed in an academic environment provides a suitable em-
pirical basis, which we can use to steer further replications and investigations in
practical environments.
Keywords: Software processes, Software process modelling, Action research
1 Introduction
Software process models are the glue that holds organisations, projects, and people
together. They provide a blueprint of all relevant artefacts, activities, roles, and sup-
porting entities necessary to implement a company-specific software process. The way
of operating projects of different complexities, including its distribution, people, differ-
ent cultures and application domains, is reflected in the complexity of today’s software
processes. This increases the demand to structure and implement software processes in
a systematic manner, and to make the resulting process descriptions easily accessible
and understandable to project participants. Consequently, one has to consider two basic
perspectives on software processes: their design and their consumption.
To design a software process, process engineers face the choice between two ma-
jor strategies: the activity-oriented strategy and the artefact-oriented one. The activity-
oriented strategy concentrates on analysing the activities and methods applied in
projects, and defining a software process on basis of the behaviour of project teams [17].
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
The basic idea of artefact orientation, in turn, consists of concentrating on what has to
be done rather than on how something has to be done. A software process is designed
on the basis of an artefact model that defines a blueprint of the results to be created and,
thus, it abstracts from the activities for creating the results by using particular methods
and modelling notations.
For the last decade, we are investigating the shortcomings and the benefits of the
two introduced strategies in direct comparison to each other [11]. Our findings indicate
to the benefits of artefact orientation in order to support flexibility in the process, pre-
cision in the results, a standardised terminology among different project participants,
or a systematic quality assurance. However, the industrial context of those case stud-
ies was always characterised by a given process defined and probably lived for years.
People had certain expectations and needs regarding the instantiation of a process to
efficiently organise and run a project, and to give guidance on how to create precise
result structures during operations.
The still unsolved question remains whether the initial choice of a certain strat-
egy matters for the process design and the process consumption if no expectations are
present and which implications the choice has.
Problem statement. Although we have deep knowledge on specific benefits and short-
comings of different software process models and the underlying paradigms when ap-
plying them at selected socio-economic contexts, we have still no knowledge which
implications the choice of a particular strategy has for process engineers and process
consumers independently of given expectations and experiences in same or similar con-
texts. The decision for one strategy or the other is, however, of critical importance as
the maintenance and a re-design of a process model as part of a software process im-
provement initiative is a cost- and time-intensive endeavour.
Research objective. We aim at investigating which implications the choice for a partic-
ular software process design strategy has for process engineers and process consumers.
Our expectation is that the selection of a strategy does not affect the consumers’ per-
ceived value. To lay the foundation for a systematic investigation of this expectation,
we describe a first controlled experiment to be further replicated in different contexts.
In this experiment proposal, we compare the design strategies from the perspective of a
process engineer and furthermore we investigate the users understanding of the partic-
ular outcomes. In summary, we define the research objective as follows:
We analyse the selection of software process design strategies
for the purpose of evaluation
with respect to the perceived values
from the point of view of the process engineers and the process consumers
in the context of the process life cycle
Contribution. We contribute a controlled student experiment in which we analyse the
perceived value of a given software process w.r.t. the strategy followed when designing
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
and implementing it, as well as when consuming its deployed descriptions from the
perspective of process consumers. The context of the study is the lecture “Software
Engineering Processes”, given at the Technische Universit¨
at M¨
Our experiment compares one process and two representative software process
frameworks (incl. software process meta models, authoring tools, and deployment in-
frastructures). We use both frameworks to analyse, conceptualise, and implement the
given process in a tool-supported manner. We finally evaluate the deployed process doc-
umentations according to a fixed set of criteria by simulating an appraisal. We opt for
the Eclipse Process Framework [4] as a representative of the activity-oriented paradigm
and for the V-Modell XT framework [6] as a representative of the artefact-oriented
paradigm. Inherited from the nature of a controlled experiment, we have to avoid any
side effects to distort the aforementioned procedure, such as organisational cultures,
the integration of the constructed process into an organisational structure and further
aspects of process maintenance.
Outline. The paper is organised as follows. Section 2 introduces the fundamentals nec-
essary for the study environment. We furthermore discuss related work, which gaps are
left open, and how our contribution intends to close the gaps. In Sect. 3, we introduce
the study design, and we present the results in Sect. 4. In Sect. 5, finally, we give a
summary of conclusions, discuss the relation to existing evidence, the impact and limi-
tations of the study, and planned future work.
2 Fundamentals and Related Work
In the following, we briefly discuss the fundamentals in terms of engineering software
processes, and related work in the context of our investigation.
Software Process Design Strategies. For the context of this paper, we distinguish be-
tween two design strategies: activity orientation and artefact orientation. The activity-
oriented strategy relies on the idea of defining a concrete process by a set of methods
to be performed in a particular order by a specific set of roles. Each of the methods
provides a construction procedure to combine description techniques [13]. The activity-
oriented strategy is especially favoured in the area of (Situational) Method Engineering.
For instance, Ralyt´
e and Rolland [15] discuss an assembly-based approach in which
pre-fabricated method chunks are combined. Method chunks shall comprise activities
as well as artefacts. Since method engineering is still in the phase of discussing and con-
solidating the basic concepts, first proposals are made to introduce systematic modelling
approaches, e.g. Brinkkemper and Saeki [2]. However, method engineering in general
pays little attention to artefacts, which is reflected by the summary of method engi-
neering concepts by Henderson-Sellers and Ralyt´
e [7]. Beyond method engineering,
current software process metamodels lay the foundation to develop arbitrary software
processes. Prominent examples are software processes, which are based on the Software
& Systems Process Engineering Metamodel (SPEM; [14]), such as the Rational Uni-
fied Process (RUP; [8]) or Hermes [3]. Still, although the importance of a well-defined
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
artefact model is recognised in this area [5], artefacts are not in scope in available ap-
proaches. Braun et al. [1] mention that only 50% of the analysed approaches include
an artefact description at all, while approaches that include an artefact description often
reduce the artefacts to an optional outcome of the methods.
The activity-oriented strategy thereby does not provide assistance in the creation
of precise result structures. In response to this situation, a new design strategy arose
baptised as artefact orientation. The idea of the artefact-oriented strategy consists of
defining a blueprint of all artefacts that are an (intermediate) result of a project. At
project level, the actual process is then defined by agreeing on a set of artefacts to be
created by particular roles and to be delivered when reaching particular milestones. The
diversity in the process definitions is thereby reduced to the dependencies among the
artefacts themselves without having to take into account the complexity of differing
processes and detailed workflows. Artefact-oriented approaches are thereby meant to
guide in the creation of precise results while offering the necessary flexibility during
their creation by avoiding to dictate concrete methods. A detailed discussion on both
strategies can be taken from [12].
Comparative evaluations and studies. There exist, to the best of our knowledge, barely
studies that empirically evaluate both previously introduced strategies to design and
implement a software process in direct comparison. We conducted such a study on the
application of an artefact-based requirements engineering approach in direct compari-
son to an activity-based approach previously used in an industrial environment [11]. We
could show, for example, an increase in the flexibility of the process and the syntactic
quality of the created artefacts when relying on artefact orientation. However, as stated
in Sect. 1, our focus lied on an industrial context with practitioners’ expectations and
experiences shaped for years in that context. So far, we could gain data that shows ad-
vantages of the artefact-oriented design strategy when narrowing down the context to a
particular discipline, but at the cost of analysing the overall software process life cycle.
To investigate the perceived value of a particular strategy taking into account the
overall life cycle of a process while controlling potential side-effects given by afore-
mentioned expectations and experiences, a controlled experiment is yet necessary. The
paper at hand reduces this gap by contributing the design for such a controlled experi-
ment as well as first results.
3 Research Design
We organise the experiment’s design according to [16]. After defining the goal and the
research questions, we describe the case and subject selection. Finally, we describe how
we collect and analyse the data, before discussing the validity procedures.
3.1 Research Questions
As stated in Sect. 1, we investigate which implications the choice of a particular soft-
ware process design strategy has for process engineers and for consumers. To this end,
we formulate a working hypothesis in accordance with our expectation that the selection
of a particular design strategy has no impact on the consumers’ perceived value:
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
WH: The selection of a design strategy for establishing an effective process manage-
ment does not affect its actual consumption.
Since we initiate experimentation on this hypothesis, we opt for a case-study-like
action research approach to capture the domain of interest and to get initial data. To this
end, we formulate two research questions that shall investigate the perceived value of
the artefact-oriented and the activity-oriented strategy taking first the perspective of a
process engineer into account and then taking the perspective of a process consumer.
RQ 1: How suitable is the used design strategy to cover the needs of process engineers
when analysing, designing, and implementing a process?
The first research question considers the analysis of the strengths of one strategy to
another when constructing a process. This construction covers the analysis of a process,
its conceptual design, and its tool-supported implementation.
RQ 2: To what extent does the used strategy matter for process consumers when inter-
preting the resulting process documentation?
Once we constructed a process (and rated the strategies for their support during the
construction), we want to know which strategy better supports the application of the
generated process documentation from a consumer’s perspective.
3.2 Case and Subject Selection
The choice of the software process frameworks is opportunistic. We need, however, to
ensure that the following prerequisites are fulfilled:
1. The software process framework has to be based on a metamodel representing ei-
ther the activity-based strategy or the artefact-based one.
2. The software process framework has to offer a tool infrastructure that allows for
the implementation and export of a process.
As example process to be implemented with the framework, we opt for a process that
reflects the complexity of a “real life” process and that offers enough information for
the process engineers to realise the process.
Regarding the subjects involved in the study, we define two groups. The process
engineer is responsible for realising the process and to rate the realisation. The process
consumer is exclusively responsible for evaluating the created process documentation
without any insights into the construction of the process.
3.3 Data Collection Procedure
Figure 1 depicts an overview of the data collection procedure. We set up the study as
part of our lecture “Software Engineering Processes” [9] in the winter term 2011/2012.
Two groups of students of roughly the same size were assigned to the particular strat-
egy (artefact or activity orientation). Each student group then conducted three work-
shops with fixed time frames for analysing, for conceptualising, and for implementing
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
the process in a tool-supported manner. The last session of the lecture considered the
evaluation of the results where the students changed their role to the one of a process
consumer for evaluating also the process documentation created by the other team. In
the following, we explain each step of the data collection in detail.
Analysis Conceptualisation Evaluation
Construction /
Workshop 1
Workshop 2
Workshop 3
Analysis Concepts
(Roles, etc.)
Software Processes
Fig. 1: Overview of data collection procedure.
Analysis workshop. The analysis comprehends two sessions in which a given sce-
nario is analysed. The scenario is a real-life process model of a special interest group
of the German Computer Society3. In the first session, two student groups analyse the
particular sources for stakeholders to infer the basic roles. The roles are collected, struc-
tured, and prepared for discussion. In the second session, the students analyse either the
process elements or the artefacts, depending on the group assignments.
Conceptualisation workshop. In the second workshop, the two student groups discuss
the analysis results; one group gets the material for the artefacts as input, the other
group gets the overall process, including milestone structures and an assignment to a
set of activities, as input. The students then switch to the conceptualisation and create
first platform-independent artefact and process models.
The outcome of the analysis and conceptualisation workshops are synthesised into
an integrated concept. This step is done by the supervisors to get consistent conditions
during the construction workshop supporting for comparable outcomes during the eval-
uation. To this end, the students are provided with a set of consolidated spread sheets
and a requirements document for the realisation. Furthermore, the supervisors prepare
the technical infrastructure in terms of creating (Subversion) repositories and bare pro-
cess templates for the students to start with.
Construction workshop. In the construction workshop, the students are initially in-
troduced into the consolidated concept. Two implementation groups are formed and in
3Available at: (in German)
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
each group one student takes the lead. The first group uses the Eclipse Process Frame-
work to implement the process and the second group uses the V-Modell XT framework,
respectively. During the construction, the supervisors assist the students with discussion
w.r.t. modelling techniques, in general, and concrete design decisions, in particular. Pre-
sentations of the groups’ outcomes conclude the construction workshop.
Table 1: Questionnaire with closed questions for process engineers (RQ 1).
No. Question (condensed) Aspect
Q1-2 The used tool and the approach were intuitively applicable. Tool
Q1-3 I got familiar with the tool and could implement all process elements. Tool
Q1-5 The tool was suitable to implement the process with minimal overhead. Tool
Q1-6 I was aware of every decision and its consequences. Tool
Q1-7 The process documentation could be created appropriately. Tool
Q1-8 I could implement all process elements. Methodology
Q1-9 I could implement all designed roles. Methodology
Q1-10 I could implement all designed artefacts. Methodology
Q1-11 I could implement all designed relationships among roles and artefacts. Methodology
Q1-12 I could implement all designed activities. Methodology
Q1-13 I could implement the designed overall process. Methodology
Q1-14 I could always create an export of the model (process documentation). Tool
Q1-15 I could perform all required tasks for the implementation. Tool
Q1-16 I was always able to identify and check the model consistency. Tool
Table 2: Questionnaire with closed questions for process consumers (RQ 2). Considered aspect
is the process documentation only.
No. Question (condensed)
Q2-1 The information in the export is easy to access.
Q2-2 The information in the export is easy to access for non-familar users.
Q2-3 The overall process is clearly presented and provides a good overview of all elements.
Q2-4 The export supports the analysis of consistency.
Q2-5 All expectations were met and all designed concepts were appropriately implemented.
Q2-6 All designed roles were implemented.
Q2-7 All designed artefacts were implemented.
Q2-8 All designed relationships between roles and artefacts were implemented.
Q2-9 All designed activities were implemented.
Q2-10 The designed overall process was adequately implemented.
Q2-11 The process model is consistent.
Evaluation session. The final step of the experiment considers the evaluation of the
designed and implemented processes. The evaluation consists of two steps, both using
a given questionnaire:
1. Self-assessment of the produced process documentation taking the perspective of a
process engineer (Table 1)
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
2. Audit of the process documentation of the other group taking the perspective of a
process consumer (Table 2)
In the self-assessment, the students rate their own work with a particular focus on the
used tool and followed methodology. For the assessment and the audit, questionnaires
with closed and open questions are made available (see Table 1 with the condensed,
closed questions for the assessment and Table 2 for the audit). We are especially inter-
ested in the closed questions to rate and compare given strategies. Each of the closed
questions considers the rating of one particular criterion against a given statement in a
scale ranging from 0 (“I strongly disagree”) to 7 (“I strongly agree”).
3.4 Analysis Procedure
Due to the low number of samples (8 students), statistical (hypothesis) testing is not
suitable. After collecting the data, we thus plot radar charts with the rankings given in
the closed questions to qualitatively analyse the results and directly compare the results
of the groups with each other.
4 Study Results
We first give a description of the case and the subjects and summarise, as a second step,
the results w.r.t. the single research questions.
4.1 Case and Subject Description
Case – Process frameworks. Since one part of the study is to implement a selected pro-
cess, we select two software process frameworks and the corresponding authoring tools.
The first chosen framework is the Eclipse Process Framework (EPF; [4]), the second
framework is the German V-Modell XT [6]. Both frameworks are based on a meta-
model supporting process modelling and structuring, as well as providing support for
publishing processes to make the process accessible for the process users, and are of a
maturity [10] that allows for using these frameworks in an experimentation setting. EPF
is based on SPEM [14], an OMG specification, which is basically an UML profile for
process engineering. The V-Modell XT is based on the V-Modell XT Metamodel [18], a
metamodel that was specifically developed to create artefact-oriented processes.
Case – Process model. The selected case is a process model given by the special interest
group “Software Development Processes” of the German Computer Society. The pro-
cess under consideration describes how the annual special interest group workshops are
organised (including roles, activities, and milestones). Since the process was originally
defined in the late 1990’s, it evolved and got into an inconsistent state. Summarised,
the process consists of a 20-page word document, an (incomplete) project plan of about
200 (hierarchal) activities, a set of templates, and a couple of Excel spreadsheets that
contain checklists and further detailed information for certain tasks.
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
Subjects. The subjects are 8 students of the lecture “Software Engineering Processes”
(winter term 2011/2012). As shown in Fig. 1, for each workshop the students are di-
vided into two groups at the beginning of the particular workshops. For the analysis
and conceptualisation workshops, the groups are formed at random. At the beginning
of the construction workshop, the students are allowed to select a process framework
themselves, which, in consequence, also defines the groups for the self-assessments and
the audits.
The goals of the selected grouping procedure are that (1) each student should have
the same basic knowledge about the considered process model, and that (2) each student
should act in different roles—in the role Process Engineer during the analysis, concep-
tualisation, construction and self-assessment, and in the role Process Consumer during
the audit.
4.2 Workshops
Three workshops are performed to analyse, conceptualise, and construct the process
models (see Fig. 1). In this section, we show the results of each particular workshop.
Analysis workshop. In the analysis sessions, the students analyse the given material to
gather information about roles, artefacts, activities, and the basic process structure (i.e.
artefact-role assignments). For those sessions, the students use creativity techniques for
the elaboration (see Fig. 2) and are provided with pre-defined templates by the supervi-
sors to structure the information. The outcomes of the analysis workshop are:
An unordered set of 37 roles and stakeholders
An unordered set of 32 artefacts
A list of more than 50 activities (partially inferred from the artefacts)
Fig. 2: Photo of the analysis workshop (elabo-
ration of artefacts).
Fig. 3: Photos of the conceptualisation work-
shop (artefact and process structures).
Conceptualisation workshop. The last analysis workshop session fades into the con-
ceptualisation workshop in which the students need to aggregate all information. One
group concentrates on artefacts and roles, structures and dependencies (Fig. 3, upper
part), and the number of artefacts of a certain type being created. The second group
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
focusses on the overall process structure that needs to be inferred from the activity
structure, and the milestones (see Fig. 3, lower part). Since both groups exchange infor-
mation, the second group also includes core artefacts to prepare a first mapping between
the process elements leading to an overall process and its core workflows.
Since the outcomes are complex and heterogeneous, the supervisors boil down the
outcomes to an integrated realisation concept that is the input for the construction work-
shop. The realisation concept is a 20-slide Powerpoint presentation that contains:
The overall process, including the phases and top-level work packages
A breakdown structure for each of the top-level work packages, including the core
artefacts, fine-grained activities/workflows, and possible execution orders of the
Information w.r.t. the dependency structure (between activities and roles, artefacts
and roles, and so on)
A consolidated set of 33 roles and stakeholders
Consolidated artefact and activity sets
Refined requirements for the construction
Construction workshop. The construction workshop is a full-day event in which the
students are at first introduced to the realisation concept. Afterwards, the two imple-
mentation groups are formed. To ensure that all groups have the same starting condi-
tions, the supervisors prepare the coarse process template the students can start with.
As outcomes, the students create:
An EPF-based implementation of the process (5 students)
A V-Modell-XT-based implementation of the process (3 students)
4.3 Evaluation (Audit)
The evaluation consists of two parts, according to our research questions. Figures 4
and 5 show the results of the self-assessment w.r.t. RQ 1 considering the two aspects
methodology and tool. Figure 6 shows the results of the audit covering RQ 2. For the
second evaluation, a questionnaire is used that requires the students to change their
perspectives form the Process Engineer view to the Process Consumer view.
RQ 1: Research question 1 considers the analysis of the strengths and limitations of
one strategy compared with the other when constructing a process. This construction
covers the analysis of a process, its conceptual design, and its tool-supported imple-
mentation. For the evaluation, we distinguish between the aspects methodology and
tool. The first aspect thereby covers the approach to transfer an analysed process and to
implement an analysed process in a given process framework. The ratings for the first
aspect are shown in Tab. 3 and Fig. 4.
The ratings show that the artefact-oriented strategy behind the V-Modell XT pro-
vides better support for the transfer and implementation of its proclaimed basic process
elements, i.e. roles, artefacts (work products), and relations/dependencies between the
process elements. The questions Q1-9 (completeness of roles), Q1-10 (completeness of
artefacts), and Q1-11 (completeness of relationships) have the maximum rating of 7,
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
while the EPF framework especially suffers in the area of relations/dependencies (Q1-
11: 6.2). Regarding the activity parts and the overall process, both frameworks provide
comparable support for process engineers. Since EPF is basically built on the activity-
oriented strategy, the framework better supports the implementation of activities and
workflows and, in consequence, shows a higher rating for Q1-12 (completeness of ac-
tivities), while the V-Modell XT only allows the implementation of one activity per
work product, but does not support the design of workflows.
Regarding the overall process design, both frameworks do not allow for a straight-
forward implementation, but require the process engineer to select one of the possible
approaches to model the process (e.g., copied vs. referred capability pattern in EPF, or
non-/hierarchical procedure modules in the V-Modell XT). The question whether the
designed process could be easily implemented in general, is undecided with a slightly
better rating for EPF (Q1-8, overall completeness: 6.2, to 6.0 for the V-Modell XT).
Table 3: Results for closed questions for pro-
cess engineers (RQ 1, methodology).
No. Rating Rating
EPF V-Modell XT
Q1-8 6.2 6.0
Q1-9 6.8 7.0
Q1-10 6.7 7.0
Q1-11 6.2 7.0
Q1-12 6.6 6.5
Q1-13 6.4 6.5
Table 4: Results for closed questions for pro-
cess engineers (RQ 1, tool).
No. Rating Rating
EPF V-Modell XT
Q1-2 4.4 5.5
Q1-3 4.8 4.0
Q1-5 4.8 3.5
Q1-6 4.6 6.0
Q1-7 6.6 4.0
Q1-14 5.4 6.5
Q1-15 5.8 6.0
Q1-16 5.0 2.5
Q1-8: Overall
completeness of
Q1-9: Completeness
overall process
V-Modell XT
Fig. 4: Radar chart with the results for research
question 1 (aspect: methodology).
Appropriateness tool
Q1-3: Usability tool
Q1-5: Efficiency tool
Q1-6: Awareness
Q1-7: Generating
Q1-14: Just-in-time
Q1-15: Features tool
Q1-16: QA support
in the tool
V-Modell XT
Fig. 5: Radar chart with the results for research
question 1 (aspect: tool).
The second aspect covers the appropriateness of the tool environment used for the
realisation. The results are shown in Tab. 4 and Fig. 5. The results for the second aspect
show that the EPF tool was easier to use for the process design in terms of usability (Q1-
3), efficiency (Q1-5), generating process documentation (configurability, Q1-7), and
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
quality assurance (Q1-16). While most of the subjects were familiar with the Eclipse
platform and, thus, had a steeper learning curve w.r.t. technical details, the editor for
the V-Modell XT is an expert tool on a fairly basic (technical) level. In consequence,
the usability of the EPF tool is better, but the appropriateness (Q1-2) and the awareness
(Q1-6) are, due to the direct implementation, better. The data also shows that the just-
in-time export of a process (Q1-14) was better rated for the V-Modell XT, while the
flexibility of the export (Q1-7) was better rated for EPF.
RQ 2: Once the process is constructed, we want to know to which extent the design
strategies support the usage of the generated process (documentation) from the con-
sumers’ perspective. The ratings of the second questionnaire are shown in Tab. 5 and
Fig. 6.
Table 5: Results for closed questions for process user (RQ 2).
Question Q2-1 Q2-2 Q2-2 Q2-4 Q2-5 Q2-6 Q2-7 Q2-8 Q2-9 Q2-10 Q2-11
Rating EPF 4.67 5.00 6.00 6.33 7.00 7.00 6.67 5.67 6.33 6.67 6.00
Rating V-Modell XT 4.20 3.80 3.00 4.00 5.20 6.00 6.20 4.40 3.80 4.75 4.67
Q2-1: HTML export completeness
Q2-2: HTML export accessibility
Q2-3: Overall process presentation
Q2-4: Process verifiability
Q2-5: Implementation completeness
Q2-6: Completeness roles Q2-7: Completeness artefacts
Q2-8: Completeness relationships
Q2-9: Completeness activities
Q2-10: Implementation
Q2-11: Process consistency
Fig. 6: Radar chart with the results for research question 2.
The data show that for all questions the EPF-based process is better rated than the
V-Modell-XT-based process. Significant questions are Q2-3 (overall process presen-
tation – EPF: 6.0, V-Modell XT: 3.0) and Q2-9 (completeness of activities – EPF:
6.33, V-Modell XT: 3.80). Even regarding the completeness of the artefacts (Q2-7),
the EPF-based process is better rated than the V-Modell-XT-based process (EPF: 6.67,
V-Modell XT: 6.20). Referring to RQ 1, where the implementation capabilities w.r.t.
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
artefacts and dependencies were rated better for the V-Modell XT (Q1-9 – Q1-11), the
data does not underpin similar effects for the users of the process.
4.4 Evaluation of Validity
In this section, we evaluate our findings and critically review our study w.r.t. threats to
Construct validity. Regarding the construct validity, we cannot guarantee that the as-
sessment criteria chosen in the questionnaire are complete enough to answer our re-
search questions. The chosen criteria, however, rely on our experiences in the analysed
design strategies (see, e.g. [12]) and were narrowly defined, whereby we consider this
threat as a minor one. Regarding the process chosen as a case, we believe that it suffi-
ciently covers the complexity of real-life processes.
Internal validity. There are different threats to the internal validity we are aware of. For
instance, the authors themselves have deep knowledge about the technical infrastructure
of the V-Modell XT as they directly participated in its development. We minimised this
threat by giving introductory talks about both infrastructures and serving as coaches
during the implementation workshops for both tools, but without direct interference
during the process implementation. Furthermore, the students were allowed to choose
the framework on basis of their own experiences and preferences potentially leading
to a bias towards the frameworks and the exported documentation. We minimised this
threat by opting for a research triangulation during the evaluation. Another threat to
be considered is that technical mistakes during the export of a process documentation
could have distorted the results in the audit. In fact, the V-Modell XT export did not
follow, for example, the standard stylesheet. However, all information were accessible
while non-functional aspects in the design of the tools and exported documentation
were not rated.
External validity. Regarding the external validity, one major concern is that we have
differing numbers of students in the different groups (EPF: 5 students, V-Modell XT:
3 students) and a generally low number of analysed samples. With our experiment, we
cannot allow for generalisation. However, our intention was to get first insights into a
field, which is, by now, barely investigated.
5 Conclusions
We conducted a controlled experiment in which a group of students analysed, concep-
tualised, implemented, and assessed a software process in a comparative manner. To
investigate the perceived value of process modelling and process consumption, we se-
lected two process frameworks covering the artefact-oriented and the activity-oriented
strategy to design and implement the given process. Both process frameworks support
the deployment of a designed process into the html-format, which we used to investi-
gate the value from the perspective of process consumers. Our results indicate that the
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
artefact-oriented strategy, implemented with the V-Modell XT framework, seems to be
perceived of high value to serve process engineers. For example, the tool-supported re-
alisation of an artefact model, role model, and explicitly defined relationships among
those models is better supported by the artefact-oriented strategy. Still, our results do
not show similar effects from the perspective of the process consumers. Even the arte-
facts’ completeness and especially the responsibilities, e.g. relationships to roles, were
rated to be better accessible using the activity-oriented framework.
Our findings imply that the assessment of a process design strategy in process craft-
ing needs not to coincide with the perceived value of the resulting process (documenta-
tion) from the viewpoint of a process consumer. It may well be that the artefact-oriented
approach accommodates better the request of process engineers for declarative goal-
driven design—to “have something to talk about”—whereas process consumers prefer
clear cut procedures.
Impact/Implications. We opted for a controlled experiment to explicitly simulate a
context where, on the one hand, a pre-defined process was given, and, on the other
hand, this given process was not implemented and maintained at all. That is, no par-
ticular strategy existed as it is often the case in industrial environments. This gave us
the possibility to investigate the perceived value of a strategy without any distortion by
given expectations and experiences. Inherited from the nature of a controlled experi-
ment with a limited scope is the need to further replicate the study in other contexts.
The replication should further proof the current working hypothesis that the selec-
tion of a strategy for establishing an effective process management does not affect its
actual consumption.
This will put us in the situation to empirically infer improvement goals, not only
for software process meta models, but also for the process development environments,
even already established ones such as EPF (see, e.g. Q1-15 and Q1-16).
Limitations. The experiment has several limitations that arise from the particular set-
ting in which we performed the experiment without any side effects. The setting was
characterised by limited time, a small number of participants and the choice of two
representative process frameworks. Also, we did not cover all features provided by the
frameworks that could have impacted the consumers’ opinion, e.g., tailoring capabil-
ities and project set-up. Hence, this first controlled experiment does not yet allow for
generalisations of our results, but reflects our experiences in practical software process
improvement endeavours and is therefore a first step into this direction.
Future Work. As future work, we plan to extend our experiment with further empirical
studies to support for a long-term generalisation of the results. To this end, we (1) will
conduct a survey to determine a taxonomy of characteristics important to process en-
gineers and users, and (2) plan to perform further experiments with student groups in-
volving several meta model-based frameworks to ground our data, before (3) extending
our experiments to industrially hosted environments. Besides covering the engineering
level, we need further investigation at the application level.
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
1. C. Braun, F. Wortmann, M. Hafner, and R. Winter. Method Construction — A Core
Approach to Organizational Engineering. In Proc. 20th ACM Symp. Applied Computing
(SAC’05), pages 1295–1299. ACM, 2005.
2. Brinkkemper, S. and Saeki, M. Meta-Modelling Based Assembly Techniques for Situational
Method Engineering. Inf. Syst., 24(3):209–228, 1999.
3. Conf´
eration Suisse. The HERMES Method. Online:
ch, 2011.
4. Eclipse Foundation. Eclipse Process Framework (EPF). Online, http://www.eclipse.
org/epf, 2010.
5. R. Foorthuis, S. Brinkkemper, and R. Bos. An Artifact Model for Projects Conforming to
Enterprise Architecture. In Proc. 1st IFIP WG 8.1 Working Conf. Practice of Enterprise
Modeling (POEM’08), volume 15 of Lect. Notes Business Inf. Proc., pages 30–46. Springer,
6. German Federal Ministry of the Interior. V-Modell XT. Definition and Documentation on
the Web. Online,
7. B. Henderson-Sellers and J. Ralyte. Situational method Engineering: State-of-the-Art Re-
view. J. Univ. Comp. Sci., 16(3):424–478, 2010.
8. P. Kroll and P. B. Kruchten. The Rational Unified Process Made Easy: A Practitioner’s
Guide to the RUP. Addison-Wesley, 2003.
9. M. Kuhrmann, D. M ´
endez Fern´
andez, and J. M¨
unch. Teaching Software Process Modeling.
In Proc. 35th Int. Conf. Software Engineering (ICSE’13), pages 1138–1147. IEEE Computer
Society, 2013.
10. M. Kuhrmann, D. M ´
endez Fern´
andez, and R. Steenweg. Systematic Software Process De-
velopment: Where Do We Stand Today? In Proc. Int. Conf. Software and Systems Process
(ICSSP’13). ACM Press, 2013. In print.
11. D. M ´
endez Fern´
andez, K. Lochmann, B. Penzenstadler, and S. Wagner. A Case Study on the
Application of an Artefact-Based Requirements Engineering Approach. In Proc. 15th Ann.
Conf. Evaluation and Assessment in Software Engineering (EASE’11), pages 104–113. IET,
12. D. M ´
endez Fern´
andez, B. Penzenstadler, M. Kuhrmann, and M. Broy. A Meta Model for
Artefact-Orientation: Fundamentals and Lessons Learned in Requirements Engineering. In
Proc. 13th Int. Conf. Model Driven Engineering Languages and Systems (MoDELS’10), vol-
ume 6395, pages 183–197. Springer, 2010.
13. B. Nuseibeh and S. Easterbrook. Requirements Engineering: A Roadmap. In Proc. 22nd
Int. Conf. Software Engineering (ICSE’00) — Future of Software Engineering Track, pages
35–46. ACM, 2000.
14. Object Management Group. Software and Systems Process Engineering Metamodel (SPEM)
Specification v2.0. Technical Standard formal/2008-04-01, OMG, 2008.
15. J. Ralyte and C. Rolland. An Assembly Process Model for Method Engineering. In Proc.
13th Int. Conf. Advanced Information Systems Engineering (CAiSE’01), volume 2068 of Lect.
Notes Comp. Sci., pages 267–283. Springer, 2001.
16. P. Runeson and M. H¨
ost. Guidelines for Conducting and Reporting Case Study Research in
Software Engineering. Emp. Softw. Eng., 14(2):131–164, 2009.
17. P. Tell and M. Babar. Activity Theory Applied to Global Software Engineering: Theoretical
Foundations and Implications for Tool Builders. In Proc. 7th Int. Conf. Global Software
Engineering (ICGSE’12), pages 21–30. IEEE Computer Society, 2012.
18. T. Ternit´
e and M. Kuhrmann. Das V-Modell XT 1.3. Metamodell. Technical Report TUM-
I0905, Technische Universit ¨
at M¨
unchen, 2009. In German.
© Springer. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings
... The paper at hand wraps up our concept proposal published in 2012 [16], by collecting and aggregating experiences made so far. Specifically, we review our previously published material [7], [17]- [20], and we add recent experiences. We provide examples and we condense our lessons learned into tipps and guidelines that help teachers improving the use of empirical studies in their own courses. ...
... This course was implemented at the Master's level, and the group size was limited to 15 students. We refer to [17], [18] as previously published material. Agile Project Management and Software Development APM The goal of the course "Agile Project Management and Software Development" (APM, Fig. 3-2) is to teach students advanced project management techniques with a special focus on agile project management and group dynamics. ...
... The experiences presented in this paper differ from the "normal" implementation of experiments. Conducting research is possible as we demonstrated in our case studies [17], [47], yet, our focus of using experimentation is to make students learn from their own experiences and to associate the experiences with data that they have collected themselves, rather than convincing them to 'just' trust in external findings (referring to [39]: "Verbal Receiving" versus "Doing"). ...
Conference Paper
Full-text available
Software engineering courses have to deliver theoretical and technical knowledge and skills while establishing links to practice. However, due to course goals or resource limitations, it is not always possible or even meaningful to set up complete projects and let students work on a real piece of software. For instance, if students shall understand the impact of group dynamics on productivity, a particular software to be developed is of less interest than an environment in which students can learn about team-related phenomena. To address this issue, we use experimentation as a teaching tool in software engineering courses. Experiments help to precisely characterize and study a problem in a systematic way, to observe phenomena, and to develop and evaluate solutions. Furthermore, experiments help establishing short feedback and learning cycles, and they also allow for experiencing risk and failure scenarios in a controlled environment. In this paper, we report on three courses in which we implemented different experiments and we share our experiences and lessons learned. Using these courses, we demonstrate how to use classroom experiments, and we provide a discussion on the feasibility based on formal and informal course evaluations. This experience report thus aims to help teachers integrating small-and medium-sized experiments in their courses.
... a complementing experiment, students could experience the effects of group dynamics themselves, e.g., changing team set-ups or external influences. Another experiment reported inKuhrmann & Münch (2016a)creates a setting in which students can experience the crucial role of communication (and absent communication) in distributed development set-ups.In Kuhrmann, Fernandez & Knapp (2013), we present a controlled experiment on the perception of software process modelling paradigms. A German NGO sponsored a process description, which the students had to analyse and improve according to a given approach (Kuhrmann, Fernández & Münch, 2013). Students used two different process development environments, each implementing a di ...
... In Munich, after the initial run, the course was reorganized according to the concept presented inKuhrmann (2012)in which we presented an approach to integrate experimentation with practical Software Engineering courses. Due to the reorganization, students experienced the (abstract) topics while conducting a controlled experiment on which we reported inKuhrmann, Fernandez & Knapp (2013). Moreover, due to therepeated execution in which we applied a course structure both without and with empirical instruments, we can present a number of experiences and a comparison. ...
... From the teaching perspective, we experienced that the choice of a real world example rather than an artificial toy example has proved to be successful. For example, the experiment outcome from Kuhrmann,Fernandez & Knapp (2013)was a fully implemented process to which the process owner stated that he did not expect the student groups to create ''such a comprehensive solution in this little time.'' Another goal—''let students experience the consequences of their decisions''—was also achieved. ...
Full-text available
Software engineering education is under constant pressure to provide students with industry-relevant knowledge and skills. Educators must address issues beyond exercises and theories that can be directly rehearsed in small settings. Industry training has similar requirements of relevance as companies seek to keep their workforce up to date with technological advances. Real-life software development often deals with large, software-intensive systems and is influenced by the complex effects of teamwork and distributed software development, which are hard to demonstrate in an educational environment. A way to experience such effects and to increase the relevance of software engineering education is to apply empirical studies in teaching. In this paper, we show how different types of empirical studies can be used for educational purposes in software engineering. We give examples illustrating how to utilize empirical studies, discuss challenges, and derive an initial guideline that supports teachers to include empirical studies in software engineering courses. Furthermore, we give examples that show how empirical studies contribute to high-quality learning outcomes, to student motivation, and to the awareness of the advantages of applying software engineering principles. Having awareness, experience, and understanding of the actions required, students are more likely to apply such principles under real-life constraints in their working life.
... The lab was conducted in the context of the course "Software Engineering Processes" [26] in 2011/2012. A detailed research design regarding the development of the quasi-experiment (according to Wohlin et al. [54]), applied research methods and instruments, and the outcomes can be depicted from [25]. In this section, we only give a brief overview on the lab, summarize our findings, and discuss the impacts on the consolidation of ArSPI. ...
... DOI: 10.1002/smr designed (context: process design artifacts, 2-staged design, Section 4.3.5), a session in which the process design was implemented using the artifact-based V-Modell XT framework and the activitybased Eclipse Process Framework (context: artifact process release), and finally a session in which the outcomes were evaluated from the perspective of the process engineers as well as from the perspective of the process users (context: measurement and evaluation, Section 4.3.6). Figure 7 summarizes the results from the assessments. Since the results are manifold and discussed in detail in [25], we only briefly discuss one key finding relevant to the context of this article. Our results underpin the artifact-based design strategy-on which ArSPI is based-to be an advantageous instrument for process engineers (the transfer of designed artifacts into the authoring environment is "more" straightforward), whereas process consumers do not evidently care about the selected design strategy. ...
... In order to make ArSPI accessible, we created a web site on which we provide all ArSPI-related material. In detail: a technical report [23] that serves as "data sink" and contains the full artifact UML model, basic processes and detailed descriptions, and additional background information, scientific contributions on ArSPI, for instance [25,26,24], an initial implementation of ArSPI as a process model based on the Eclipse Process Framework, and document templates and templates for evaluation purposes, e.g., the evaluation material used in [25]. ...
Full-text available
Structured approaches are beneficial for successful software process improvement (SPI). However, process engineers often struggle with standardized SPI methods, such as capability maturity model integration (CMMI) or International Organization for Standardization (ISO) 15504, and complain about too generic or voluminous approaches or methods that are alien to the organizations in which SPI is conducted. Therefore, process engineers need to customize existing SPI models or develop new approaches for company-specific SPI programs. While conducting SPI in the context of the German V-Modell XT, we faced the need to develop a new method for artifact-based SPI. In the process, we found that the construction procedures of SPI models are barely documented, and thus, their successful adaptation solely depends on the process engineers' expertise. With this article, we aim to address this lack of support and provide a structured reflection on our experiences from creating and adopting the Artifact-based Software Process Improvement & Management (ArSPI) model. We present the steps of the construction procedure, the validation, and the dissemination of the model. Furthermore, we detail on the applied methods, the design decisions, and the challenges encountered. By providing a reference procedure and tested methods, we support process engineers with the creation and adoption of SPI approaches.
... Our role as MDE practitioners is to access such artifacts by discovering their intentions and properties, then download and integrate their content into our software projects, as illustrates Figure 1 (A). In Phase 1, this approach can foster reuse of artifacts previously stored in repositories, reducing cost and time-to-market to integrate them in appropriate representations in Phase 3 [5], e.g., into application lifecycle management tools [6], process modeling languages [7], model transformation chains [8], component models [9], tool integration [10], and others. Repositories, to be effective, need a sort of semantic information (so-called qualified data) associated with such artifacts. ...
... Our role as MDE practitioners is to access such artifacts by discovering their intentions and properties, then download and integrate their content into our software projects, as illustrates Figure 1 (A). In Phase 1, this approach can foster reuse of artifacts previously stored in repositories, reducing cost and time-to-market to integrate them in appropriate representations in Phase 3 [5], e.g., into application lifecycle management tools [6], process modeling languages [7], model transformation chains [8], component models [9], tool integration [10], and others. Repositories, to be effective, need a sort of semantic information (so-called qualified data) associated with such artifacts. ...
Conference Paper
Large-scale collaboration in Model Driven Engineering (MDE) demands the use of one or more repositories such as GEMOC, ReMoDD and SEMAT, which share artifacts (e.g., models, meta-models, transformations, etc.) for global reuse scenarios. In order to benefit the MDE community from an important quality attribute (i.e., understandability of MDE artifacts), this work analyzed the information available in ReMoDD. We conducted a study of the representation of reusable assets conformance to the criteria found through the execution of a multivocal research protocol. We found that these assets are not in conformity with these criteria, thus hampering the establishment of future Software Ecosystems (SECOs) for MDE.
... Due to this human involvement and the multitude of fields for which software has become crucial, software engineering is considered hard to teach. Literature is rich and discusses different experimental settings [15], in-class projects [23], or project courses [6] in general—each addressing technology (e.g., analysis, coding, and testing) or management issues (e.g., project management, the software process, and teams and soft skills [7, 30]). However, most of the software engineering courses address the system/product development. ...
Conference Paper
Full-text available
Empirical software engineering aims at making software engineering claims measurable, i.e., to analyze and understand phenomena in software engineering and to evaluate software engineering approaches and solutions. Due to the involvement of humans and the multitude of fields for which software is crucial, software engineering is considered hard to teach. Yet, empirical software engineering increases this difficulty by adding the scientific method as extra dimension. In this paper, we present a Master-level course on empirical software engineering in which different empirical instruments are utilized to carry out mini-projects, i.e., students learn about scientific work by doing scientific work. To manage the high number of about 70 students enrolled in this course, a seminar-like learning model is used in which students form expert teams. Beyond the base knowledge, expert teams obtain an extra specific expertise that they offer as service to other teams, thus, fostering cross-team collaboration. The paper outlines the general course setup, topics addressed, and it provides initial lessons learned.
... project quality (see also the discussion in Sect. 5). Another field of application considers the validation of previously conducted studies and the calibration of the metrics used for further studies. For example, we have already tested the benefits and shortcomings of applying artefact orientation to RE in various experiments and case studies.[14, 13]. We could also confirm the value of replication studies as those studies confirmed trends, e.g. the support of consistency and a clear terminology. While most of the variables we used in our studies match indeed the stated improvement goals, there are some variables we plan to remove for further replication as they show to have too many ...
Conference Paper
Full-text available
Context: For many years, researchers and practitioners have been proposing various methods and approaches to Requirements Engineering (RE). Those contributions remain, however, too often on the level of apodictic discussions without having proper knowledge about the practical problems they propagate to address, or how to measure the success of the contributions when applying them in practical contexts. While the scientific impact of research might not be threatened, the practical impact of the contributions is. Aim: We aim at better understanding practically relevant variables in RE, how those variables relate to each other, and to what extent we can measure those variables. This allows for the establishment of generalisable improvement goals, and the measurement of success of solution proposals. Method: We establish a first empirical basis of dependent variables in RE and means for their measurement. We classify the variables according to their dimension (e.g. RE, company, SW project), their measurability, and their actionability. Results: We reveal 93 variables with 167 dependencies of which a large subset is measurable directly in RE while further variables remain unmeasurable or have too complex dependencies for reliable measurements. We critically reflect on the results and show direct implications for research in the field of RE. Conclusion: We discuss a variety of conclusions we can draw from our results. For example, we show a set of first improvement goals directly usable for evidence-based RE research such as "increase flexibility in the RE process", we discuss suitable study types, and, finally, we can underpin the importance of replication studies to obtain generalisability.
Conference Paper
For large-scale processes as implemented in organizations that develop software in regulated domains, comprehensive software process models are implemented, e.g., for compliance requirements. Creating and evolving such processes is demanding and requires software engineers having substantial modeling skills to create consistent and certifiable processes. While teaching process engineering to students, we observed issues in providing and explaining models. In this paper, we present an exploratory study in which we aim to shed light on the challenges students face when it comes to modeling. Our findings show that students are capable of doing basic modeling tasks, yet, fail in utilizing models correctly. We conclude that the required skills, notably abstraction and solution development, are underdeveloped due to missing practice and routine. Since modeling is key to many software engineering disciplines, we advocate for intensifying modeling activities in teaching.
Companies that want to improve the quality of software products or speed up software development, e.g., to improve the time-to-market, put emphasis on the software process used to organize and steer software development projects. A software process describes the basic development approach, artifacts being produced, activities to be performed, and roles taking responsibility or contributing to development artifacts or activities. In order to address the specific circumstances, companies look for software process improvement (SPI) programs. The thesis at hand aims to support organizations and process engineers to better conduct SPI in a systematic and organized manner by instrumenting the paradigm of artifact-orientation. Artifact-orientation is a design paradigm that puts emphasis on the artifacts being produced in a project - the “what”. By describing the artifacts as detailed as possible while giving process engineers the freedom to apply their preferred methods or methods that best fit the actual context, artifact-orientation allows for an increased flexibility. In this thesis, we apply artifact-orientation to the domain of software process improvement. In 10 selected papers, we describe the context for software process improvement and put special emphasis on modeling of software processes, variability of software processes, software process life cycle models and software process infrastructures. We then apply artifact-orientation to software process improvement by defining an artifact-based approach to systematically conduct SPI, and extend our discussion by presenting an integrated Artifact-based Software Improvement & Management model. This model goes beyond isolated SPI endeavors and allows for implementing SPI in the context of a company-wide software process management (SPM). Finally, we discuss the feasibility of the artifact-based approach in the context software process enactment, and we also describe an approach to educate process engineers to apply the presented approach in their respective contexts.
Full-text available
Software processes improvement (SPI) is a challenging task, as many different stakeholders, project settings, and contexts and goals need to be considered. SPI projects are often operated in a complex and volatile environment and, thus, require a sound management that is resource-intensive requiring many stakeholders to con- tribute to the process assessment, analysis, design, realisation, and deployment. Although there exist many valuable SPI approaches, none address the needs of both process engineers and project managers. This article presents an Artefact-based Software Process Improvement & Management approach (ArSPI) that closes this gap. ArSPI was developed and tested across several SPI projects in large organisations in Germany and Eastern Europe. The approach further encompasses a template for initiating, performing, and managing SPI projects by defining a set of 5 key artefacts and 24 support artefacts. We present ArSPI and discus results of its validation indicating ArSPI to be a helpful instrument to set up and steer SPI projects.
Technical Report
Full-text available
Dieser Bericht beschreibt das Metamodell des V-Modell XT. Unter einem Metamodell verstehen wir dabei die grundlegende Strukturierung der Beschreibungselemente des V-Modell XT, beispielsweise in Form der Beschreibungselemente Vorgehensbaustein, Produkt oder Aktivität mitsamt aller Abhängigkeiten zwischen diesen Elementen. Die grundlegende Strukturierung spiegelt sich unmittelbar in der V-Modell XT XML-Datei und im V-Modell XT Editor wider. Die PDF beziehungsweise HTML-Version des V-Modells gehen durch strukturelle Transformation aus der in diesem Bericht beschriebenen Struktur hervor. Dieser Bericht ist eine erweiterte und kommentierte Fassung der Metamodelldokumentation, die dem V-Modell XT standardmäßig beiliegt.
Full-text available
Most university curricula consider software pro- cesses to be on the fringes of software engineering (SE). Students are told there exists a plethora of software processes ranging from RUP over V-shaped processes to agile methods. Furthermore, the usual students’ programming tasks are of a size that either one student or a small group of students can manage the work. Comprehensive processes being essential for large companies in terms of reflecting the organization structure, coordinating teams, or interfaces to business processes such as contracting or sales, are complex and hard to teach in a lecture, and, therefore, often out of scope. We experienced tutorials on using Java or C#, or on developing applications for the iPhone to gather more attention by students, simply speaking, as these are more fun for them. So, why should students spend their time in software processes? From our experiences and the discussions with a variety of industrial partners, we learned that students often face trouble when taking their first “real” jobs, even if the company is organized in a lean or agile shape. Therefore, we propose to include software processes more explicitly into the SE curricula. We designed and implemented a course at Master’s level in which students learn why software processes are necessary, and how they can be analyzed, designed, implemented, and continuously improved. In this paper, we present our course’s structure, its goals, and corresponding teaching methods. We evaluate the course and further discuss our experiences so that lecturers and researchers can directly use our lessons learned in their own curricula.
Conference Paper
Full-text available
A software process metamodel (SPMM) defines a language to describe concrete software processes in a structured man-ner. Although agile methods gained much attention in re-cent years, we still need to provide process engineers with ad-equate tools to design, implement, publish and deploy, and manage comprehensive software processes. In response to this need, several SPMMs have been developed. It remains, however, unclear, which of those SPMMs are disseminated to which extent. In this paper, we contribute first results of a study on the state-of-the-art in the systematic develop-ment of software processes using standardized SPMMs and their corresponding infrastructure. Our results show that only a few documented standards exist and, furthermore, that among those standards only two are disseminated into practice. We focus on those standardized SPMMs, show their process ecosystem, and sketch a first picture on the state-of-the-art in SPMM-based software process develop-ment in order to foster discussions on further problem-driven research.
Conference Paper
Full-text available
This article presents a model for projects that have to adhere to Enterprise Architecture (EA) in order for their results to be aligned with the broader organization. The model features project artifacts (deliverables such as Software Architecture Documents), their mutual relationships, their relationship with EA, and the processes in which they are created and tested on conformance. We start with applying Activity Theory to show the crucial mediating role that artifacts have in projects and to identify and justify the new EA-related artifacts we introduce. We subsequently incorporate these findings and existing best practices in a standard software engineering approach in order to create a practical model that projects can apply for EA conformance. This model features both new, dedicated EA artifacts, and well-known existing artifacts of which we describe the way they should conform to EA. Finally, two action research studies are used to empirically support the model.
Conference Paper
Full-text available
The need for a better productivity of system engineering teams, as well as a better quality of products motivates the development of solutions to adapt methods to the project situation at hand. This is known as situational method engineering. In this paper we propose a generic process model to support the construction of a new method by assembling method chunks generated from different methods that are stored in a method base. The emphasis is on the guidance provided by the process model, as well as on the means underlying guidelines such as similarity measures and assembly operators. The process model is exemplified with a case study.
Full-text available
The situational method engineering (SME) literature is surveyed and a synoptic evaluation presented in the context of formalizing and regularizing the conceptual framework and underpinning theory. Metamodels proposed for use in SME are evaluated as well as highlevel process models for method construction. Method fragments and method chunks are then described formally followed by their identification and creation (from existing methods, from scratch or from past usage). Method creation is then analyzed in terms of various processes for constructing a full methodology from the method fragments/chunks. In particular, we contrast the use of the "map" technique and of the "deontic matrix" technique. The survey is concluded with an evaluation of some ideas on method tailoring and the emerging research on quality evaluation applied to SME.
Conference Paper
Although a plethora of tools are available for Global Software Engineering (GSE) teams, it is being realized increasingly that the most prevalent desktop metaphor underpinning the majority of tools have several inherent limitations. We have proposed that Activity-Based Computing (ABC) can be a promising alternative to build tools for GSE. However, significant effort is required to introduce a new paradigm; there is a need of sound theoretical foundation based on activity theory to address challenges faced by tools in GSE. This paper reports our effort aimed at building theoretical foundations for applying activity theory to GSE. We analyze and explain the fundamental concepts of activity theory, and how they can be applied by using examples of software architecture design and evaluation processes. We describe the kind of data model and architectural support required for applying activity theory in building supporting infrastructure for GSE, and describe a proof of concept prototype.
Als die Bundesrepublik Deutschland Mitte der 80er Jahre damit begann, das V-Modell zu entwickeln, stand vor allem eins im Vordergrund: Inhalt. Es sollte klar festgelegt werden, wie der Softwareentwicklungsprozess der Auftragnehmer des Bundes aussieht. Die Inhalte fanden internationale Beachtung. Sie waren allerdings in Form einfacher Textdokumente festgeschrieben. Dies gilt für das V-Modell 92 und das V-Modell 97.
Method engineering for information system development is the discipline to construct new advanced development methods from parts of existing methods, called method fragments. To achieve this objective, we need to clarify how to model the existing methods and how to assemble method fragments into new project-specific methods, so-called situational methods. Especially, to produce meaningful methods, we should impose some constraints or rules on method assembly processes. In this paper, we propose a framework for hierarchical method modelling (meta-modelling) from three orthogonal dimensions: perspectives, abstraction and granularity. According to each dimension, methods and/or method fragments are hierarchically modelled and classified. Furthermore, we present a method assembly mechanism and its formalization as a set of rules. These rules are both syntactic and semantic constraints and presented in first order predicate logic so that they can play an important role in the assembly process of syntactically and semantically meaningful methods from existing method fragments. The benefit of our technique is illustrated by an example of method assembly, namely the integration of the Object Model and Harel's Statechart into Objectcharts.