Experiment Design

Menu

Loading wiki pages...

View
Wiki Version:
<h4><a href="https://osf.io/2tqj7/wiki/Nomenclature/" rel="nofollow">&larr; Back to Nomenclature</a></h4> <h2>Experiment Design</h2> <p>This wiki article lays out the design and the execution plan of the experiment to test whether the Framework developed for introductory programming courses is effective in enhancing the beginning students' ability to program concepts without overwhelming them with the syntax of a new programming language.</p> <h3>Nomenclature</h3> <p>Understanding of this project's experiment design relies heavily on the reader's knowledge of a few key terms used throughout this document. Please refer to <a href="https://osf.io/2tqj7/wiki/Nomenclature/" rel="nofollow">Nomenclature</a> article of this wiki to review the definitions of those key terms applicable to this project.</p> <h3>The Environment</h3> <p>The experiment for the project will be conducted throughout the <strong>Winter 2018</strong> quarter at <strong>California Polytechnic State University</strong>, during which the first-year computing major students (Software Engineering, Computer Science, Computer Engineering) take the course Fundamentals of Computer Science I (CPE-101).</p> <p>The primary investigator will be the instructor of a single offering (section) of CPE-101, and there will be around 30 students enrolled in the offering of the course. The offering will be composed of three hours of common lecture time and two separate three-hour lab times per week.</p> <p>All 30 students will be enrolled in the same lecture hours in which they will receive instruction on introductory programming concepts. During the lectures, concrete examples for the concepts discussed and important techniques necessary to complete the class assignments will be presented, but no step-by-step guide on how to construct a full solution for the assignments will be given. </p> <p>One half (approximately 15) of the students will be treated as a control group and enrolled in the lab hours separately from an experimental group (also approximately 15). </p> <p>The control group they will be taught the methods of programming in a manner that is consistent with the traditional approach, which encourages jumping right into the implementation with the standard programming language chosen for the course.</p> <p>The experimental group will be presented with the Framework and taught the methods of programming with minimal reliance on the standard programming language chosen for the course.</p> <h3>The Framework</h3> <p>The framework to be utilized in the experimental groups' lab hours are mainly composed of the following teaching methods, as described in the <strong>Overview</strong> section of Home article of this wiki:</p> <ul> <li> <p><strong>Design Recipe</strong> from <a href="http://www.htdp.org/2001-01-18/Book/node14.htm" rel="nofollow"><em>How to Design Programs</em></a>, with augmentations to distinguish functional arguments from console and file system I/Os</p> </li> <li> <p><strong>Code Outlining</strong> to externalize the problem-solving steps in easily readable and sharable format</p> </li> <li> <p><strong>Peer Review Process</strong> for students to learn from each other and to practice effectively communicate different ideas for the given problem</p> </li> <li> <p><strong>Automatic Code Template Generation</strong> to minimize the cognitive load spent on familiarizing oneself with the syntactic structure of the implementation language</p> </li> <li> <p><strong>Automatic Unit Test Generation</strong> to reduce the introductory-level learning curve to test-driven development while still encouraging thinking through the given problem sufficiently prior to implementation</p> </li> </ul> <p>As the secondary goal in the <strong>Overview</strong> of this project stated, the development of electronic tools and the workflow around such tools to allow the efficient integration of the above framework is also being considered.</p> <p>However, important to note is that the above framework does not necessarily require any extra tools to be implemented in a classroom setting. The main goal of this project, to validate this framework, can and will be achieved in a manner that does not introduce coupling of the framework to any tools developed for efficient integration.</p> <h3>The Execution</h3> <p>Throughout the ten-week duration of the quarter, two groups of students (control and experimental, each enrolled in different lab hours) will receive the same lectures, but will be presented with different tools and procedures to complete lab and project assignments.</p> <p>The control group will be presented with the traditional methods of test-driven development and restricted peer evaluation or collaboration, whereas the experimental group will receive instructions with heavy emphasis on code outline construction, peer review of the outlines and feedback exchange, and test value (example) compositions.</p> <p>There will be planned quizzes and "midterm" exams throughout the quarter, which will present all students with the same questions, including a small number of questions designed to test the <em>ability to program</em> as defined in the <strong>Nomenclature</strong> section.</p> <p>During the three-hour final exam that is scheduled at the very end of the academic term, which will be the same exam given to all students enrolled in the course university-wide, a question similar to the ones presented in the midterms will be included.</p> <p>By collecting the scores earned on the exam problems by different groups (control and experimental during the midterm, control and experimental during the final exam, and potentially all other students during the final exam) and analyzing the differences, we will be able to validate if the Framework was effective in making a statistically significant difference in the experimental groups' <em>ability to program</em>.</p> <p>In addition to validating the Framework based on the exam results, in-person interviews, surveys, and inspection of the student assignment submissions will be performed throughout the academic term to determine the students' reaction to the integration of the Framework into the teaching of the course. </p> <p>Collection and analysis of student reaction data is expected to reveal the magnitude of marginal <em>friction</em> introduced by integrating the Framework into the course. In the case that this friction is determined to be overshadowing the benefits the Framework is expected to produce in students' <em>ability to program</em>, a set of suggestions for potentially reducing such friction shall be provided with the publication of the benefits of the Framework alone.</p> <p>For more detailed information on data collection and analysis, please refer to <a href="https://osf.io/2tqj7/wiki/Validation%20Plan/" rel="nofollow">Validation Plan</a> article of this wiki.</p> <p><br></p> <h4><a href="https://osf.io/2tqj7/wiki/Validation%20Plan/" rel="nofollow">&rarr; Continue to Validation Plan</a></h4>
OSF does not support the use of Internet Explorer. For optimal performance, please switch to another browser.
Accept
This website relies on cookies to help provide a better user experience. By clicking Accept or continuing to use the site, you agree. For more information, see our Privacy Policy and information on cookie use.
Accept
×

Start managing your projects on the OSF today.

Free and easy to use, the Open Science Framework supports the entire research lifecycle: planning, execution, reporting, archiving, and discovery.