Computers & Education 56 (2011) 802–817

Contents lists available at ScienceDirect

Computers & Education

journal homepage: www.elsevier.com/locate/compedu

The design and development of a computerized tool support for conducting

senior projects in software engineering education
Chung-Yang Chen*, Kao-Chiuan Teng
Department of Information Management, National Central University, 300 Jhong-Da Road, Jhong-Li City, Tao-Yuan 32001, Taiwan, ROC

a r t i c l e i n f o a b s t r a c t

Article history: This paper presents a computerized tool support, the Meetings-Flow Project Collaboration System (MFS),
Received 9 April 2010 for designing, directing and sustaining the collaborative teamwork required in senior projects in software
Received in revised form engineering (SE) education. Among many schools’ SE curricula, senior projects serve as a capstone course
20 October 2010
that provides comprehensive training in collaborative project development. With the focus on collabo-
Accepted 21 October 2010
ration training, instructors of senior projects often address issues that include how to encourage
collaboration and ensure that collaborative efforts are sustained throughout the project’s development.
Keywords:
In order to help resolve these issues, the MFS takes a holistic approach. The meetings-flow concept that
Applications in subject areas
Cooperative/collaborative learning undergirds the MFS introduces a novel macro-level and meeting-oriented group process to guide the
Post-secondary education proceeding of the project’s collaborative work. The design of the MFS facilitates a computerized envi-
Programming and programming languages ronment that helps to institutionalize and monitor such a group process. In introducing the MFS, we
Teaching/learning strategies focus initially on the elaboration of the concept and design, after which we present and validate the
system implementation and usage. We also evaluate the MFS and receive a positive result with respect to
the educational issues raised in this paper. Finally, we comparatively summarize the MFS to discuss its
values and the role it plays in CSCL (computer supported collaborative learning) and PBL (project-based
learning) of SE education.
Ó 2010 Elsevier Ltd. All rights reserved.

1. Introduction

The importance of software engineering in computing education is well documented in recent literature, which promotes project-based
learning (PBL) (Milentijevic, Ciric, & Vojinovic, 2008; Rooji, 2009) and collaboration training in software engineering (SE) curricula (Hilburn
& Humphrey, 2002; Sancho-Thomas, Fuentes-Fernandez, & Fernandez-Manjon, 2009; Van der Duim, Andersson, & Sinnema, 2007). Among
many schools’ SE curricula, senior projects serve as a capstone course that provides comprehensive training in collaborative project
development (Mead, 2009; Melin & Cronholm, 2004; Van Vliet, 2006). Senior projects allow SE students to apply what they have learned
during their college years and to work in teams to implement computer-based systems. The project duration, varying from six months to
a year, is longer than that of usual curriculum coursework in order to allow for a comprehensive walk through of the project lifecycle.
Although a senior project may be relatively smaller than those in real-life applications, it constitutes a student’s greatest single endeavor.
From an empirical perspective, managing people involved in a software project’s collaborative work has proven challenging, and known
problems include: a lack of user or stakeholder involvement, ignorance of what other team members are doing, the lone-warrior situation,
etc. (Marchewka, 2010; Motschnig-Pitrik & Figl, 2007; Reel, 1999; The Standish Group, 2007). The involvement of people in collaborative
software developments is apparently a critical lesson that should be given in senior projects. However, because of their inexperience with
long-term teamwork and fragmented knowledge of software development (Chamillard & Braun, 2002), students placed in teams sometimes
explore their project blindly and do not know how collaboration should proceed throughout the project development (Hassan, 2008;
Schlimmer, Fletcher, & Hermens, 1994). Hence, teachers of senior projects need to address two instructional issues: how to encourage
collaboration, and how to ensure that collaborative effort is sustained throughout a project’s development.

* Corresponding author.
E-mail addresses: cychen@mgt.ncu.edu.tw (C.-Y. Chen), 964203042@cc.ncu.edu.tw (K.-C. Teng).

0360-1315/$ – see front matter Ó 2010 Elsevier Ltd. All rights reserved.
doi:10.1016/j.compedu.2010.10.022
 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817 803

To direct collaboration in conducting student project development, Chen (2009) has proposed a meetings-flow concept. The concept
suggests that the execution of a project’s “mandatory collaborations” (Robillard & Robillard, 2000) takes the form of meetings, and it
proposes a holistic focus on collective and serialized meetings in carrying out student team projects. This paper extends this preliminary
work and further develops a computerized support, the Meetings-Flow System (MFS). The concept inside the MFS, i.e., the meetings-flow,
introduces a novel macro-level group process to guide a project’s collaborative work. The design and implementation of the MFS provides
a computerized environment that sustains the group process and promotes the interpersonal involvement required; it also helps realize the
evolving nature of a project’s group memory codified in meetings (i.e., the interconnection of meeting minutes facilitated by the MFS) in
order to streamline the collaborative development. In addition, the MFS is Web-based, which permits flexibility in running the meeting-
oriented group process while also providing a centralized repository of meetings content.
Computer-aided educational collaboration is an important topic in literature, where a number of tools enabling collaborative work and
learning (CSCL) are seen. Existing CSCL tools focus mainly on the micro-level of internal operation and facilitation inside a collaborative
learning activity. To a comprehensive project-based learning (PBL) environment like a senior project, these tools are insufficiently holistic for
guiding students in designing and directing collaborative development. The MFS is designed to fill in this gap.
The rest of this paper is organized as follows. Section 2 reviews the literature related to collaboration training. Section 3 introduces the
framework and design of the MFS. Section 4 presents and evaluates the implementation of the MFS, and Section 5 compares this system
with existing tools focusing on their values and the roles they play in PBL and CSCL. Finally, Section 6 concludes the paper and outlines
directions for future research.

2. Literature review

2.1. Collaboration training in senior projects

