The work-reflection-learning cycle - Department of Computer and ...

Due to the openness of OSS communities, students may use them as
an environment for learning which is interactive, ‘real’ and outside
the university. OSS development has been acknowledged both as a
means and as an objective of learning in SE education. Whereas the
number of studies reporting lessons learned from students’
participation in OSS development is still limited, experience and
lessons learned from student projects have been reported (e.g. [19,
20]). Toth [20] lists the following benefits of using and extending
OSS tools in student SE projects: a baseline of such tools
automatically gives a ‘critical mass’ to the projects, the tools can
freely be extended, using OSS is engaging for students, students
may evolve their own tools (‘eating their own dog food’), and
students increase their value in the job market. Spinellis [21] points
to the following benefits of working with OSS in general: increased
industry contacts, professional maturation, improved skills in
written communication, experience with system administration, and
exposure to management approaches. These are benefits equally
relevant to SE and CS students as to SE professionals. Jaccheri and
Østerlie [22] demonstrated that students may learn from an action
research approach to participation in OSS development, resulting
both in familiarity with action research and improved capabilities in
programming and design. Ellis et al. [19] mention possible
disadvantages of using OS projects as a basis for SE education: lack
of documentation, inconsistent coding standards, and inconsistent
quality.
Lessons learned and guidelines emerging from current studies on
student projects engaging in OSS communities generally address the
pedagogical organization of SE project courses in which students’
primary development task is itself OSS development. There is
however a lack of research on (i) ways in which the OSS
community might be an important source of knowledge relevant to
the students’ development task without being its main arena, and (ii)
pedagogical issues arising from such a setting. This is where this
paper aims to contribute.
3. OUR CASE
The particular SE project investigated in this work is part of an
undergraduate level course at a Norwegian technical university. The
students take the course in the final semester of their Bachelor
program, i.e. their 6 th semester. The students work in mostly selfformed
teams of 3-5 students, developing software for an external
customer. Students make a prioritized wish list from a number of
available project descriptions mainly provided by industry, and
teams are assigned tasks by course staff according to students’
preferences and skills. The workload of the course is half of the
semester, but students tend to spend more time on the project, giving
it higher priority than parallel courses. In addition to the software
product, the students must hand in a project report (both a
preliminary and a final version) to the customer and course staff.
Also, the teams give oral presentations of their projects halfway
through the semester and at the end of the semester. There are no
lectures in the course except an introductory lecture in which
available projects are presented. Each team receives supervision on
their project process from a member of course staff, usually a
teaching assistant. The customer is responsible for providing
supervision on technical issues when necessary, as well as providing
resources otherwise unavailable to the students (e.g. particular
hardware, software, and physical or virtual workspace). Based on
the course staff’s evaluation and customer feedback through an
evaluation form, each team is given one grade (except in rare cases
where major variation in individual work effort is documented by
the team). The grade is based on a combination of the software
product, the documentation and the project process. The teams are
provided with some templates and guidelines for their work, e.g.
related to project planning, status reporting and contents of the
project report.
There are no general requirements that any particular process
model, analysis/design methodology, development tool or
collaboration technology be used in the projects. Students are
expected to relate to the customer’s requirements and draw on their
skills and resources from previous and parallel courses at the
university. The teams use tools available at the university, provided
by the customer, or otherwise available. When needed and feasible
within the time frame of the project, the teams are expected to get
into new technology as part of their project work.
The student team followed in the case study presented in this paper
consisted of five male students: Ethan, George, Sam, Owen, and
Morgan (names have been altered), all in their twenties. Their
development task was to make an auctioning system for an IT
consultancy company, here called Anniva. The company wanted to
use the system for in-house purposes and as a substitute for an
existing system used by employees to sell items (such as PCs and
bicycles) to colleagues on a private basis. As a secondary objective
for the project, the company wanted the team to make use of a
particular open source Java development framework, here denoted
PLENTI, in making the auctioning system, to see how the
framework could be utilized. The team succeeded in developing the
auctioning system, receiving the grade B on their project. (B is
regarded as a good grade; of the nine project teams in the 2007
semester of the course, there were 2 As, 4 Bs and 3 Cs.) Crucial to
the team’s development work, as will be seen, was their interaction
with the PLENTI developer community.
4. RESEARCH METHOD
The student team of our study was observed during the spring
semester 2007, i.e. over a period of four months. Given the real-life
context, focus on a contemporary phenomenon, lack of control over
events and our intent to explore “how” and “why” aspects of the
setting, a case study was appropriate [23]. Part-time participant
observation was conducted with adherence to principles of
interpretive field research [24]. For the research project at large, data
(mainly documents and interviews) was collected across all teams in
the course. Data for the study reported in this paper originate from
an in-depth study of one particular project team and includes
recordings, field notes and pictures from 15 hours of meetings
between the team and customer/supervisor and 60 hours of teaminternal
work sessions and meetings (mainly in the computer lab),
copies of pages from the team’s wiki, some logged msn
conversations, various project documents from the team’s
workspace, the preliminary and final version of the project report,
all email correspondence going through the team’s email list,
recorded interviews with the team, the supervisor and the customer,
and the threads in the PLENTI user forum (listserv) resulting from
the team’s requests to the forum.
Generally, the researcher was given free access to work sessions and
meetings (participation and recording) as well as to the team’s
server workspace, wiki and email list. The researcher attended all
meetings with the customer, with the exception of a couple of
meetings which were audio recorded for the researcher by a team
793
111