Capstone, Dickinson, Braught
(→Notes to Instructor)
|Line 80:||Line 80:|
Revision as of 13:47, 8 September 2018
|Course||Computer Science Senior Seminar|
|Instructor(s)||Grant Braught, Dickinson College|
|Term||First offered as COMP491/492 in Academic Year 2016-17 at Dickinson College. Revised for the 2017-18 Academic Year.|
|Course Overview||A two-semester required senior capstone including perspective on and experience with H/FOSS projects. In the first semester students complete readings, exercises and activities that familiarize them with H/F/OSS philosophy/community/tools. They complete exercises to help them select an H/FOSS project in which to participate and form teams. They then begin a series of exercises that include: Installing the project as a user; Installing the project as a developer; Rebuilding the project from source; Running the test suite; Verifying bugs from the issue tracker (Bug Gardening); and Fixing bugs. During the second semester students continue work on their selected H/F/OSS project fixing bugs and proposing additional contributions to the project that have value both to them and their H/FOSS community. Students also complete readings on contemporary and ethical issues in computing and participate in class discussions on these topics.|
|Course Length||Two 14-week semesters.|
|Student Characteristics||Typically offered to 10-20 senior computer science majors per year.|
|Prerequisites||This course was designed for use in the final year of a Computer Science major at a small liberal arts college. Students having completed the first three years of an undergraduate CS curriculum should be well prepared for this course. Our students typically have completed the core courses and are competent in: Object Oriented Programming (2 courses in Java), Data Structures (in Java), Analysis of Algorithms, Programming Languages (including C/C++, Python, Scheme, Prolog), Organization and Architecture. They may also have completed additional electives (e.g. Operating Systems, Networking, AI, Databases) and other core courses (e.g. Theory of Computation).|
|Infrastructure|| The course outlined below assumes 28 75-minute course meetings (2 per week) per semester, plus a 3-hour final exam period. Students are expected to average between 8 and 12 hours of work outside of class per week.
Many of the activities and assignments rely on the use of particular technologies. These can be substituted with equivalent technologies but are currently:
- Recognize the ethical, legal and social implications of computing.
- Be exposed to H/F/OSS and Software Engineering topics.
- Improve their ability to work (reading/modifying/testing) within a substantial existing code base.
- Interact with a community of developers and users.
- Deepen their ability to write clearly and develop their mastery of specific forms of disciplinary writing.
- Be prepared for graduate study or a professional career in computing.
Methods of Assessment
The following assessment mechanisms will be used:
- Forum Postings: Students will post (in Moodle) discussion questions based on reading assignments to guide the subsequent in-class discussion. [LO: 1,2,6]
- Reflective Writing:
- Following each discussion students complete a reflective blog entry clarifying and/or expanding their understanding of the material. [LO: 1,2,5,6]
- Each week of project work teams summarize actions, accomplishments, existing challenges and proposing work for the following week on thei team wiki. [LO: 3,4,5,6]
- Live-Texting: Students will live-text (using Slack) while working on the projects as documentation of their efforts. [LO: 3,4]
- Completion Criterion Meetings: Each project activity (User Install, Developer Install, Bug Gardening, Bug Fix) have completion criterion. Teams schedule a meeting with the instructor to demonstrate that they have been met. [LO: 5,6]
- Homework: Early course meetings (during project selection) specific homework assignments are given, each with its own deliverable. [LO: 2,3,4]
- Project Checkpoint Presentations: Project teams will schedule presentations for each of the project check points. These will be 10 minute, in-class presentations with content dependent upon the specific check point. [LO: 2,3,4,5,6]
- Poster Presentations: Teams produce a poster and participate in a poster presentation session [LO: 4,5,6,7]
Notes to Instructor
- There is a substantial number of marked assignments in this course (daily attendance, participation and engagement (PAE), blog posts, assignments, project checkpoints, presentations, papers, posters, etc). It can be challenging to keep up and provide quality feedback to everyone. Using class time to provide general feedback to everyone has been an effective strategy.
- Discussion classes were managed by having students post questions that they would like to discuss to a forum. The instructor then reviewed these questions and formed discussion questions for the class meeting. The class was broken into small groups (4-5) that discussed the questions and then reported out to the larger group.
- A Slack plug-in that sends post data (e.g. number of posts per day) through google analytics. This provides a convenient mechanism, in additional to reviewing Slack channels, to check that teams are working consistently across time.
- Project Install (User / Developer) can be easy for some teams and difficult for others. If teams go beyond about two weeks, the instructor spent time debugging the installation process and helping the team to get up and running. This has frequently led to student teams contributing updated installation documentation back to the project.
- The Bug Gardening exercise is easily time-boxed into two weeks or less.
- The Bug Fix exercise extends through the remainder of the year for most teams. Though those that complete one bug fix are able to work with their community to define a new contribution.
- The biggest challenge for students is to become comfortable knowing when and how to ask questions of their communities. This is also in my experience the largest area of growth for students across the course with most becoming active members of their H/FOSS communities by the end of the course.
Overall this course has been successful. Revision plans for the next offering include:
- Revision of the git version control exercises
- Revision of the completion criterion for the developer install to include:
- Producing a VirtualBox appliance for contribution back to community.
- Demonstrating a change in the primary language of the project that requires a rebuild from source.
- Adding trivial test cases, one that passes, one that fails.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Materials linked to by this page may be governed by other licenses.