The introduction of CPSC 219 into our curriculum was motivated by several factors.

	Many instructors of third and fourth year courses mentioned that students lacked some important knowledge about tools that, when used properly, would allow them to complete assignments and projects faster and with less difficulty. These instructors felt that, if they could rely on the students knowing these tools, then they could assign projects that are more interesting, but would prove too challenging under the then prevailing conditions.
	One of our upper-level requirements, CPSC 319, was a full-year Software Engineering project course. Because it lasted from September to April, this course caused scheduling difficulties for many students, particularly those in the Cooperative Education program who for one reason or another were not following the standard COOP schedule.
	Many students in the Cooperative Education program found their first work-term difficult, as they had to learn a new environment and new tools, and had taken relatively few Computer Science courses (in most cases only four plus a course on Discrete Mathematics that has relatively little impact on the first COOP work term, even though it is extremely useful for other purposes).

It is to address these problems that CPSC 219 was created. It provides knowledge about tools and programming techniques that are essential to students going on work terms, or working on assignments and projects in their upper-level Computer Science courses. The introduction of CPSC 219 also solves the CPSC 319 scheduling problem. The old version of CPSC 319 was split into two halves that lasted one term each:

	In the first half of the course, the students studied some of the tools that they now learn in CPSC 219, as well as other topics such as group project management.
	In the second half of the course, the students were divided into groups, and did the actual project, from requirements analysis to implementation and testing.

Since all of the tools that the students previously learned about in the first half of CPSC 319 are now covered in CPSC 219, it is now possible to cover the project management topics, and do the group project, in a single term. This new version of CPSC 319 will be offered for the first time in January 2002. Moreover, starting this year, CPSC 219 has replaced CPSC 319 as program requirement.

The remainder of this paper is organized as follows: in Section 2, I discuss the process through which we developed the course and decided on the topics to be covered. Next, I describe the practical details of the first two offerings of the course. Finally, I summarize my experience in teaching the course, and discuss its future.

2. The development of the course

We started developing CPSC 219 in May 2000. Our goal was to help the students acquire fundamental, practical skills and knowledge that would assist them in completing medium-sized software engineering projects. Hence, we determined that part of the course would introduce the students to tools used in software development. On the other hand, we also wanted to discuss other concepts that were not yet part of our lower-level curriculum, but are needed for both work terms and upper-level courses. We thus decided that the course should cover the following broad topics (listed here in no particular order):

	Unix.
	Microsoft DOS/Windows and its development tools.
	Scripting language.
	Testing and Debugging.
	Makefiles.
	Graphical User Interfaces.

The choice of specific topics for scripting languages and graphical user interfaces was more difficult. For scripting languages, we decided quickly to include shell scripts (for both the Bourne and C shells), DOS batch files, and Perl. We also wanted to include Javascript, but we realized that the course had already as much contents as the students could possibly handle in one term. We thus had to leave it out.

We also had many discussions about the language that we would use to introduce Graphical User Interfaces. The first term of CPSC 319 had traditionally used Tcl/Tk for that purpose. The two students who helped us develop the course pointed out that, as far as they knew, very few students really used it afterwards (the author must confess that he has never programmed using Tcl/Tk). The alternative was to use Swing. Since the two languages used in our first year courses are Scheme and C++, we had to introduce an additional language in both cases. Moreover, we already have a set of Tcl/Tk course notes that covered exactly the elements we were interested in teaching (from CPSC 319), whereas we had no such notes for Swing. Despite this drawback, we decided to go ahead with Swing for three reasons:

	It is likely to be much more useful (in a practical sense) than Tcl/Tk, although both could be used equally well to teach the concepts involved.
	Students should be exposed to Java at some point during the course of their studies, and doing it at that point makes at least as much sense as doing it at any other time.
	Finally, learning Java is relatively easy if one knows C++, and so not much time needs to be spent on it.