In software project development, collaboration plays a critical role in project success. Unlike cooperative work, which refers to the
common work mode of each team member working separately on defined parts of a project task, collaboration is a coordinated,
synchronized activity that is the result of a continued attempt to construct and maintain a shared conception of a problem (Napier &
Johnson, 2007; Roschelle & Teasley, 1995). Compared to cooperation, collaboration emphasizes collective participation and the mutual
engagement of participants in solving a problem together (Holliman & Scanlon, 2006). Collaboration is particularly critical in joint devel-
opment environments where people often come together to accomplish various project tasks and solve project-related problems (Robillard
& Robillard, 2000).
Since collaboration is critical in business reality, it is inherited as a critical lesson for SE students. Software development collaboration
differs from the team-oriented nature of student group projects, i.e., the mutual-reliance of students in project work (Abernethy, Piegari, &
Reichgelt, 2007; Hassan, 2008; Lipman, 1991). As Denning (1992) and Scragg, Baldwin, and Koomen (1994) argued back in the 1990s,
computing education does not prepare students to work in joint development environments populated by people in various roles. They also
pointed out that many of the skills which students lack are communication- and collaboration-related, rather than technological. Many
articles in the computing and engineering education literature have identified this gap and advocated educating students with more
project-based learning and group-oriented collaboration training (Favela & Peña-Mora, 2001; Hilburn & Humphrey, 2002; Mead, 2009;
Melin & Cronholm, 2004; Milentijevic et al., 2008; Sancho-Thomas et al., 2009; Van der Duim et al., 2007; Van Vliet, 2006).
Collaborations in senior projects may be internal (i.e., among students only) or external (i.e., with outside members participating, such as
the instructor or sponsoring company). In conducting students’ internal collaboration, instructors need to be aware of three syndromes,
owing to students’ team-oriented nature. The first is the “free-rider syndrome” (Goldratt, 1997). Researchers Van der Duim et al. (2007) have
reported this syndrome as one of the major problems in student team project development. The free-rider syndrome commonly exists in
student group work because individual performance is not visualized and the grading policy focuses on the group as a whole. The second
syndrome that often arises and hinders collaboration in student group work is the “Wyatt Earp syndrome” (Boehm & Port, 2001). This occurs
when a student presents a new idea or accomplishment to the instructor without having first discussed it with other members of the group.
The third syndrome has been labeled the “student syndrome.” The problem here is that many people, but students especially, do not fully
devote themselves to a task until the last possible moment before a deadline (Goldratt, 1997; Marchewka, 2010), which may aggravate the
uncertainty of senior projects as mentioned earlier.
Owing to the aforementioned problems, instructors may need to control student group projects quite closely. Rather than just relying on
infrequent milestones, they may need to conduct evaluations at more appropriate intervals (Melin & Cronholm, 2004). In their article
“Teaching Teamwork,” Hilburn and Humphrey (2002) suggest a cyclic development (CD) strategy to handle student group project devel-
opment. Similar to iterative development models (Humphrey, 2000; Marchewka, 2010), CD applies divide-and-conquer and watch-and-go
strategies by focusing on and implementing a subset of requirements that are introduced to iterative systems. During each development
loop, the various types and levels of risks/uncertainties are monitored and a subset of requirements for the next cycle is selected. CD offers
a good general principle for monitoring student project work, and it is the basis for the computerized tool support that this paper develops
to further address the issues that arise in collaborative senior project development.

2.2. Computer-aided collaboration training

Computer-aided educational collaboration is an emerging research. Currently, it mainly focuses on how technology can enhance
student–student or instructor–student interaction in a collaborative learning task. A number of tools enabling collaborative learning (CSCL)
can be found in recent Computer & Education publications. For example, the GroupScribbles proposed by Looi, Chen, and Ng (2010) engages
students in collaborative learning in science classes. According to their report, in a collaborative activity where the tool is presented,
students are able to take active roles in analyzing information, interacting with peers and teachers, solving problems, and designing
solutions. The DriveHQ (Wang, 2009) is a groupware that uses the strategy of friendship and meaningful learning tasks to promote indi-
vidual accountability and positive interdependence. The Participatory Training (PT) program focuses on the effects of visualizing
804 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817

participation. PT visualizes how much each group member contributes to his or her group’s online communication during a collaborative
learning task. The CoDE (Puntambekar, 2006) system facilitates the consolidation of divergent ideas during the converging discussion of
a collaborative task. The paper examines the tool by walking through the responses of 24 students during the interactive process of solving
the given seven problems. The BSCW (Nicol & MacLeod, 2005) system implements a location-independent central repository to improve
group sharing of resources among collaborative activities.
Some tools are developed for collaborative work in computing education. The NUCLEO proposed by (Sancho-Thomas et al., 2009)
provides a computerized environment for students to learn teamwork skills in university programming courses. Their report argues that
university courses in computing programming usually seek to provide students not only with technical knowledge, but also with the skills
required to work in real-life software projects. In this regard, the tool provides a socio-constructivist environment for students to collab-
oratively accomplish a programming task. The Version Control System (VCS), which is proposed by Milentijevic et al. (2008), implements
a collaborative monitoring mechanism of codified collaborative work. The authors use UML sequence diagrams in describing the design of
the system and evaluate it on the test group of 21 students.
From the perspective of senior project development, most of these collaborative tools refer to the interactive and operating tools used
within a group activity. In other words, existing CSCL tools focus primarily on the internal aspects of collaboration at the micro-level. In
software projects, various collaborative and participative functions make up the development of the projects. However, because of their
fragmented knowledge of software development, students often explore the projects blindly (Chamillard & Braun, 2002; Hassan, 2008).
According to Van Vliet (2006), such blind exploration may hinder the educational development of senior projects if there is no plan of
instruction regarding the required team effort and the discipline being taught. To date, such a macro aspect of collaboration training is
lacking. Hence, in conducting senior project development, this paper takes a holistic perspective to collaboration training, and aims at
developing a computerized support for guiding students in designing and directing the development of a collaborative project.

3. The meetings-flow system (MFS)

3.1. Concept

In this section of the paper, the meetings-flow system (MFS) is presented. Here, the term meetings-flow does not refer to the micro-level
of internal control flow inside a meeting, but to the holistic modeling of mandatory project collaboration into functional meetings and their
inter-connectivity. The MFS is based on Chen’s (2009) preliminary work regarding the meetings-flow concept. According to several studies,
teamwork in meetings enables the participation and interaction of all people involved in a collaborative work and promotes the sharing of
inspiration and knowledge (Gallivan & Keil, 2003; Garcia, Kunz, & Fischer, 2005; Hass, 2006). In this regard, the meetings-flow concept
promotes a focus on project meetings, and further suggests a holistic view of the meeting entities to ensure a continual meeting effort in
planned projects’ collaborative development. This paper continues the development of the concept, and further implements it into
a computerized support.
Fig. 1 is the structural framework of the MFS, which consists of two parts: (1) modeling substantial collaborative teamwork and
stakeholder involvement in functional meeting classes, and (2) organizing the meeting classes to form meetings-flow. The contents of the
framework, in terms of these two parts, are elaborated in the following subsections.

3.1.1. Modeling substantial collaborative teamwork into meeting classes

In group-oriented project development, project members perform collaborations which are closely connected to a series of shared works
that compose the accomplishment of a project (George & Jones, 2008). In software projects, the Work Breakdown Structure, abbreviated as
WBS, is the serialized composition of a project’s planned work for accomplishing the project goals (PMI, 2004). Hence, as Fig. 1 shows, to
identify collaborations that are mandatory, the MFS focuses on a project’s WBS, and it terms the Collaborative or Participative work items in
the WBS as CP functions in identifying and planning the internal and external mandatory collaborations of the project.

Fig. 1. The object-oriented framework of the meetings-flow concept in MFS.

 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817 805

To facilitate a mutual understanding of and commitment to the project’s mandatory collaborations, the MFS requires students to take
part in the work of determining CP functions. During the process of CP function identification, 5W1H theory (Yates & Orlikowski, 1992;
Yoshioka, Herman, Yates, & Orlikowski, 2001) is applied. Students apply the theory to delineate teamwork and define the participating
roles. According to Fig. 1, participating roles include the student team, the instructor, and company stakeholders for an industry-sponsored
project. With the 5W1H method, CP functions are characterized by who performs what CP functions with/to whom. For example, a senior
project team may identify two CP functions as follows: a course instructor (who) performs a CP function (what) of “reviewing the project” to
a student team (whom); students (who) perform a CP function (what) of “presenting and confirming the ideas” to the instructor (whom). The
where and how can be used in planning the location and means (e.g., face-to-face or distributed work mode) for carrying out a CP function.
The MFS takes the form of meetings for institutionalizing the execution of CP functions. In this paper, CP functions are aggregated as the
agenda in a functional meeting class, and calling for a meeting refers to the creation of a meeting object from its associated meeting class.
Thus, collaboration becomes repeatable through the instantiation of corresponding functional meeting classes. With object technologies,
the sustainability of CP functions is presented in two ways. First, repeatable CP functions are encapsulated as the predefined agenda in the
associated functional meeting class, which can be instantiated (i.e., called for) any time performance of the CP functions is required. Second,
a functional meeting class is not accomplished unless all of the agenda items are accomplished. This means that when all of the expected
agenda items cannot be dealt with in one meeting (object) action, they are continued in subsequent meetings (instantiated meeting objects
for the same meeting type) until all the agenda items have been accomplished.

