Extended computing integrated curricula scored for K-12 CS standards
Data files
Apr 23, 2024 version files 67.08 KB
-
CIA_Coding_Combined_Cleaned.csv
-
README.md
Apr 23, 2024 version files 67.47 KB
-
CIA_Coding_Combined_Cleaned.csv
-
README.md
Abstract
Integrated computing curricula combine learning objectives in computing with those in another discipline, like literacy, math, or science, to give all students experience with computing, typically before they must decide whether to take standalone CS courses. One goal of integrated computing curricula is to provide an accessible path to an introductory computing course by introducing computing concepts and practices in required courses. This dataset analyzed integrated computing curricula to determine which CS practices and concepts they teach and how extensively and, thus, how they prepare students for later computing courses. The authors conducted a content analysis to examine primary and lower secondary (i.e., K-8) curricula that are taught in non-CS classrooms, have explicit CS learning objectives (i.e., CS+X), and that took 5+ hours to complete. Lesson plans, descriptions, and resources were scored based on frameworks developed from the K-12 CS Framework, including programming concepts, non-programming CS concepts, and CS practices.
README: Extended computing integrated curricula scored for K-12 CS standards
https://doi.org/10.5061/dryad.j6q573nnt
Framework Development and Scoring Training
Full details about the framework development and training for the scorers can be found at Margulieux, L. E., Liao, Y-C., Anderson, E., Parker, M. C., & Calandra, B. D. (2024). Intent and extent: Computer science concepts and practices in integrated computing. ACM’s Transactions on Computing Education. doi: 10.1145/3664825
Description of the data and file structure
The listed computing integrated extended curricula were scored for which concepts and practices they included. The concepts and practices are based on the K-12 CS framework.
Computer Science Practices & Non-Programming Concepts
1 = Present, Blank = Not present
Programming Concept Codes
Mutually exclusive codes
- Nothing - students do not use the concept, or they use a program that has the concept in the background but do not interact with it (e.g., if a Scratch program has a sprite that sets up the background, but students are never guided to look at that sprite, then they aren’t using it (Action Fractions 4th Pizza lesson has good examples). In block-based languages, interact means at minimum work with a block connected to that block.
- Use/Employ (E) - students are given code related to a concept that they run to understand how it works or answer questions about it, but they do not change anything about it
- Modify (M) - students are given code related to a concept and asked to change something about it, such as change the order of blocks or modify the parameters
- Create (C) - students create a new sequence/algorithm, which might involve dragging new blocks into the workspace, writing new code, or repurposing existing code to create a new sequence (e.g., if a starter project includes disconnected blocks, piecing them together in the correct order would be Create, whereas rearranging the order of an existing sequence would be Modify)
- Unguided (U) - students are given specifications for the concepts to include in a program but not how to implement them (e.g., the program must include 3 sprites)
Non-mutually exclusive codes
- Introduce (I) - when a coding concept is introduced in a non-programming/unplugged context (e.g., related conditionals to decision-making outside of CS) or demoed by the teacher
- Reinforce (R) - when a coding concept is reinforced in a non-programming/unplugged context or demoed by the teacher
- New Feature (N) - when a coding concept is applied with a new feature (e.g., changing the properties of sprites by changing their size, appearance, sound, etc. would each be a new feature)
- Optional (O) - this is a conservative optional, meaning that it doesn’t include all of the possible concepts a student might use or any extra content for advanced students. Instead, it denotes only when a student must pick between different options for completing an assignment (e.g., CS First Storytelling). Thus, our coding focuses on the concepts required to complete the curriculum, not the upper limit of what students might experience during the curriculum.
Coding Decision Tree
Are students doing a programming activity?
- Yes - for each concept used in code that students interact with, what's the highest level that they use between E > M > C > U (which often involves writing over codes as the lesson progresses).
- for each concept, is there a new feature introduced? If yes, add N and descriptor.
- if the concept isn't used or the students don't directly interact with it, leave it blank.
- No - Are there unplugged instructions or teacher demos?
- If yes, then use I (and most likely N).
- If not, leave it blank.
Methods
Search and Inclusion Criteria
While the current dataset used many of the same tools as a systematic literature review to find curricula, it is not a systematic review. Unlike in literature reviews, there are no databases of integrated computing curricula to search systematically. Instead, we searched the literature for evidence-based curricula. We first searched the ACM Digital Library for papers with "(integration OR integrated) AND (computing OR 'computer science' OR CS) AND curriculum" to find curricula that had been studied. We repeated the search with Google Scholar in journals that include "(computing OR 'computer science' OR computers) AND (education OR research)" in their titles, such as Computer Science Education, Computers & Education, and Journal of Educational Computing Research. Last, we examined each entry in CSforAll's curriculum directory for curricula that matched our inclusion criteria.
We used four inclusion criteria to select curricula for analysis. Our first criterion was that curricula must include learning objectives related to programming concepts, non-programming CS concepts, or CS practices. These CS concepts and practices were based on the K-12 CS Framework, and many of the curricula included explicit connections to the K-12 CS Framework or to the Computer Science Teacher Association's CS standards, which are based on the framework. More information about how the framework was used can be found in Margulieux, L. E., Liao, Y-C., Anderson, E., Parker, M. C., & Calandra, B. D. (2024). Intent and extent: Computer science concepts and practices in integrated computing. ACM’s Transactions on Computing Education. doi: 10.1145/3664825.
Our second criterion was that curricula must include at least five hours of instruction. This criterion was necessary to explore how CS instruction develops and evolves over several hours of instruction. It also serves to complement the previous analysis, which analyzed all activities regardless of length and ranged from less than an hour to multiple days, Margulieux, L. E., Parker, M. C., Uzun, G. C., & Cohen, J. D. (2023). Levels of computing concepts used in computing integration activities across disciplines. Journal of Technology and Teacher Education, 31(2), 167-202. Waynesville, NC USA: Society for Information Technology & Teacher Education https://www.learntechlib.org/p/221815/.
Fortunately, many integrated computing curricula fit these criteria. To make the scope of work reasonable, we added two additional inclusion criteria: curricula must be free to access and curricula must be for primary and lower secondary school (i.e., grades K-8 in the United States). For both criteria, we erred on the side of inclusion. For example, we included free curricula that used robotics, such as Bee Bots or KIBO, because schools might receive grants or gifts to purchase robots. In addition, courses that are typically taught in upper secondary school were included if they are commonly taught earlier in an accelerated track, such as Algebra.
The final dataset included 27 curricula from 9 different curricula creators. Within these curricula, there were 519 lessons with over 600 hours of content. Some follow-up curricula to those listed below, such as Scratch Encore or CSinSF’s Green and Blue curricula, were excluded from the analysis because they focus exclusively on CS learning objectives and, thus, were not considered integrated computing. Other common integrated curricula, such as Project GUTS or UCL Scratch Maths, were excluded based on our first criteria for not including CS learning objectives.
Unit of Analysis and Scorers
These 27 curricula were all organized as a compilation of lessons. Lessons were designed to be used during one class period, typically 30 minutes to an hour in length. Lessons were typically discrete, except that final projects would often stretch over multiple lessons. Lessons included multiple activities, such as reviewing previous concepts, introducing new concepts, or completing tasks. For this analysis, the unit of analysis was the lesson. Each lesson typically included a lesson plan describing learning objectives and activities, instructional artifacts like presentations or worksheet activities, and computational artifacts like starter projects or sample projects. These materials provided rich and redundant information about the concepts being taught. Information about which practices were taught was often less explicit.
The five scorers in this analysis were the five authors of this dataset. Four of the five scorers were professors who have studied computer science education for at least 9 years each. Their Ph.D.s are in the areas of computer science, curriculum and instruction, instructional design, and instructional technology. The other scorer was a doctoral student studying computer science education in an instructional technology Ph.D. program.