One of the topics discussed in Chap. 7, which deals with lab-based teaching, is the integra- tion of software projects in computer science education. We explain the rationale for proj- ect-based learning and concentrate on the actual mentoring process of software projects developed by high school computer science pupils. Project evaluation is an additional important issue that should be addressed in this context. Specifically, questions such as the following ones should be considered: How should pupils’ projects be evaluated? What should be the nature of the evaluation? When should the evaluation take place? How should software projects developed by teamwork be evaluated? How can project evalua- tion enhance learners’ understanding of computer science? Indeed, project evaluation is not a simple task and therefore, should be addressed in the MTCS course.
Activity 69: Construction of a Course-Summary Exam
In this activity, a course-summary exam (e.g., the AP exam) is constructed. In some sense, this activity is similar to the previous activity (Activity 68); it is, however, car- ried out with respect to a different scope of computer science content and learner popu- lation. From the content perspective, a course-summary exam evaluates learners’
knowledge with respect to all the subjects included in the course; from the learner population perspective, a course-summary exam is not intended to be solved by one (or small number of) specific class, but rather by the entire course population. Definitely, these larger scales set a challenge.
In addition to the importance of letting the prospective computer science teachers experience test design and construction processes, we highlight two additional peda- gogical advantages of the facilitation of this task in the MTCS course. First, in order to develop a course-summary exam, the prospective computer science teachers should review the entire course curriculum, and as a result, it is reasonable to assume that they deepen their familiarity with this curriculum. Second, while building the exam ques- tions, they should consider the notion of diversity (see Chap. 3) in order to adopt the exam to a wider learner population that will take it.
Specifically, in this activity, the students work in pairs and construct a course- summary exam together with its evaluation rubric. Then, the following stages can take place:
1. Each pair exchanges its test with another pair and each student solves individually the test that the pair received.
2. Each pair checks the exams of the two students with which they switched the exams according to the valuation rubric it prepared.
3. Based on the exam evaluation, if needed, each pair updates the exam and its evalu- ation rubric.
171 10.3 Project Evaluation
We mention that the focus is placed here on the evaluation of software projects. Clearly, non-software projects can also support learning processes of computer science. See, for example, Activity 84 in Sect. 12.7 for a discussion about the evaluation of non-software projects.
In what follows, we first present several approaches for project evaluation. Then, we suggest several activities about project evaluation to be facilitated in the MTCS course.
We address the evaluation of two kinds of projects: software projects developed by individuals and software projects developed by teams.
10.3.1 Individual Projects
Meerbaum–Salant and Hazzan (2010) suggest three resources for the evaluation of software project developed by pupils individually: the teacher, peers (that is, other pupils in the class), and the pupil who develops the project. We elaborate on each of them.
•
Teacher evaluation can be performed in two ways:– Formative assessment: This assessment is carried out by the teacher during the entire process of project development with respect to (almost) each activity that the student performs. The purpose of formative assessment is to guide the pupils in the develop- ment process in order to support their development process and improve their under- standing of the relevant computer science contents.
– Summative assessment: The teacher performs summative assessment several times during the development process, usually at the end of specific stages, to monitor the students’ and class’ progress.
•
Peer assessment can be carried out, for example, in the following way: The pupils are divided into groups. Each pupil presents his or her project to the other group members and receives their feedback.•
Individual feedback/evaluation can be encouraged by asking each pupil to reflect on his or her work and on the way he or she plans to meet the schedule that the teacher set for the entire class. See Chap. 5 for a broader discussion about reflection and reflective processes.10.3.2 Team Projects
Software projects developed by teams are more common in undergraduate computer sci- ence education, and specifically, in capstone courses that the students study in their senior year. In these courses, undergraduate computer science students develop a software proj- ect, in most cases in teams, that encapsulates what the students have studied during their undergraduate studies.
Studies that address student software projects usually deal with issues such as the assignment of students to groups (Redmond 2001), the coordination of teamwork
10
(Moses et al. 2000), the grading of such projects (Chamillard and Merkle 2002), and ways by which instructors can gain information about the contribution of individual students to the team project (Lawhead and Wilkins 2000).In this spirit, the following discussion about the evaluation of projects developed by teams is especially relevant for software projects developed by undergraduate students, but nevertheless can be applied also in the high school setting.
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 allo- cation with respect to the profession of software engineering is important for several rea- sons. 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 between
•
personal targets and team goals.Team-based rewards may cause social problems, such as the free-rider phenomenon.
•
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 computer science students which aims at motivating both team- work and collaboration as well as the personal contribution of each team member 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 cus- tomer stories as well as the time estimations given by the students at each of the three itera- tions in which the projects were developed throughout the semester. The second ingredient of the grading policy is an individual component (35%), whose main criterion is the per- sonal 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.
Activities 70–72 address project evaluation and aim to further increase students’ aware- ness to the challenges involved in this process.
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 meeting the
schedule according to the team time estimations:
(10%) for iteration 1 (25%) for iteration 2 (25%) for iteration 3 25% – Project documentation
15% – Group evaluation of the academic coach
50% – Weekly reflection Pair programming experience Test-Driven-Development exercise Weekly presence
25% – Performance of a personal role:
Actual implementation
Further development and enhancement 25% – Personal evaluation of the coach