3.1.2. Organizing meeting classes to form the meetings-flow

Once the meeting classes are identified, they are organized and interconnected into the meetings-flow. In this paper, two types of
meetings-flow are defined. The first type is the temporal meetings-flow, which is formed according to the sequential relationships of the
meeting classes on the WBS. The second type is the contextual meetings-flow, which is defined as the information dependencies among
various functional meeting classes. As Fig. 2 illustrates, scheduling a meeting class B after the completion of meeting class A outlines the
sequence of the meetings, thus forming a temporal flow of A and B. Inter-meeting dependency suggests that B needs the conclusions of
P, thus forming a contextual flow of B and P.
The reasons for constructing these two flow types are as follows. If project meetings are planned based on the WBS, they form
a sequential relationship and a macro-level group process can then be defined. The realization of such a group process refers to the when (in
the 5W1H method) of the meetings on the flow, which helps to guide students in carrying out designated collaborations. The macro-level
group process serves as a centralized group path for monitoring collaborative development and stakeholder engagement. Moreover, if the
content of a meeting represents the group memory of the collaborative work, then the contextual meetings-flow represents the evolving
nature of project’s group memory codified in meetings and helps to realize the role each functional meeting plays in the team’s global
accomplishment. Such a realization (contextual meetings-flow) refers to why (in the 5W1H method) a meeting class exists in the meetings-
flow, which helps the student team stay focused on the meeting agenda to yield a fluent execution of the project’s collaborative work.
Fig. 3 below shows the temporal and contextual meetings-flow designs of a senior project case, which will also be referred to later on in
the Implementation Results section. Note that in the figure, the cloud-like shape is used to denote a functional meeting class, and it
represents the repeatability of a meeting and the surrounding ad-hoc and informal communications that center on the meeting:
communications that support and accomplish the given agenda of the meeting.

3.2. System design

Fig. 4 depicts the contextual level of the system’s behavioral design by showing the actors and their interactions with the system. Note
that although CP functions are entered into the system by a project leader, the MFS suggests that the planning of the CP functions be done
together with the team members under the guidance of the course instructor. Also, when planning the CP functions and the meeting classes
for the project, the MFS is designed to allow the automatic import of a project’s WBS from the MS Project.
Looking into the design details, we can see that the MFS consists of two functional modules called MF-Designer and MF-Runner. The use
cases for these two modules are illustrated in Fig. 5. As the diagram shows, the MF-Designer module is designed for the following tasks:
(1) setting up a project and creating the phases for the project, as indicated by the use case heading “Create a senior project,” (2) planning
the collaborative work cycle for each phase and defining the associated functional meeting classes, and (3) designing the meetings-flow, as
indicated by the use case headings “Design meetings-flow” and “Assign participating roles.” The MF-Runner is used when students execute
meetings on the flow. Its tasks are to administer the execution of meetings (“Run meetings-flow”), manage the status of meetings during
a work cycle (“View managerial statistics”), and maintain the contexts of the contents of these meetings (“Share information”).
According to the project design, the lifecycle of a senior project comprises several phases, including the project initialization phase, the
implementation phase, and the final delivery/presentation phase. With the cyclic development model, each phase has a corresponding work
cycle for carrying out the development to incrementally achieve the phase goal. The cycle consists of substantial CP functions, which are
further characterized into meeting classes. The phase, cycle and meeting class creation are done in the “Design meetings-flow” use case.
Fig. 6 further illustrates the detailed collaboration required in the above use case. As the diagram shows, for each project phase the actor
first defines the work cycle and then identifies the associated functional meeting classes according to the CP functions in the work cycle. In

Functional meeting class

P A B Sequential meetings-flow
Group memory conveyed via the
contextual meetings-flow

Fig. 2. The temporal and contextual flows of functional meeting classes P, A and B.
806 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817

Fig. 3. The meeting-oriented group process model for cyclic senior project development.

the diagram, the flows of meetings are denoted by the “linkages.” Once meeting classes are defined, linkages can then be instantiated
according to two embedded organization rules, i.e., the temporal position of meeting classes on the WBS, and the information interde-
pendences among the meeting classes. To capture such meeting interdependences, the MFS applies the design structure matrix (DSM)
(Eppinger, 2001) from project management in planning the information flows among the meeting classes. After the meetings and their
linkages are defined, stakeholder engagement is also planned via this use case.
Once the MF-Designer is completed, students use the “Run meetings-flow” use case in the MF-Runner module to operate the meetings-
flow. A meeting is called by first entering the current work cycle and clicking on the selected meeting class to create (instantiate) an object of

Fig. 4. The context diagram of MFS.

 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817 807

Fig. 5. Major use cases and relevant stakeholders for the two functional modules.

the meeting class. Once the meeting is called and created, students use the system to upload documents or reports that they have been
assigned to prepare, or to download the requested artifacts from other meeting objects for preparing the meeting. The use case also allows
for the addition of any new and transient issues to be brought to the meeting for timely discussion and communication. The system then
sends meeting attendance, invitation, or just notification messages to relevant stakeholders according to the degree of their planned
involvement (see Fig. 3). This means that that instructor also receives a meeting notification from the MFS so that he/she can keep track of
the team progress.
In the design of the meetings-flow operation, four states of a meeting’s operational lifecycle are further specified. A meeting is not
initialized unless it is called. Once called, it enters the preparing state where the meeting is set up. A meeting enters the under-progress state
when it takes place, and it stays in this state until all items on the agenda are accomplished. During the under-progress state a meeting class
may generate many objects (i.e., further meetings), because all of the agenda cannot typically be handled in a meeting action (i.e., a meeting
object). The meeting finally enters the completed state when all items on the agenda have been accomplished. The meeting-state design
serves the purpose of monitoring the progress of collaborative development by showing the statuses of the meetings on the flow. We will
demonstrate this development in the following Implementation section.

Fig. 6. Designing the meetings-flow: the collaborative view.

808 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817

4. Implementation result

4.1. Using the MFS

The above framework and design are further implemented into a Web-based computerized solution. In demonstrating the system, we
use a senior project case to walk through the implementation. The case, coded as PIS, is a senior project from the Computing Engineering
Undergraduate program of the Information Management department (abbreviated as CEUIM in this paper) at National Central University,
Taiwan. CEUIM aims to help students establish software development capabilities by offering a series of SE courses, including senior projects
such as PIS. The stakeholders of the PIS project include five students, an instructor, and a company who sponsors the development of the
project. The PIS project uses the MFS tool support during the project development. Due to the original foreign (Chinese) language issue, the
contents of the following screens have been translated into English to extend the readability of this paper.

4.1.1. Creating a project and planning the meetings-flow

