Design

A First Course in Design (GA Tech and Janet Kolodner) is an attempt to develop skills in design and an understanding of the design activity early in the curriculum. The crew at GA Tech designed an instructional experience for first year students. My understanding, and interpretation, is the course is not discipine specific, rather it addresses skills and ways of thinking about design -

our position is that this course, and subsequent design courses, should produce students who have the ability to reflect on their design activities and articulate critical decisions; who can solve problems flexibly using the science and technology they have learned; who have a deep appreciation of what other disciplines bring to their problems as well as a deep understanding of their own discipline; and who have strong social skills needed for teamwork.

Cognitive Apprenticeship

Cognition and Design References

Design as an Introduction to Computer Science was an NSF sponsored project at UMass Dartmouth exploring the teaching of OO design without requiring prerequisite coursework or knowledge in programming.


OO Early

Faculty at Duke University and faculty at other institutions are developing material to support an objects-early curriculum. In particular, the material under development is a set of classes that can be used to produce programs, then studied and enhanced by students. The approach is grounded in the apprenticeship model. Hopefully the classes developed represent "good" designs and provide the type of examples needed by students.

Mercer, R. and A. M. Berman (1996) Object-Oriented Technology and C++ in the First Year: Ten Lessons Learned.

OOPSLA Workshop on Pedagogical Patterns: Successes in Teaching Object Technology

Pedagogical Patterns

Syllabi


Curriculum

University of Virginia

The Computer Science Department at the University of Virginia has embarked on a "serious" redesign of the undergraduate computer science experience - curriculum. Experience is perhaps a better term since they interpreted their charge as being more than simply specifying the courses and the content (rearranging the decks chairs does not necessarily improve the situation). Their rationale is presented below, as found in their documentation (see also their curriculum paper):

Formerly, our curriculum emphasized:

  1. The construction of relatively small programs, at most a few hundred lines.
  2. The use of a programming language that is used rarely outside of undergraduate courses.
  3. The development of programs "afresh" for each assignment course.
  4. A development lacking modern tools.
  5. Programming in isolation or in small groups at best.
  6. The belief that if a program "works", it is acceptable.
  7. An informal development approach rather than one that is rigorous and exercises analytic skills.
Practicing computer scientists have to deal with the antithesis of what we taught:
  1. Software systems that are often thousands or even millions of source lines long.
  2. Tasks that involve modifying such systems rather than developing them.
  3. Existing systems that might be very old but remain important and have to be maintained.
  4. Tool-rich working environments.
  5. Development efforts that are undertaken by large teams.
  6. The realism of cost performance trade-offs in business contexts.
  7. System development according to mandated processes and standards.
  8. Expenditure of considerable effort on tasks other than source-code development.

Clearly, their goals are in line with the concerns encountered in software process education.

A second major facet of their activity in curriulum is the identification of both knowledge and skills. This distinction appears to be in line with what may be referred to as the declarative/procedural distinction. Clearly, the skills areas indicates things that you should be able to "do" and applying particular information/knowledge in the performance of a task. Furthermore each topic in these broad areas is specified with a "depth of treatment" (Exposure, Familiarity, Mastery). Apparently they realize that certain activities are learned over repeated and differing exposure, this is particularly true of what might be termed "best practices." This is definitely the case where the outcome of the educational experience is the reflective practitioner. To accomplish this a differential treatment level is specified for each topic in each course. This combined with the closed labs where skills can be practiced and feedback offered makes a very interesting set of ideas.

Innovations in Introductory Computer Programming at MIT

Perhaps the most fundamental idea in modern computer science is that of interactive processes. Computation is embedded in a (physical or virtual) world; its role is to interact with that world to produce desired behavior. While von Neumann serial programming has it that computation-as-calculation uses inputs -- at the beginning -- to produce outputs -- at the end -- computation-as-interaction treats inputs as things that are monitored and outputs as actions that are taken over the lifetime of an ongoing process. By beginning with a decomposition in terms of interacting computational processes, we can teach our students a model of the world much closer to the one that underlies the thinking of most computer professionals.

Rethinking CS101 is a project to develop a curriculum for the first course in computer science based around the idea of computation as interaction.


To Top of Software Process Collection
To UMass Dartmouth
To CIS Department at UMass Dartmouth

Comments should be sent to

Richard Upchurch (rupchurch@umassd.edu)
or
ciswebster@wwwmail.umassd.edu
Computer and Information Science Department
University of Massachusetts Dartmouth
285 Old Westport Rd.
N. Dartmouth, MA 02747-2300
RUpchurch@umassd.edu

This document
Created: July 8, 1996
by RLU

Modified: March 23, 1997