Yoopeedoo (UPEDU): a process for teaching software process

Abstract

The software engineering process is a growing concern for many
software development organizations. The need for well-educated software
engineers is bringing new software engineering programs to universities.
In many programs, software process education adds up to a few hours of
lectures in an introductory software engineering course. This paper
presents the structure and the content for a full, one-semester course
on software processes, which has been designed in close collaboration
with industry. The course is based on a software process called UPEDU
(Unified Process for EDUcation), pronounced Yoopeedoo, and has been
customized from the Rational Unified Process (RUP) for the educational
environment. Many artifacts derived from a project case study are used
as examples or templates. The content of the course is oriented towards
the cognitive skills needed to perform the various activities required
in the software process

Full text

Page 1

YOOPEEDOO (UPEDU): A Process for Teaching Software Process
Pierre N. Robillard, Ph.D., P.Eng
Ecole Polytechnique de Montréal
C.P. 6079, Station Centre-ville
Montréal, QC, Canada, H3C 3A7
Tel: 514-340-4238, Fax: 514 340-3240
pierre-n.robillard@polymtl.ca

Philippe Kruchten, Ph.D., P. Eng.
Rational Software Canada
650 West 41st Avenue, Suite 638
Vancouver, BC, Canada, V5Z 2M9
pbk@rational.com

Patrick d'Astous, Ph.D., P.Eng.
Ecole Polytechnique de Montréal
dastous@info.polymtl.ca
Published in: 14th Conf. On
Software Engineering
Education and Training,
Charlotte NC, 2001, IEEE
Computer Society, pp. 18-26
Abstract
Process in software engineering is a growing concern for many software development
organizations. The need for well-educated software engineers is bringing new software
engineering programs to universities. In many programs, software process education adds up
to a few hours of lectures in an introductory software engineering course. This paper presents
the structure and the content for a full, one-semester course on software process, which has
been designed in close collaboration with industry. The course is based on a software process
call UPEDU, and has been customized from the RUP for the educational environment. Many
artifacts derived from a project case study are used as examples or templates. The content of
the course is oriented towards the cognitive skills needed to perform the various activities
required of software process.
This material will be published in textbook format with CD by Pearsons in fall 2001.
Keywords: Software process, UPEDU, Software Process Education
1: Introduction
The software process is becoming a major concern in most software development
organizations. SPICE, CMM, RUP and OPEN are the new keywords, and process diversity
has been stressed in a recent issue of the magazine, IEEE Software [1]. Although industries
are relying increasingly on defined process activities in developing their software, very few
computer science and computer engineering programs offer a dedicated course on software
process. Software process is mainly taught as one subject among many in a first or second
course on software engineering [2, 3]. Considering the importance of software process in the
industrial environment, we believe that there is a need for a full course in software process in

Page 2

any software-engineering-oriented program. There are many difficulties associated with
designing a course on software process, however. One of these derives from the immaturity of
a domain which is just 10 years old [4], and another from the number of differing viewpoints
on the meaning of software process.
The first, but highly diffused, expression of interest in software process was manifested in
the SEI’s CMM approach [5]. CMM (the Capability Maturity Model for software
development) is a model designed to assess the maturity of the software processes of an
organization and to identify the key practices required to increase the maturity of these
processes. This view is based on assigning practices to one of five maturity levels. The
purpose of the model is to ultimately derive a maturity level for the organization. The CMM
approach leads naturally to standardization, and is supported by ISO/IEC 15504 - (An
Emerging Standard on Software Process Assessment) [6]. The model is straightforward and
the various sets of practices are based on common sense and empirical evidence. The course
content for approaches such as CMM is purely descriptive, however, and can be taught within
a few hours.
The Personal Software Process (PSP) has been defined as a teaching tool for students who
are improving their software programming skills [7]. This approach defines a series of
improvements to an individual’s development practices to be presented to the student in a
specified order. With this approach, personal data collection is stressed, and improvements are
suggested based on the way in which the data are interpreted. The PSP structure is designed to
fit into a university program and is supported by well-defined exercises. It is very much
oriented towards individual improvement at the construction phase of the software life cycle.
Such an approach will be difficult to follow for software engineers who are less familiar with
coding, like software architects, software managers, software designers and configuration
managers, but who are at the same time very much involved in the software process.
Software process is also linked to methodology, either with a lowercase m or an uppercase
M [8]. Thus, Methodology concerns everything about how a group repeatedly produces and
delivers systems: team, skills, roles, tools, environment, artifacts, techniques, standards,
products, etc. The Methodology includes all aspects of software development, and is therefore
more comprehensive than the software process. Although software engineering students could
benefit a great deal from learning about Methodology, the topic is related more to the
organizational aspect of the environment than to software engineering itself. Industrial
engineering students are more likely to take an interest in Methodology implementation
paradigms. By contrast, a methodology describes a few techniques and drawing notations for a
few roles, such as those of software architects and designers. Many university software
engineering programs offer courses on these ‘small-m’ methodologies, which are called
software design or software analysis courses, and which are sometimes based on formal
notations like UML or Z. These methodologies or design processes are usually only a small
component of what industries call software process.
Software process could also be defined in conjunction with software life-cycle processes [9,
10]. Life-cycle models serve as a high-level definition of the activities that take place during
development. The well-known life cycles are, for example, the waterfall model, the
prototyping model, incremental/iterative development, the spiral model [11]. There are also
life cycle process models, which detail the activities of the life-cycle components. However,
these activities are not ordered or structured within a sequence or time frame. They more or
less constitute the building blocks of the software life cycle [12]. Life cycles are coarse
representations of software activities, while software life-cycle processes are detailed
descriptions of input/output and of the activities of life-cycle sub-process units. This
information is structured in a standard format, like ISO/IEC 12207 and ISO/IEC 15504. This