As Fig. 7 shows, when a user logs into the system, a list of the user’s working projects are presented. Two buttons are shown on the left-
hand side of the screen. These are “Design View” and “Work View,” which link to MF-Designer and MF-Runner, respectively. As the screen
displays, the user selects the “PIS” new project to charter the project and its team, and to assign project roles to the team members (see the
right half of Fig. 7). This page of people-role engagement helps students to understand the responsibilities of various project roles in relation
to software development. Because the PIS project has an industrial involvement, the liaison roles to both sides (the external company and
the student team) are also confirmed here to engage their future involvement in collaborative work.
After the project is created, the team and the instructor use the screen shown in Fig. 8 below to plan the phases/stages and the cor-
responding work cycle. In the PIS project, three phases are created: the requirement stage to define the functional scope; the imple-
mentation stage to elaborate the requirements and implement the corresponding program code; and the delivery/presentation stage to
perform the acceptance tests, wrap up the system, and prepare the final reports. These phases may differ in different senior projects. MFS
also facilitates the exercise in which students plan the goals and corresponding WBS of the work cycle.
Once the WBS is available, students are told to conduct a role-playing game to identify mandatory CP functions. The game applies the CRC
(Class Responsibility Collaboration) method (Brown, 2002) from the course material of Systems Analysis and Design. The CRC method serves

Fig. 7. Creating a new project and assigning relevant stakeholders to the project.
 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817 809

to identity candidate classes and their collaborative responsibilities in fulfilling certain system functions. During this game, students play the
roles of the instructor, the external stakeholder, and the student team in identifying mutual needs for collaboration and participation. The
game centers on the student team role in order to focus on the students’ collaborative work in the project. To further identify CP functions
that are mandatory, the game follows a lazy strategy (Brown, 2002): each role player tries to be as lazy as possible and to persuade other role
players who collaborate in the project to accept the proposed mandatory CP functions.
After a list of CP functions is identified and agreed upon, the students and the instructor plan functional meetings. The bottom part of
Fig. 8 is a screenshot of a meeting class definition. As the figure shows, the REQR meeting is declared (yet not instantiated), and the project
roles identifying who needs to attend the meeting are assigned (see the “Attend_roles” field on the screen). According to the degree-of-
involvement design, the assignment also includes people who should review, or approve, or be notified about a meeting’s action and results.
The MFS links the selected project roles to the associated project members or stakeholders assigned in Fig. 7. The bottom-right part of Fig. 8
shows the task of defining the meeting agenda and assigning who is responsible (the “Assigned_role” field) for preparing what agenda and
the associated documentation.
The team then organizes the temporal and the contextual flows of the meeting classes. Due to its corresponding position in the WBS, the
temporal flow of the meeting classes is automatically established by the system. As for the contextual flow, Fig. 9 shows the work of
constructing it in a tabular form. As mentioned earlier, the construction applies the DSM method in defining the interdependencies among
the meeting classes. As the diagram (Fig. 9) shows, the assignment of “previous meeting” indicates a “from” of information dependency in
DSM. For instance, there is an information flow regarding the product baseline from the CM meeting to the REQR meeting, which means that
the CM meeting must conclude and generate a product baseline as it is required for the following REQR meeting. The right-hand side of Fig. 9
shows a view of the resulting contextual flow for the “implementation” cycle of the PIS project. Note that in the meetings-flow screen the
oval shape (meetings) is clickable for users so they can enter to operate and execute the meetings.

4.1.2. Executing the meetings-flow

The PIS project team uses the MF-Runner to execute the meetings-flow design. When a meeting class is called, it enters the “preparing”
state. Fig. 10(a) displays a meeting object creation (instantiation) from the REQR meeting class. This page allows for the dynamic addition of
any new participants or current issues to the meeting action. Meeting participants can upload to the system the designated documents as
well. After the meeting creation page is completed, the system automatically sends out emails regarding the meeting notification.
When a meeting is in action (being held), it remains in the “in-progress” state. Fig. 10(b) shows a page of a meeting in action. The
checkboxes in Fig. 10(b) showing the expected participants enable the team to record attendance. Meeting members utilize the page to

Fig. 8. Planning project’s cycle and associated meeting classes declaration.

810 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817

Fig. 9. Planning the flow of meetings for the project.

upload the resulting contents. When a meeting object is ended, the system produces the meeting minutes in PDF format to codify the group
memory for this meeting action. When the agenda cannot be completed at once, the meeting stays “in-progress.” The convener then
instantiates and schedules another meeting object. The number of objects instantiated from a meeting class during the work cycle reflects
the number of times that the meeting is recalled. The purpose of this design is to preserve the evolution of the group work in corresponding
meeting entities. When all agenda items have been accomplished, the meeting enters the “completed” status.
With this method of system implementation, group progress can be monitored according to the statuses of the meeting classes on the flow.
As Fig. 11 shows, the MFS uses different colors for showing the statuses of a meeting. As the screenshot indicates, the PIS project is in the REQE
and the INNOV meetings. Stakeholders are able to see the group progress of development by this dynamically generated graphical information.

Fig. 10. The screens for (a) calling for a meeting and (b) running the meeting.
 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817 811

The current version of the MFS features three graphical and numerical reports in managing student performance and stakeholder
involvement in meetings. Fig. 12(a) shows the effort distribution within the meeting classes for selected project duration. Fig. 12(c) is an
attendance and engagement report which allows stakeholders to know the mutual involvement in meetings. It also highlights the
importance of social presence to a project’s collaborative work (Garrison & Vaughan, 2008). Fig. 12(b) is a consolidated view of the time
spent on the meeting classes, which identifies the process bottleneck. From the diagram, we see that for the PIS project case, the VAL
meeting appeared to be the most effort-consuming. This information can potentially lead to SPI (software process improvement) oppor-
tunities. In the PIS project case, after reviewing the information with the students, the instructor found that in addition to combining
individual work, students tended to use the VAL meeting to code and solve programming problems together, resulting in a large increase in
the meeting time.

4.2. Evaluation of the MFS

We conducted an evaluation of the MFS to validate the assistance it brought to the two instructional issues and the three student team
syndromes raised in this paper. The evaluation was carried out via Information System Development (abbreviated as ISD), a senior project
development course, in the CEUIM program at National Central University. The ISD senior project course runs across two semesters.
Students take the course and start their projects in the beginning of the second semester (spring) of their junior year, and finish the projects
during the first semester (fall) of their senior year.
There were 44 senior students participating in the evaluation. These students were enrolled in the authors’ ISD course during 2008, 2009
and 2010. According to the team-forming rule set by the department, each team should consist of at least 5 students. The purpose of this rule
is to encourage students to team up with unfamiliar members. Given the number of students who participated in the MFS evaluation, 8
teams were formed with 5 or 6 students in each team. The student project teams worked on their innovative ideas to implement various
software products. These products, according to CEUIM, can be categorized mainly into Web applications, stand-alone MIS, and wireless
applications. The composition of the participating groups, though not very large in size, covered all three types, and a collective evaluation of
the MFS was conducted under these mixed conditions.
The evaluation included a survey and follow-up interviews. The survey consisted of twelve questions, along with instructions to the
students on how to understand and reply to the questions. The design of the survey questions was based on the issues raised in this paper,
which focus on how to encourage and sustain collaboration throughout project development. Accordingly, four question categories
specific to senior project characteristics and relevant teamwork settings surveyed in the literature section were further developed. The four
categories were the following: (1) directing teamwork and monitoring the Wyatt Earp, free-rider and student syndromes (Questions No. 1,
3, 4, 8 and 9); (2) creating a positive team environment (Questions No. 11 and 12); (3) streamlining stakeholders’ involvement (Questions
No. 2 and 5); and (4) sustaining the collaborative environment (Questions No. 6, 7 and 10). Student teams were asked to respond to the
survey questions on a four-point scale ranging from “strongly agree” to “agree,” “disagree,” or “strongly disagree” (Looi et al., 2010).
After the survey, we conducted follow-up interviews. The role of the interviews in the evaluation process was to review and have an in-
depth discussion of the survey results. This was deemed necessary, as the survey was designed to show only the degrees of agreement
regarding the questions; thus we conducted interviews to further explore how the tool helped to address the research questions. Interviews
began by going through the responses to the questions and then redirecting attention to a resolution of the central issues, namely, the two
instructional issues and the three student team syndromes. So that the discussion period would be objective and open-minded, survey
results were not linked to the identities of the respondents. The questions and survey results are illustrated in the following table (Table 1).
Findings and lessons-learned from the interviews are described in the material that follows. Validity issues regarding the evaluation are
addressed in Section 5.

