Barry Burd <bburd@icosa.drew.edu>
Drew University
USA
Drew University, a small private college in the United States, offers a course in software engineering once every two years. This year the course has been revitalized using the Internet in several different ways.
Drew University[1] is a small private college in Madison, New Jersey, USA. Our joint Mathematics/Computer Science Department[2] offers a Computer Science major developed along guidelines published by the Association for Computing Machinery[3][4]. Being a small department, and stemming originally from a mathematics-only department, our curriculum places heavy emphasis on programming and the design of programs and algorithms. Our curriculum is fully integrated with the University's commitment to the liberal arts. (As I understand it, the notion of a "liberal arts" education is unique to colleges and universities in the United States. For a slightly overstated description of the liberal arts philosophy, see the Liberal Arts Colleges Web site[5].)
The Drew campus has several computing luxuries not afforded to other small institutions. Since 1984 each entering first-year student has received a desktop computer (or notebook computer) and printer. In 1984 the standard issue was a desktop computer with a Z-80 chip running CP/M[6][7]. For the current academic year, students receive Pentium notebook computers. A nostalgic year-by-year list of hardware acquisitions is available at the University's Computer Initiative Museum[8].
Most Drew students live on campus, so in 1988 the University installed a digital telephone system[9] connecting all offices and dormitories to a VAX[10], which in turn was connected to Bitnet[11]. At this point our professors could assume that each student had ready access to e-mail, word processing, and (if necessary) computer programming in Pascal.
A few years later the Bitnet[11] connection became an Internet connection. In 1995 we began installing a fiber optic network that, when completed, will give each student in each dormitory room full access to the Web and its riches.
Our Department of Mathematics and Computer Science[2] has only seven faculty members, with only two or three in computer science and the rest in mathematics. This forces us to offer certain courses only once every two years. Our Software Engineering[13] course is given in the autumn semester in even-numbered years. We normally find this particular course offering to be difficult and unsatisfactory because the course material applies mostly to large industrial software development projects, an area that the rest of our curriculum does not fully address.
In previous years we found that a large programming project would add meaning to the material in the course. The enormity of the project forced students to think seriously about planning, teamwork, and documentation. Even so, students were aware that they were developing a "throwaway" project--one that would never be used after the end of the semester.
This year we have had enormous success by restructuring the course to make use of the Internet. We use the Internet in several ways:
The course enrolled nine students, which is normal for an upper-level course at Drew University[1]. Eight of the nine students were computer science majors. Most came with a good background in C programming, but only one had experience using Borland Delphi[14]--the official development language for the course.
As I prepare this paper for presentation to INET'97[15], the students' project is in its final stages. Each part of the project has been coded, and the students are working on pasting together the entire package. At this point, the students are learning about integrating the work of three separate teams (and how troublesome that process can be). When the project is completed it will be posted at the URL listed in this paper's references[12].
What follows is a discussion of each way in which the Internet was used in teaching the course.
Until the campus fiber optic network is completed, our students will have only text-based access to the Web (using Lynx[16]) from their dormitory rooms. Even so, students have full graphical Web access on public stations in our academic computer center[17]. Students love to browse, and having class-related materials on the Web gets their attention more easily than textbooks. It also helps to broaden their view of the subject, since the Web contains software engineering source documents written by hundreds of authors, not just one textbook author.
A good staring point for Web pages dealing with software engineering concepts is located at the World Wide Web Virtual Library site[18].
The Software Engineering course is different from other courses offered by our department in one very significant way. Our other courses deal in tangible facts--the semantics of a programming language instruction, the complexity of an algorithm, or the decidability of a problem. But software engineering deals with intangible ideas--which methodology might be used in a certain application domain, how you can deal with legacy systems, what heuristics you might apply to devise an effective test suite. The overall fuzziness of the Software Engineering course content makes our students nervous. As a professor coming from a mathematics background, I feel less comfortable in this field where there are so few final, inarguable facts.
CASE[19] (computer-aided software engineering) software helps to ease the pain. CASE offers a tangible, hands-on environment in which students can try out the ideas discussed in other parts of the course. They can see these ideas in action while the software checks their work for consistency and completeness.
Until recently, CASE tools were difficult to find. Some software engineering textbooks provided a limited set of tools. In many instances these tools were written by the textbook author as an afterthought, and had little or no real-world versatility. (A notable exception is the book Software Engineering With C++ and CASE Tools by Michael Pont, published by Addison-Wesley[20]. It comes with the Yourdon Select CASE tool.)
A manager in a software development department is required to evaluate the applicability of alternative CASE tools. But without the World Wide Web, it was impractical to have students compare one tool against another. An instructor who taught software engineering each semester might have a long-standing collection of tools, but in a small liberal arts institution I had to spend days before the start of a semester on the tedious paperwork and phone calling involved in collecting samples of competing tools.
The availability of freeware and academic software on the World Wide Web changes all that. Students can try out a wide range of tools, evaluate several tools, choose tools most appropriate for the tasks, and use some of the freeware tools to develop their project.
You can find a huge list of CASE tools at Software-Engineering Archives Web site at Queen's University[21]. Another site--the CASE Tool home page--has a large list of downloadable freeware and shareware CASE tools[22]. You can also read about classification schemes for CASE tools at a research page maintained at the University of Malaya[23].
Of all the available CASE tools, the two tool sets most commonly used among educators might be Rational Rose from Rational Software Corporation and Visible Analyst Workbench from Visible Systems Corporation[24][25]. Visible Analyst Workbench is easy to learn and easy to use. Rational Rose is coupled tightly with Grady Booch's Object-Oriented Analysis and Design methodology[26] but, for educators, has a nice power-to-price ratio.
In a course with a strong emphasis on outcome, I recommend choosing an easy-to-learn CASE tool. Otherwise, the process of learning to use the tool gets in the way of finishing the project. Students find it difficult to organize the whole software development endeavor, so a CASE tool that slows down the process, or makes the process more complicated, is of no use at all.
The students were given almost complete freedom in choosing a project to work on. I did it this way to simulate the "coming up with an idea" part of the software life. I gave them a few simple guidelines and retained the right to veto an idea that somehow fit the guidelines but was otherwise unacceptable. The guidelines were as follows:
I decided not to press too hard on the second guideline--developing software that uniquely fulfills a need. A full-scale search of all products on the market would have been too much for a one-semester course. Of course in most real-life situations, the idea-generation part of the software life cycle is much more constrained than it is by these three rules. Even so, the three rules served their purposes well.
The students chose to write a PIM (personal information manager). A typical PIM has several features--a calendar to help the user keep track of appointments, a phone book, an automated to-do list, and so on. It can be reduced to a simple list of appointments and their times, or extended into an elaborate piece of software that crosslinks appointments, people, events, holidays, and group meeting times.
With so much software being offered in evaluation form on the World Wide Web, it was easy for students to download a number of sample PIM programs. A very useful list of PIM programs was available at Yahoo[27].
By downloading and reviewing existing PIM programs the students were able to
It is difficult to justify an instructional approach by claiming that the approach is fun for the instructor. Even so, this part of the course was fun. Students downloaded software on their own time and brought it to my office so I could install it on a notebook computer. In class we displayed each PIM on a large projection screen and played with its interface while we critiqued its features. We spent a few class periods doing this until I began to feel guilty, because we were enjoying ourselves so much. At that point I interrupted the exploration of existing PIMs with a guest speaker--a member of our academic computer center staff who had tried many PIMs on his own and had something to say about each one. Finally, the students entered the serious design stage.
In a paper entitled Competitive Versus Cooperative Reward Structures, author Ames stresses social reinforcement rather than project attributes as the primary factor in motivating students[28].
Research or no research, the educational benefits of an atmosphere involving frequent, fluid discussion among students is obvious. This is especially true in a course on software engineering, in which teamwork plays an important role. With an online discussion group I was able to assume, without hesitation, that students could share ideas on team-related issues on a daily basis. None of the physical barriers--finding meeting space, finding a common time to meet--would get in the way.
Students respond much better to a push mechanism, like a listserv[29] or a shared e-mail distribution list, than to a pull mechanism, like a private newsgroup. It is true that newsgroup software supports threaded discussions, and this can be useful if the volume of postings is very high. But with the small classes we have at Drew University[1], an e-mail distribution list is more effective in getting students to participate.
For an online discussion of the use of e-mail in education, see EMLTEACH[30].
The students came up with this idea. They started with a plain text file and thought about adding hyperlinks. In the end they had created only plain text. A document with hyperlinks (pointing from one part of the document to another) would have been easier to read and easier to use. But even without the hyperlinks, putting this text on a Web server gave everyone the opportunity to view the same document at any time from anywhere on campus (including the students' dormitories). This made the document more accessible, and helped students avoid a common software engineering pitfall--the tendency to create extensive paperwork in a project's preliminary stages and then set the paperwork aside and ignore it while creating the actual code.
The students' document is located on the Drew University Web server.[31].
The unique feature of the course is the last item--sharing the class project on the Web. This aspect of the course has been of enormous benefit in overcoming the throwaway syndrome that we saw in previous years. Students work harder (and grapple with more real-life software development issues) because they know that their project will eventually be made public.
The old story about the way the Web "levels the playing field" for small and large companies is boldly illustrated in this exercise. Without the Web it would be virtually impossible for our students to distribute their software beyond the boundaries of the local college campus.
Students think more about testing their program before releasing it to the outside world. Even though the project is developed strictly for Windows 95, it needs to be tested on a variety of machine configurations with various amounts of RAM, several video resolutions, and different software environments (with and without certain paths, subdirectories, DLL files, and so on).
Throughout the course, students placed much more importance on the class project, and saw less relevance to the learning of any software engineering principles that were not directly project based. Depending on your point of view, this outcome is either an advantage or a disadvantage. In the long-standing liberal arts[5] battle for scholarly learning over career-based training, this outcome is a distinct disadvantage. On the other hand, the constant focus on the course project created a certain criterion by which students could judge the usefulness of each software engineering concept. The ability to thoughtfully critique concepts in a course is often lacking in our students, who have been trained to memorize and repeat concepts without delving deeply into their significance.
Originally I had hoped that the Web publishing idea would have an impact on the way the students felt about their grades. The habit of some students to argue with professors for higher grades is a phenomenon that plagues some (but not all) universities. Students need their grades to be credible, and some of this credibility hinges on the extent to which students feel that the professor is making outcome-based decisions about their work. If the professor claims that a student's work is only "fair," then some students challenge this with a claim that quality is arbitrary, and that grades should be based not on judgment but on real accomplishments.
So, in having students publish on the World Wide Web, one of my goals was to get students to feel the quality of their work more acutely. My reasoning was, if students knew that their work would be shown to the world, they would be much more careful in making claims about the work's quality and would be more bashful about insisting on higher grades.
Unfortunately, students do not relate grades to quality the way professors do. It is true that Web publishing made students much more aware of any deficiencies in their work, but this did not keep them from seeing high grades as a separate, independent goal. With this new way of teaching the course, I have had no fewer discussions about grades than in previous semesters.
At this point I pass on a few additional thoughts about teaching a course of this kind--a project-based course with the outcome of publishing on the Web.
First, plan on helping students to package the software with compression programs such as WinZip[32] or with programs that create automatic setup/install procedures. No other course in our curriculum deals with this issue at all. Even in previous offerings of our Software Engineering course, with no final project being published, we never discussed the need for installation packages of any kind. For a list of several automated software installation programs, see the MFC Professional Product Gallery at the Vision X Software site[33].
Once the class project is made available on the Web, have the students list it with search engines, lists of freeware, and so on[34][35]. This affects the number of downloads, and students can use the secure feeling of knowing that people are interested in trying their software.
Decide on a mechanism for having students keep track of downloads, respond to feedback, and deal with any technical questions from users. For instance, you can get one student in the class to list his or her e-mail address along with the software's readme file. Failure to do this means relying on some very conscientious students being interested enough to take the initiative. Once the semester is over, you have no way of enforcing a requirement that students follow up on users' comments, but having students think about such things is a very worthwhile goal.
Finally, as the semester progresses, remind students occasionally that their work will be published on the Web. Near the end of the semester I was shocked to discover that one of the students was never aware of this goal. He had joined the class a week after the start of the semester, missed my introductory remarks, and then had never read the course syllabus.
When I offer the course again I would like to add another use of the Internet--having students share their ideas with people outside the university, using e-mail, news, or a listserv[29]. This will serve three purposes.
To make this work, I will seek out participants (colleagues at other institutions, students in classes run by colleagues, and so on) before the start of the semester.
This year the course is graded using written examinations and peer evaluations. In future years I would like to include the number of downloads by people off campus as one of the assessment criteria used in the course. This possibility comes with two difficulties.
Another exciting possibility is the notion of developing a Web-enabled application. As students work to develop their own PIM, the people at Lotus Development Corporation are announcing plans to make Lotus Organizer available as a Web browser applet[36].
In the near future I hope to quantify the benefits of using the Internet to teach software engineering. For now I must be content with anecdotal evidence which suggests that
Until further data are collected, I will put my trust in the second of these two items.