From: kpierce@andre.d.umn.edu (Keith Pierce)
Newsgroups: comp.software-eng
Subject: Re: Projects for software engineering courses
Date: 8 Jan 1993 13:50:22 -0600
Organization: University of Minnesota, Duluth
Distribution: world
NNTP-Posting-Host: andre.d.umn.edu

Here at the University of Minnesota Duluth, I've tried from-scratch
development projects for several years. The results were usually
disappointing: the product, if finished at all, was of very low quality
and rarely met specifications completely; the one-quarter
time limit was so short that near the end of the term students abandoned
all of the engineering principles learned in class and resorted to
fire-drill mode in order to get a product finished before finals; such
practice negated much of what I tried to teach them about quality
assurance, the value of inspections, the importance of a well-defined
and rigorously followed process, and so forth. Lastly, most efforts were
simply abandoned as unusable, thus further reinforcing the
all-too-often-correct impression that in computer science we teach
throw-away programming.

Lately, I've tried a project in which students are required to perform
maintenance exercises on a large software artifact. This approach has
been much more satisfying. Students write only a few hundred lines of
code, and so they have time to put in place and follow a good process
which includes mandatory inspections and formal reviews, a configuration
management plan, a thorough test plan (which includes significant
regression testing), as well as the usual requirements analysis and
specification, design, coding, and testing of a modification. The
project continues from quarter to quarter, each class starting with the
product and documentation as it was left by the previous class.

The upshot is that students get a good dose of aspects of software
engineering that they don't get in other courses, without the killer
coding phase (so they have time for other activities like sleeping and
studying for their other courses). In addition students gain very
forcefully an appreciation for the quality attribute of maintainability,
since their friends in the next class will have to live with what they
leave behind.

For a couple of years I used the SEI's DASC artifact, a 10,000-line Ada
program. Since our students don't know Ada, they lost several weeks just
ramping up, which diminished the effectiveness of the project (this is a
good basis for a project, though, if your students know Ada). This year
I started using a compiler, written in Pascal, that compiles and
interprets programs written in Pascal-S, a subset of Pascal. I'm pleased
with the project: not only has it eliminated the language problem, but
also students gain significant experience in regression testing, since I
have obtained for their use a version of the Pascal Validation Suite,
from which we extracted about 300 test programs. Students have had to
wrestle with setting up automated test procedures.

I am planning to make this project available to the general public.
Please reply to me if you would like to try the project.

In summary, consider maintenance projects for such courses.


Keith Pierce, Professor
Department of Computer Science 
University of Minnesota, Duluth
Duluth, MN 55812-2496

internet: kpierce@d.umn.edu
bellnet:  218-726-7194
Newsgroups: comp.software-eng
Subject: Re: Class projects for software engineering course
Summary: 
Expires: 
Followup-To: 
Distribution: 
Organization: University of Minnesota, Duluth
Keywords: project software engineering

Here at the University of Minnesota Duluth, I've tried from-scratch
development projects for several years. The results were usually
disappointing: the product, if finished at all, was of very low quality
and rarely met specifications completely; the one-quarter
time limit was so short that near the end of the term students abandoned
all of the engineering principles learned in class and resorted to
fire-drill mode in order to get a product finished before finals; such
practice negated much of what I tried to teach them about quality
assurance, the value of inspections, the importance of a well-defined
and rigorously followed process, and so forth. Lastly, most efforts were
simply abandoned as unusable, thus further reinforcing the
all-too-often-correct impression that in computer science we teach
throw-away programming.

Lately, I've tried a project in which students are required to perform
maintenance exercises on a large software artifact. This approach has
been much more satisfying. Students write only a few hundred lines of
code, and so they have time to put in place and follow a good process
which includes mandatory inspections and formal reviews, a configuration
management plan, a thorough test plan (which includes significant
regression testing), as well as the usual requirements analysis and
specification, design, coding, and testing of a modification. The
project continues from quarter to quarter, each class starting with the
product and documentation as it was left by the previous class.

The upshot is that students get a good dose of aspects of software
engineering that they don't get in other courses, without the killer
coding phase (so they have time for other activities like sleeping and
studying for their other courses). In addition students gain very
forcefully an appreciation for the quality attribute of maintainability,
since their friends in the next class will have to live with what they
leave behind.

For a couple of years I used the SEI's DASC artifact, a 10,000-line Ada
program. Since our students don't know Ada, they lost several weeks just
ramping up, which diminished the effectiveness of the project (this is a
good basis for a project, though, if your students know Ada). This year
I started using a compiler, written in Pascal, that compiles and
interprets programs written in Pascal-S, a subset of Pascal. I'm pleased
with the project: not only has it eliminated the language problem, but
also students gain significant experience in regression testing, since I
have obtained for their use a version of the Pascal Validation Suite,
from which we extracted about 300 test programs. Students have had to
wrestle with setting up automated test procedures.

I am planning to make this project available to the general public.
Please reply to me if you would like to try the project.

In summary, consider maintenance projects for such courses.


Keith Pierce, Professor
Department of Computer Science 
University of Minnesota, Duluth
Duluth, MN 55812-2496

internet: kpierce@d.umn.edu
bellnet:  218-726-7194
Newsgroups: comp.software-eng