4.2.1. Directing and monitoring teamwork

As the results indicate, most of the students (about 88%) indicated that they “agree” or “strongly agree” that the MFS was beneficial in
guiding their collaborative development of the project. In the discussion of directing teamwork, Questions No.1, 4 and 9 gained a positive
response. These questions pertained to students’ learning of how to design and carry out project collaborative work. As the students replied,
the existence of the flow structuralized the required teamwork proceedings, thus helping them to direct the development of the project.
Students further commented that the meetings-flow appeared as a “backbone-like centralized group path,” which in fact evoked more ad-
hoc and informal teamwork activities that supported the execution of the meeting series.
In the discussion of monitoring teamwork (corresponding to Questions No. 3 and 8), participants responded that human involvement was
able to be formalized and publicly scrutinized because the meetings and meetings-flow were clearly defined. Typically, software devel-
opment tends to be a “black box” (Tiwana, 2004) which may cause ineffective teamwork in joint development environments. This is

Fig. 11. The visualization of the overall group progress by different colors of the meetings’ states on the meetings-flow.
812 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817

Fig. 12. Three graphical managerial views of meeting-oriented collaborative development.

particularly true in senior projects where in-process collaboration is a focus of training. In the MFS, identified meetings ensured that
mandatory collaborations were clearly defined inside the “black box,” or development cycle, of projects. The commitment status of indi-
viduals was better visualized and publicly scrutinized, thus helping to reduce the free-rider and Wyatt Earp syndromes. This is particularly
confirmed by responses to Questions No. 3 and 8, which were designed to determine whether the tool helps resolve the two syndromes in
senior projects. With respect to the “student syndrome,” the survey result of Question No. 9 indicates the tool increased the granularity of
teamwork presented in the contextual relationships of collaborations. During the interview the students replied: “the tool provided a visual
presentation of the meetings-flow; such a collective view with different colors for meeting statuses (see Fig. 11) envisioned the in-process

Table 1
Descriptive statistics of students’ attitudes toward the use of MFS.

Evaluation items Strongly Agree Disagree Strongly

agree disagree

q % q % q % q %
1. MFS helps me learn how to design and carry out project collaborative work 29 65.9 11 25 2 4.5 2 4.5
2. MFS helps institutionalize stakeholder involvement 28 63.6 10 22.7 4 9.1 2 4.5
3. MFS helps visualize the group progress 34 77.3 8 18.2 1 2.3 1 2.3
4. MFS establishes the connectivity of collaborative work and yields a smooth and continual execution 27 61.4 11 25 4 9.1 2 4.5
5. MFS helps streamline the discussions with stakeholders 26 59.1 13 29.5 4 9.1 1 2.3
6. I feel that collaborative learning via MFS is effective and continuous throughout the project 28 63.6 10 22.7 3 6.8 3 6.8
7. I feel that the meetings-flow, particularly the contextual flow, makes meetings effective 30 68.2 10 22.7 2 4.5 2 4.5
8. MFS helps me know better how and what other team members are doing 29 65.9 9 20.5 3 6.8 3 6.8
9. MFS helps direct the group work step by step by utilizing the functional meetings 28 63.6 12 27.3 3 6.8 1 2.3
10. I would like to use MFS in my next group project 25 56.8 12 27.3 7 15.9 0 0
11. I would like to work with my teammates again 22 0.5 18 40.9 4 9.1 0 0
12. I know my teammates well since the project began 10 22.7 14 31.8 15 34.1 5 11.4
Total (exclude No.12): 306 63.2 124 25.6 37 7.6 17 3.5
 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817 813

progress of collaborative work.” Students also noted that the MFS helped maintain the significant amount of project document contents
resulting from meetings.
It may be worth mentioning that setting learning-goals might also have contributed to their collaborative development of a project. In
the projects we examined, students had the learning goal of accomplishing challenges together, rather than simply completing the project on
time within a budget. In senior projects, instructors may set tasks that have various levels of difficulty, and some of the tasks may be nearly
“mission impossible” to students. In this situation, collaboratively meeting and trying to overcome the challenges becomes a training focus
in which students can use the MFS to carry out collaborations and achieve the learning goal. This is corroborated by the following obser-
vation. During the interview, students commented that by having such a goal and the MFS tool, they enjoyed the process of collaboratively
developing and completing the projects, and learned that satisfactory project outcomes were delivered only by working together.

4.2.2. Creating a positive team environment

Regarding the question (No.11) of whether the students are willing to work as a team again, we further discuss how MFS helped to
encourage collaboration and create a positive team environment. We also used Question No.12 to cross-verify the following confounding
factor: having good friends on a team may bias the evaluation, which is intended to determine how the tool helps to create a teamwork
environment. In software development, it is typical for developers to work alone before a problem gets out of control rather than
communicate and work with others (Heller, 2000). Although it appears that people by nature like to help others who are in urgent need
(Hudson, 2007), ironically projects often fail because of the inability of people to know others’ needs and give help or support in a timely
manner (Ceschi, 2005).
The MFS raised this issue in senior projects; we found that some members in these project teams were less enthusiastic about group
work. To encourage greater participation and information-sharing in meetings, students were taught to take advantage of elements in
Maslow’s “Hierarchy of Needs” model (Jones, 2007). They were encouraged to share any success or interesting stories of a personal nature
that might be relevant to the team. The objective of such encouragement was to help them earn recognition and self-actualization. Also, as
members spoke out about encountered problems, both the team and the instructor learned about new issues affecting the team; hence, such
personal disclosure became a valuable team asset. During the meetings, the value of helping people was emphasized and promoted with one
team’s interesting slogan: “How many times did you lend a hand today?” Students were encouraged to express appreciation to others in
public, thus creating a positive “Hawthorne effect” (Steele-Johnson, 2000). Under such a climate, students were able to promptly discuss any
concerns before they escalated into roadblocks.

4.2.3. Streamlining stakeholders’ involvement

Besides their positive response to internal collaborations, students also felt that the MFS helped institutionalize stakeholder involvement
and helped organize the group discussions (Questions No. 2 and 5). In their reply to questions, two responses emerged. The first response
was the following: “. in the REQR meetings, the instructor directed our thoughts before we presented them to company stakeholders [in
REQE meetings]. we were then supposed to bring the feedback from the discussion with company stakeholders to the next REQR.” As this
statement indicates, the meetings-flow enabled the instructor to intervene in the collaboration and watch how students went with the
company, which helped to keep things on track.
The second response that emerged from the discussion shed light on the reason for this success: “. the contextual meetings flow
required us to maintain the results of meetings; these meeting documentations, once collected, presented the evolution of the project
content agreed on by relevant stakeholders.” It is evident that through the meetings-flow, students learned to build the group memory in an
organized way, and then consistently communicate with the company stakeholders by having proof and evidence. Project contents
preserved in contextualized meetings were helpful when the project needed to be rolled back to a certain prior version; students were able
to check the relevant meeting contents to help recall the group memory.

