Daniel T. Joyce

The computer as a problem solving tool: a unifying view for a non-majors course

At Villanova University we have a popular course for non-majors focused on problem solving with computers, taught using our own lecture and lab materials. This paper seeks to describe the essence of the problem solving course by focusing on an assignment that is given after the first unit of the course has been completed. This assignment, writing an essay about how someone uses a computer to solve a problem, requires the application of most of the topics of the first third of the course and is very representative of the spirit of the course as a whole.

Use of laboratories in computer science education: guidelines for good practice: report of the working group on computing laboratories

This paper explores various aspects of the use of laboratories in teaching Computer Science. The foIlowing six topics are discussed in detail: i scope of courses, ii relationship between lecture and lab, iii pedagogy, iv an Internet repository for laboratory materials, v institutional support and vi technology, The first three items deal with content while the last three are concerned with implementation. This document is part of a continuing effort that the authors envision will result in a laboratory development manual.

A virtual lab to accompany CS1 and CS2

For the past two years at Villanova we have successfully conducted a ‘virtual” lab in conjunction with our CSl and CS2 courses. We use the term “virtual” to describe our lab because we have neither a reserved room for the lab work nor scheduled lab hours. Instead, the students can work at any of the public terminal sites on campus whenever they are open. They can even work on their labs at home if they have the ability to phone into our computer network. This paper explains why we choose to implement the Virtual Lab, its basic structure, topics, and success.

Developing laboratories for the SIGCSE computing laboratory repository: guidelines, recommendations, and sample labs (report of the ITiCSE '97 working group on designing laboratory materials for computing courses)

We focus on the practical issue of designing laboratory activities, concentrating on identifying key components necessary to insure quality and usefulness in the on-line SIGCSE Computing Laboratory Repository. We summarize the current capabilities and future extensions of the Repository, characterize a variety of qualities necessary and recommended for successful laboratory activities, identify a standard cover page for all lab activity submissions, and specify some guidelines for referees of submitted materials. Finally, we have designed four sample laboratory projects. Their contents are summarized in this paper and the completed projects will be available from the Repository after student testing in the Fall of 1997, if not sooner.

Report on improving SIGCSE/ITiCSE program creation process

Based on post-meeting review forms, most attendees of the SIGCSE Symposium and ITiCSE Conference greatly appreciate the programs put together by the respective program committees. In recent years, nevertheless, several SIGCSE members have communicated their concerns to the SIGCSE Board about the paper solicitation, submission, review, and selection process used for these meetings.

Experience with a fourth-generation language system for software development: an educator's perspective

Abstract The author taught software engineering for many years before practicing it in a “real world” project. The project used Paradox, a fourth-generation language system for PCs. This article describes the project and why it is considered “software development,” although it used a packaged data base system. Included are insights derived from the experience, emphasizing those things that were surprising, the things for which the author was not prepared by just studying and teaching the classic software engineering papers and textbooks.

A unifying project for CSI

It is difficult to effectively cover all the topics of the CS1 curriculum [1], such as good programming design, de bugging, and testing techniques, in a single semester . At Villanova University CS1 is taken by both computer science majors and other students who wish to learn abou t computer science . Although more and more of the student s are entering the class with some computer programmin g background, we still assume that the typical student has none. Therefore,a lot of class time is invested in introducing the students to the basic concepts of programming an d the syntax and semantics of a language, currently Pascal . By the time enough material has been covered to allow the assignment of a large project, it is close to th e end of the semester . Most of the systems on campus, bot h the electronic and the flesh and blood varieties, are at thi s point running close to capacity. Therefore the assignment of a large project at the end of the semester, althoug h somewhat of a tradition, raises the danger of systems be coming overloaded, sluggish, and possibly shutting down altogether . Rather than assign a large project at the end of th e semester, complete with specification, design, coding an d testing stages, an alternative is to use a maintenance related assignment . The students receive a hard and a soft copy of a program that demonstrates the design guidelines emphasized during the semester . Their assignment is to perform several adaptive updates . This accomplishe s three things :

CS Ed Week activities survey

SIGCSE asked its members to share what they had planned for CS Ed Week. Many great activities were reported and we describe a few below. Something that many departmental activities had in common: pizza and cake! For a complete list of member events check out our website: http://sigcse.org/events/week.

Examining the potential of fuzzy software requirements specifications

Abstract This paper looks at the possibility of using fuzzy terms in a software requirements specification. Potential benefits are reviewed. Methods for testing whether a fuzzy specification is met are investigated. Ways of modeling criticality and rigidity of specifications using fuzzy approaches are also identified. An example based on query response times is used throughout the paper. The results of a pilot study to see whether computer response time requirements can be fuzzified are described.