Conference PaperPDF Available

A Template for Real World Team Projects for Highly Populated Software Engineering Classes



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.
A Template for Real World Team Projects for Highly Populated Software
Engineering Classes
Burak Turhan, Ayşe Bener
Boğazi University, İstanbul, 34342 Bebek, Turkey.
{turhanb, bener}
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
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
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 otherfour 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 years 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
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
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
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
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
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.
[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.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
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
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,
[6] Catherine C. Bareiss, ‘A semester project for CS1’, In
Proceedings of the 27
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
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
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
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
... Does education affect this issue? Some universities stress project work and try to mimic industry projects (Turhan and Bener 2007) (Fagerholm et al. 2013), and hence students from this type of environment could be better proxies for novice industrial software engineers than students not exposed to such training. Is it possible for students in certain situations to understand the industrial context (Svahnberg et al. 2008), and hence behave similarly to professional software engineers? ...
Full-text available
[Context] Controlled experiments are an important empirical method to generate and validate theories. Many software engineering experiments are conducted with students. It is often claimed that the use of students as participants in experiments comes at the cost of low external validity while using professionals does not. [Objective] We believe a deeper understanding is needed on the external validity of software engineering experiments conducted with students or with professionals. We aim to gain insight about the pros and cons of using students and professionals in experiments. [Method] We performed an unconventional, focus group approach and a follow-up survey. First, during a session at ISERN 2014, 65 empirical researchers argued and discussed the use of students in experiments with an open mind. Afterwards, we revisited the topic and elicited experts’ opinions to foster discussions. Then we derived 14 statements and asked the 58 researchers to provide their level of agreement with the statements. Finally, we analyzed the researchers’ opinions and used the findings to further discuss the statements. [Results] Our survey results showed that, in general, the respondents disagreed with us about the drawbacks of professionals. We, on the contrary, strongly believe that no population (students, professionals, or others) can be deemed better than another in absolute terms. [Conclusion] Using students as participants remains a valid simplification of reality needed in laboratory contexts. It is an effective way to advance software engineering theories and technologies but, like any other aspect of study settings, should be carefully considered during the design, execution, interpretation, and reporting of an experiment. The key is to understand which developer population portion is being represented by the participants in an experiment. Thus, a proposal for describing experimental participants is put forward.
... The prevalence of team projects in IS education is also demonstrated by the large amount of case studies and best practices showing how to use teamwork in a variety of IS courses such as IS and decision support courses (Fellers, 1996), database management systems, and IS analysis and design (Nance, 2000;Poindexter, Basu and Kurncz, 2001;Slyke, Trimmer and Kittner, 1999), e-commerce (Ngai, 2007), introductory programming ( McKinney and Denton, 2006), introduction to computer science (Daigle, Doran and Pardue, 1996;LeJeune, 2003) and software engineering (Bielikova and Navr, 2005;Hilburn, 2000;Hogan and Thomas, 2005;Tadayon, 2004;Turhan and Bener, 2007). ...
Full-text available
The ability to work effectively in teams has been a key competence for information systems engineers for a long time. Gradually, more attention is being paid to developing this generic competence as part of academic curricula, resulting in two questions: how to best promote team competencies and how to implement team projects successfully. These questions are closely interwoven and need to be looked at together. To address these questions, this paper identifies relevant studies and approaches, best practices, and key findings in the field of information systems education and related fields such as computer science and business, and examines them together to develop a systematic framework. The framework is intended to categorize existing research on teams and team competencies in information systems education and to guide information systems educators in supporting teamwork and promoting team competencies in students at the course and curricular level in the context of teaching in tertiary education.
... While collaborative learning is most often used in courses focusing on programming, there is a lot of evidence that this technique is also useful in courses in: computer architecture [8], software engineering [5], [6], [10], database design, project management, multimedia and interface design [11], etc. ...
Conference Paper
Full-text available
Collaboration in contemporary teaching and learning practice can be highly supported and improved via usage of information and communication technology, even when it comes to solving complex team assignments in university courses. One of the possibly best types of software tools for such purposes is wikis. This paper presents the experimental usage of wiki as means of introducing collaborative activities in two completely different courses on the undergraduate level of Computer Science studies -- an introductory eBusiness course for freshmen, and the advanced course in Software Engineering for final year students.
Conference Paper
Developing large-scale software applications in teams has long been a popular feature of capstone courses in computing degree programs, particularly in the fields of computer science and software engineering. Instructors utilize real world problems as well as external clients to motivate the students and to provide authentic experiences. Within the field of game design and development, students have strong desires to make and ship a game or series of games during their collegiate experience. To address this need, we created a production studio course offering that addressed the desires of students to create a game as a culminating experience while focusing upon the production process and challenges that are particular to the game industry. In this paper we describe the process undertaken by students, faculty and staff to ship a game. We discuss the successes and failures of the team and in achieving their goals. We show the similarities and differences between the process of developing and shipping a game and other types of large-scale software design and development projects undertaken in similar courses
Conference Paper
Companies that agree in participating in a project course as paying client usually expect to receive software that can be used actually. However these kind of courses are only able to produce prototypes, so that the client has to make certain modifications to the software in order to reach its production readiness. In this paper we introduce a new approach which provides clients with the knowledge required to fulfill this task. The idea is to incorporate client's developers in all development phases of the project so that they are able to serve as knowledge carrier in excess of the course.
Full-text available
Software engineering is Money Magazine's top rated profession. The development of novel information systems has created new industries and catapulted developers to wealth and stardom. Yet, for many students of computer and information systems, software engineering is just another hurdle they must jump to satisfy degree requirements. How best to teach software engineering so that students appreciate its unique and vital lessons remains an unanswered question. Our software engineering course exploits students' experience in specific domains as a foundation for learning the skills of software development. The course syllabus provides a vehicle for honing one's development skills, practicing abstraction, and finally experiencing the "aha" phenomenon when the student has successfully integrated two different fields of knowledge into a new discipline. We report the results of this approach.
Conference Paper
Full-text available
Team project courses are important elements in most computer science and software engineering programs. For many students, the team project course represents the only non-trivial software development experience before graduation. The team project should be used to introduce them to important project and process issues that otherwise are very difficult to teach. Sloppy documentation, poor project planning and tracking or ineffective communication will eventually affect the teams and teach the students a important lessons for their future work. In this paper, we investigate how students select, carry out and complete their projects. The results show that students tend to select mainstream projects with good specifications and that certain project types are less suitable for the course. The results also show that process related deliverables are crucial to the final outcome of the projects. Among the hardest, but also most important, deliverables we find the project plan
Conference Paper
A typical CS2 course has two goals that often work at cross-purposes. One goal is to teach students how to apply a variety of software engineering skills to create solutions to real-world problems. A second goal is to teach students the theory and practice behind classical algorithms and data structures. The use of small, short-term programming assignments, however, tends to sacrifice the first goal in favor of the second. We successfully experimented with solving this problem by organizing a CS2 course around a programming project that spanned an entire term. This paper describes the project, our experiences in using it, and the reactions of the students.
In a project-intensive introduction to software engineering at Carnegie Mellon University (CMU), students developed an interactive exhibit for the Kansas Cosmosphere and Space Center. In a similar course at The Wichita State University, students modified the original CMU project to fit new customer requirements. This package of educational materials provides the software products and documents developed by the students in these courses, along with lesson plans, exams, and other materials used by the instructors.
Conference Paper
While much work has been done on the lab component of the CS1 course, programming assignments have not received as much attention. Many CS1 courses have a series of programming assignments that supplement the lab component. However, the assignments are often unrelated to each other. While the advantages of semester project for upper division courses are well known, little has been done on the use of a semester project in the first programming course. However, it is feasible for a first semester programmer to complete an entire semester project if it is designed properly. The development of a semester-long programming project done in phases has many benefits to offer a CS1 course.
Conference Paper
An increasing number of departments offering software engineering courses are adopting approaches that attempt to provide a real world software development experience within an academic setting. In this paper, the use of such approaches are combined with a few more practices used in industry to closer approximate a real world environment.
Conference Paper
A typical CS2 course has two goals that often work at cross-purposes. One goal is to teach students how to apply a variety of software engineering skills to create solutions to real-world problems. A second goal is to teach students the theory and practice behind classical algorithms and data structures. The use of small, short-term programming assignments, however, tends to sacrifice the first goal in favor of the second. We successfully experimented with solving this problem by organizing a CS2 course around a programming project that spanned an entire term. This paper describes the project, our experiences in using it, and the reactions of the students.
Conference Paper
A two-semester undergraduate software engineering course sequence is taught at Fort Lewis College. The first course in the sequence (Systems Analysis) emphasizes software engineering terminology and ″theory″ through the ″lecture and reading″ format. The second course (Systems Design and Implementation) is a project intensive software design course. This article describes the unique features of the course and the author's experience with using a project-intensive course model for this course.
Conference Paper
Recent curricular recommendations (e.g., [7,9]) encourage the early and regular use of significant group projects in the introductory computer science sequence. In this paper, we report on a group project that we used in two courses during the second half of the semester. Rather than having each group work on the same project (or even individual projects), the groups build parts of a larger project: a distributed auction system to be used by art shows at conventions. Students reacted quite positively to the experience, in spite of reporting that they spent upwards of twenty hours on the project in many weeks. Students also learned important software design principles from experience.