Most of generation 2
This commit is contained in:
Charlotte Van Petegem
parent
267daf9af4
commit
c7da2aa932
2 changed files with 145 additions and 12 deletions
102
bibliography.bib
102
bibliography.bib
|
|
@ -855,6 +855,20 @@
|
|||
file = {/home/charlotte/sync/Zotero/storage/X4THCVSY/cronfa43520.html}
|
||||
}
|
||||
|
||||
@techreport{danielsonFinalReportAutomated1976,
|
||||
title = {Final {{Report}} on the {{Automated Computer Science Education System}}},
|
||||
author = {Danielson, R. L. and Others, And},
|
||||
year = {1976},
|
||||
month = jun,
|
||||
url = {https://eric.ed.gov/?id=ED125599},
|
||||
urldate = {2024-02-07},
|
||||
abstract = {At the University of Illinois at Urbana, a computer based curriculum called Automated Computer Science Education System (ACSES) has been developed to supplement instruction in introductory computer science courses or to assist individuals interested in acquiring a foundation in computer science through independent study. The system, which uses PLATO terminals, is presently in routine use in several courses at the University of Illinois, and it has been used at Wright Community College in Chicago. Recent changes in programing and technical innovations have increased its instructional effectiveness. The first section of this report describes the goals and design of ACSES. Later sections provide yearly reviews of progress made for the duration of a grant from the National Science Foundation. (EMH)},
|
||||
langid = {english},
|
||||
keywords = {Annual Reports,Computer Assisted Instruction,Computer Science Education,Higher Education,Independent Study},
|
||||
annotation = {ERIC Number: ED125599},
|
||||
file = {/home/charlotte/sync/Zotero/storage/PSFFZRJP/Danielson and Others - 1976 - Final Report on the Automated Computer Science Edu.pdf}
|
||||
}
|
||||
|
||||
@article{dawsonAssessmentRubricsClearer2017,
|
||||
title = {Assessment Rubrics: Towards Clearer and More Replicable Design, Research and Practice},
|
||||
shorttitle = {Assessment Rubrics},
|
||||
|
|
@ -1115,6 +1129,15 @@
|
|||
file = {/home/charlotte/sync/Zotero/storage/L63BQ9D6/Elbadrawy et al. - 2016 - Predicting Student Performance Using Personalized .pdf;/home/charlotte/sync/Zotero/storage/2K9HRDGJ/7452320.html}
|
||||
}
|
||||
|
||||
@inproceedings{engelbart1968research,
|
||||
title = {A Research Center for Augmenting Human Intellect},
|
||||
booktitle = {Proceedings of the {{December}} 9-11, 1968, Fall Joint Computer Conference, Part {{I}}},
|
||||
author = {Engelbart, Douglas C and English, William K},
|
||||
year = {1968},
|
||||
pages = {395--410},
|
||||
file = {/home/charlotte/sync/Zotero/storage/W5GNPHGI/Engelbart and English - 1968 - A research center for augmenting human intellect.pdf}
|
||||
}
|
||||
|
||||
@article{epsteinImmediateFeedbackAcademic2001,
|
||||
title = {Immediate {{Feedback}} during {{Academic Testing}}},
|
||||
author = {Epstein, Michael L. and Epstein, Beth B. and Brosvic, Gary M.},
|
||||
|
|
@ -1639,6 +1662,23 @@
|
|||
file = {/home/charlotte/sync/Zotero/storage/JS69Q9SX/Hollingsworth - 1960 - Automatic graders for programming classes.pdf}
|
||||
}
|
||||
|
||||
@article{hungAutomaticProgrammingAssessment1993,
|
||||
title = {Automatic Programming Assessment},
|
||||
author = {Hung, Sheung-Lun and Kwok, Iam-For and Chan, Raymond},
|
||||
year = {1993},
|
||||
month = mar,
|
||||
journal = {Computers \& Education},
|
||||
volume = {20},
|
||||
number = {2},
|
||||
pages = {183--190},
|
||||
issn = {0360-1315},
|
||||
doi = {10.1016/0360-1315(93)90086-X},
|
||||
url = {https://www.sciencedirect.com/science/article/pii/036013159390086X},
|
||||
urldate = {2024-02-07},
|
||||
abstract = {Software metrics have been used extensively to provide quantitative measures of software characteristics. This paper aims at evaluating the relevance of using software metrics as means of assessing students' performance in programming. The study focusses on the use of four basic software metrics which are combined to form a single assessment score. The four metrics are respectively those which measure programming skill, complexity, programming style and programming efficiency. Measurements suggested that the lines of code metric is a good candidate for measuring programming skill. McCabe's cyclomatic complexity metrics have been adopted for measuring program complexity. Program execution times are used as the measuring yardsticks for programming efficiency. To facilitate automatic assessment, a program analyzer has been constructed which can provide measures of all the relevant software metrics together with the appropriate assessment scores. The tool was tested with sample assignments of Pascal programs and good distribution of marks has been obtained.},
|
||||
file = {/home/charlotte/sync/Zotero/storage/TI5Q63PJ/hung1993.pdf.pdf;/home/charlotte/sync/Zotero/storage/37JRXCS4/036013159390086X.html}
|
||||
}
|
||||
|
||||
@article{huntFastAlgorithmComputing1977,
|
||||
title = {A Fast Algorithm for Computing Longest Common Subsequences},
|
||||
author = {Hunt, James W. and Szymanski, Thomas G.},
|
||||
|
|
@ -1723,6 +1763,18 @@
|
|||
file = {/home/charlotte/sync/Zotero/storage/IW5SWITR/Insa and Silva - 2018 - Automatic assessment of Java code.pdf;/home/charlotte/sync/Zotero/storage/VY7F759E/S1477842417301045.html}
|
||||
}
|
||||
|
||||
@article{isaacson1989automating,
|
||||
title = {Automating the Execution of Student Programs},
|
||||
author = {Isaacson, Peter C and Scott, Terry A},
|
||||
year = {1989},
|
||||
journal = {ACM SIGCSE Bulletin},
|
||||
volume = {21},
|
||||
number = {2},
|
||||
pages = {15--22},
|
||||
publisher = {{ACM New York, NY, USA}},
|
||||
file = {/home/charlotte/sync/Zotero/storage/XVVKJK4A/Isaacson and Scott - 1989 - Automating the execution of student programs.pdf}
|
||||
}
|
||||
|
||||
@inproceedings{jacksonGradingStudentPrograms1997,
|
||||
title = {Grading Student Programs Using {{ASSYST}}},
|
||||
booktitle = {Proceedings of the Twenty-Eighth {{SIGCSE}} Technical Symposium on {{Computer}} Science Education},
|
||||
|
|
@ -2721,6 +2773,21 @@
|
|||
file = {/home/charlotte/sync/Zotero/storage/I8LFXN35/Nidhra and Dondeti - 2012 - Black box and white box testing techniques-a liter.pdf}
|
||||
}
|
||||
|
||||
@techreport{nievergeltACSESAutomatedComputer1976,
|
||||
title = {{{ACSES}}: {{The Automated Computer Science Education System}} at the {{University}} of {{Illinois}}},
|
||||
shorttitle = {{{ACSES}}},
|
||||
author = {Nievergelt, J. and Others, And},
|
||||
year = {1976},
|
||||
month = aug,
|
||||
url = {https://eric.ed.gov/?id=ED134229},
|
||||
urldate = {2024-02-07},
|
||||
abstract = {The Automated Computer Science Educational System (ACSES) has been developed at the University of Illinois for the purpose of providing improved education for the large number of students taking introductory computer science courses. The major components of this system are: a library of instructional lessons, an interactive programing system with excellent error diagnostics, an information retrieval system, an automated exam and quiz system, and several lessons which judge student programs. This report briefly describes each of these components, as well as some ideas on programing language design resulting from this experience, and presents an evaluation of the use of the system over the past three years. (Author)},
|
||||
langid = {english},
|
||||
keywords = {Artificial Intelligence,College Curriculum,Computer Assisted Instruction,Computer Science Education,Information Retrieval,Instructional Innovation,Instructional Systems,Online Systems,Programing Languages},
|
||||
annotation = {ERIC Number: ED134229},
|
||||
file = {/home/charlotte/sync/Zotero/storage/S56CZBGA/Nievergelt and Others - 1976 - ACSES The Automated Computer Science Education Sy.pdf}
|
||||
}
|
||||
|
||||
@article{nirmalakhandanTeachingToolsPromote2007,
|
||||
title = {Teaching {{Tools}} to {{Promote Active Learning}}: {{Case Study}}},
|
||||
shorttitle = {Teaching {{Tools}} to {{Promote Active Learning}}},
|
||||
|
|
@ -3104,6 +3171,24 @@
|
|||
abstract = {Predicting the performance of a student is a great concern to the higher education managements. The scope of this paper is to identify the factors influencing the performance of students in final examinations and find out a suitable data mining algorithm to predict the grade of students so as to a give timely and an appropriate warning to students those who are at risk. In the present investigation, a survey cum experimental methodology was adopted to generate a database and it was constructed from a primary and a secondary source. The obtained results from hypothesis testing reveals that type of school is not influence student performance and parents' occupation plays a major role in predicting grades. This work will help the educational institutions to identify the students who are at risk and to and provide better additional training for the weak students.}
|
||||
}
|
||||
|
||||
@inproceedings{reekTRYSystemHow1989,
|
||||
title = {The {{TRY}} System -or- How to Avoid Testing Student Programs},
|
||||
booktitle = {Proceedings of the Twentieth {{SIGCSE}} Technical Symposium on {{Computer}} Science Education},
|
||||
author = {Reek, Kenneth A.},
|
||||
year = {1989},
|
||||
month = feb,
|
||||
series = {{{SIGCSE}} '89},
|
||||
pages = {112--116},
|
||||
publisher = {{Association for Computing Machinery}},
|
||||
address = {{New York, NY, USA}},
|
||||
doi = {10.1145/65293.71198},
|
||||
url = {https://dl.acm.org/doi/10.1145/65293.71198},
|
||||
urldate = {2024-02-07},
|
||||
abstract = {This paper discusses TRY, a software package for the UNIX1 operating system that tests student programs. The motivation for developing the system is established by describing problems associated with traditional grading methods and electronic program submission. The design and use of the TRY system is discussed, along with the advantages it provides to both the student and the instructor.},
|
||||
isbn = {978-0-89791-298-3},
|
||||
file = {/home/charlotte/sync/Zotero/storage/U3PGR5DM/Reek - 1989 - The TRY system -or- how to avoid testing student p.pdf;/home/charlotte/sync/Zotero/storage/UU7NTE7B/reek1989.pdf.pdf}
|
||||
}
|
||||
|
||||
@inproceedings{renzellaEnrichingProgrammingStudent2020,
|
||||
title = {Enriching Programming Student Feedback with Audio Comments},
|
||||
booktitle = {Proceedings of the {{ACM}}/{{IEEE}} 42nd {{International Conference}} on {{Software Engineering}}: {{Software Engineering Education}} and {{Training}}},
|
||||
|
|
@ -3471,6 +3556,21 @@
|
|||
file = {/home/charlotte/sync/Zotero/storage/KM7R4LCV/5387105.html}
|
||||
}
|
||||
|
||||
@techreport{streibelCriticalAnalysisComputerBased1985,
|
||||
title = {A {{Critical Analysis}} of {{Computer-Based Approaches}} to {{Education}}: {{Drill-and-Practice}}, {{Tutorials}}, and {{Programming}}/{{Simulations}}},
|
||||
shorttitle = {A {{Critical Analysis}} of {{Computer-Based Approaches}} to {{Education}}},
|
||||
author = {Streibel, Michael J.},
|
||||
year = {1985},
|
||||
month = apr,
|
||||
url = {https://eric.ed.gov/?id=ED263881},
|
||||
urldate = {2024-02-07},
|
||||
abstract = {Three major approaches to the use of computers in education are examined, serious limitations of each are presented, and questions are raised as to the efficacy of technologolizing education. The drill and practice approach is shown to embody a deterministic, behavioral technology that turns learning into a systematically-designed and quality-controlled form of work. Computerized tutorial programs are shown to extend the behavioral and technological approach to learning even further by shaping interactions via an external agent's intentions in order to maximize the learner's performance gains. Most seriously, computerized tutorial interactions pre-empt the personal intellectual agency and ultimately inner-directed learning. Finally, the use of computers is shown to limit the learner's mental landscape to objective, quantitative, and procedural tools. A list of references completes the document. (JB)},
|
||||
langid = {english},
|
||||
keywords = {Computer Assisted Instruction,Computer Simulation,Computer Software,Drills (Practice),Futures (of Society),Man Machine Systems,Mastery Learning,Problem Solving,Programed Tutoring,Programing,Teaching Methods},
|
||||
annotation = {ERIC Number: ED263881},
|
||||
file = {/home/charlotte/sync/Zotero/storage/XIYNVFIA/Streibel - 1985 - A Critical Analysis of Computer-Based Approaches t.pdf}
|
||||
}
|
||||
|
||||
@inproceedings{strijbolBlinkEducationalSoftware2023,
|
||||
title = {Blink: {{An Educational Software Debugger}} for {{Scratch}}},
|
||||
shorttitle = {Blink},
|
||||
|
|
@ -4282,7 +4382,7 @@
|
|||
@article{zhidkikhReproducingPredictiveLearning2024,
|
||||
title = {Reproducing {{Predictive Learning Analytics}} in {{CS1}}: {{Toward Generalizable}} and {{Explainable Models}} for {{Enhancing Student Retention}}},
|
||||
shorttitle = {Reproducing {{Predictive Learning Analytics}} in {{CS1}}},
|
||||
author = {Zhidkikh, Denis and Heilala, Ville and Petegem, Charlotte Van and Dawyndt, Peter and J{\"a}rvinen, Miitta and Viitanen, Sami and Wever, Bram De and Mesuere, Bart and Lappalainen, Vesa and Kettunen, Lauri and H{\"a}m{\"a}l{\"a}inen, Raija},
|
||||
author = {Zhidkikh, Denis and Heilala, Ville and Van Petegem, Charlotte and Dawyndt, Peter and J{\"a}rvinen, Miitta and Viitanen, Sami and De Wever, Bram and Mesuere, Bart and Lappalainen, Vesa and Kettunen, Lauri and H{\"a}m{\"a}l{\"a}inen, Raija},
|
||||
year = {2024},
|
||||
month = jan,
|
||||
journal = {Journal of Learning Analytics},
|
||||
|
|
|
|||
55
book.org
55
book.org
|
|
@ -3,7 +3,7 @@
|
|||
#+AUTHOR: Charlotte Van Petegem
|
||||
#+LANGUAGE: en-gb
|
||||
#+LATEX_CLASS: book
|
||||
#+LATEX_CLASS_OPTIONS: [paper=240mm:170mm,numbers=noendperiod,BCOR=10mm,DIV=10]
|
||||
#+LATEX_CLASS_OPTIONS: [paper=240mm:170mm,parskip=half-,numbers=noendperiod,BCOR=10mm,DIV=10]
|
||||
#+LATEX_COMPILER: lualatex
|
||||
#+LATEX_HEADER: \usepackage[inline]{enumitem}
|
||||
#+LATEX_HEADER: \usepackage{shellesc, luacode}
|
||||
|
|
@ -138,7 +138,7 @@ Finally, we will give a brief overview of the remaining chapters of this dissert
|
|||
|
||||
Increasing interactivity in learning has long been considered important, and furthermore, something that can be achieved through the addition of (web-based) IT components to a course\nbsp{}[cite:@vanpetegemPowerfulLearningInteractive2004].
|
||||
This isn't any different when learning to program: learning how to solve problems with computer programs requires practice, and programming assignments are the main way in which such practice is generated\nbsp{}[cite:@gibbsConditionsWhichAssessment2005].
|
||||
[cite/t:@cheangAutomatedGradingProgramming2003] identified the labor-intensive nature of assessing programming assignments as the main reason why students are given few such assignments when ideally they should be given many more.
|
||||
[cite/t:@cheangAutomatedGradingProgramming2003] identified the labor-intensive nature of assessing programming assignments as the main reason why students are given few such assignments when in an ideal world they should be given many more.
|
||||
Automated assessment allows students to receive immediate and personalized feedback on each submitted solution without the need for human intervention.
|
||||
Because of its potential to provide feedback loops that are scalable and responsive enough for an active learning environment, automated source code assessment has become a driving force in programming courses.
|
||||
|
||||
|
|
@ -148,8 +148,7 @@ Because of its potential to provide feedback loops that are scalable and respons
|
|||
:END:
|
||||
|
||||
Automated assessment was introduced into programming education in the late 1950s\nbsp{}[cite:@hollingsworthAutomaticGradersProgramming1960].
|
||||
In this first system, programs were submitted in assembly on punch cards.
|
||||
(For the reader who is not familiar with punch cards, an example of one can be seen in Figure\nbsp{}[[fig:introductionpunchard]]).
|
||||
In this first system, programs were submitted in assembly on punch cards[fn:: For the reader who is not familiar with punch cards, an example of one can be seen in Figure\nbsp{}[[fig:introductionpunchard]].].
|
||||
In the early days of computing, the time of tutors was not the only valuable resource that needed to be shared between students; the actual compute time was also a shared and limited resource.
|
||||
Their system made more efficient use of both.
|
||||
[cite/t:@hollingsworthAutomaticGradersProgramming1960] already notes that the class sizes were a main motivator to introduce their auto-grader.
|
||||
|
|
@ -172,9 +171,9 @@ In more modern terminology, Naur's "formally correct" would be called "free of s
|
|||
|
||||
[cite/t:@forsytheAutomaticGradingPrograms1965] note another issue when using automatic graders: students could use the feedback they get to hard-code the expected response in their programs.
|
||||
This is again an issue that modern graders (or the teachers creating exercises) still need to consider.
|
||||
[cite/t:@forsytheAutomaticGradingPrograms1965] solve this issue by randomizing the inputs to the student's program.
|
||||
Forsythe & Wirth solve this issue by randomizing the inputs to the student's program.
|
||||
While not explicitly explained by them, we can assume that to check the correctness of a student's answer, they calculate the expected answer themselves as well.
|
||||
Note that\nbsp{}[cite/t:@forsytheAutomaticGradingPrograms1965] were still writing a grading program for each different exercise.
|
||||
Note that in this system, they were still writing a grading program for each different exercise.
|
||||
|
||||
[cite/t:@hextAutomaticGradingScheme1969] introduce a new innovation: their system could be used for exercises in several different programming languages.
|
||||
They are also the first to implement a history of student's attempts in the assessment tool itself, and mention explicitly that enough data should be recorded in this history so that it can be used to calculate a mark for a student.
|
||||
|
|
@ -182,19 +181,49 @@ They are also the first to implement a history of student's attempts in the asse
|
|||
Other grader programs were in use at the time, but these did not necessarily bring any new innovations or ideas to the table\nbsp{}[cite:@braden1965introductory; @berryGraderPrograms1966; @temperlyGradingProcedurePL1968].
|
||||
|
||||
The systems described above share an important limitation, which is inherent to the time at which they were built.
|
||||
Computers were big and heavy, and had operators who did not necessarily know whose program they were running or what those programs were.
|
||||
(Engelbart's Mother of All Demos, widely considered the birth of the idea of the personal computer, only happened in 1968.)
|
||||
Computers were big and heavy, and had operators who did not necessarily know whose program they were running or what those programs were.[fn:: The Mother of All Demos by [cite/t:@engelbart1968research], widely considered the birth of the /idea/ of the personal computer, only happened after these systems were already running.]
|
||||
So, it should not come as a surprise that the feedback these systems gave was slow to return to the students.
|
||||
|
||||
*** Using scripts and tools
|
||||
*** Tool- and script-based assessment
|
||||
:PROPERTIES:
|
||||
:CREATED: [2024-02-06 Tue 17:29]
|
||||
:END:
|
||||
|
||||
We now take a leap forward in time to the 1980s.
|
||||
We now take a leap forward in time.
|
||||
The way people use computers has changed significantly, and the way assessment systems are implemented changed accordingly.
|
||||
Note that while the previous section was complete (as far as we could find), this section is decidedly not so.
|
||||
At this point, the explosion of automated assessment systems/automated grading systems for programming education had already set in.
|
||||
To describe all platforms would take a full dissertation in and of itself.
|
||||
So from now on, we will pick and choose systems that brought new and interesting ideas that stood the test of time[fn:: The ideas, not the platforms. As far as we know none of the platforms described in this section are still in use.].
|
||||
|
||||
*** Onto the web
|
||||
ACSES, by [cite/t:@nievergeltACSESAutomatedComputer1976], was envisioned as a full course for learning computer programming.
|
||||
They even designed it as a full replacement for a course: it was the first system that integrated both instructional texts and exercises.
|
||||
Students following this course would not need personal instruction[fn:: In the modern day, this would probably be considered a MOOC (except that it obviously wasn't an online course).].
|
||||
|
||||
Another good example of this generation of grading systems is the system by [cite/t:@isaacson1989automating].
|
||||
They describe the functioning of a UNIX shell script, that automatically e-mails students if their code did not compile, or if they had incorrect outputs.
|
||||
It also had a configurable output file size limit and time limit.
|
||||
Student programs would be stopped if they exceeded these limits.
|
||||
Like all assessment systems up to this point, they only focus on whether the output of the student's program is correct, and not on the code style.
|
||||
|
||||
[cite/t:@reekTRYSystemHow1989] takes a different approach.
|
||||
He identifies several issues with gathering students' source files, and then compiling and executing them in the teacher's environment.
|
||||
Students could write destructive code that destroys the teacher's files, or even write a clever program that alters their grades (and covers its tracks while doing so).
|
||||
His TRY system therefore has the avoidance of teachers testing their students' programs as an explicit goal.
|
||||
Another goal was avoiding giving the inputs that the program was tested on to students.
|
||||
These goals were mostly achieved using the UNIX =setuid= mechanism[fn:: Note that students were thus using the same machine as the instructor, i.e., they were using a true multi-user system, as in common use at the time.].
|
||||
Every attempt was also recorded in a log file in the teacher's directory.
|
||||
Generality of programming language was achieved through intermediate build and test scripts that had to be provided by the teacher.
|
||||
|
||||
This is also the first study we could find that pays explicit attention to how expected and generated output is compared.
|
||||
In addition to the basic character-by-character comparison, it is also supported to define the interface for a function that students have to call with their outputs.
|
||||
The instructor can then link an implementation of this function in the build script.
|
||||
|
||||
Even later, automated assessment systems were built with graphical user interfaces.
|
||||
A good example of this is ASSYST\nbsp{}[cite:@jacksonGradingStudentPrograms1997].
|
||||
ASSYST also added evaluation on other metrics, such as runtime or cyclomatic complexity (as suggested by\nbsp{}[cite:@hungAutomaticProgrammingAssessment1993]).
|
||||
|
||||
*** Moving to the web
|
||||
:PROPERTIES:
|
||||
:CREATED: [2024-02-06 Tue 17:29]
|
||||
:END:
|
||||
|
|
@ -2631,6 +2660,10 @@ Another important aspect that was explicitly left out of scope in this manuscrip
|
|||
:CUSTOM_ID: chap:discussion
|
||||
:END:
|
||||
|
||||
Dodona is a pretty good piece of software.
|
||||
People use it, and like to use it, for some reason.
|
||||
We should probably try make sure that this is still the case in the future.
|
||||
|
||||
#+LATEX: \appendix
|
||||
* Pass/fail prediction feature types
|
||||
:PROPERTIES:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue