~~~~~~~~ COURSE PORTFOLIO ~~~~~~~~
Introduction to Computer Science: A Course Portfolio for CSCE 144
Part of the Disciplinary Commons Project
Laurie Murphy (Pacific Lutheran University)
CONTENT
Course Syllabus for CSCE 144
Course Schedule (Fall 2005)
Syllabus Annotations
The annotations below describe my decision process in formulating the syllabus
for the course.
Textbook Choice - Choosing a book for this course
is always difficult as can be seen by the fact that at least every year, if not
every semester, faculty teaching the course choose a different book. Here
are some of the reasons I chose the Lewis & Loftus text:
- It has a thorough introduction section that describes how computers, hardware, software
and the Internet work, as well as the process of editing and compiling programs.
Some introductory texts just jump into the programming process and don't give
the background information on computers, networks and the web. I doubt I'll
spend much time covering this material in class, but for students without
much experience, this could give some much needed insight.
- The topic order seems to basically be in line with what our ad hoc departmental
committee recommends; basic data types and expressions and object creation and use
come before writing classes of one's own, although this is still done before
selection and iteration, which may be too early. We'll see...
- The text uses Java 1.5 which should be helpful for the students' transition to
CSCE 270.
- Advanced topics like inheritance, polymorphism, exceptions and recursion
are covered later in the book.
- The book has many self-review exercises (with answers), exercises and some
programming assignments at the end of each chapter.
- The book is quite readable and I think will be accessible to students. I
like the "key concept" boxes that emphasize important points. It is the fourth
edition of the book so I anticipate (and hope!) it will have fewer errors, which
can be very confusing for novice programmers.
- The student web site looks helpful.
Prerequisite Statement - When I taught the
course three years earlier (and to my knowledge every time it has been taught
by others in the past five years) the statement of prerequisites not only mentioned the
necessary mathematics background, but also
concluded with the following note:
Note also that this course is designed as a first year course for computer
science and computer engineering majors. It is also required for some other
majors including physics. If you are just looking for a course to fill a general
university requirement, then this is probably not the right one for you.
You might want CSCE 120 instead.
This statement is very honest and lets the students know up front what
the course is generally all about. It also reflects some of the frustrations of
faculty who have taught the course in the past that students who "didn't belong" in
the class would quickly be overwhelmed by the material and the amount of work
required by the course. Although I knew I was opening myself and the students
up to the possibility of this same sort of thing happening during the current
semester, I felt strongly that I wanted to present a more inclusive view of the
course. Thus I changed the statement to point out that the course could
be useful to non-majors and a place where students could explore the possibility
of pursuing CS or CE further. One of the best programmers I've had in an
introductory computer science course (CS2) was an English major.
To help alleviate concerns or fears inexperienced students might have,
I also added an explicit statement that previous programming experience was not
required for the course.
Course Goals - My previous statement of goals, which
has changed little since, read:
This course is designed to be an introduction to some of the basic concepts of
computer science within the context of learning a computer language. By the end
of the term you should expect to have a good working knowledge of the Java
language, a rudimentary idea of computer science as a discipline, and have
been exposed to object oriented programming and graphical programming.
I decided to modify the course goals on the syllabus to reflect the course objectives identified
in this portfolio of skill development,
contextualization of computer science and fostering
a hospitable environment. The first two I
stated explicitly. For the last it made more sense to me to actually be hospitable,
sharing with the students my hope that they'd enjoy the class and programming, rather
than to tell the students that I wanted the class atmosphere to be a hospitable
one.
Communication outside of class
In recent years the amount of communication outside of class via email and
the class forum in my classes has increased substantially. I find these
modes of communication extremely valuable for the following reasons:
- email - Students often email me when they are having problems
completing their programming assignments. Nothing beats the fact-to-face
communication of office hours for providing this sort of help. However, I
like email because it forces students to articulate specific questions. They
cannot walk in my office and offer a generic "it doesn't work" or "it crashes".
If their first
(or subsequent emails) don't ask a specific enough question I reply with a
question that prompts them to be specific (e.g., "What does the error message
say?", "What have you done to track down the error?", etc.) Students soon
begin to realize that articulating a precise question the first time will
get them the help they need much more quickly.
- online forum - I have had some classes that make extensive use of
online class forums. For example, a couple of my classes with only around 20 students
logged over 400 forum postings over the course of the term. Again, I like this
mode of communication because it forces students to be articulate. It also
makes students aware that others are having similar problems to their own (very
helpful for less confident students), gives them a chance to help others (a
constructive outlet for more advanced students), and all students can benefit
from the exchanges that occur. To encourage students to
use the forum I check and answer forum questions often, give little "hints" on
lab and homework assignments (especially early in the semester) to help them
realize it is worthwhile to read the postings, I let them know it is
fine to post questions anonymously (that way they don't have to worry about
looking "stupid") and I thank them for their questions and their replies to others.
While I answer many of the questions on the forum, some of the most productive
threads have developed when I have been unable to check the forum often because
I was at a conference or had a looming paper deadline. Students will really step
up and help each other out. One danger of using class forums though is that
students will post too much of their code, thus giving others their solution. I
try to make it clear that if they need to include more than a couple lines of code
in their posting then they need to email me directly.
Group Work - one of the things I learned at a
workshop on active and cooperative learning I attended a few years ago is
to grade and give credit for in-class group work. The workshop facilitator explained
that by giving students a grade, even if it doesn't count a lot, you are
showing the students that you value group work and they will pay more attention
to it when it is returned. So, I reduced the value of the group research project
(a new component added to the course by my predecessor at the suggestion
of our ad hoc curriculum committee)
from 10% to 5% (my thinking is the project only requires a
15-20 minute group presentation and handouts, so it probably
shouldn't be worth as much as 2-3 lab assignments, which no doubt take the
students considerably more time and effort) in order to allot 5% to in-class group work.
Academic Honesty - in our department there is a
culture of encouraging students to help one another and to collaborate when
appropriate. However, I have noticed in past semesters that some
students interpret our academic honesty policy a bit too liberally, taking
it to mean that it was fine to collaborate on entire lab assignments as long
as they acknowledged the other students' help. Students should get all the
help they need in the form of suggestions for how to approach a problem or
debugging assistance, but they really need to work a bit more independently than I
have seen. Thus, this term I added an explicit statement that they should not
write code on a lab assignment with another student.
Classmate Contact Info - I read about this
in an online document titled "Creating a Syllabus" from Tools for Teaching
http://teaching.berkeley.edu/bgd/teaching.html.
Lots of other great ideas there too!
[TOC] | <-Context | Methods->
Last Modified: 6/2/2006