|A1||X||Preliminary design description (2003.08.01)|
|A2||X||Task analysis by Saturday - actually, Friday afternoon (2003.08.01)|
Needs analysisCS21A: Introduction to Computing is the first of two introductory computer science courses offered by a liberal arts tertiary-level institution, the Ateneo de Manila University. It is taken by all freshmen majoring in computer science and sophomores majoring in management and information systems. Non-majors occasionally take the course as a free elective or as part of their interdisciplinary studies.
For this needs analysis, data was collected from CS21A section B (CS21A-B), the introductory computer science section that I teach. CS21A-B is composed of 16 freshmen majoring in computer science, 3 juniors taking interdisciplinary studies, and 1 graduate student working toward a master's degree in computer science.
This report is based on anonymous polls conducted during section hours, observations of interaction inside and outside the sectionroom, and student feedback through notebooks and projects.
Curricular goals of CS21AIn CS21A, students are expected to learn basic programming concepts (input, output, variables, expressions, Boolean logic, loops, objects, and simple graphical user interfaces) and implement small programs in Java.
Aside from language-specific syntax, they are also expected to learn how to:
- Analyze problems and design solutions: identify subproblems and
objects in a situation and expressing their solution as a series of
step-by-step instructions in clear and precise natural language
- Learn independently: refer to primary sources such as source code
and application programming interfaces (APIs) as well as to
secondary sources such as tutorials and textbooks
- Read programs: determine what a program outputs given certain sets
of input without running the program
- Develop solutions: develop correct, clear, precise,
well-formatted and easy to read programs that meet or exceed the requirements
- Test and debug: systematically identify and fix syntactic and
logical errors in programs
- Write documentation: write clear and understandable natural language descriptions and explanations
Intended learning activity: peer review of programsPeer review of programs can help students improve their programming, testing and writing skills.
Students who are assigned to review non-working programs practice testing and debugging. The students who authored the non-working programs learn how to correct their mistakes and they can ask their reviewers for help understanding a topic.
Students who are assigned to review working programs can comment on how clearly the program demonstrates the topics taught in section. They can also suggest ways for the authors exceed the requirements.
Students may encounter advanced features while reviewing their sectionmates' programs. This helps them develop their ability to learn independently.
|Private e-mail||Students e-mail quizzes and other exercises that should not be shared with their sectionmates. The files are stored in an ordinary e-mail account and filtered by hand into a separate mailbox.|
|Mailing list files||Students upload projects and exercises to the Files section of the section mailing list hosted on http://groups.yahoo.com .|
|Mailing list messages||Students e-mail some files (particularly non-working files that urgently need help) to the section mailing list.|
|Web-based forum||phpBB (http://courses.ateneo.edu/forums/) and WebCT (http://ilearn.ateneo.edu) offer web-based forums with attached files. The section currently does not use these resources.|
|Submissions||Submit v2 can be found at http://courses.ateneo.edu/submit/ . WebCT also supports project submission. The section currently does not use these resources.|
Peer reviewSome students feel that no one else reads their programs. Most expressed a desire to know what other people thought about their programs. Currently, there are few mechanisms for feedback. A few questions have been posted on the mailing list, but most students do not discuss their work there. This is probably done through informal, face-to-face discussions held outside section. Students tend to stay within their clique.
Public recognition is a powerful motivator, according to one of the students' notes: "What we're really proud of is that our project was chosen to be an example for one of the lessons: array (Flashyflash3). It really does pay to read ahead." (jaze)
|Private e-mail||Currently, no peer reviews have been assigned. The teacher can require students to Cc: an assigned partner when submitting a project; however, this means that all the students have to remember all the other people's addresses, or their e-mail submissions are facilitated by a webpage that keeps track of the assigned partners.|
|Mailing list messages||Very little discussion takes place on the mailing list.|
|Mailing list files||No discussion in the files area. However, some students cited other people's programs in their own.|
|Web-based forum||This resource is currently not being used. The teacher can require students to participate in threads, but it may be hard to track their activity.|
|Submissions||The submission systems do not support collaboration or peer review.|
Categorization of programs
Students faced with an unsorted list of programs are discouraged from reviewing other people's work. Some programs do not work yet while others use advanced features not yet discussed in section. Filenames do not give much information.
Organizing the programs according to the features they implement and their readability provides students with a learning guide. Students can then study simpler programs before moving on to more complicated code. They can also look for programs that demonstrate concepts they want to learn. Here are two examples of organized submissions:
Private e-mail The teacher extracts and categorizes each program. Feedback can be slow, but the summary is well-organized. Mailing list messages No categorization is usually done. Keywords in the subject can be helpful. Mailing list files Rough categorization can be done if students upload to the appropriate folders, but it's difficult to do a finer-grained search. Web-based forum Rough categorization can be done if students post to the appropriate threads. Full-text search may help for finer-grained searches. Submissions Not applicable. Students cannot view other students' files. No support for collaboration or searching.
Projects frequently specify standard names for uploaded files to simplify checking and enforce coding standards. Java requires the section name to match the filename.
|Private e-mail||No problem.|
|Mailing list files||The mailing list software does not allow duplicate filenames in one directory. As a result, students have to create directories in order to store files with prescribed names.|
|Mailing list messages||Files can be named the same, but this results in high traffic.|
|Web-based forum||Files can be named the same, but files are available to everyone, and downloading all the files is tedious.|
Activity trackingThe teacher needs to keep track of students' progress through different topics. This is currently manually maintained. Students may also want to see which files have been most recently submitted.
|Private e-mail||The teacher can sort received messages by date or by author. Students cannot see their sectionmates' contributions.|
|Mailing list messages||Archived messages are sorted by date. The mailing list search functions can be used to find a student's most recent posts.|
|Mailing list files||Archived files are sorted by filename. An activity log under the management section helps the teacher monitor student activity, but log entries do not link directly to uploaded files. Students can choose to notify the mailing list when they upload a file. However, students complained about the resulting traffic.|
|Web-based forum||Posts are sorted by date. Threaded discussions like the WebCT forum may make it difficult to track activity inside threads.|
|Submissions||The teacher can see a list of students and their submitted files. Files submitted after the deadline are marked in red. Activity logs are not available.|
ConvenienceMany users do not have easy or inexpensive access to the Internet. They have many accounts and can forget to check special sites.
|Private e-mail||E-mail can be written and read offline. The teacher must sort and extract files individually.|
|Mailing list messages||E-mail can be written and read offline. Users must download files individually.|
|Mailing list files||E-mail notification is possible, but results in unacceptably high traffic. Users must download files individually. If the files are in different folders, users must enter each folder and download each file.|
|Web-based forum||No e-mail interaction, so students might forget to check the site. Users must download files individually. WebCT can show multiple messages on one page.|
|Submissions||No e-mail interaction, so students might forget to check the site. In WebCT, the teacher must download files individually. In Submit v2, the teacher can download all the current project submissions in one archive.|
|Private e-mail||Each message is archived. No problem.|
|Mailing list messages||Each message is archived. No problem.|
|Mailing list files||No versioning. Users can delete their old files and upload new version, or they can name their new versions differently.|
|Web-based forum||Each message is archived. No problem.|
|Submissions||No versioning. Users can overwrite their old files and upload a new version, or they can name their new versions differently.|
Academic BackgroundThe CS21A course requires basic computer skills but does not require previous programming background. Our students are a heterogenous group. Some have extensive programming backgrounds in Turbo Pascal or C++, and some have never programmed at all.
Personal characteristicsBased on the survey and the informal interviews, most students appear to be strongly motivated and enthusiastic about learning. Some are a little hesitant, but try their best even though they feel that their sectionmates far outperform them.
They are interested in games and graphics. They enjoy writing programs that suit their interests or help them with their other academic subjects. They are willing to read ahead in order to implement the features they want.
Social characteristicsBased on the survey and on feedback in their notebooks, peer recognition appears to be very important to the students. They prefer working in groups, and frequently work on their programs over lunch or during their other breaks. However, certain people tend to dominate the discussion, so I need to find some way to involve the other students and help them feel that they have something valuable to contribute.
ConclusionStudents are keen to learn from each other, but peer reviews must be organized so that students are not overwhelmed with information or limited to their cliques.
Major goalStudents will be able to monitor their progress in CS21A through frequent evaluation and practice.
SubgoalsBy using the system, the student will be able to
- post programs for sectionmates to review
- post and read reviews of programs
- discuss programs
- search for programs that demonstrate a concept
EvaluationStudents will be evaluated on their ability to
- write clear, understandable code that helps other students learn
- test and evaluate programs other students wrote
Major goalTeachers will be able to monitor student progress and encourage collaboration.
SubgoalsTeachers will be able to
- assign student projects
- monitor student progress and activity
- grade projects and reviews
- moderate discussions
EvaluationThe system will be compared with informal collaboration, files uploaded to the common webspace, and e-mail discussions. It will be evaluated based on
- how students have interacted with people outside their cliques
- how useful the students find the system for searching for programs relevant to their needs
- the participation of students who are not as active in section and on the discussion list
Task definitionStudents will submit programs for review, evaluate other people's programs and their own progress, and ask and answer questions.
Peer review, categorization of programsThe teacher can evaluate project submissions based on a user-defined rubric. The teacher can also enable student evaluations through a 'buddy' system, where each student is assigned to review another student's code. Buddies can be assigned manually or automatically. Evaluations can be a mix of free-form comments, checklists, and scales. When students upload new versions, their buddies are notified. The evaluated programs can be viewed as a matrix of student submissions versus project topics. In addition, students looking for examples can search for relevant programs.
Students will be paired with 'buddies' for each project. The teacher can specify the buddy assignments or allow the system to set them.
The buddy may be required to post an initial evaluation by a certain deadline. The buddy is responsible for checking the features implemented in a particular project and helping the author look for and fix errors.
After the buddy has posted the initial evaluation, all students can then comment on the project submission. The author is encouraged to upload new versions incorporating suggestions made.
Questions and answers can be handled through a modified bulletin board system.
Namespace collisionsThe system allows users to upload files with the same name.
Activity trackingAll student submissions can be tracked on a matrix, with late submissions marked accordingly. Student progress through topics can also be tracked through project features implemented. Collaboration between students can be viewed as a graph or as an adjacency matrix. This helps teachers ensure that students interact with people outside their clique. Activity logs help users track what programs were recently submitted, reviewed or discussed.
ConvenienceAutomatic archiving of files makes it easy for teachers to download all submissions for a project.
A cross-platform application allows offline participation in the discussion boards and program evaluations, allowing students to collaborate even if they do not have convenient Internet access. They can download packets from the system and disconnect from the Internet, process the packets offline, and then reconnect and upload the reply packets.
Version controlUploaded files are automatically placed under version control, allowing students to submit multiple versions of their project without worrying about overwriting their old files. Users can see the state of the system at arbitrary dates.
Required contributionsTeachers can set required contributions on a per-project basis. For example, teachers can require students to submit evaluations by a certain date. Several deadlines can be specified.
Strategy for moderationBecause some students can dominate an unmoderated discussion, teachers should make sure to encourage students who are not as active. Charts showing student activity will help teachers identify lurkers.
Teachers should also make sure that all programs are reviewed, that reviews are of sufficient quality, all relevant questions are answered, and answers are not mistaken. Students can help keep track of unanswered questions and unreviewed programs as well.
Without intervention, students might confine their reviews to their friends' programs. Teachers need to make sure that students review different people's programs by assigning different pairs of reviewers for each program.
Rules for contributionsDemonstration programs should be short, well-commented, and easily understood. The programs do not have to work at the start, but the author should update the program to incorporate the suggestions from the review.
Tutorials and reviews should be written with the aim of helping the author, one's sectionmates, and other people who are learning how to program. Criticism should be constructive.
TimeframeSemester-long, with frequent deliverables.
CollaboratorsThe main collaboration is between students in a section. The teacher can comment on programs or correct mistakes that other students miss.
Programs and reviews can be shared with the outside world (configurable on a per-project basis). Questions and answers are forwarded to the students.
StructureSubmissions are categorized by project. Within each project, submissions are sorted by student ID, student name, or status and features. Each program page will display a screenshot, links to the program, the review, and questions and answers. Student pages summarize all the contributions made by the student. Teachers can view a number of charts and graphs to help them track student progress.
System designThe server maintains the canonical system data. It will initially store data in XML files in a directory structure, but can be adapted to databases if required.
Users will interact with the system through either of two front-ends. A web-based interface allows users to access the system when online and a Java client allows offline use.
|$BASE_URL/sections/||Sections for the current semester|
|$BASE_URL/sections/$section_id/||List of sections|
|$SECTION_BASE/projects/$project_id/||Description of the project and the list of actions|
|$SECTION_BASE/projects/$project_id/standard.jar||jar of all the standard files|
|$SECTION_BASE/projects/$project_id/submissions/$student_id/code||Base URL for the most recent version of their code.|
|$SECTION_BASE/projects/$project_id/submissions/$student_id/notes/||Base URL for notes and discussion.|
|$BASE_URL/warp/$YYYYMMDD/...||Warps to midnight of the given day|
|$BASE_URL/warp/$YYYYMMDDHH/...url...||Warps to HH:00:00 of the given day (24h)|
|$BASE_URL/warp/$YYYYMMDDHHMM/...url...||Warps to HH:MM:00 of the given day (24h)|
|$BASE_URL/warp/$YYYYMMDDHHMMSS/...url...||Warps to the given time (24h)|
|$SECTION_BASE/people/||Directory of people|
|$SECTION_BASE/people/$person_id/||Description, list of their work|
|$SECTION_BASE/people/progress/$person_id||Activity so far|
|$SECTION_BASE/people/$person_id/progress/||Activity so far|
|$SECTION_BASE/people/$person_id/projects/||List of projects|
File structure: CVS repositoryStudent code is stored in a CVS repository. There is one repository for each sem. There are two modules: sections, people
sectionsCVS directory tree structure:
|sections.xml||an index of all sections|
|$section/||an index of all sections|
|$section/index.xml||a description of the section|
|$section/accounts.xml||a list of students and teachers|
|$section/projects/||student projects (see projects)|
Allowable values for sem: "1st", "2nd", "sum". Example: 2003/1st/cs21a/a/
projectsThe projects directory has one main file - index.xml . When a project is created, $project_id/ is added to the project module. The following files and directories are part of the project:
|project.xml||the project description|
|standard/||support sections and other files|
|submissions/$student_id/code/||the student's code|
|submissions/$student_id/notes.txt||combined notes of the student and the buddy|
|submissions/$student_id/eval.xml||evaluation of the project|
peopleWhen an account is created, $account_id/ is added to the people module. The following files are found in the account directory:
- foaf.rdf - Friend-of-a-Friend description
- sections.xml - A list of section URIs (checked against sections/$section/accounts.xml)
Current mirrorCurrent mirrors are needed very frequently. After every upload, a cvs update is run in the appropriate project directory. This can be found in $BASEDIR/current/sections/$section/projects/$project_id/ Similarly, a current copy of student information and progress is kept in $BASEDIR/current/sections/$section/accounts/
Time warpsTime warp checkouts are handled on a file-by-file basis when done through URL rewriting. Making an archive of timewarped entries uses $BASEDIR/tmp/ as the temporary directory. The timewarp only works for the current semester. People who need past data need to approach the server administrator.