4.2.4. Sustaining collaboration

Software development is highly dynamic (Chen & Chen, 2009). During its development, unexpected occurrences may affect the
conclusions reached in a previous meeting. For example, the external stakeholder may request a requirement change, resulting in an impact
on previous conclusions in prior meetings. The MFS provides an educational venue for students to handle such dynamics. In the discussion
of sustaining collaboration, which corresponds to Questions No. 6, 7 and 10, students replied that they utilized the contextual meetings-flow
(e.g., Fig. 9) to perform change impact analysis which determined if any CP functions needed reworking. Students liked the tool because it
can automatically notify the relevant members (according to the stakeholder assignment) and request that they check whether previous
conclusions need to be revised (a minor update) or reworked (i.e., at a reconvened meeting).
The following example serves as a further illustration. In the PIS project case, after REQE and PP had been conducted, the company
stakeholder posed a change to certain requirements which had been previously concluded in REQE. In this case, they used the system screen
(Fig. 9) to check the inflows and outflows of REQE and found that the change: (1) directly related to the “confirmed requirements” outflow of
REQE to PP, and (2) affected the “functional scope” inflow from REQR. This led students to consider a rework on REQR and PP. They informed
the participants, including the instructor, of the rework and checked to see if they needed to call for REQR again. Students also ran PP again to
reschedule the development based on the requirement change.
We found this information (i.e., the contextual flow of meetings) useful in helping students to sustain collaboration. During times of
change in project development, it frequently happens that the group effort is gradually skipped for tasks/events that require the CP function,
and teamwork begins to be handled by individuals. The MFS is used not only for designing collaborative meeting tasks, but also for helping
to sustain the required group effort in the dynamic environment of software development.
As for the survey result of Question No. 10, 84% of the survey participants felt like trying the tool again. In the further discussion of how
the MFS had assisted in sustaining collaboration, we found that MFS was mostly recognized as helping establish and maintain project’s
meetings contents For example, many students liked the automated functions such as sending meeting notifications, creating meeting
minutes, providing the context of meetings’ documents, etc. Some students also pointed out the need for enhancement of the tool interfaces.
We will address this issue in Section 5.3 (Limitations of the MFS).
814 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817

4.2.5. Linking meeting performance to the grading policy

We found that to effectively sustain a positive team environment, many students require incentives and tangible feedback from the
instructor. Linking meeting performance to the grading policy is one way of providing this incentive. However, during the interviews, several
students expressed a concern about this linkage. They were informed that instructors may have a grading policy whereby extra credit can be
earned according to how well students participate in meetings, as well as how many times they help others. According to this grading policy,
extra credits are awarded as a form of encouragement and no punishment is given for failing to obtain them. We learned that the extra credit
grading policy can be used wherever students tend to act as “lone warriors” (individualists), as often happens with particularly skilled
students (Motschnig-Pitrik & Figl, 2007; Smith, Sheppard, Johnson, & Johnson, 2005). The extra credit grading design does not punish these
students, but rather entices them to earn higher grades by helping others.

5. Summary

5.1. Comparison of related works

In this section of the paper, the MFS is summarized by comparing it to existing related tools published in recent Computer & Education
literature. Two classes are revisited due to their relevance to collaborative software engineering training: instructional tool support
including computer supported collaborative learning (CSCL), and project-based learning (PBL). Existing CSCL tools concern the micro-level
process of a group learning task and take advantage of computer-mediated communication (CMC) support for facilitating a collaborative
activity. By contrast, existing tools in PBL facilitate a comprehensive learning environment for software development that takes the form of
projects. Although the tools of CSCL and PBL assume different perspectives, they are both beneficial in software engineering education.
Hence, we compare them with the MFS in terms of their values and the roles they play in collaborative software development training. These
comparisons are presented in Table 2 and further described in the material that follows.
From the perspective of collaborative project development training, existing tools in CSCL focus more on the micro-level of internal
interaction within a collaborative task. In a student team project environment where various collaborations make up the development of the
project, there is a need for training students to be able to design and go through various collaborative and participative functions of the
project. The MFS is designed to serve this need by providing the training of macro-level design in collaborative project teamwork.
Regarding the role of PBL, although the existing tools also codify collaboration, these contents refer mostly to the logs of the interaction
occurring inside meetings. Thus, the contents exist independently in the system without contextual linkages regarding the development of
a team project. The MFS is not designed to record the interactive process inside a group meeting. Rather, it serves to maintain the resulting
contents of meetings, and these contents are automatically interrelated according to the relationships of the meetings (i.e., the meetings-
flow). Such a function refers to the preservation of the flow of agreed contents: contents that represent the evolving nature of the project’s
group memory.
As for the engagement of stakeholder involvement, most collaborative tools in the table allow for the appearance and identity
(sometimes using a username/nickname instead of a real name) of participating students in the computerized discussion environment.
According to the social presence theory, the presence of the collaborators helps in communicating and performing a group task effectively;
thus, many CSCL tools require the presence of the participants’ identities. In a software development environment that contains many
interrelated and continuous collaborative tasks, human involvement should be further institutionalized to ensure the consistency and
sustainability of the development. In this regard, the MFS engages students and stakeholder members who are supposed to be involved in
a project’s CP functions. Thus when certain CP functions are recalled, the designated participants are able to perform these functions,
ensuring the continuity of their involvement in collaborative project development.

5.2. Validity check of the evaluation