Page 3

is standard information, which could serve as a very appropriate reference for a course on
software process.
Software process could also be defined as a product, which can be customized by users.
This is the approach embodied in the Rational Unified Process (RUP) [13]. RUP is a Web-
enabled software engineering process, which acts as an e-coach by providing prescriptive
guidelines and templates. This process is designed to fit most organizational needs, and it
must be adapted or configured for the appropriate environment, which means that it is a
framework from which a specific process can be derived.
A course dedicated to software process must go further than a description of key practices,
assessment approaches, the various life cycles and the many methodologies (small m)
associated with software development. The purpose of the course is to enable students to
understand the concepts behind software process, to increase their skills as team members and
to contribute, eventually, to the improvement of their own software process environments. The
main goal is to teach students what constitutes a software process activity, how and why it is
related to other process activities, and what their outcomes are. The main course objective is
to teach the students what they are doing while they build software, rather than listing the types
of activities that can be carried out.
Students have one semester in which they understand the full scope of software process. In
industrial environments, we observe that software engineers are often involved in only a few
activities of a software process at a time. The learning curves of students in software process
activities are steeper than those of professionals.
2: UPEDU
UPEDU (joyfully pronounced Yoopeedoo) is an acronym for Unified Process for
EDUcation. The purpose of this project, which was undertook at the École Polytechnique de
Montréal, is to design a software engineering process containing the main process activities or
the activities that have a significant cognitive content. The objective is to introduce students to
just the right number of software process activities to enable them to understand the role of
software process in software development projects and to have them set aside activities which
are more specific to a given task. Most students have little industrial software development
experience, and many o the process activities have little meaning for them. The students will
better understand these more specific activities later, when they are working in the ‘real’
world. The difficulty is to maintain a good balance in the process activities in terms of the
various conceptual viewpoints they represent. Too many activities could reduce the learning
process to a boring experience, however there should be enough activities to build a software
process, which is of academic interest. Students are aware that the objective of the course is to
learn the principles of software process and not to learn that specific process for its own sake,
as it could never be used in an industrial environment.
2.1: The Physical structure of the UPEDU
In practice, the UPEDU is meant to be a teaching aid, aiming at students in software
engineering in their 3rd or 4th year in a North American curriculum. The UPEDU consists of
several artifacts:
a) A text-book, destined to the student, which contains 13 lessons of software process; we will
describe them below
b) A CD-ROM, which contains supporting material:
•
The UPEDU process itself, in a browsable format.

Page 4

•
•
•
A case study (see below).
Self-assessment questions.
Additional reading on software process: key papers published in this area, or
pointers to where to find them on the web (“cyber-reading”).
Supporting material for professors to build their own course: PowerPoint slides for
each of the 13 classes.
c) A web site, which will contains additional or more up-to-date supporting material for
students and for professors (with controlled access for the latter), as well as discussion
forums for both students and professors.
•
2.2: The process model underlying the UPEDU
UPEDU is an academic customization of the RUP 2000, and we briefly outline here the
major concepts that where used to create it. Like the RUP from which it is derived, the
UPEDU is based on the concept that a software process is a collaboration between abstract
active entities called roles which perform operations called activities on concrete, tangible
entities called artifacts.
Figure 1 depicts this fundamental conceptual model using the UML notation for a class.
Here, a role denotes one of several roles which may be played by an individual (or a small
group of individuals) in the process. In the process, roles perform activities. An activity is a
piece of work executed by one role. The granularity of an activity is usually a few person-
days. An artifact is any piece of information or physical entity produced or used by the
activities of the software engineering process. Examples of artifacts include models, plans,
code, executables, documents, databases, and so on.
















Figure 1 Conceptual model for roles, artifacts and activities

Role
Activity
0..*
0..*
1
1
Performs
Artifact
0..*
0..*
1
1
IsResponsibleFor
0..*
0..*
0..*
0..*
input
Consumes
0..*
0..*
0..*
0..*
Produces
Figure 2 shows the graphical notation used to describe the various process components. A
Process Component is a coherent aggregate of the Process Definition Elements organized from
a given vantage point, such as a discipline (testing, for example) or the production of some
specific artifact (requirements management, for example). The Designer role and the Reviewer
role are different, and Architecting and DetailedDesign are composite work items. A given
role (see, for example, Designer) can work on different work items, artifacts or activities.

Page 5

DesignModel
Designer
+IsResponsibleFor
+performer
Reviewer
+assistant
+performer
+performer
Architecting
DetailedDesign
Review
Initial Design
ProcessComponent
ClassDesign
UseCaseDesign
Figure 2 Graphical notation for process description
Requirements
Use-Case Model
Implementation Model
Implementation
Test Model
Test
Analysis & Design
Design Model
Configuration & Change Mngnt
Project Mngnt
Deployment

Figure 3 UPEDU workflows
Figure 3 presents the workflows and the corresponding main artifacts that have been used to
define UPEDU. Five engineering workflows and two management workflows have been
retained and defined. Business Modeling, Deployment and Environment are workflows of the
RUP process, which have not been kept for UPEDU. The UPEDU workflows are greatly
simplified relative to the original RUP workflows. For example, only 37% of the artifacts are
used in UPEDU, and only 10% of the guidelines. The emphasis of UPEDU is on providing a
software process for learning, which will lead to a good understanding of the software process