We thus ended up with seven different topics, which are:

	Unix Concepts: File system structure, file and directory management commands (ls, cp, etc), man pages, editors such as Emacs and Vi, process control, file ownership and permissions, hard links and soft links, other Unix commands such as awk, chmod, find, grep, less, ln, sort, tar and uniq.
	Shell Scripts and Batch files: variables, wildcards, expressions, control structures, redirection, piping (all of these for both the Bourne Shell and the C Shell). Writing simple shell scripts for file and directory management.
	The Perl scripting language: variables and their types (scalars, arrays and hashes), context sensitivity, terms and operators, flow control, reference data types and their uses in complex data structures, subroutines, objects, file handles and file operations, pattern matching using regular expressions, and parsing.
	Testing and Debugging: the testing process, selecting test cases, black box and white box testing, using the Gnu Debugger (GDB) and the Data Display Debugger (DDD).
	Configuration Management: Makefiles, and Visual C++: review of separate compilation in C++, makefiles' purposes, rules and dependencies, variables, suffix and pattern rules, using makedepend to generate dependencies automatically, how to use multiple makefiles.
	The Java programming language: primitive types, variables, operators, control flow, object references and their usage, defining new classes, predefined classes, exceptions, file input/output, abstract classes and interfaces, inner classes, applets.
	Graphical User Interfaces using Swing: event handling concepts, containment hierarchies, top-level components (frames and dialogs), other components (panels, buttons, labels, menus, text fields, file choosers), listeners, layout managers (border, flow, box and grid).

Each of these is covered in either one or two weeks, depending on the number and difficulty of the concepts involved.

Unfortunately, not all of the sections of the online course notes were fully ready by September 1st, and hence many of them, as well as most of the labs, were finalized as the course progressed. The section on Graphical User Interfaces, in particular, is still, as of today, mostly links to the online Swing tutorials. While these tutorials are fairly complete, they also contain too much information for our purposes, and as a result are not as easily accessible to the students as we would like our online course material to be. We will remedy this during the summer by writing our own set of notes for Swing; the links to the online Swing tutorials will remain available for the students who are interested.

3. The first offering

The original plan was to have eleven labs worth 20% of the final grade, a set of eight lab quizzes that would be written in the lab, also worth 20% of the final grade, a 50 minutes midterm worth 15%, and a final examination that would account for the remaining 45%. However I found out very quickly that this was impractical for three reasons:

	It is nearly impossible for an instructor to come up with five different lab quizzes on a same topic that are of equal difficulty, and yet different enough so that students in a later lab section do not get any advantage over students in the earlier sections.
	Having eight individual quizzes (even short ones) is an excessive burden on the students.
	And finally, writing five quizzes in a week is more work than I could handle given my other responsibilities.

For these reasons, the number of quizzes was reduced from eight to four, and the quizzes were written in the lecture rather than in the labs (even though this meant less lecture time). The relative weights of the components remained unchanged. Also, the last two lab assignments were merged into a mini Swing project that the students could do in teams of two.

3.2 Labs assignments