Although the evaluation of the MFS shows positive results, threats to the validity of the results in this study require discussion. Four
validity checks have been used for assessing tool performance. These validity checks address issues pertaining to the tool construct, external
factors, conclusion, and internal factors (Kitchenham, Pickard, & Pfleeger, 1995). We use these validity checks to cope with threats to the
evaluation of this study.
To minimize the threats to the construct validity of the evaluation, we focus on reviewing the composition and complexity of the
participants in the evaluation. The number of participants was 44. This small size can be explained by the new development of the MFS as
a research prototype that is not yet widely used. To counteract the disadvantage of having a small sample size, we expanded the evaluation
to a longer time for the purpose of gathering more data. The authors collected the evaluation data from students who were enrolled in the
authors’ ISD course during 2008, 2009 and 2010. Since software development usually varies according to information system types, the
complexity of the participants’ composition can be seen from various types of development in the surveyed organization and student teams.
To minimize threats to external validity, we conduct the study in the SE education domain, thus declaring an application scope of the tool
introduced in this study. For applying the tool in the same domain, we further address the issue of training. Since students are inexperienced
in project development and meeting operations, they must be prepped at the beginning of the project. Hence we suggest that training in
project planning and the MFS be given to ensure that individuals have sufficient knowledge for executing the project and the tool. Yet
another external validity issue pertains to similar results being obtained in other senior projects. We suggest that such a repeatability issue
be further addressed by using the CMMI’s four common features (i.e., ability to perform, commitment to performance, and verifying and
directing the implementation) and the associated generic practices (Bamberger, 1997; Chen & Chen, 2009; SEI, 2006) in order to institu-
tionalize the performance.
One threat that may have affected the internal validity of the evaluation was the linkage between the research questions of this paper and
the survey questions in the tool evaluation. To address this issue, we designed the survey questions on the basis of the two educational
issues and the three syndromes presented in this paper. Accordingly, four question categories were constructed and the questions were
developed based on these categories. The questions were directly linked to the problem domain and to the research issue. Because current
Table 2
A comparison of existing CSCL or PBL related tools.
Tools
GroupScribbles
(Looi et al., 2010)
DriveHQ (Wang, 2009)
VCS
(Milentijevic et al., 2008)
BSCW
(Nicol & MacLeod, 2005)
Synergeia/FLE3
(Rubens, Emans,
Leinonen, Skarmeta,
& Robert-Jan Simons, 2005)
PT (Janssen, Erkens,
Kanselaar, & Jaspers, 2007)
CoDE (Puntambekar, 2006)
NUCLEO
(Sancho-Thomas et al., 2009)
MFS (This implementation)
Intended operating Role in CSCL Role in PBL Providing tools Showing contexts Engaging stakeholder
environment for designing among group involvement
group activities collaborative activities
Classroom Micro-level instruction Internal behaviour N/A N/A Anonymous
C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817
of a group activity effectiveness within participation
a project’s group task
Classroom Same as above Same as above N/A N/A Showing students’ identity
when participating in a
group learning task
Project environments N/A Training various developers N/A Versioned documentation Same as above
to share project’s contents contents resulting from
group practices
Project environments A hardware environment Training various developers N/A N/A Same as above
for running project group to share files in a controlled
activities computerized venue
Virtual classroom Micro-level instruction Internal behaviour N/A N/A Same as above
of an online group activity effectiveness inside a
project’s group task
Classroom Micro-level instruction Same as above Yes N/A Same as above
of a group activity
Virtual classroom Same as above Same as above N/A N/A Same as above
Project environments Micro-level instruction of Same as above N/A N/A Same as above
an online
project group activity
Project environments Macro-level design of group activities A holistic training aspect The design and execution Training in establishing The training in engaging
for a project on project’s teamwork, of collaborative activities the connectivity of a and sustaining various
which is envisioned in forms of meetings project’s collaborative work. stakeholders’ involvement
by a meeting-oriented Preservation of the group in a collaborative
macro-group process. memories throughout project development
a project
815
816 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817

study emphasizes the design and prototype development of the MFS, in the evaluation we focused on the core functional design of the tool
in resolving the research questions. Other extensive evaluation items such as user friendliness, ease of system operation, etc., were not
evaluated in this study, as they were confounding factors in trying to realize the usefulness of the methodology, i.e., the meetings-flow,
inside the tool.
An important threat to conclusion validity (i.e., the reliability of the evaluation result) is the attitude of the testing groups and the
truthfulness of their feedback to the survey and the interview. We address this validity issue by taking the following steps. First, during the
survey, students were told not to provide their personal identity and group information on the questionnaire. Thus, they were able to freely
answer the questions without having to worry that their grades would be affected. Second, for the purpose of reducing on-site time stress
and peer pressure, the survey was administered as a take-home evaluation. Third, for the data produced in the interview, member checking
(Seaman, 1999) was performed by allowing subjects to review and reconfirm the transcripts of their interviews. Finally, we conducted
a simple follow-up questionnaire (a survey about the survey). This was to determine if there was any inappropriate or uncomfortable issue
that arose during the evaluation.

5.3. Limitations of the MFS

In this section, the limitations of the MFS are further noted. First, development for the current version of the MFS tends to be text-based.
For example, the MFS uses a tabular format (see Fig. 9) for users to create and connect the meeting classes, and also to specify the
connections. This could be further improved by being replacing with a graphical presentation and the drag-n’-drop function, so students
might have more fun in learning teamwork and meeting design. Second, the current version of the MFS is not able to be operated in mobile
or wireless environments such as PDAs or smart-phones. The MFS could be improved by extending its usage through mobile technology to
facilitate users in an environment where a computer is not available. Finally, the MFS may require access control over the meetings content.
Though the MFS helps to establish and maintain a project’s meetings contents, currently, the contents are open to all users. This means that
those who should have limited access to certain projects can still see all other projects on the MFS. The MFS should be further embedded
within the RBAC (role-based access control) function of information retrieval to enhance its security.
In addition to technological limitations, the MFS is limited by its knowledge requirement of project planning. Students need to know
project planning methods when they use the MF-Designer to design teamwork and meetings. Students who are unfamiliar with project
planning or project management knowledge may have difficulties in using this tool. It is therefore suggested that the instructor participate
in the design of meetings. Although some students may receive training in Project Management, especially pertaining to the creation of the
WBS in the project planning phase, during their earlier study, for those who do not take related courses the participation of the instructor
creates a hands-on opportunity for students to learn the concept.
As for the evaluation of the current study, it also has a limitation. Since this paper focuses on the design and development of the MFS tool
and since current development of the tool is limited to a research prototype, we emphasized in the evaluation the importance of realizing
the usefulness of the methodology, i.e., the meetings-flow, inside the tool to address the issues raised in this paper. Other extensive
evaluation measures, such as user friendliness, ease of system operations, appearance of interfaces, etc., were not included in this study. As
the tool is better packed and more widely used, an empirical study will be conducted to fully investigate the extensive benefits to users.

6. Conclusion

Managing human involvement is a challenging task in the collaborative development of a software project, and a critical lesson in senior
projects. This paper brought up a holistic perspective on the collaborative work in senior projects, and presented the implementation of an
instructional tool for students in designing and carrying out collaborative project development. The tool and its concept were developed not
only to help design the mandatory collaborations of a senior project, but also to facilitate a meeting-oriented group process that can sustain
a continual execution of collaboration throughout the project. A comparative discussion with related tools points out the design feature of
the MFS, the sustained group venue it promotes, and the integrated role it plays in the CSCL and PBL of software engineering education.
In the future, we will continue to develop the MFS in order to explore its greater value in software engineering education. For example,
we propose to conduct the empirical study mentioned earlier to fully investigate the extensive benefits that the MFS presents to users. We
would also like to focus on the contribution of the MFS towards knowledge management of students’ collaborative learning in project-based
software development training. Thus, in our next study we plan to realize the function for the creation and conveying of group knowledge
enabled by the meetings-flow and MFS; we also plan to look into the educational effectiveness of reproducing the expected group
knowledge for students by using the MFS.

Acknowledgement

This paper thanks research assistant Mr. K.C. Teng for his dedication and devotion to the development of the earlier version of the MFS.
This paper also sincerely thanks Prof. Chin Yuan Ho and his student groups in collaboratively using and evaluating the tool.

References

Abernethy, K., Piegari, G., & Reichgelt, H. (2007). Teaching project management: an experiential approach. Journal of Computing Science in Colleges, 22(3), 198–205.
Bamberger, J. (1997). Essence of the capability maturity model. IEEE Computer, 30(6), 112–114.
Brown, D. W. (2002). Introduction to object oriented analysis: Objects and UML in plain english (2nd ed.). Danvers, MA: John Wiley & Sons Inc.
Boehm, B. W., & Port, D. (2001). Educating software engineering students to manage risk. In: Proceedings of the 23rd international conference on software engineering.
Ceschi, M. (2005 May/June). Project management in plan-based and agile companies. IEEE Software, 22(3), 21–27.
Chamillard, A. T., & Braun, K. A. (2002). The software engineering capstone: structure and tradeoff. ACM SIGCSE, 34(1), 227–231.
Chen, C. Y. (2009). A preliminary study of the meetings-flow approach for conducting student final-year projects. Journal of Computing Science in Colleges, 24(6), 28–34.
Chen, C. Y., & Chen, P. C. (2009). A holistic approach to managing software change impact. Journal of Systems and Software, 82(12), 2051–2067.
Denning, P. (1992). Educating a new engineer. Communications of the ACM, 35(12), 83–97.
 C.-Y. Chen, K.-C. Teng / Computers & Education 56 (2011) 802–817 817

