Content uploaded by Burak Turhan
Author content
All content in this area was uploaded by Burak Turhan on Feb 20, 2015
Content may be subject to copyright.
A Template for Real World Team Projects for Highly Populated Software
Engineering Classes
Burak Turhan, Ayşe Bener
Boğaziçi University, İstanbul, 34342 Bebek, Turkey.
{turhanb, bener}@boun.edu.tr
Abstract
Assigning projects of group work in the context of
software engineering courses has become a commonly
used practice in several educational institutions.
Previously reported results examined different aspects
of this approach. The problem is that most studies are
based on relatively small group sizes. In this article a
large scale project template for a class-wide project
that is currently in use in the Department of Computer
Engineering, Boğaziçi University, will be presented.
1. Introduction
A majority of software engineering courses, that
includes group project model, divides the students into
groups of size three to four [1], [4], [5]. But these
projects are the first and the only experiences for the
students before they start working in the industry [1],
[2]. Besides other things, one aim of such courses
should be to prepare the students to the practices that
are employed in the industry. For this purpose,
semester-long class-wide projects seem more
appropriate, even if some of the project work assigned
to students are not very complex [3], [6], [7], [8], [9].
This article presents a project template that is
currently in use in a software engineering course (a.k.a.
Cmpe450) with a class-wide team project. We describe
a case study to share our experiences and lessons
learned from the course. This course is offered in fall
semesters to senior students as the last required course
in the curriculum.
The following section will give brief information
about the course. In Section 3 project selection
preferences will be discussed. Section 4 explains the
project template. Finally the last section gives a
summary and conclusions based on our experiences in
Cmpe450.
2. Structure of the Course
Until 2002, Cmpe450 was a lecture oriented course,
where software engineering theories were taught and
discussed during class hours. Small group projects
were assigned to students, expecting that they should
apply the theory to practice and they were expected to
submit well-documented and working projects at the
end of the semester.
Later, suggestions from new faculty members and
alumni led to the construction of a steering committee
within the department in order to evaluate the course
and to update its content for a better performance. The
committee made contacts with the industry leaders and
the alumni. Taking their needs and concerns into
consideration, the committee decided to increase the
weight of the project that simulates real life.
The syllabus has changed to emphasize the project
in terms of its size, scope, complexity and grading. The
weight in grading is divided as 70% for the project and
30% for the exams (one midterm and a final) and class
attendance.
On the average, 70 students take this course each
fall semester. The academic profile of these students is
quite high representing the top 1% of Turkey in the
central university admissions exam. There is an
instructor who teaches and participates actively in the
planning and management of the term project. There
are also 4 Teaching Assistants (TA’s) who are more
actively involved in the day-to-day project
management. Compared to other ‘four credit’ courses
offered in the department, Cmpe450 gets the highest
human resource allocation. This clearly indicates the
importance given to this course by the Computer
Engineering Department.
The ultimate goal of the course is to prepare the
students to the common real life problems of the
software industry, especially in Turkey. Most of the
graduates are employed by these small to mid size
organizations that have different perceptions of
software engineering standards. We claim that
simulating a chaotic environment will help the students
to build realistic expectations of a work place.
29th International Conference on Software Engineering (ICSE'07)
0-7695-2828-7/07 $20.00 © 2007
In software development industry, companies tackle
three main problems: cost minimization (finishing a
project within budget), tight deadlines (finishing a
project on time) and quality product (delivering the
product with minimum defects). An engineering
approach in software development will help them to
overcome these problems. Therefore, another goal of
this course is to teach students the software
development process as a field of engineering, i.e.
software engineering.
3. Project Selection
Our main principle in choosing and managing the
projects has always been to help students in improving
their independent decision making abilities under
pressure. Contrary to previous work in the literature, in
our case the number of students is relatively high.
Therefore we had to pick more complex projects from
different domains. The project topics included an e-
learning system, a various versions of department
automation portal and a purchase automation system
for the whole university.
3.1. The Customer
Until last year in these projects, the instructor and
the TA’s have played the role of both the customer and
the employer. The customer role was unavoidable,
since these projects were made up by the teaching staff
and a real customer did not exist. All the requirements
was forced by the staff and extended by the potential
users of the software.
Based on our experience we have concluded that it
is not a good practice to take on the role of the
customer. Although we are confident that the projects
have fulfilled the overall goals of the course, each
project that is developed with this methodology failed
in terms of the final product. We think this emerges
from the fact that no matter how good the teaching
team plays the role of the customer, they also have to
be in interaction with the students with the instructor
hat on. This makes it difficult for the students to
perceive the instructors as a customer. While agreeing
with Wikstrand & Börstler on this issue, we did not
lose control over the project specific details [2].
Last year we carefully reviewed the results of
course evaluation forms and alumni survey of the past
three years and as a result we decided to assign a
project with a real customer. Last year’s project was a
complete success in terms of the goals defined,
although the students were completely unfamiliar with
the domain of the project. In this article we will refer to
the last year’s project: purchase automation system. It
is an implementation of very complex and time
consuming paper work of government procurement
processes handled by the Administration and Finance
Department of the university. Government
procurement at the university involves complex
government budgeting rules, tenders for procurement
and interaction of various academic and administrative
departments, and Ministry of Finance with the
Purchasing and Finance department of the university.
All of these interactions were done manually and a lot
of paper and signatures traveled among these parties.
The process was time consuming and prone to errors. It
was also impossible for the senior management of the
university to control the purchases and expenditure
since there was no MIS reporting.
This project was unique in a way that it was the
first project with a real customer from a different
domain in the history of Cmpe450. The final product is
currently piloted by some departments in the
university. The pilot will be gradually expanded to add
more departments every other quarter until at last the
whole university takes advantage of this system. This
development is planned to reach its full length within a
year.
4. Project Template
4.1. Pre-Semester Tasks
Several course meetings are handled among the
teaching staff before the beginning of the semester. A
project is made up from scratch or a potential customer
project is selected considering that the project fits the
complexity constraint.
Once the project is decided upon, the
modularization of the project is handled by the
teaching staff so that the students are randomly divided
into eight groups on the average and each group has a
balanced work load. Two groups are constantly
constructed whatever the project is: the test and the
database groups. Each TA is assigned to two of these
groups.
4.2. Virtual Company Model
Furthermore, the groups are considered as virtual
companies, which are working cooperatively and
developing different modules of a larger project. One
student in each group is chosen as the CEO of that
company (i.e. random, highest GPA, lowest GPA,
remedial graduate students, gender, etc.). Each group
also has a database group correspondent, a test group
correspondent, and an integration committee
correspondent. The integration committee is made up
29th International Conference on Software Engineering (ICSE'07)
0-7695-2828-7/07 $20.00 © 2007
of these correspondents and it is responsible for the
successful integration of the modules developed by
different groups. Other roles that are assigned to
individuals of a group include requirement engineers,
design engineers and coders. Most of the time, we
leave the internal structure of the groups to the
students’ own choices and just advice them to
incorporate these other roles.
Students are announced to submit a CV before the
first lecture. Then short interviews are conducted with
all students to get a hint about in which part of the
project they can work most effectively. These
interviews are taken into consideration while assigning
the students to project groups as if we hire employees
to a software development company in a real life
setting.
Another simulated situation in the project is the
replacement of students during the project. Once in the
project timeline, 1 or 2 people from each group are
exchanged within groups as if some people resigned
and new employees are hired in a real life project.
Test group’s responsibilities include the
configuration and the administration of the project
server, where all source codes and documentation are
stored in a repository, setting the standards for coding
and quality, creating test scenarios from the
requirements document and reporting bugs after
making the unit and integration tests of the software.
The database group is responsible for designing the
database by communicating with other groups,
combining their needs and to supply necessary
interfaces to access the physical database. A strict rule
to follow is not to allow anyone to access the
information about the structure of the database design.
Other groups’ responsibilities vary between projects
and determined accordingly.
In-group communications are handled by regular
meetings and e-mail lists. Inter-group communications
are handled by integration committee correspondents
and web sites for all groups where all documents and
contact info are published.
4.3. Project Schedule
The deadlines are determined in the pre-semester
meetings. We choose to ask for 3 versions of the
software during a 13-week semester. We advise
developing at least 2 versions, where requirements
change slightly. We set the schedule of each group so
busy that no one remains unoccupied. In industry
terms, we do not want anyone at the benches.
Deliverables collected during the project are:
Requirements Analysis Document, Object Design
Document, Software Design Document, Database
Design Document, Standards for Coding and Quality
Document, Test Scenarios Document, Test Results
Documents, User Manual, Installation and
Configuration Guide. These documents are revised
between versions.
A demonstration to the customer is arranged when
the deadline of a version is reached. The comments of
the customer after each demonstration are the highest
factors that affect the project grade.
4.4. Tracking Progress
The progress of the students is observed in the
weekly meetings of groups with their TA’s. In addition
TA’s constantly stay in touch directly with the group
CEO’s. Each member in the group submits weekly
progress reports directly to the TA’s. The CEO of each
group, besides his/ her weekly progress report, submits
another weekly document describing the work done by
the individual members of that group and another
weekly document describing the overall progress of
that group. TA’s are responsible for checking the
consistency of these reports. Furthermore, during some
parts of the lecture hours, students discuss with the
instructor the difficulties that they face along the
project.
4.5. Grading
At the beginning we announce that our primary
goals are customer satisfaction and a product that
works. If the customer is unhappy and/or the product
does not work, nobody passes this class. On the other
hand we declare that if the customer is happy and there
is a working product no one will get a grade below B
unless he/she receives a highly negative 360 degree
evaluation of their colleagues. Our aim is to emphasize
that no matter how good the code is if the product does
not work and/or the customer is unhappy a software
development company can not get its money. Another
point is that we are all the same team and we work for
the same goal and success. If there is a problem in one
of the groups the CEOs should have a quick meeting
and employ crises management in order to complete
the project. Otherwise everyone will fail or the
company will bankrupt in real life.
In order to differentiate top performers, we employ
a 360 degree evaluation within the teams such that
everyone ranks their co-worker and the CEO in terms
of their performance and contributions to the project.
At the end of the semester, Each TA has the sufficient
information about the students in his/her group for
evaluation. These are incorporated with the customer
comments, exam grades, CEOs’ evaluations of his/ her
group and the within-group evaluations in order to
29th International Conference on Software Engineering (ICSE'07)
0-7695-2828-7/07 $20.00 © 2007
shape the overall grades. If a student ranks everyone
equally, we discard that student’s rankings.
5. Summary and Conclusions
This article presented a template, which is detailed
in Section 4, for managing a real world project for a
software engineering course. After four years of
experience the following patterns are observed in each
semester’s course projects:
• The first demonstrations are total disasters.
Students can not realize what they are into in
such a short period of time. It is after the first
demonstration that they realize the severity of
the expectations and what failure means.
• There are always ‘heroes’ of the projects who
take big responsibilities and carry on the
project. At least one of the CEO’s turns out to
be a hero.
• Most students develop the ability to make quick
decisions in critical times in such a chaotic
environment.
• It is much better to find a real customer than to
play the role of one.
• No one wants or dares to continue to work on
the project after it is delivered. So the
documentation should be very precise to enable
hiring an administrator for the final product.
• It is too hard and often not applicable to map
the theory and the practice part of the course.
• TA’s are highly utilized with lots of face to
face conversations and e-mails per day.
We have seen that in the 360 degree evaluations
there are a few students with outstanding performance
(i.e. heroes) and also a few students with no
contribution at all. The rest and the majority of the
students were average performers. We believe that
these results are quite similar to real life conditions.
We are keeping in touch with the students who have
graduated in previous years. We conduct face to face
meetings with them to gather feedback about their
opinion. The preliminary feedback suggests that after a
few years of work experience in the real world, the
graduates appreciate what they learn in this class and
the overall project experience.
Following the described template, a working
software project is developed and it is being used as a
pilot project. Next semester’s project will be to
implement an inventory management system by taking
the purchase automation software as the nucleus
application. Hopefully this software will become a
centralized source of automation within the university.
Future work includes reporting the results of alumni
feedback and to update the template if necessary.
References
[1] M. Brian Blake, ‘A Student-Enacted Simulation
Approach to Software Engineering Education’, IEEE
Transactions on Education, Vol.46, No.1, 2003 pp.124-132.
[2] G. Wikstrand and J. Börstler, ‘Success Factors for Team
Project Courses’, In Proceedings of the 19th Conference on
Software Engineering Education & Training (Cseet'06) -
Volume 00, Washington, DC, 2006, pp. 95-102.
[3] Joseph M. Clifton, ‘An Industry Approach to the
Software Engineering Course’, In Proceedings of the 22
nd
SIGCSE Technical Symposium on Computer Science
Education, ACM Press, New York, NY, 1991, 296-299.
[4] James E. Tomayko, ‘Teaching Software Development in
a Studio Environment’, In Proceedings of the 22
nd
SIGCSE
Technical Symposium on Computer Science Education, ACM
Press, New York, NY, 1991, pp. 300-303.
[5] James E. Tomayko, ‘Teaching a Project Intensive
Introduction to Software Engineering’, Special Report SEI-
87-SR-1, Software Engineering Institute, CMU, Pittsburgh,
Pa,
[6] Catherine C. Bareiss, ‘A semester project for CS1’, In
Proceedings of the 27
th
SIGCSE Technical Symposium on
Computer Science Education, ACM Press, New York, NY,
1996, pp. 310-314.
[7] Joseph A. Turner and Joseph L. Zachary, ‘Using Course-
Long Programming Projects in CS2’, In Proceedings of the
30
th
SIGCSE Technical Symposium on Computer Science
Education, ACM Press, New York, NY, 1999, pp. 43-47.
[8] Samuel A. Rebelsky and Clif Flynt, ‘Real-World
Program Design in CS2 The Roles of a Large-Scale, Multi-
Group Class Project’, In Proceedings of the 31
st
SIGCSE
Technical Symposium on Computer Science Education, ACM
Press, New York, NY, 2000, pp. 192-196.
[9] E. J. Adams, ‘A Project-intensive software design
course’, in Proceedings of the 25
th
SIGCSE Technical
Symposium on Computer Science Education, ACM Press,
New York, NY, 1993, pp. 112-116.
29th International Conference on Software Engineering (ICSE'07)
0-7695-2828-7/07 $20.00 © 2007
