Assessment - Guide to Teaching Computer Science: An Activity-Based Approach - page 191

According to Hazzan ( 2003 ), the evaluation of software projects developed by
teams is analogous to reward allocation to software teams in the industry. The topic
of reward allocation with respect to the profession of software engineering is impor-
tant for several reasons. We mention three reasons which are also relevant for the
evaluation of software projects developed in educational frameworks:

• Teamwork is essential for software development. As a result, conflicts between
the contribution to the teamwork and the way by which rewards are shared may
intensify.
• Software developers are usually highly motivated. This can cause conflicts be-
tween personal targets and team goals.
• Team-based rewards may cause social problems, such as the free-rider phenom-
enon.

Accordingly, a relevant question addressed by the literature is whether to distribute
incentives among team members equally or not.
Dubinsky and Hazzan ( 2005 ) suggest a grading policy for software projects
developed by teams of undergraduate CS students which aims at motivating both
teamwork and collaboration as well as the personal contribution of each team mem-
ber to the project success (see Table 10.1 ). The grading policy is composed of two
main components. The first one is a group component (65 %) whose main criterion
is the meeting of the customer stories as well as the time estimations given by
the students at each of the three iterations in which the projects were developed
throughout the semester. The second ingredient of the grading policy is an indi-
vidual component (35 %), whose main criterion is the personal performance of the
student with respect to his or her development tasks as well as with respect to his or
her personal role in the project.

Table 10.1 A grading policy for software projects developed by teams. (Dubinsky and Hazzan
2005 )
Group component (65 %) Individual component (35 %)

60 %—answer the customer stories and meet-
ing the schedule according to the team time
estimations:

50 %—weekly reflection Pair programming
experience

(10 %) for iteration 1 Test-Driven-Development exercise

(25 %) for iteration 2 Weekly presence

(25 %) for iteration 3 25 %—performance of a personal role:

25 %—project documentation Actual implementation

15 %—group evaluation of the academic coach 25 %—Further development and enhance-

ment personal evaluation of the coach