DOI: 10.5061/dryad.j6q573nnt
title: Extended computing integrated curricula scored for K-12 CS standards

description: 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.
description: <strong>Search and Inclusion
 Criteria</strong> 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 <em>Computer
 Science Education</em>, <em>Computers &
 Education</em>, and <em>Journal of Educational Computing
 Research</em>. 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., <em>Anderson, E.</em>,
 Parker, M. C., & Calandra, B. D. (2024). Intent and extent:
 Computer science concepts and practices in integrated computing.
 <em>ACM’s Transactions on Computing Education</em>. 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.,
 <em>Uzun, G. C.</em>, & Cohen, J. D. (2023). Levels of
 computing concepts used in computing integration activities across
 disciplines. <em>Journal of Technology and Teacher Education,
 31</em>(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. <strong>Unit of Analysis and
 Scorers</strong> 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. 
description: # **Extended computing integrated curricula scored for K-12 CS standards**
 [https://doi.org/10.5061/dryad.j6q573nnt](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 &gt; M &gt; C &gt; 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.