第五章 結論與建議
附錄一 79 篇文獻來源
[1] Andersson, R., & Roxå, T. (2000). Encouraging students in large classes. ACM SIGCSE Bulletin, 32(1), 176-179.
[2] Gibbs, D. C. (2000). The effect of a constructivist learning environment for field-dependent/independent students on achievement in introductory computer programming.
ACM SIGCSE Bulletin, 32(1), 207-211.
[3] Tesser, H., Al-Haddad, H., & Anderson, G. (2000). Instrumentation: a multi-science integrated sequence. ACM SIGCSE Bulletin, 32(1), 232-236.
[4] Roberts, E. (2000). Strategies for encouraging individual achievement in introductory computer science courses. ACM SIGCSE Bulletin, 32(1), 295-299.
[5] Chase, J. D., & Okie, E. G. (2000). Combining cooperative learning and peer instruction in introductory computer science. ACM SIGCSE Bulletin, 32(1), 372-376.
[6] Zeller, A. (2000). Making students read and review code. ACM SIGCSE Bulletin, 32(3), 89-92.
[7] Wolz, U. (2001). Teaching design and project management with Lego RCX robots. ACM SIGCSE Bulletin, 33(1), 95-99.
[8] Reed, D. (2001). Rethinking CS0 with JavaScript. ACM SIGCSE Bulletin, 33(1), 100-104.
[9] Lischner, R. (2001). Explorations: structured labs for first-time programmers. ACM SIGCSE Bulletin, 33(1), 154-158.
[10] Applin, A. G. (2001). Second language acquisition and CS1. ACM SIGCSE Bulletin, 33(1), 174-178.
[11] Haberman, B., & Kolikant, Y. B.-D. (2001). Activating “black boxes” instead of opening
“zipper”-a method of teaching novices basic CS concepts. ACM SIGCSE Bulletin, 33(3), 41-44.
[12] McDowell, C., Werner, L., Bullock, H., & Fernald, J. (2002). The effects of pair-programming on performance in an introductory programming course. ACM SIGCSE Bulletin, 34(1), 38-42.
[13] George, C. E. (2002). Using visualization to aid program construction tasks. ACM SIGCSE Bulletin, 34(1), 191-195.
[14] Lane, H. C., & VanLehn, K. (2003). Coached program planning: dialogue-based support for novice program design. ACM SIGCSE Bulletin, 35(1), 148-152.
[15] Nagappan, N., Williams, L., Ferzli, M., Wiebe, E., Yang, K., Miller, C., & Balik, S. (2003).
Improving the CS1 experience with pair programming. ACM SIGCSE Bulletin, 35(1), 359-362.
[16] Thomas, L., Ratcliffe, M., & Robertson, A. (2003). Code warriors and code-a-phobes: a study in attitude and pair programming. ACM SIGCSE Bulletin, 35(1), 363-367.
[17] Parker, J., & Becker, K. (2003). Measuring effectiveness of constructivist and behaviourist assignments in CS102. ACM SIGCSE Bulletin, 35(3), 40-44.
[18] Guzdial, M. (2003). A media computation course for non-majors. ACM SIGCSE Bulletin, 35(3), 104-108.
[19] Barros, J. P., Estevens, L., Dias, R., Pais, R., & Soeiro, E. (2003). Using lab exams to ensure
64
programming practice in an introductory programming course. ACM SIGCSE Bulletin, 35(3), 16-20.
[20] VanDeGrift, T. (2004). Coupling pair programming and writing: learning about students' perceptions and processes. ACM SIGCSE Bulletin, 36(1), 2-6.
[21] Katira, N., Williams, L., Wiebe, E., Miller, C., Balik, S., & Gehringer, E. (2004). On understanding compatibility of student pair programmers. ACM SIGCSE Bulletin, 36(1), 7-11.
[22] Mahmoud, Q. H., Dobosiewicz, W., & Swayne, D. (2004). Redesigning introductory computer programming with HTML, JavaScript, and Java. ACM SIGCSE Bulletin, 36(1), 120-124.
[23] Rich, L., Perry, H., & Guzdial, M. (2004). A CS1 course designed to address interests of women.
ACM SIGCSE Bulletin, 36(1), 190-194.
[24] Thomas, L., Ratcliffe, M., & Thomasson, B. (2004). Scaffolding with object diagrams in first year programming classes: some unexpected results. ACM SIGCSE Bulletin, 36(1), 250-254.
[25] DePasquale, P., Lee, J. A., & Pérez-Quiñones, M. A. (2004). Evaluation of subsetting programming language elements in a novice's programming environment. ACM SIGCSE Bulletin, 36(1), 260-264.
[26] Goldman, K. J. (2004). A concepts-first introduction to computer science. ACM SIGCSE Bulletin, 36(1), 432-436.
[27] Kuittinen, M., & Sajaniemi, J. (2004). Teaching roles of variables in elementary programming courses. ACM SIGCSE Bulletin, 36(3), 57-61.
[28] Hanks, B., McDowell, C., Draper, D., & Krnjajic, M. (2004). Program quality with pair programming in CS1. ACM SIGCSE Bulletin, 36(3), 176-180.
[29] Dougherty, J. P., & Wonnacott, D. G. (2005). Use and Assessment of a Rigorous Approach to CS1.
ACM SIGCSE Bulletin, 37(1), 251-255.
[30] Wicentowski, R., & Newhall, T. (2005). Using image processing projects to teach CS1 topics.
ACM SIGCSE Bulletin, 37(1), 287-291.
[31] Soh, L.-K., Samal, A., Person, S., Nugent, G., & Lang, J. (2005). Closed laboratories with embedded instructional research design for CS1. ACM SIGCSE Bulletin, 37(1), 297-301.
[32] Guzdial, M., & Forte, A. (2005). Design process for a non-majors computing course. ACM SIGCSE Bulletin, 37(1), 361-365.
[33] Bailey, T., & Forbes, J. (2005). Just-in-time teaching for CS0. ACM SIGCSE Bulletin, 37(1), 366-370.
[34] McKinney, D., & Denton, L. F. (2005). Affective assessment of team skills in agile CS1 labs: the good, the bad, and the ugly. ACM SIGCSE Bulletin, 37(1), 465-469.
[35] Beck, L. L., Chizhik, A. W., & McElroy, A. C. (2005). Cooperative learning techniques in CS1:
design and experimental evaluation. ACM SIGCSE Bulletin, 37(1), 470-474.
[36] Marques, N. C., Azevedo, F., Morgado, C., & Custódio, J. F. (2005). Using Octave to introduce programming to technical science students. ACM SIGCSE Bulletin, 37(3), 198-202.
[37] Decker, A., Ventura, P., & Egert, C. (2006). Through the looking glass: reflections on using
65
undergraduate teaching assistants in CS1. ACM SIGCSE Bulletin, 38(1), 46-50.
[38] Cliburn, D. C. (2006). A CS0 course for the liberal arts. ACM SIGCSE Bulletin, 38(1), 77-81.
[39] Gonzalez, G. (2006). A systematic approach to active and cooperative learning in CS1 and its effects on CS2. ACM SIGCSE Bulletin, 38(1), 133-137.
[40] Bierre, K., Ventura, P., Phelps, A., & Egert, C. (2006). Motivating OOP by blowing things up: an exercise in cooperation and competition in an introductory java programming course. ACM SIGCSE Bulletin, 38(1), 354-358.
[41] Byckling, P., & Sajaniemi, J. (2006). Roles of variables and programming skills improvement.
ACM SIGCSE Bulletin, 38(1), 413-417.
[42] Lewis, M. C., & Massingill, B. (2006). Graphical game development in CS2: a flexible infrastructure for a semester long project. ACM SIGCSE Bulletin, 38(1), 505-509.
[43] Bennett, A., Briggs, J., & Clark, M. (2006). High school computing clubs: a pilot study. ACM SIGCSE Bulletin, 38(3), 38-42.
[44] Hanks, B. (2006). Student attitudes toward pair programming. ACM SIGCSE Bulletin, 38(3),
[47] Radenski, A. (2007). Digital support for abductive learning in introductory computing courses.
ACM SIGCSE Bulletin, 39(1), 14-18.
[48] Leutenegger, S., & Edgington, J. (2007). A games first approach to teaching introductory programming. ACM SIGCSE Bulletin, 39(1), 115-118.
[49] Lau, K.-K. (2007). Active learning sheets for a beginner's course on reasoning about imperative programs. ACM SIGCSE Bulletin, 39(1), 198-202.
[50] Malan, D. J., & Leitner, H. H. (2007). Scratch for budding computer scientists. ACM SIGCSE Bulletin, 39(1), 223-227.
[51] Frost, D. (2007). Fourth grade computer science. ACM SIGCSE Bulletin, 39(1), 302-306.
[52] Adams, J. C. (2007). Alice, middle schoolers & the imaginary worlds camps. ACM SIGCSE Bulletin, 39(1), 307-311.
[53] Boyer, K. E., Dwight, R. S., Miller, C. S., Raubenheimer, C. D., Stallmann, M. F., & Vouk, M. A.
(2007). A case for smaller class size with integrated lab for introductory computer science. ACM SIGCSE Bulletin, 39(1), 341-345.
[54] Bagley, C. A., & Chou, C. C. (2007). Collaboration and the importance for novices in learning java computer programming. ACM SIGCSE Bulletin, 39(3), 211-215.
[55] Rao, T., & Mitra, S. (2008). An early software engineering approach to teaching cs1, cs2 and ai.
ACM SIGCSE Bulletin, 40(1), 143-147.
[56] Braught, G., Eby, L. M., & Wahls, T. (2008). The effects of pair-programming on individual
66
programming skill. ACM SIGCSE Bulletin, 40(1), 200-204.
[57] Beck, L. L., & Chizhik, A. W. (2008). An experimental study of cooperative learning in cs1. ACM SIGCSE Bulletin, 40(1), 205-209.
[58] Dodds, Z., Libeskind-Hadas, R., Alvarado, C., & Kuenning, G. (2008). Evaluating a breadth-first cs 1 for scientists. ACM SIGCSE Bulletin, 40(1), 266-270.
[59] Sivilotti, P. A., & Laugel, S. A. (2008). Scratching the surface of advanced topics in software engineering: a workshop module for middle school students. ACM SIGCSE Bulletin, 40(1), 291-295.
[60] Janzen, D., & Saiedian, H. (2008). Test-driven learning in early programming courses. ACM SIGCSE Bulletin, 40(1), 532-536.
[61] Lui, A. K., Cheung, Y. H., & Li, S. C. (2008). Leveraging students' programming laboratory work as worked examples. ACM SIGCSE Bulletin, 40(2), 69-73.
[62] Stone, J. A., & Madigan, E. M. (2008). The impact of providing project choices in CS1. ACM SIGCSE Bulletin, 40(2), 65-68.
[63] Falkner, K., & Palmer, E. (2009). Developing authentic problem solving skills in introductory computing classes. ACM SIGCSE Bulletin, 41(1), 4-8.
[64] Boyer, K. E., Phillips, R., Wallis, M. D., Vouk, M. A., & Lester, J. C. (2009). The impact of instructor initiative on student learning: a tutoring study. ACM SIGCSE Bulletin, 41(1), 14-18.
[65] Desai, C., Janzen, D. S., & Clements, J. (2009). Implications of integrating test-driven development into CS1/CS2 curricula. ACM SIGCSE Bulletin, 41(1), 148-152.
[66] Hambrusch, S., Hoffmann, C., Korb, J. T., Haugan, M., & Hosking, A. L. (2009). A multidisciplinary approach towards computational thinking for science majors. ACM SIGCSE Bulletin, 41(1), 183-187.
[67] Rodger, S. H., Hayes, J., Lezin, G., Qin, H., Nelson, D., Tucker, R., . . . Slater, D. (2009).
Engaging middle school teachers and students with alice in a diverse set of subjects. ACM SIGCSE Bulletin, 41(1), 271-275.
[68] Kacmarcik, G., & Kacmarcik, S. G. (2009). Introducing computer programming via gameboy advance homebrew. ACM SIGCSE Bulletin, 41(1), 281-285.
[69] Hundhausen, C., Agrawal, A., Fairbrother, D., & Trevisan, M. (2009). Integrating pedagogical code reviews into a CS 1 course: an empirical study. ACM SIGCSE Bulletin, 41(1), 291-295.
[70] Eagle, M., & Barnes, T. (2009). Experimental evaluation of an educational game for improved learning in introductory computing. ACM SIGCSE Bulletin, 41(1), 321-325.
[71] Arshad, N. (2009). Teaching programming and problem solving to CS2 students using think-alouds. ACM SIGCSE Bulletin, 41(1), 372-376.
[72] Summet, J., Kumar, D., O'Hara, K., Walker, D., Ni, L., Blank, D., & Balch, T. (2009).
Personalizing CS1 with robots. ACM SIGCSE Bulletin, 41(1), 433-437.
[73] Lau, W. W., Ngai, G., Chan, S. C., & Cheung, J. C. (2009). Learning programming through fashion and design: a pilot summer course in wearable computing for middle school students.
67 ACM SIGCSE Bulletin, 41(1), 504-508.
[74] Pivkina, I., Pontelli, E., Jensen, R., & Haebe, J. (2009). Young women in computing: lessons learned from an educational & outreach program. ACM SIGCSE Bulletin, 41(1), 509-513.
[75] Al-Bow, M., Austin, D., Edgington, J., Fajardo, R., Fishburn, J., Lara, C., . . . Meyer, S. (2009).
Using game creation for teaching computer programming to high school students and teachers.
ACM SIGCSE Bulletin, 41(3), 104-108.
[76] Gunion, K., Milford, T., & Stege, U. (2009). Curing recursion aversion. ACM SIGCSE Bulletin, 41(3), 124-128.
[77] Ma, L., Ferguson, J., Roper, M., Ross, I., & Wood, M. (2009). Improving the mental models held by novice programmers using cognitive conflict and Jeliot visualisations. ACM SIGCSE Bulletin, 41(3), 166-170.
[78] Lasserre, P. (2009). Adaptation of team-based learning on a first term programming class. ACM SIGCSE Bulletin, 41(3), 186-190.
[79] Ngai, G., Lau, W. W., Chan, S. C., & Leong, H.-v. (2009). On the implementation of self-assessment in an introductory programming course. ACM SIGCSE Bulletin, 41(4), 85-89.
68
附錄二 資料萃取表
附表 1 編號 6 資料萃取表
Data Extraction Form Title of paper Making students read and review code
Authors Andreas Zeller Journal/Conference ITiCSE
Year 2000 Volume 32 Issue 3 Page # 89-92
School Level □Elementary □Secondary ■College
Course
□Computer Course (elementary & secondary school)
■Introductory Programming (College: CS1-CS majors)
□Second programming course (College: CS2-CS majors)
□Introductory Programming (non-CS majors)
□Other:____________________________
Where the study was
conducted (Country) Germany Programming Language
Taught
□Java □C++ □C □Scratch □Alice □Logo □Lego Mindstorms ■Other: Pascal
Topic/Concept
Emphasized in Particular N/A Teaching
Method/Strategy Peer review code
Rationale
In a "tradition" programming course, students only experience one side of reviewing--the result of the instructor's assessment. What we'd like is that the student also finds herself in a reviewer's situation - struggling with code written by fellow students, and experiencing what it means if a program cannot be read or understood by other people.
Specific
Hardware/Software Used
Praktomat: System for automatic testing, submit assignment, compiling students’
code, automatic grading.
Learning Activities Used in Instruction
1. The student logs into Praktomat and gets her assignment.
2. The student submits her program to Praktomat.
3. Programs that cannot be compiled or fail the test are rejected.
4. After successful submission, the student can retrieve programs of her fellow students in order to read and review them.
5. The student may obtain reviews and re-submit improved versions of her program.
6. Eventually, one of the instructors assesses and grades the program for functionality and understandability.
After a student has submitted her program successfully, she can retrieve a program in order to review it. Reviewing means that the program code could be read and annotated as well as assessed for various style considerations, such as program indentation, consistent usage of identifiers, structure, data flow, etc.
These style criteria
were explained in the course; this same form would later be used by the instructors for the final assessment. Praktomat uses a blind review process: the author's identity is disclosed only after the assessment is done.
An important thing to note is that the final assessment is totally independent from any earlier reviewing. The instructors never see any review, nor do they learn anything about the review process, nor does the grade depend on sent reviews.
Praktomat hides all these details from the instructors, making it a "students only"
business.
In the beginning of our course, each student who would send in a review was allowed to delay the submission of his final program for another week. It turned
69
out that this incentive was not required: people were so eager to obtain reviews that they competed with each other in submitting a large number of early reviews.
Findings
From the student's view, Praktomat usage was a tremendous success. In the official evaluation, students were asked to judge whether some Praktomat usage had improved the quality of their programs:
57.7% confirmed the effectiveness of automatic testing (and an additional 28.8%
confirmed this partially)
61.5% confirmed the effectiveness of reading and reviewing programs of fellow students (and an additional 19.2% confirmed this partially)
63.5% confirmed the effectiveness of having their programs read and reviewed by fellow students (and an additional 13.5% confirmed this partially)
On the average, students who wrote no review at all, had a grade of 1.93; students who wrote one or more reviews reached a grade
of 2.18.
Instructor’s view
The initial effort was high. Creating the assignments and test eases demanded much more effort than in non-automated settings. This was due to the high precision required for automated testing, but also to the high number of possible configurations. (Writing
Prahtomat also took a great deal of work--but this was a one-time effort.)
• Students and instructors perceived a much higher fairness in assessing the students' work. All programs were subjected to the same tests; detailed criteria unified the assessment of programming style.
• We found that automatic testing considerably simplified assessing the
functionality of the program. We also found that the programming style improved much faster than in earlier courses--which we assume is a result of mutual reviewing.
Discussion/ Suggestions
To ensure a maximum of fairness among student reviewers, we implemented a number of rules that assign a solution to a reviewer. Whenever a student asks Praktomat for a program to be reviewed, Praktomat follows these simple rules:
Everyone gets his share.
Praktomat prefers programs which have received a minimum of reviews so far.
This ensures that eventually, every solution is reviewed.
Give, and it shall be given to you.
Praktomat prefers programs whose authors have composed a maximum of reviews. This encourages early and multiple reviewing.
Tit for tat.
Pralctomat prefers programs whose authors have reviewed a program of the requesting student. This means that students review each other in pairs: If student A gives an unsubstantiated review to student B, she must fear that B applies the same low standards when sending him her review of A's program.
Opposites attract. Among all remaining solutions, Praktomat chooses the one whose assignment has a maximum distance from the reviewer's assignment-- and it never chooses a solution below a minimum distance. This discourages
plagiarism.
70
附表 2 編號 10 資料萃取表 Data Extraction Form
Title of paper Second language acquisition and CS1 Authors Anne Gates Applin
Journal/Conference SIGCSE 2001
Year 2001 Volume 33 Issue 1 Page # 174-178
School Level □Elementary □Secondary ■College
Course
□Computer Course (elementary & secondary school)
■Introductory Programming (College: CS1-CS majors)
□Second programming course (College: CS2-CS majors)
□Introductory Programming (non-CS majors)
□Other:____________________________
Where the study was
conducted (Country) USA (Pearl River Community College) Programming Language
Taught
□Java □C++ □C □Scratch □Alice □Logo □Lego Mindstorms ■Other: No information
Topic/Concept
Emphasized in Particular No information Teaching
Method/Strategy
Treatment: The use of programming templates that students add to or modify Control: Having students write programming assignments from scratch
Rationale
A major premise was that reading well-written programs would help students write well-written programs. This seems simple enough and this premise has been studied and verified in English classrooms as well as foreign language
classrooms. The more you read, the better you write. However, retention and understanding are key issues if we are to provide a foundation for further computer science study.
Specific
Hardware/Software Used N/A Learning Activities Used
in Instruction
The first two programming assignments were identical for both groups. In the next three, the students were solving the same problem, but the treatment group was adding coded solutions to larger more complex systems.
Findings
After controlling for certain factors, the statistical analysis showed that students who added to program templates as programming assignments scored better on the comprehensive examination and had higher overall course averages than their counter parts who wrote programs from scratch.
Discussion/ Suggestions
The students in the experimental group complained about the difficulty of the programs during the treatment period.
Explanations including running the first treatment program in the classroom and carefully following the code along with the program run might have resulted in an even larger group effect.
附表 3 編號 20 資料萃取表
Data Extraction Form
Title of paper On understanding compatibility of student pair programmers Authors Tammy VanDeGrift
Journal/Conference SIGCSE
Year 2004 Volume 37 Issue 1 Page # 2-6
School Level □Elementary □Secondary ■College
Course
□Computer Course (elementary & secondary school)
■Introductory Programming (College: CS1-CS majors)
□Second programming course (College: CS2-CS majors)
□Introductory Programming (non-CS majors)
71
□Other:____________________________
Where the study was
conducted (Country) USA Teaching
Method/Strategy Pair programming Topic/Concept
Emphasized in Particular N/A Rationale
However, one concern when using pair programming is that the stronger student will do most of the work, diminishing the learning experience for the weaker partner.
Programming Language Taught
■Java □C++ □C □Scratch □Alice □Logo □Lego Mindstorms □Other: _________________
Specific
Hardware/Software Used N/A
Learning Activities Used in Instruction
To introduce the pair programming concept, students read the paper, “All I Really Need to Know About Pair Programming I Learned in Kindergarten” [8].
Additionally, the instructors demonstrated pair programming, followed by a debriefing session about the roles of drivers and navigators.
Students completed three pair programming projects, with each project spanning two weeks.
Each student wrote individual reports for each project.
These reports served as an accountability mechanism, so that students had to understand the project solution well enough to write about it. Project report guidelines were given to the students: an introduction (purpose of the
application), system use (how a user interacts with the system), process (how the team designed and implemented the solution), system description (internals of the system, descriptions of key algorithms and data structures), testing and evaluation (evidence of test cases, evaluation of the solution), and a conclusion (learning experiences).
Findings
Perception of PP：
Students perceived having more confidence in their solutions, having more understanding of the project solution, and being more efficient in debugging.
Those without prior experience felt that pair programming had more value. Men and women seem to value the experience almost equally. Students more advanced in their studies tended to value the experience more than the freshmen students.
Students felt they benefitted from having a partner for programming projects, since partners helped answer questions, brought complementary sets of ideas and skills to the group, and helped with debugging and problem solving.
Students felt that finding time for meeting with their partners posed the biggest burden. Since the course did not include computer laboratory time; all project work had to be done outside class. Many students at this institution do not live on campus and had to fit working with partners into their commuting schedules.
The next major complaint was working with people with different personalities and different skill levels. Even though students felt this was a disadvantage, only 6.14% mentioned that they would rather choose their own partners for completing the projects. Overall, we see that students felt working in a social setting had both positives and negatives.
Perceptions of Written Reports：
Students valued the chance to explain the project, describe problems they encountered, and write a summary of the project.
However, they felt that writing reports took too much of their time, writing was repetitive after finishing the project, and it felt like “busy”work.
72 Discussion/
Suggestion
Insights Into Students’ Processes： Along with process, written reports gave us insight into the challenges faced and resources used by introductory students. Pair programming, while creating challenges in a few cases, generally created a useful and valuable resource for students. Students struggled with using the Java language (Boolean operators, loops, parameters)and translating their own ideas into functioning code. Course resources, such as previous homework assignments, lecture notes, and the class discussion board helped students overcome
challenges.
附表 4 編號 30 資料萃取表
Data Extraction Form
Title of paper Using image processing projects to teach CS1 topics Authors Richard Wicentowski, Tia Newhall
Journal/Conference SIGCSE
Year 2005 Volume 37 Issue Page #
School Level □Elementary □Secondary ■College
Course
□Computer Course (elementary & secondary school)
■Introductory Programming (College: CS1-CS majors)
□Second programming course (College: CS2-CS majors)
□Introductory Programming (non-CS majors)
□Other:____________________________
Where the study was
conducted (Country) USA Teaching
Method/Strategy Media computation Topic/Concept
Emphasized in Particular
The primary goal of our CS1 project is to reinforce arrays and compound data types through the use of a real world application.
Rationale
In CS1 courses, it is often difficult to come up with large, real-world programming projects that are at an appropriate level and that really excite students.
Programming Language Taught
□Java □C++ ■C □Scratch □Alice □Logo □Lego Mindstorms □Other: _________________
Specific
Hardware/Software Used N/A
Learning Activities Used in Instruction
Our image processing project takes an image file as input, and then provides a menu or GUI interface to the user to select different image manipulation features such as blurring the image or rotating the image. Students implement each image modification as a separate function. Each image manipulation function takes the two dimensional image array as input. To solve the assignment, students must know how arrays are passed to functions, how to access array elements, and how to develop algorithms for processing the pixel array to get the desired effect.
Extra credit parts are used to challenge some of the more ambitious students.
Some of the image manipulation features we suggest as extensions are quite difficult (like rotating the image to an arbitrary angle). We also encourage students to come up with their own features. This is a nice way to allow for some creativity and flexibility in a course where the assignments are often completely defined.
Findings
Overall the students enjoyed the project and felt that it helped them to understand arrays.
Of the surveyed students, over 80% said that they “really enjoyed” or “enjoyed”
the project, and only one student didn’t like the project. Almost all students felt that it was at about the right level of difficulty, and most stated that it would have been difficult to complete without being given the function prototypes for some
73 effects.
Survey results showing percentage of students who answered either ”very helpful” or ”help ful” to questions about how well the assignment helped reinforce their understanding of arrays.
Project Helpful in Reinforcing Understanding of:
arrays in general 86%
semantics of passing arrays 83%
array data access/manipulation 90%
searching and sorting algorithms 67%
Discussion/
Suggestion N/A
附表 5 編號 42 資料萃取表
Data Extraction Form
Title of paper Graphical game development in CS2: a flexible infrastructure for a semester long project
Authors Mark C. Lewis, Berna Massingill Journal/Conference SIGCSE
Year 2006 Volume 38 Issue 1 Page # 509
School Level □Elementary □Secondary ■College
Course
□Computer Course (elementary & secondary school)
□Introductory Programming (College: CS1-CS majors)
■Second programming course (College: CS2-CS majors)
□Introductory Programming (non-CS majors)
□Other:____________________________
Where the study was
conducted (Country) USA Teaching
Method/Strategy Game Development Topic/Concept
Emphasized in Particular N/A
Rationale N/A
Programming Language Taught
■Java □C++ □C □Scratch □Alice □Logo □Lego Mindstorms □Other: _________________
Specific
Hardware/Software Used No information
Learning Activities Used in Instruction
The basic idea of the project is that students will write a game based on a
The basic idea of the project is that students will write a game based on a