Eppinger, S. (2001). Innovation at the speed of information. Harvard Business Review, 79(1), 149–158.
Favela, J., & Peña-Mora, F. (2001). An experience in collaborative software engineering education. IEEE Software, 18(2), 47–53.
Gallivan, M. J., & Keil, M. (2003). The user–developer communication process: a critical case study. Information Systems Journal, 13, 37–68.
Garcia, A. C. B., Kunz, J., & Fischer, M. (2005). The key to social efficient meetings. International Journal of Project Management, 23, 17–24.
Garrison, D. R., & Vaughan, N. (2008). Blended learning in higher education: Framework, principles, and guidelines. San Francisco, CA: Jossey-Bass.
George, J. M., & Jones, G. R. (2008). Understanding and managing organizational behavior (5th ed.). Englewood Cliffs, NJ: Prentice-Hall.
Goldratt, E. M. (1997). Critical chain. Great Barrington, MA: The North River Press.
Hass, M. R. (2006). Knowledge gathering, team capabilities, and project performance in challenging work environment. Management Science, 52(8), 1170–1184.
Hassan, A. (2008). A methodology for combining development and research in teaching undergraduate software engineering. International Journal of Engineering Education,
24(3), 567–580.
Heller, T. (2000). If only we’d known sooner: developing knowledge of organizational changes earlier in the product development process. IEEE Transactions on Engineering
Management, 47(3), 335–344.
Hilburn, T. B., & Humphrey, W. S. (2002). Teaching teamwork. IEEE Software, 19(5), 72–77.
Holliman, R., & Scanlon, E. (2006). Investigating co-operation and collaboration in near synchronous computer mediated conferences. Computers & Education, 46(3), 322–335.
Hudson, V. F. (2007). The human touch. Industrial Engineer, 39(9), 40–44.
Humphrey, W. S. (2000). Introduction to team software process (TSPi). Reading, MA: Addison Wesley Inc.
Janssen, J., Erkens, G., Kanselaar, G., & Jaspers, J. (2007). Visualization of participation: does it contribute to successful computer-supported collaborative learning. Computers
& Education, 49, 1037–1065.
Jones, G. R. (2007). Introduction to business. New York, USA: McGraw-Hill Inc.
Kitchenham, B., Pickard, L., & Pfleeger, S. L. (1995). Case studies for method and tool evaluation. IEEE Software, 12(4), 52–62.
Lipman, M. (1991). Thinking in education. Cambridge, UK: Cambridge University Press.
Looi, C. K., Chen, W., & Ng, F. K. (2010). Collaborative activities enabled by GroupScribbles (GS): an exploratory study of learning effectiveness. Computers & Education, 54(1),
14–26.
Marchewka, J. T. (2010). Information technology project management. New Jersey: USA: John Wiley and Sons Inc.
Mead, N. R. (2009). Software engineering education: how far we’ve come and how far we have to go. Journal of Systems and Software, 82(4), 571–575.
Melin, U., & Cronholm, S. (2004). Project oriented student work – learning & examination. In: Proceedings of the 9th SIGCSE conference on innovation and technology in
computer science education.
Milentijevic, I., Ciric, V., & Vojinovic, O. (2008). Version control in project-based learning. Computers & Education, 50(4), 1331–1338.
Motschnig-Pitrik, R., & Figl, K. (2007). Developing team competence as part of a person centered learning course on communication and soft skills in project management.
Proceedings of the 37th ASEE/IEEE Frontiers in Education Conference.
Napier, N. P., & Johnson, R. D. (2007). Technical projects: understanding teamwork satisfaction in an introductory IS course. Journal of Information Systems Education, 18(1),
39–48.
Nicol, D. J., & MacLeod, I. A. (2005). Using a shared workspace and wireless laptops to improve collaborative project learning in an engineering design class. Computers
&Education, 44(4), 459–475.
Project Management Institute (PMI). (2004). PMBOK guide: A guide to the project management body of knowledge.
Puntambekar, S. (2006). Analyzing collaborative interactions: divergence, shared understanding and construction of knowledge. Computers & Education, 47(3), 332–351.
Reel, J. S. (1999 May/June). Critical success factors in software projects. IEEE Software, 16(3), 18–23.
Robillard, P. N., & Robillard, M. P. (2000). Types of collaborative work in software engineering. Journal of Systems and Software, 53(3), 219–224.
Roschelle, J., & Teasley, S. (1995). The construction of shared knowledge in collaborative problem solving. In C. O’Malley (Ed.), Computer-supported collaborative learning.
Berlin, Germany: Springer-Verlag.
Rooji, S. W. (2009). Scaffold project-based learning with the project management body of knowledge. Computers & Education, 52(1), 210–219.
Rubens, W., Emans, B., Leinonen, T., Skarmeta, A. G., & Robert-Jan Simons, R. J. (2005). Design of web-based collaborative learning environments. Computers & Education,
45(3), 276–294.
Sancho-Thomas, P., Fuentes-Fernandez, R., & Fernandez-Manjon, B. (2009). Learning teamwork skills in university programming courses. Computers & Education, 53(2),
517–531.
Schlimmer, J. C., Fletcher, J. B., & Hermens, L. A. (1994). Team-oriented software practicum. IEEE Transactions on Education, 37(2), 212–220.
Scragg, G., Baldwin, D., & Koomen, H. (1994). Computer science needs an insight-based curriculum. ACM SIGCSE Bulletin, 26(1), 150–154.
Seaman, C. (1999). Qualitative methods in empirical software engineering. IEEE Transactions on Software Engineering, 25(4), 557–572.
SEI. (2006). Capability maturity model integration. Pittsburgh, PA, USA: Carnegie Mellon University Press.
Smith, K. A., Sheppard, S. D., Johnson, D. W., & Johnson, R. T. (2005). Pedagogies of engagement: classroom-based practices. Journal of Engineering Education, 94(1), 87–101.
Steele-Johnson, D. (2000). Goal orientation and task demand effects on motivation, affect, and performance. The Journal of Applied Psychology, 85(5), 724–738.
Tiwana, A. (2004). Beyond the black box: knowledge overlaps in software outsourcing. IEEE Software, 21(5), 51–58.
The Standish Group. (2007). CHAOS summary for 2006. West Yarmouth, MA: USA.
Van der Duim, L., Andersson, J., & Sinnema, M. (2007). Good practices for educational software engineering projects. In: Proceedings of the 29th international conference on
Software Engineering.
Van Vliet, H. (2006). Reflections on software engineering education. IEEE Software, 23(3), 55–61.
Wang, Q. (2009). Design and evaluation of a collaborative learning environment. Computers & Education, 53(4), 1138–1146.
Yates, J., & Orlikowski, W. J. (1992). Genres of organizational communication: a structurational approach to studying communications and media. Academy Management
Review, 17, 299–326.
Yoshioka, T., Herman, G., Yates, J., & Orlikowski, W. J. (2001). Genre taxonomy: a knowledge repository of communicative actions. ACM Transactions on Information Systems,
19(4), 431–456.