ArticlePDF Available

Abstract and Figures

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.
Content may be subject to copyright.
This is an author-generated version.!
The final publication is available at!
DOI: 10.1109/ICSE.2013.6606665!
Bibliographic information:!
Marco Kuhrmann, Daniel Méndez Fernández, Jürgen Münch. Teaching Software Process
Modeling. In Proceedings of the 35th International Conference on Software Engineering (ICSE),
pages 1138-1147, San Francisco, United States, May 2013.
Teaching Software Process Modeling
Marco Kuhrmann
Technische Universit
at M
Faculty of Informatics
Garching, Germany
Daniel M
endez Fern
Technische Universit
at M
Faculty of Informatics
Garching, Germany
urgen M
University of Helsinki
Department of Computer Science
Helsinki, Finnland
Abstract—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.
Index Terms—software process education teaching methods
Software process models are the glue that holds organiza-
tions, projects, and people together. Therefore, the develop-
ment, the maintenance, and the improvement of a software pro-
cess model constitute challenging tasks that each requires well-
trained and experienced process engineers. Although being
an essential part of software engineering, software processes
are, if at all, only marginally included in a typical software
engineering (SE) curriculum. Typically, such curricula contain
lectures and labs that consider the SE basic principles, require-
ments engineering, architecture, programming and program-
ming languages, and some in-depth courses, which are usually
specific to the universities’ focus, e.g., automotive software
engineering, business information systems, or robotics.
The university curricula, as they are defined, provide the
basic computer science knowledge including a rudimentary
SE toolbox. They lack, however, the opportunity to experience
“real world” problems, e.g., programs of considerable size in
large-scale development projects with moaning customers and
further soft facts that realistically shape typical problems and
risks. Hence, students are often left unprepared for todays
industrial project environments. This is problematic as most
of the software projects fail not because of technical issues
but because of an insufficient ability to understand project
organization and management, which is basically reflected by
software processes. Studies show that “with few exceptions,
the reasons that large-scale development programs have failed
have not been technical [. . . ]. As the cancellation of two large
and critical efforts demonstrates, these systems have almost
always failed because of program-management problems” [1].
Those topics that cause the majority of economic damage
to industry
are not taught at university in a way students
can experience the effects of missing or poorly implemented
software processes. The reason for this shortcoming is that the
aforementioned aspects in SE need to be tailored in order to
fit into the lectures’ schedule. This is additionally enforced
by strict time schedules in the curricula, e.g., arising from the
Bologna process
. On the other hand, it can be seen as fruitful
with respect to learning if students can experience themselves
the effects of the SE principles or techniques/methods they
are taught. This might help to better understand their practical
relevance. Programs, for instance, can be developed and tested
by the students themselves. Errors that were made during the
development can be easily experienced. Also, for lecturers it
is easier to monitor, correct, and rate those kinds of tasks.
Software processes, on the other hand, are more complicated
to teach. Since the “execution engine” of software processes
is an organizational context involving human beings, software
processes cannot be taught the same way like programming
While todays SE curricula mostly address the system layer,
software processes are situated on the organization and project
layer in which completely different topics matter. However,
since students will work usually after graduation in the context
of large projects that are coordinated by significantly complex
processes (whether they are explicitly defined or not), they
need to have a fundamental understanding about process
models and process management (e.g., how processes can
be used to coordinate teams), as well as of challenges and
IDC’s worldwide IT investment volume forecast in 2010 estimated a
growth to 1,735 Trillion $ in 2013—at the same time the Standish Group
periodically names about 25% of the projects to be a failure.
The Bologna Process Towards the European Higher Education Area,
risks that are associated with software processes and their
deployment or improvement.
A. Problem Statement
Although we have insights into todays industrial project
environments with all its challenging and problematic facets,
we still miss to effectively prepare the students for those envi-
ronments. Students need to be prepared for such environments
with a basic understanding about the relevance and the goals of
software process modeling and management. The design of a
course that gives students access to this understanding and the
evaluation of such a course’s success remains a challenging
task, mainly because of soft facts given in the envisioned
context that cannot be generalized and taught in classical
courses structured with lectures and exercises only.
Yet missing are concepts and lessons learned for the design
and the evaluation of a course on software process modeling
including the analysis of processes, their implementation, and
their improvement.
B. Objective
We aim at defining a concept for a course that pays attention
to the skills a process engineer must have in today’s industrial
environments. Therefore, we aim at defining general goals and
requirements for a course that applies to the needs of teaching
software processes. We design and implement the structure
and the content of such a course in a universities curriculum,
and validate our approach against the requirements.
C. Contribution
We contribute a concept and its evaluation for a course on
software process modeling going beyond a classical teaching
format with lectures and exercises. To this end, we define the
requirements for a course to tackle the problems stated above.
We contribute the design of the course via a blueprint including
most relevant topics and a proposed schedule.
The concept has been fully implemented and evaluated
at the Technische Universit
at M
unchen in the winter term
2011/2012. The evaluation includes the evaluation against
the requirements, the formal evaluations according to the
faculties standards, and an informal feedback-based evaluation
performed by the students. In addition, parts of the concepts
have been implemented in a process definition and manage-
ment course (based on [2]) at the University of Helsinki
(winter 2012/2013). Experiences of this implementation are
integrated in the discussion section. Finally, we conclude with
a discussion of our results.
D. Outline
The remainder of this paper is organized as follows: In
Sect. II, we discuss the related work. Section III defines the
requirements a course on software process modeling should
meet. In Sect. IV, we describe the course design, introduce
a blueprint, map the requirements, and show an example
implementation. Section V presents an evaluation, which is
based on a formal evaluation by the faculty and an informal
one that is based on the students’ feedback. We conclude the
paper in Sect. VI by critically discussing the passed courses
and drawing a roadmap for future work.
Different concepts have been proposed to teach software
process aspects. Besides traditional classroom teaching, we
distinguish between approaches based on practical exercises,
experiments, games, and simulation. The Personal Software
Process (PSP) [3] is the most prominent teaching approach
that focuses on practical exercises. The underlying idea is
to apply process principles at the level of single developers.
Studies have shown that applying such processes at individual
level can lead to significant performance improvements [4]. In
contrast to the approach presented here, the PSP exercises all
deal with relatively small and local processes.
Empirical approaches focus on teaching by conducting
experiments, typically as part of a regular course. The stu-
dents take the role of experimental subjects to experience the
effects of selected processes or techniques themselves. Typical
objectives of such experiments consider comparisons of dif-
ferent quality assurance processes (e.g., [5]), Global Software
Engineering (GSD, e.g., [6]–[8]), or Software Engineering in
general (e.g., [9]–[12]). In contrast to the approach presented
here, the experimental treatments are usually engineering level
processes and not process modeling or process management
activities. Only few experiments exist that focus on process
management aspects (e.g., [13], [14]).
Approaches for teaching lean and agile practices are often
based on educational games [15]. Lean production processes,
for instance, are often demonstrated with the means of a game
to impart knowledge about lean principles. In contrast to the
approach presented in this paper, this kind of teaching typically
aims at a better understanding of a specific philosophy rather
then at better understanding the challenges of defining and
managing large software processes.
Finally, simulation is sometimes used to support teaching in
the area of software processes [16]. Here, students can make
local decisions and see their global effects. Simulation is also
suited for playing “what if games” and, thus, help to better
understand processes. In contrast to the our approach, simula-
tion have a more limited scope that consists of understanding
process dynamics.
All these different approaches have their specific strengths
and could be seen, at least partially, as valuable additions to
the approach presented in this paper.
Software engineering comprises many tasks—technical ones
as well as organizational and management tasks. A number
of roles in projects are responsible to perform those tasks
and to produce artifacts. Furthermore, several stakeholders are
also included in a project, e.g., top management, IT services,
interdisciplinary users. Because of the number of participating
people and the projects’ objectives, coordination and com-
munication are, besides the classical engineering disciplines,
essential to meet the project goals. Software process models
are a means to describe how the communication is structured,
how collaboration is established, which artifacts have to be
produced, and how to coordinate teams to operate (manage
and control) a software project in general.
A. Basic Goals
The basic goal of the course is to effectively teach the
basic concepts in software process modeling over their whole
life cylcle, i.e. the analysis of processes, the conceptualiza-
tion/design of processes, their tool-supported implementation,
and, finally, their deployment and evaluation.
B. Requirements
Based on the basic goals, we derived the following re-
quirements for a course on software process modeling. The
requirements basically originate from experiences gathered in
a number of process improvement and coaching projects and
trainings. In the following, we provide brief explanations why
we consider those requirements to be important.
REQ 1: Students need to understand the importance of process
Students will work in organizations and projects where they
have to deal with processes with all their facets. Hence, they
need an understanding why things work the way they do. Even
in the case in which students work in an environment that
is free of any (documented) process, students need to have
knowledge about project organization, collaboration pattern,
and opportunities to operate projects successfully, for example,
considering progress control.
REQ 2: Students need to understand the integration of process
models into an organizational environment
We believe that students need to learn how organizations
are structured in general. Such knowledge includes interfaces
between a project and their embedding into an organization
(e.g., project internal processes and their relation to business
processes), knowledge about process groups (e.g., the role of
the quality management), and process infrastructures and their
requirements (e.g., organizational and cultural prerequisites to
apply agile methods like Scrum or to implement a process
model using SPEM/EPF).
REQ 3: Students need to experience realistic process models
in terms of differences in size and complexity related to small,
medium, and large organizations and projects
We often observe that educational programs are focused on
agile development practices in small teams. However, it is
still factually important to teach that software processes are
a means to organize software development, especially when
applying agile methods. Still, depending on the organizations’
culture or the project size, different process models are of
interest and need to be taught. For instance, a globally acting
enterprise usually implements a process model of considerable
size and complexity to reflect the structure, in general, and
certain project situations, in particular. Such process models
may contain hundreds of work products and activities, or
dozens of roles, which, if summarized, we have experienced
to constitute thousands of process elements to be maintained
(see, e.g., the V-Modell XT).
REQ 4: Students need differentiated knowledge about different
modeling approaches
Since there exists a plethora of modeling approaches that
can be used to design and implement a process model, students
need to understand those approaches, their basic philosophies,
concepts, and the basic idea behind a particular approach.
Each modeling approach has opportunities and limitations,
which can become “show stoppers”, because they might be
incompatible to the organization’s philosophy. A wrong design
decision can lead to a valid process model, which might,
however, not be implementable; for example, if the chosen
process modeling tool does not support certain association
types. Also, weak designs may cause increased effort in terms
of maintainability. Therefore, the different approaches need to
be effectively taught in conjunction with their consequences
for, e.g., developing/realizing a process or identifying and
correcting errors.
REQ 5: Students need to learn the most relevant existing
process models (such as national or international standards)
Organizations often use or have to some extent adhere to
existing process models. Students need to understand the basic
concepts of such models, their suitability for specific contexts,
their underlying principles, and their customization needs.
The selection of the most relevant process models depends
on several factors (such as the country or a specific domain
that might be addressed by the overall computer science
curriculum). Examples might be international standards (such
as ISO 12207:2008 [17]), national standards (such as the V-
Model XT in Germany), or domain-specific standards (such
as IEC 26262 [18] for the automotive domain or IEC 62304
[19] for medical devices).
At the university, we face the problem that the usual
teaching format consists of a weekly lecture and an exercise
(90 minutes each), where the exercise is usually done the week
after the lecture. In consequence, theoretical parts are taught
in a theater style, where the lecturer “acts” in front of the
students. The week after, the topics of the lecture are repeated
and supported with some exercises the students can work on.
This leads to a work slot of effectively 90 minutes (at most)
per week in which possible examples have to fit in. In terms
of software process modeling, this is a ridiculous time span
compared to real SPI projects, which comprehend an effort
between 50 and more than 200 man days [20].
Trainings in an industry environment are differently struc-
tured. Such trainings are organized in a workshop style with
typical durations of 3 to 5 days. In such trainings, theoretical
and practical parts are interwoven. Lab-sessions of several
hours can be included, which gives more freedom to work
on examples. Of course, those workshops are still far away
from “real” SPI projects, but proved to be more efficient than
the dispersed university teaching style.
The basic course design, which we presented in [14], was
developed according to the demand to change the way software
processes are taught. From our experience, which we made
in university teaching as well as in professional trainings in
an industry context, we re-designed our lecture to meet the
requirements from Sect. III.
In this section, we briefly introduce a software process life
cycle model on which the course design is based and the
resulting course design. We show how the requirements are
met and present an example implementation.
A. The Software Process Life Cycle
When teaching software process modeling to students, a
systematic framework is required. Several of such software
process life cycles (SPLC) have been proposed, e.g., an 8-step
approach that describes the lifecycle of a descriptive process
model [2]. These life cycles mainly differ in the span of the
life cycle (number of covered phases) and the specific focus
(prescriptive or descriptive modeling or process improvement).
All these life cycle models follow a typical process, i.e. models
can be specified, built, implemented, analyzed, used, assessed,
evolved, or rejected.
Phase Description
Analysis In the analysis phase the actual process is analyzed. The
process goals and the process requirements have to be
determined. If available (e.g., when evolving a given process
model), prescribed process models have to be analyzed.
Techniques to be applied in this phase are for instance:
interviews, workshops, or audits.
Conception In the conception phase descriptive modeling techniques [2]
are applied to create process prototypes. The overall goal
of this phase is to define the target process model includ-
ing, e.g., the selection of modeling techniques/adaptation
options, creating drafts of the process to be, and so on. All
those activities are done without paying much attention to
concrete technical implementations.
Realization In the realization phase the concrete realization approach
is defined (including concrete modeling techniques that
may be supported by a technical infrastructure, i.e. EPF
[21]). Furthermore, the requirements and designs—made
during the conception phase—are refined in order to be
implemented in the selected (technical) environment. From
the management perspective, the realization and the quality
assurance plans are created on a level that allows for
concrete implementation tasks, which are also performed
in this phase. Depending on the kind and the complexity of
the process model under consideration, the conception and
the realization phases can be done in parallel.
Deployment In the deployment phase pilot projects, trainings and con-
crete deployment strategies are concretized [22]. This in-
cludes the roll-out of a certain process in an organization
or a specific change of an existing process that is already
conducted in an organization. We also subsume in this phase
an evaluation of the process by using different means such
as assessment, audit, or measurement-based improvement.
We use an aggregated and simplified life cycle for the course
(see Table I), which consists of the following phases: analysis,
conception, realization, and deployment. Since this life cycle
is iterative, it supports for continuous improvement of software
process models.
B. Blueprint
Our course design
is based on both, our experience in
university teaching as well as industry workshops. We adopted
the workshop-based approach in the university teaching to give
students more space to gain practical experience, and on the
other hand, to give researchers the opportunity to conduct
research [14]. The course concept (Fig. 1) uses the SPLC
model from Table I as underlying conceptual framework to
align all relevant topics into the course’s structure. For the
practical parts students go through the SPLC when analyzing,
designing, and realizing a software process model. Because of
the time constraints of a semester, practicing the deployment
is not possible.
1) Theoretical Parts (light gray): The course consists of
three lecture phases. In the first phase (about three weeks),
the fundamentals and the basic knowledge is imparted. In the
second phase of about eight weeks, the lecturer prepares the
frame for the spotlight topics that cover areas of specialization.
The students work independently on the spotlight topics; they
prepare presentations and small essays to summarize their out-
comes. Also, during this phase the practical parts are prepared.
The third phase (about two weeks) is the evaluation phase.
Outcomes from the practical parts are evaluated according
to scientific methods. The topics as well as the proposed
examples covered by the theoretical part can be taken Table II.
2) Practical Parts (dark gray): At the time when the second
phase of the theoretical parts starts, the classical exercises,
which can be used at the very beginning of the course
over two sessions, are replaced by practical trainings (labs).
Therefore, a project assignment in which the project objectives
are contained needs to be prepared. The choice of the project
should be opportunistic keeping, however, in mind that a
realistic complexity should be inherent (an example is given
in Sect. V-C). The project objectives need to be aligned with
the course’s contents (cf. Table II) w.r.t. the agenda of the
overall course and topics that can be worked on in a self-
contained manner, e.g., work packages that can be handled in
one session. The chosen example should support a continuous
and seamless work among the different sessions. Another
important aspect is that outcomes of the practical parts need
to be prepared for evaluation and, thus, need to be defined in
order to be measurable. Figure 1 also shows the assignment
of the SPLC phases to the second lecture phase and the
workshops. In terms of the SPLC model, the workshops cover
the analysis, the conception, and the realization as tasks that
can be done in a workshop slot of 90 or 180 minutes.
This teaching format was awarded with the “Ernst Otto Fischer
Teaching Award” (2012) by the Faculty of Informatics, Technische Uni-
at M
unchen (
otto fischer lehrpreis.html).
Areas of specialization and context for practical trainings
Workshop 1
Workshop N
Evaluation Exam
Lecture Period
W. 1-3
W. 12-13
W. 4-11
W. 5-11 – Workshops in small student teams
Lecturer: further basic knowledge, motivation and
organizational frame for the practical trainings,
Students: work on spotlight topics
Project definition for
the practical
Basic knowledge Evaluation using
Lecture Phases !
* Deployment is not part of a
workshop but part of the SPLC
SPLC Phases !
Fig. 1. Course blueprint showing the theoretical (light gray), the practical (dark dark) parts, the mapping to the SPLC phases, and a planning pattern.
3) Scientific Parts: We also introduced a pattern for con-
ducting research in the context of this lecture format [14]
including experimentation and survey research.
C. Requirements Mapping
In Sect. III, we named the requirements we consider
important to run a course on software process modeling.
Furthermore, Fig. 1 shows the SPLC-based blueprint that gives
the frame for such a lecture. In consequence, a number of
topics needs to be addressed by the lecture that cover general
information on software processes, the importance of software
processes, their relation to organizations and other kinds of
processes, as well as knowledge w.r.t. modeling approaches,
concrete software process models, systematic approaches to
analyze, design, realize, and deploy software processes, and
supporting methods/techniques in order to do software process
engineering. Therefore, we mapped the requirements, the
blueprint, and the necessary topics using Table II. The table
shows the lecture phases (fundamentals, areas of specializa-
tion, evaluation), names the performers (lecturers doing the
theoretical parts, students working on spotlight topics, and the
practical parts), and gives a mapping to the requirements. To
support easy reproduction, the table also provides references
to embody the key contents, such as concrete process models,
selected methods, and tools.
D. Example Implementation
The blueprint was implemented for the first time in the
second run of the lecture
“Software Engineering Processes”
Lecture “Software Engineering Processes”, winter term 2011/2012,
master‘s level,
index.shtml; material German and partially English, available on request
in the winter term 2011/2012 (the first lecture was given in the
classic way). This lecture gives an introduction to the domain
of process engineering and process management [2], [32], [37],
[38]. Table II shows the topics addressed in the lecture aligned
to the software process life cycle and the (common) tasks
needed to be performed to analyze, conceptualize, design,
implement, publish, and assess a software process. This course
was implemented at the master’s level. In order to provide
a high-quality class, to foster interaction, and due to the
experimental character, the group size was restricted to 15
students. The whole lecture was organized to be held in a
block of 180 minutes per week to create the necessary space
for practical trainings and experiments.
Week Topics
1–3 Fundamentals
4–7 Software processes and infrastructures,
SPLC: Analysis,
SPLC: Conception
8–9 Software process metamodels,
SPLC: Realization,
workshops: analysis and conception (90 minutes each)
10–12 SPLC: Deployment,
SPLC: Management and continuous improvement,
workshop: realization (180 minutes)
13 Evaluation
A 13-week schedule for the pilot implementation is shown
in Table III (in relation to Table II). The table boils down the
blueprint (Fig. 1) and shows, what are the particular contents,
and what is the duration a phase.
Performer Topic in the lecture REQ1 REQ2 REQ3 REQ4 REQ5
T Motivation, need for software process models 8
T Software process terminology and philosophies 8 8
T Software processes and organizations (i.e. organization pattern) 8 8
T Business processes, software processes, and project management at a glance 8 8
Software processes and infrastructure
T Basic software process models (waterfall, V-shaped, iterative approaches) 8 8 8
T/S Agile methods (Scrum [23], XP [24], Crystal, FDD, Kanban, MSF Agile) 8 8
T/S Rich processes (RUP [25], V-Modell XT [26], Prince2, Hermes) 8 8
T/S Other approaches: (Situational) Method Engineering [27] 8 8
T Other processes: maturity models, e.g., CMMI [28], SPICE [29], ISO 9000 [30] 8 8
T Other processes: ITIL [31] and other processes for operation 8 8
T Tool-support for software process users: process enactment in projects 8 8
T Tool-support for software process authors: overview authoring tools 8
Areas of specialization
T The “Software Process Life Cycle” (SPLC, overview) 8
SPLC: Analysis
T Motivation and overview 8 8
T/P Stakeholder analyses, role models (context: organization pattern) 8 8 8
T/P Process and workflow analyses 8
T/P Artifact analyses 8
T Process model analysis (cf. descriptive modeling [2]) 8
SPLC: Conception
T Design strategies (overview) 8
T Conceptual modeling approaches (e.g., templates structures, etc.) 8
T/P Mapping of analyzed processes to process entities (e.g., milestones, roles, tasks) 8
T Design of process tailoring (overview over different approaches) 8 8
T/P Design of the process documentation 8
T Creating software processes by using software process lines [32] 8 8
Software process metamodels see below 8
SPLC: Realization
T General implementation strategies 8 8 8
T Iterative process realization approach 8 8
T Creating feedback loops and dealing with change 8 8
SPLC: Deployment
T Deployment strategies (big bang, incremental, pilot projects [22]) 8 8 8
T Planning of coaching and training 8 8
T Planning and set-up tools and tool infrastructures 8 8
T Experiences regarding “deployment traps” 8 8 8
SPLC: Management and continuous improvement
T Process management in the context of continuous improvement (overview) 8 8 8
T Introduction to continuous improvement (i.e. PDCA/Deming cycle [33]) 8 8 8
T Assessment/Audit/Certification for individuals, projects, and companies 8 8
T/S Selected models in detail (CMMI + Scampi [34], SPICE [29], Six Sigma) 8 8
T Planning and managing an improvement program 8
Software process metamodels and tools
S ISO 24744 (metamodel only [35]) 8 8
S SPEM (metamodel and tools, i.e. EPF, incl. hands on [36]) 8 8
S V-Modell XT (metamodel and tools, incl. hands on [26]) 8 8
T Overview empiric research (e.g., questionnaires, surveys goals, how to’s) 8 8
P Planning and performing an assessment 8 8
Criterion Winter semester Winter semester Result
2010/2011 2011/2012
Number of answered questionnaires 6 8
Common criteria (1 = very high, 5 = very low)
Complexity 3.00 (old questionnaire: “level”) 2.38 +0.62 "
2.83 (old: one question)
2.12 +0.71 "
Speed 2.75 +0.08
Appropriateness of effort compared to ECTS points n.a. 3.00 (fair) n.a.
Overall rating (1 = very good, 5 = very bad)
Lecture 1.25 1.5 -0.25 %
Exercise 2.17 1.33 +0.84 "
Relation to practice 2.0 1.62 +0.38 1
In the following, we describe the evaluation of our course.
Since we took into account the requirements stated in Sect. III,
we omit the inference of formal criteria for their evaluation.
This evaluation is inherently covered by the mapping shown
in Table II. Instead, we rely on a formal evaluation predefined
by our faculty and an informal evaluation directly performed
anonymously by the students.
A. Formal Evaluation
The faculty performs a formal evaluation, usually in the last
third of the semester. Since we gave the lecture twice (first
run in the classic fashion, second run in the new format), we
can compare both runs. Due to updated questionnaires, the
evaluations are not directly comparable. However, the basic
information can still be extracted. The questionnaires are very
comprehensive (8-10 pages) and contain questions regarding
the lecture itself, the exercises, certain fine-grained aspects,
such as evaluation of the lecturer, reasons for having missed
some lectures, and so on. Regarding our requirements, we are
especially interested in the following questions:
1) Did we manage to give a lecture in the new format, which
stays on the same high level than before?
2) Did we get the students better motivated by the new style
of the exercises (practical parts/labs, more interaction and
so on)?
3) Were we able to sensitize the students about the practical
relevance of process modeling?
To answer those questions, we analyzed the formal faculty
questionnaires for appropriate criteria. Table IV shows the
selected criteria.
Since not all students were present when making the eval-
uation, we have only few answered questionnaires (6 out of 9
from the first run, 8 of 14 form the second run) and, thus, those
are not subject to quantitative analyses. The questionnaires,
however, give answers to our questions. The selected common
criteria show that the level of the lecture not only stays high
(3 is the average in the scale), but also increases. Although
changing the style of running this lecture, all common criteria
show a (slight) improvement.
To answer the other questions, we identified three questions
in the questionnaire that give an overall rating w.r.t. the lecture
itself, the exercises, and the relation to practice. In the overall
rating the lecture itself stays on a very high level while, at the
same time, the rating of the exercises increases significantly.
Our last question, whether we could better sensitize the
students for the practical relevance of process modeling, also
shows that the new format has to be considered successful.
Summarized, the ratings show that, in the second run, the
lecture stays at a high level, but the quality of the exercises
increases significantly whereby we have to consider that the
students see the lecture also as more demanding. By introduc-
ing the new format that is focused on workshops and creative
work rather than on classic exercises, students got closer to
practice and, thus, could gather experiences.
B. Informal Evaluation
In addition to the formal evaluation, we also performed an
informal evaluation twice: the first evaluation after the first
third of the lecture and a second evaluation at the end of
the lecture. The evaluation consists of a one-minute-paper-like
feedback. Each student should briefly fill out a small sheet of
paper that covers the following aspects:
1) (up to 5) points that are positive
2) (up to 5) points that are negative
3) (up to 5) points that I still wanted to say (informal)
The structure of the class, the selected topics, the combination
of theory and practice, the way of continuously evaluating
the work and finding the final grades were rated positively.
Especially the the practical projects and the team work in the
workshops was highlighted. On the other hand, the students
mentioned the tough schedule and the not always optimal
tailoring of the tasks for the practical sessions. Also, the stu-
dents wished to have more feedback loops w.r.t. presentation
techniques and self-reflection.
Since we informed the students about the “experimental”
character of this special course in advance, the students did not
complain, but welcomed the opportunity to give the feedback
to improve their own class.
C. Experiences Made in Munich
We implemented the course twice (Munich: in 2010 in the
classic format and in 2011 in the new format) and compared it
to an equivalent course at the University of Helsinki (classic
format with experience-oriented exercises). Since we imple-
mented the course twice, we can compare both runs as well
as draw some conclusions from our experiences.
Our experiences are two-fold: on the one hand, we can judge
the teaching format itself, which we already did in [14]; on
the other hand, we especially can compare the lecture runs
according to, e.g., the level or the content. Fundamentally,
our experiences are quite well reproduced by the faculty’s
evaluation, which is summed up in Table IV.
In addition to those ratings, we want to highlight the
following experiences. In the following, we summarize our
1) Real World Example: We experienced that the choice of
a real world example rather than a synthetical toy example
has proved to be successful. For this class, we have been
provided with the software process by the “Special Interest
Group Software Processes” of the German Computer Society.
The objectives of the workshops were to analyze this given
process, to define several improvements, and to implement
the design into two given software process frameworks (see
also Table III). Our acceptance criteria (complete design
documentation and process implementation) were achieved.
Also, the process owner was satisfied giving us the feedback
that he did not expect the student groups to create “such a
comprehensive solution in this little time.
2) Decisions & Consequences: Another goal—“let students
experience the consequences of their decisions”—was also
achieved. While implementing the process in the workshop,
we could observe a certain learning curve. For instance, one
team had a complete design, but selected an inappropriate
modeling concept in the Eclipse Process Framework [21].
The shortcomings became obvious when they tried to connect
content packages and the delivery process, which was not
supported the way the group thought it would be. The group
had to refactor the implementation, which was an annoying
and time-consuming task, both increasing their awareness on
the consequences of certain design decisions.
3) Forming a Team: Another, not explicitly defined, goal
was also achieved. Because of the team work, the considerable
share of independent work and interaction in the class we
formed working team. We observed the students improving
their communication and collaboration skills. Much of the
work was done due to intrinsic motivation of the teams.
4) Exams: We compared the final grades of both lectures
and recognized significantly better grades in the second run.
During the exams, the students could not only answer all (the-
oretical) knowledge-related questions, but also all knowledge
transfer and application-related questions. The students usually
referred to the practical examples and were able to transfer and
apply their experiences to new situations.
D. Experiences Made in Helsinki
In the course at the University of Helsinki, different types
of practical assignments were used. Among more traditional
exercises aiming at knowledge transfer, assignments such
as process programming, process elicitation, and exploratory
tasks were given to the students.
1) Application of Modeling Paradigms: Process program-
ming was one of the topics of the practical assignments at
the University of Helsinki. The students were asked to model
different processes by using a formal notation. The students
were able to better understand the level of detail of the required
information (such as product or control flow information) that
is necessary to formalize software processes. In addition, the
students were asked to create process models for creative
processes as well as for processes that can be fully automated.
This supported, on the one hand, a better understanding of the
typical characteristics of creative software processes and their
differences to processes that are better suited for automation.
On the other hand, students could experience that different
types of processes require different modeling paradigms (such
as a constraint oriented or an imperative paradigm).
2) Utilization of Elicitation Techniques: Another topic of
the practical assignments at the University of Helsinki was
process elicitation techniques. The students got interview
transcripts from practitioners describing their activities in real
projects. The students were asked to extract relevant process
modeling concepts such as roles, artifacts, and responsibilities.
This improved the understanding of the challenges when
extracting process knowledge from real projects via interviews.
The students experienced how difficult it is to transform
informal information or tacit knowledge into process models.
The students could also see how difficult it is for individuals
to formulate their behavior in a rule-oriented manner.
3) Suitability of Process Models for Different Contexts:
The course at the University of Helsinki included several ex-
ploratory assignments. The students were asked, for instance,
about empirical evidence on the effects of specific processes
in a certain environment (e.g., what kind of evidence exists for
model-based testing w.r.t. its impact on reliability of the tested
software in the automotive domain). These kind of exploratory
tasks helped the students to see how many aspects are involved
in process modeling and management. They also understood
that there is not always only one solution or one best solution
but that the choice of the most suited solution it depends
usually on the context. The course used a conversation-based
style for the exercises so that different students could present
their solutions. The solutions were discussed afterwards. For
some students it was surprising to see that typically several
solutions are acceptable.
In the following, we give a brief summary of conclusions
and the implications we see in our course concepts, before
concluding with an outline of future work.
We discussed the problem of missing to effectively prepare
students for industrial life. Based on feedback from our
industrial partners and our own experiences, we identified the
missing education in software processes (and modeling) as a
major shortcoming. Based on experience exchanges between
the University of Helsinki and the Technische Universit
unchen, we analyzed existing curricula, critically discussed
our existing lectures on this topic, and derived key require-
ments courses on software process modeling should satisfy.
We checked our courses against the proposed requirements
and decided to design a new course concept having a new
format to cope with the problems stated above.
The new concept allows for teaching the basic concepts
of software process modeling with realistic scenarios at a
realistic level of complexity supporting, for example, learning
curves while establishing a differentiated knowledge about
different modeling approaches. We evaluated our new lecture
against our requirements by conducting a formal evaluation
that follows our faculties standards and by conducting an
informal evaluation in which the students directly rated the
course. The direct comparison of our new teaching format
with the classical format applied in previous terms showed, for
example, a significant improvement of the exercises’ quality
and the relation of the contents to practice.
We consider this kind of lecture format to be successful
for not only the field of software processes, but also for other
software engineering fields. For the winter term 2012/2013 at
the Technische Universit
at M
unchen, we are already conduct-
ing a lecture on agile project management methods following
the same format
. Since we are confident of the suitability of
the introduced concepts for teaching topics with a generally
practical application field, it is further planned to replicate the
format at courses with a completely different topic, e.g., in
the area of empirical software engineering. Our course thus
directly impacts on our own teaching curricula implemented
in two different universities.
The contributed course concepts, the provided exemplary
content map, and the experiences provided in this paper allows
other lectures to optimize their own courses in the field of
software process modeling. Furthermore, it also supports the
establishment and optimization of courses on other topics that
demand to apply practical examples, to experience real world
problems, and to learn how to deal with those problems in a
differentiated manner.
The presented course is a first experimental implementation
step towards optimizing our courses on software process
modeling. For this reason, we are working on extensions of our
concepts in response to feedback from academia and industry,
and on the transfer of the concept to other topics such as
agile project management. Furthermore, we are planning a
family of observational studies to investigate the effects this
course has when being applied in other contexts or to a larger
number of students. We thus cordially invite the reader to join
Lecture Agile Project Mangement & Software Development”, winter term
2012/2013, master‘s level,
ws1213/index.shtml; material available on request
the continuous improvement of the concepts and the future
empirical investigation of the effects this teaching format has.
[1] Humphrey, W. S., Konrad, M. D., Over, J. W., and Peterson, W. C.,
“Future directions in process improvement, Crosstalk The Journal of
Defense Software Engineering, vol. 20, no. 2, 2007.
[2] M
unch, J., Armbrust, O., Soto, M., and Kowalczyk, M., Software
Process Definition and Management. Springer, 2012.
[3] W. S. Humphrey, PSP(SM) - A Self-Improvement Process for Software
Engineers. Addison-Wesley, 2005.
[4] Rombach, D., M
unch, J., Ocampo, A., Humphrey, W. S., and Burton,
D., “Teaching disciplined software development, International Journal
of Systems and Software, vol. 81, no. 5, 2008.
[5] Kamsties, E. and Lott, C., An empirical evaluation of three defect-
detection techniques, in 5th European Software Engineering Confer-
ence, 1995.
[6] Deiters, C., Herrmann, C., Hildebrandt, R., Knauss, E., Kuhrmann,
M., Rausch, A., Rumpe, B., and Schneider, K., “GloSE-Lab: Teaching
Global Software Engineering, in Proceedings of 6th IEEE International
Conference on Global Software Engineering. IEEE, 2011.
[7] Keenan, E., Steele, A., and Jia, X., “Simulating Global Software
Development in a Course Environment,, in International Conference
on Global Software Engineering (ICGSE). IEEE, 2010.
[8] Richardson, I., Milewski, A. E., and Mullick, N., “Distributed Devel-
opment an Education Perspective on the Global Studio Project, in
International Conference on Software Engineering (ICSE). ACM, 2006.
[9] Huang, L., Dai, L., Guo, B., and Lei, G., “Project-Driven Teaching
Model for Software Project Management Course, in International
Conference on Computer Science and Software Engineering. IEEE,
[10] Dahiya, D., “Teaching Software Engineering: A Practical Approach,
ACM SIGSOFT Software Engineering Notes, vol. 35, no. 2, 2010.
[11] Bavota, G., De Lucia, A., Fasano, F., Oliveto, R., and Zottoli, C.,
“Teaching Software Enginerring and Software Project Management:
An Integrated and Practical Approach, in International Conference on
Software Engineering (ICSE). IEEE, 2012.
[12] P
adua, W., “Measuring complexity, effectiveness and efficiency in
software course projects, in International Conference on Software
Engineering (ICSE). ACM, 2010.
[13] Ocampo, A. and M
unch, J., “Rationale modeling for software process
evolution, International Journal on Software Process: Improvement and
Practice, vol. 14, no. 2, 2009.
[14] Kuhrmann, M., “A Practical Approach to align Research with Master’s
Level Courses, in 15th International Conference on Computational
Science and Engineering. IEEE, (to appear) 2012.
[15] Dukovska-Popovska, I, Hove-Madsen, V., and Nielsen, K. B., “Teaching
lean thinking through game: Some challenges, in 36th European Society
for Engineering Education (SEFI) on Quality Assessment, Employability
& Innovation, 2008.
[16] M
unch, J., Pfahl, D., and Rus, I., “Virtual software engineering labora-
tories in support of trade-off analyses, International Software Quality
Journal, vol. 13, no. 4, 2005.
[17] Joint Technical Committee ISO/IEC JTC 1, Subcommittee SC 7,
“Systems and software engineering Software life cycle pro-
cesses, International Organization for Standardization, Tech. Rep.
ISO/IEC 12207:2008, 2008.
[18] ISO TC22/SC3/WG16, “Road vehicles Functional safety, Interna-
tional Organization for Standardization, Tech. Rep. ISO 26262:2011,
[19] IEC, “Medical device software Software life cycle processes, Interna-
tional Electrotechnical Commission, Tech. Rep. IEC 62304:2006, 2006.
[20] Mendez Fernandez, D., Penzenstadler, B., and Kuhrmann, M., “Pattern-
Based Guideline to Empirically Analyse Software Development Pro-
cesses, in 16th International Conference on Evaluation & Assessment
in Software Engineering, 2012.
[21] Eclipse Foundation, “Eclipse Process Framework (EPF), Online, http:
//, 2010.
[22] Armbrust, O., Ebell, J., Hammerschall, U., M
unch, J., and Thoma, D.,
“Experiences and results from tailoring and deploying a large process
standard in a company, Software Process: Improvement and Practice,
vol. 13, no. 4, 2008.
[23] K. Schwaber, Agile Project Management with Scrum. Microsoft Press,
[24] K. Beck, Extreme Programming. Addison-Wesley, 2003.
[25] P. Kruchten, The Rational Unified Process: An Introduction, 3rd ed.
Addison-Wesley Longman, 2003.
[26] Federal Ministery of the Interior, “V-Modell XT Online Portal, Online,
2010. [Online]. Available:
[27] S. Brinkkemper, M. Saeki, and F. Harmsen, “Meta-Modelling Based
Assembly Techniques for Situational Method Engineering, Information
Systems, vol. 24, no. 3, 1999.
[28] R. Kneuper, CMMI: Improving Software and Systems Development
Processes Using Capability Maturity Model Integration (CMMI-Dev),
1st ed. Rocky Nook, 2008, no. ISBN: 978-3898643733.
[29] van Loon, H., Process Assessment and ISO/IEC 15504: A Reference
Book. Springer, 2007.
[30] ISO 9000:2005. Quality Management Systems Fundamentals and
Vocabulary. International Organization for Standadization, 2005.
[31] Office of Government Commerce, ITIL Lifecycle Suite 2011. The
Stationery Office Ltd., 2011.
[32] D. Rombach, “Integrated Software Process and Product Lines, in
International Software Process Workshop (SPW), ser. Lecture Notes in
Computer Science. Springer, 2005.
[33] Deming, W. E., Out of the Crisis, 2nd ed. MIT Press, 2000.
[34] SCAMPI Upgrade Team, “Standard CMMI Appraisal Method for
Process Improvement (SCAMPI) A, Version 1.3: Method Definition
Document, Software Engineering Institute, Carnegie Mellon University,
Tech. Rep. CMU/SEI-2011-HB-001, 2011.
[35] Joint Technical Committee ISO/IEC JTC 1, Subcommittee SC 7,
“Software engineering metamodel for development methodologies,
International Organization for Standardization, Tech. Rep. ISO/IEC
24744:2007, 2007.
[36] OMG, “Software & Systems Process Engineering Metamodel Specifi-
cation (SPEM) Version 2.0, Object Management Group, Tech. Rep.,
[37] W. S. Humphrey, “The software process: Global goals, in International
Software Process Workshop (SPW), ser. Lecture Notes in Computer
Science. Springer, 2005.
[38] A. Goodman, Defining and Deploying Software Processes. Auerbach
Publishers Inc., 2005.
... Krusche et al. [8] found that approx. 40% of the students struggle to find the correct model for a task, which is in line with our findings [10]. Such issues can be tracked back to the following reasons: the solution space is large, the modeling techniques are manifold, the number of modeling tools is high and, finally, a model can be created for different purposes, e.g., communication or code generation. ...
... Description. This case study was conducted in the course Software Process Engineering [10], which was offered several times ( Table 1). The key objective of the course is to enable students to understand software processes and their role in organizations and projects, to analyze organizations and projects, to develop proper processes to support their development endeavors and, finally, to assess the suitability of process models. ...
... Besides general information about traditional, agile and hybrid development methods, students use a structured process development and improvement model, which structures the course and provides a guideline through the different steps, i.e., process analysis, process conceptualization and design, process deployment and enactment, and process improvement. While the basic course outline as presented in [10] was kept stable, in 2020, the Covid-Pandemic forced us to adjust the course to address the changed teaching requirements, i.e., online teaching. This enabled us to implement the case study as part of the online teaching and examination procedures. ...
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.
... 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 APM and SQM courses require the students to have profound knowledge in software development practices, i.e., coding and (optionally) software testing. As a "specialty", the SEP course was implemented twice: the first edition was organized using a classic course model, i.e., lectures and exercises, while the second edition was implemented using experiments [16], [18]. We discuss this in the evaluation of our teaching approach in Section IV-A1. ...
... The instrument is a set questionnaires that comprises a formal course evaluation (quantitative) and another "1-minutepaper" like evaluation (qualitative). Due to space limitations, we omit the full instrument, which can however be taken from our previously published papers [14], [16], [18]. In the following, we provide an aggregation of the findings from the three courses presented above. ...
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.
... Less attention has been paid to using empirical studies with an educational purpose in mind, where the experiment has an explicit didactic or experiential role. Few curricula are available that include the execution of empirical studies as an integral part of a lecture (e.g.,Kuhrmann, Fernández & Münch, 2013;Hayes, 2002). The use of students as experimental subjects has often been discussed in the literature. ...
... 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 different modelling paradigm. ...
... Making contact with industry and the prospects of finding a job or starting a company, foster students' motivation to actively participate in courses, and may contribute to higher motivation, engagement, and better understanding of course contents. For instance, inKuhrmann, Fernández & Münch (2013), we reported on a new teaching format applied to a software process modelling course, including an empirical study. The course evaluation showed that students experienced the course significantly better than the class before (without the study), although they perceived the course as more demanding (see 'Example 1: a course on software process modelling with and without experiments'). ...
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.
... One of the reasoning for this is that despite numerous benefits, teaching SPM is not an essential part of the software engineering course and it only marginally included in a typical software engineering course. Several researchers have reported their experiences in learning and teaching software process models in the classrooms (e.g., [8] [9][10]), and outlined recommendations and challenges encountered. Dubinsky et al. [11] and Hazzan et al. [12] suggested a set of principles for teaching process models based on their experiences. ...
... Several efforts have been reported earlier regarding the teaching and learning of process models to the software engineering students. In their study, Kuhrmann et al. [9] designed a Master's level course to teach the students about process models and their importance in software development. Additional knowledge about the analysis, design, and implementation of process models during software project development was also included in the course. ...
... The paper at hand contributes a course design for an empirical software engineering course and experiences from a first implementation. The overall design follows an approach that brings teaching closer to research [27] , and that was successfully applied to different methodical topics, in particular software process modeling [24] and advanced project management [26]. Different that the other implementations of the base concept, the course presented in the paper at hand addresses large classes (50+ students). ...
... [1, 33] ). And it must not be questioned that empirical instruments provide a good basis to organize whole courses or individual sessions, e.g., [24, 26]. ...
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.
... Factors, Agility Experimentation in Software Engineering education is usually used at the level of engineering processes, i.e., quality assurance and test [13,16], Global Software Engineering (GSE; [17,25]), process modeling [20,22], or Software Engineering in general, e.g., [4,9,23]. Finally, newer approaches integrate (continuous) experimentation and close collaboration between academia and industry with the principles of Lean software and product development, e.g., [11,21]. ...
... We present the overall design of the course "Agile Project Management & Software Development" (APM), which follows the pattern presented in [19,20]. Figure 1 illustrates the general course organization and the course's content. ...
Conference Paper
Full-text available
Software development consists to a large extend of human-based processes with continuously increasing demands regarding interdisciplinary team work. Understanding the dynamics of software teams can be seen as highly important to successful project execution. Hence, for future project managers, knowledge about non-technical processes in teams is significant. In this paper, we present a course unit that provides an environment in which students can learn and experience the impact of group dynamics on project performance and quality. The course unit uses the Tuckman model as theoretical framework, and borrows from controlled experiments to organize and implement its practical parts in which students then experience the effects of, e.g., time pressure, resource bottlenecks, staff turnover, loss of key personnel, and other stress factors. We provide a detailed design of the course unit to allow for implementation in further software project management courses. Furthermore, we provide experiences obtained from two instances of this unit conducted in Munich and Karlskrona with 36 graduate students. We observed students building awareness of stress factors and developing counter measures to reduce impact of those factors. Moreover, students experienced what problems occur when teams work under stress and how to form a performing team despite exceptional situations.
... For instance, software engineering courses at the university usually consist of lectures along with a small software project [12], but software process is often treated as an additional module to the core curriculum. Trainings in an industry environment are, on the other hand, organized in a workshop style with theoretical and practical parts interwoven [13]. Although ISO/IEC 29110 is well-structured and described in great details in the guides, it is a technical text on complex subject. ...
Conference Paper
Full-text available
The software development industry is dominated by a myriad of smaller organizations world-wide, including very small entities (VSEs), which have up to 25 people. Managing software process is a big challenge for practitioners. In 2011, due to the VSEs’ increasing importance, a set of ISO/IEC 29110 standards and guides were released. Although other initiatives are devoted to small entities, ISO/IEC 29110 is becoming the widely adopted standard. But it is an emerging standard and practitioners need to be actively engaged in their learning. In this sense, serious games offer the potential to entertain and educate. This study shows empirical evidence to support the overall applicability of the game proposed as learning tool. Moreover, the results indicate that the learning tool creates a positive experience, and therefore could be used as a strategy to promote the standard.
... The course "Agile Project Management & Software Development" (APM; [18], [19]) follows the pattern presented in [20], [21], and is illustrated in Figure 1 that shows the general course organization and content. The course consists of 4-hour sessions and comprises three phases: In phase 1, the scene is set, topics are introduced, and students are assigned their "special topics", which they have to prepare for phase 2. In the second phase, the course pattern changes: instead of "classic" lectures and exercises, the sessions follow a workshop model, whereas the workshops are composed of lecture-and exercise parts to which students actively contribute by presenting their "special topics", and the workshops also contain creativity tasks and discussion rounds. ...
Conference Paper
Full-text available
Software development consists to a large extent of human-based processes with continuously increasing demands regarding interdisciplinary team work. Understanding the dynamics of software teams can be seen as highly important to successful project execution. Hence, for future project managers, knowledge about non-technical processes in teams is significant. In this paper, we present a course unit that provides an environment in which students can learn and experience the role of different communication patterns in distributed agile software development. In particular, students gain awareness about the importance of communication by experiencing the impact of limitations of communication channels and the effects on collaboration and team performance. The course unit presented uses the controlled experiment instrument to provide the basic organization of a small software project carried out in virtual teams. We provide a detailed design of the course unit to allow for implementation in further courses. Furthermore, we provide experiences obtained from implementing this course unit with 16 graduate students. We observed students struggling with technical aspects and team coordination in general, while not realizing the importance of communication channels (or their absence). Furthermore, we could show the students that lacking communication protocols impact team coordination and performance regardless of the communication channels used.
... De acordo com Reis (2000), esta fase ocorre quando um modelo de processo está pronto para execução, ou seja, o processo deve estar instanciado, e que leva em consideração a coordenação dos desenvolvedores, a interação entre as ferramentas e desenvolvedores, a garantia de que o processo está sendo executado conforme modelado, dentre outras questões. Um dos conceitos que se destaca nessa fase é o Mecanismo de Execução de Processos ou Máquina de Processo, principal foco deste trabalho, que consiste na interpretação do modelo de processo instanciado de acordo com a semântica da linguagem de modelagem, gerenciando as informações do ambiente e orientando os desenvolvedores de acordo com este modelo [Huff, 1996]. Um dos principais objetivos desse mecanismo é manter o estado da execução do processo consistente com o estado real da realização das tarefas. ...
Conference Paper
Full-text available
This paper presents a work related to the software processes enactment based on the recommendations contained in quality models and norms: CMMI, MPS.BR and ISO/IEC 12207. From this work, it aims to define a process framework to specify and implement a free software tool to support the software processes enactment adherent to these models. This tool will be developed in the context of the SPIDER Project, continuing the researches related to PSEEs (Process-Centered Software Engineering Environments). Resumo. Este artigo apresenta um trabalho relacionado à execução de processos com base nas recomendações constantes em modelos e normas de qualidade: CMMI, MPS.BR e ISO/IEC 12207. A partir deste trabalho, pretende-se definir um framework de processo para especificar e implementar uma ferramenta de software livre de apoio à execução de processos de software aderente a estes modelos. Esta ferramenta será desenvolvida no contexto do Projeto SPIDER, dando continuidade as pesquisas relacionadas à PSEEs (Process-Centered Software Engineering Environments). 1. Caracterização do Problema À medida que os sistemas de informação e os produtos computacionais tornaram-se componentes comuns do dia-a-dia das pessoas, os softwares passaram a ganhar mais espaço na vida delas, tornando-se indispensáveis. E, à medida que as tecnologias evoluem, o nível de exigência dos usuários também evolui, aumentando a complexidade dos requisitos e influenciando na maneira como os softwares são desenvolvidos. Com objetivo de solucionar estes problemas e buscando aumentar a qualidade de software, a Engenharia de Software tem produzido ferramentas a fim de auxiliar o desenvolvimento de software, assim como estudado e produzido formas de controlar o processo de desenvolvimento [Reis, 2003]. Neste contexto, destaca-se a área de Tecnologia de Processos de Software, que envolve a construção de ambientes para modelagem, execução, simulação e evolução de processos de desenvolvimento de software.
As systems become larger and more complex, and as increasing numbers of development programs are integrated and distributed, development processes, methods, and management must change. To keep pace with these changes, the directions of process improvement must also change. This article describes the likely future directions of process improvement evolution.
Conference Paper
The Global Studio Project integrated the work of Software Engineering students spread across four countries into a single project and represented, for most of the students, their first major "real-world" development experience. Interviews indicated that the major areas of learning were informal skills that included learning to establish and work effectively within a team, learning how to react quickly to frequent changes in requirements, architecture and organization, and learning to manage and optimize communications. Since all these skills require rapid reaction to unpredictable factors, we view them as improvisation and discuss the role of experiential education in facilitating improvisation.
Extreme Programming (XP) is a lightweight design method developed by Kent Beck, Ward Cunningham, and others. After notable successes, XP has been generating huge interest, and no small amount of controversy. Much of the interest stems from XP's pragmatic approach to development. Key practices include pair programming, writing tests upfront, frequent refactoring and rebuild, continuous integration and testing. Key principles incremental and iterative development, working with the simplest solution, cutting out extraneous documentation, and collective code ownership.