Helping Students Learn To Organize And Manage A Design Project
Bibliographic record
Abstract
Abstract NOTE: The first page of text has been automatically extracted and included below in lieu of an abstract Session 1438 HELPING STUDENTS LEARN TO ORGANIZE AND MANAGE A DESIGN PROJECT A.W. Fentiman, J.T. Demel, R. Boyd, K. Pugsley, P. Dutta The Ohio State University Introduction As part of the NSF-sponsored Gateway Engineering Education Coalition program, some freshman engineering students at The Ohio State University participate in a three- or four-quarter integrated sequence of courses that culminates in a one-quarter team design project. Two groups of students have completed the team design project during the past year. The first group, consisting of students who were calculus-ready when they entered Ohio State in the fall of 1994, took the design course in Spring Quarter 1995 (their third quarter). The other group, students who were not calculus-ready when they entered Ohio State, took an additional quarter of math and physics courses before they began the design course in Autumn Quarter 1995 (their fourth quarter). In the design class, teams of four or five students are required to build and program a robot to negotiate a 4 ft x 9 ft course with a hill in it, picking up blocks placed at prescribed locations and carrying them into the finish area. Figure 1 is a diagram of the course. Points are awarded for each block brought to the finish area. Teams can earn extra points by transferring blocks to an elevated bonus zone beyond the finish area. The robots are tested, both individually and in head-to-head competitions, at the end of the ten-week quarter. Points earned in the individual runs and the head-to-head competition contribute to the team’s course grade. Other activities that are graded throughout the quarter include written and oral reports and laboratory exercises related to various robot subsystems. At the beginning of the design project, each team is required to prepare a detailed design schedule. The schedules are reviewed by the faculty and suggestions are made to help students prepare realistic schedules. Teams in the first pilot group (Spring 1995) were expected to follow their schedules, and faculty informally monitored their progress. However, no formal intermediate deadlines or milestones were set. All teams completed their robots in time for the competition, and all successfully carried at least one block into the finish area. But many of the teams worked nearly around the clock the day or two before the competition. Since the competition was near the end of the quarter when instructors in other courses were giving exams and other term projects were due, spending many hours on the design project had a negative effect on some students’ grades in other courses. It was clear that students needed more help in organizing and managing their design projects. During the second pilot course (Autumn 1995), students were given more guidance in project organization and management. The methods used to help students learn how to organize and manage their design projects and some conclusions about the students’ performance are presented in the remainder of this paper. Helping Students Organize a Project At the beginning of the team design project, students are asked to prepare a design schedule. A detailed, realistic schedule is crucial if the teams are to successfully complete their projects in the ten-week academic term. It is important that the students develop the schedule themselves so that they are forced to think about the tasks that must be done and their relationships to each other. However most students, particularly freshmen, have not had any experience with developing a schedule for a multi-task project and do not know how to begin. $iii’1996 ASEE Annual Conference Proceedings ) ‘.,+,~yy’:
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.003 | 0.012 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.002 | 0.001 |
| Science and technology studies | 0.003 | 0.001 |
| Scholarly communication | 0.007 | 0.004 |
| Open science | 0.003 | 0.006 |
| Research integrity | 0.003 | 0.004 |
| Insufficient payload (model declined to judge) | 0.069 | 0.062 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".