The lab assignments were designed to track as closely as possible the concepts that we considered important for each section of the course. Here is a summary of the contents of the individual lab assignments, listed in the order in which they were assigned during the term.

	Lab 1 (Basic Unix Concepts): this was an easy lab where the students were asked to perform a number of tasks for which they needed to use the file management commands described in the online course notes, as well as lookup some additional options that were described only in the manual pages for these commands. Finally, they needed to use both Vi and Emacs to edit a couple of small files.
	Lab 2 (Shell Scripts and Batch Files): in this lab, the students had to write two shells scripts and a DOS batch file. The first shell script performed file manipulations recursively in a directory and all of its subdirectories. The second shell script was a menu-driven file-management utility, where the file management actions themselves were relatively simple, but required that permissions and existence of files be checked. The students wrote two versions of each script: one for the Bourne Shell, and one for the C Shell. The batch file simply copied selected files from one place to another.
	Lab 3 (Advanced Unix Concepts): this lab asked the students to perform a number of tasks using chmod, find, etc. They also had to write pipelines, and observe how file permissions worked by trying to read a file created by their neighbor. Finally, the last part of the lab asked them to write a simple AWK program.
	Lab 4 (The Perl Scripting Language, part 1): in this lab, the students started by gaining first-hand experience with variables, subroutines and parameters by writing a simple subroutine to compute Fibonacci numbers. Next they learned about arrays and references by writing two versions of insertion sort: one that returns a new sorted array, and one in which the array is passed by reference and mutated. Finally, the last problem was meant to familiarize the students with hashes, by asking them to count the number of times each word occurs in a sentence stored as a string.
	Lab 5 (The Perl Scripting Language, part 2): this lab was divided in two parts: in the first part, the students had to write simple file-manipulation scripts that involved pattern matching. In the second part, they wrote a simple class and a driver program for it.
	Lab 6 (Testing and Debugging): this lab was also divided in two parts: first the students were asked to provide test cases for a simple C++ class, and implement a driver program to perform the tests, providing both the expected output and the actual one. Then they were guided through a sequence of exercises where they debugged a number of programs using both GDB and DDD.
	Lab 7 (Makefiles and Visual C++): in the first part of the lab, the students wrote makefiles for a few different (small) projects, using suffix and pattern rules, automatic variables, etc. Then they were asked to write a small Console Application, to compile it, to run it and to save its output to a file.
	Lab 8 (The Java Programming Language, part 1): the students were asked to write two programs: a program that consists of a simple class and a driver program, and a program to read text from a file and print out the list of words, along with the number of occurrences of each word. Both programs were meant to give the students some practical experience writing Java programs. Apart from File I/O there was nothing that they hadn't already done in C++.
	Lab 9 (The Java Programming Language, part 2): in this lab, the students first wrote a simple program to give them practice with interfaces and inheritance (some of them had not seen inheritance previously, as it is traditionally introduced in another one of our second year courses, which they can take before, after, or concurrently with CPSC 219). Then they wrote a second, larger, program that tied a number of things together (inheritance, abstract classes, and exceptions).
	Lab 10 (Designing a GUI using Swing): The objective of this lab was to give the students practice designing and implementing graphical user interfaces. Hence, they first had to design the graphical user interface for a simple day planner program, and then they implemented it using Swing. This was a two-weeks lab that could be done individually or in teams of two. In their last lab session of the year, I asked the students to demo their projects to me. Part of the marks were given for the user interface, while others went to the actual code behind it.

Most of the labs were of appropriate length and difficulty, apart from labs #2 and #10. Lab #2 was much too long, and many students spent over 20 hours on it. This was partly because of problems with the syntax to which they were unaccustomed, partly because I failed to realize that one part of the question was much harder to do with the Bourne Shell than with the C Shell. Lab #10 was also too long, although this time the main reason was the amount of searching through the online Java documentaton that the students had to do in order to deal with Calendar dates and File Input/Output.

3.3 Student's reactions

The reactions of the students who took the course in the first term it was offered were overall positive, although most of them acknowledged that there were problems. The most significant comments were:

	I found the things we learned are very useful in my COOP job.
	We really need more than one hour of lecture per week to go over all the concepts.
	There was too much syntax to learn.

The first comment tells us that we at least partially met our initial goals. The second one points to a problem that I am still grappling with: how to best make use of the limited amount of lecture time? Using transparencies seem to help a bit, but some concepts require time and can not be gone over quickly without losing too many students. The problem may also lie partially with the students who, like the instructor, are used to courses with three hours of lecture per week, and are finding the adaptation a bit difficult.

The third comment points to a more significant problem with the current contents of the course: the students have to use two different shell scripts, DOS batch files, Perl, Java and C++, in a period of only thirteen weeks. This is a lot of syntax to deal with, and too much time seems to be spent on this (in all course activities) that would be better used dealing with the underlying concepts.

4. Changes between the first and second offering

At the end of the second term, I once again surveyed the students to get as much specific feedback about the course as possible. They were asked

	whether or not they had already taken or were taking our second year Data Structures course (to help evaluate their other answers),
	how many hours of lecture per week they though the course needed,
	and to rank each of the topics covered in the course according to the following criteria: usefulness of the topic itself, helpfulness of the lectures in introducing the topic, helpfulness of the online notes to help them learn the concepts, how hard they found the lab, how long they found the lab, and how helpful the online notes were in assisting them do the lab.

Unfortunately, there has not yet been enough time to fully analyze the results of this survey. Moreover, the teaching evaluations will not become available to me until the month of June. However, preliminary results show that most students would like more than one hour of lecture per week (most said 2 or 3), and that they thought that most topics were useful.

5. Conclusions and Future Plans