From: tai@buckaroo.WPI.EDU (L. Taikitsadaporn)
Newsgroups: comp.software-eng,comp.edu
Subject: Re: Class Project For Software Engineering Course
Date: 4 Jan 1993 21:40:26 GMT
Organization: Worcester Polytechnic Institute
Distribution: world
NNTP-Posting-Host: buckaroo.wpi.edu
Originator: tai@buckaroo.WPI.EDU


In article <1ia3e0INN9m5@aludra.usc.edu>, karrer@aludra.usc.edu (Anthony Karrer) writes:
|> At LMU we have been using a project-oriented software engineering
|> class for the last ten years, and I've been teaching it for the
|> last three years.  The projects that we've found to be most effective
|> for a semester long course (if you expect the students to achieve
|> a working product ... some courses go only through detailed design)
|> are board games such as Monopoly, Risk, Othello, Backgammon, etc.
|> 
|> These are particularly well suited to this class because they are
|> fairly well known by students or can easily be learned.  As such you
|> avoid the many of the problems of ill-defined requirements specifications
|> leading to heart-ache at the end of the semester.
|> 
|> One article that you should look at and possibly get an outline from
|> is:
|> 
|> Elaine Kant, "A Semester Course in Software Engineering", Software
|> Engineering Notes, 6(4), Aug 1981.
|> 
|> We use a modified version of this for our course.
|>  
|> -- 
|> Take It Easy,
|>   Anthony Karrer (akarrer@pollux.usc.edu)

I'm not an instructor/professor, merely a student but I would like to share a
student's perspective on a project oriented software eng. (SWE) course I took at
Worcester Polytech last year.  Our academic calendar is such that we run on a
quarter system where each quarter is only 7 weeks long.  In the SWE course I took
the class was divided into groups of 5-7 members each.  Each group is to
role-play the role of a client as well as that of a production team.  Each group
is to come up with a product design (going throught the entire SWE design process
from prelim design to detailed design, structure charts, data flow diagrams (StP
was used for this), data dictionary as well as a marketing scheme for our
product).  As a client we put the design specs up for "bidding" from other
groups.  In other words, group A will hire a group to implement and code their
product (let's say group B got the "contract").  Group B will interact with a
representative from group A when clarifications are needed.  Group A will then be
hired by yet another group (group C) to implement group C's product.  Our
professor had made it a rule that no two groups can implement each other's
product.  Within each group each member is assigned a role, ie. CASE tool
specialist, testing specialist, team leader, doc. prep. specialist, etc.

From a student perspective I think it worked out very well.  Each group in my
class was able to produce a working product by the end of the 7 weeks.  It was a
very good learning experience for students to be able to role play as both the
client and the "contractor" while at the same time learning the SWE design
process.  In class the professor lectured on each process as well as talked about
other issues such as Object Oriented Programming.

I would be happy to share the material I have from this class if anyone is
interested.


Lisa Taikitsadaporn
(tai@wpi.wpi.edu)