From: pconrad@fred.cis.udel.edu (Phill Conrad)
Newsgroups: comp.software-eng,comp.edu
Subject: Re: Class Project For Software Engineering Course
Date: 5 Jan 1993 03:23:09 GMT
Organization: University of Delaware, Newark
Distribution: world
NNTP-Posting-Host: fred.cis.udel.edu

In article <1i4lfqINN849@crcnis1.unl.edu> memon@cse.unl.edu (Nasir Memon) writes:
>I am teaching an  undergrad software engineering course the coming semester.
>Have not taught such a course before and as such am no `expert'  in software
>eng. I would like the course to be project oriented. Have been looking around
...
>Also, any other suggestions for an interesting class project?  

When I took such a course, our class project seemed very successful.  We
were able to capture some of the real world difficulties (unclear requirements,
tradeoff between more features vs. less features, technology vs. politics,
quality vs. deadlines), while still keeping the project somewhat 
manageable.  I say somewhat, because both the students and the instructor
worked their respective rear-end's off!  But it was a lot of fun also!
NOTE: This takes an imaginative and energetic instructor to really pull-off.


We organized ourselves into groups which were identified as software 
firms.  Our first assignment was to name our firm and produce a "prospectus"
highlighting the capabilities of our firm, the chief officers, and the
technical expertise within our teams.

Then, the instructor introduced us to the "Fine Widget Company", a
manufacturing concern, and to I. M. Gone, its President.  (A fictional
character portrayed by the instructor).  It seems that things are a
mess at FWC.  Mr. Gone would like each of several companies to help
him detemine how computerizing the FWC Work Order system might help
him solve some of his business problems.

With the stage now set, there are four deliverables.  A requirements
specification, a proposed system design (from the user view), a proposed
implementation (hardware proposal, and high level module software design,
WITH price quotes) and finally delivery of a working *prototype* system.
(May be a subset of the total defined system, depending of pace of the 
semester,and the ambitiousness of the design.  Could be negotiated between
each group and the instructor).

HOWEVER, the REALLY INTERESTING PARTS ARE:

  1) As his name implies Mr. Gone, is not around very often.  So the
companies must rely on Mr. Gone's associates.  The directors of
Manufacturing, Maintenance, Finance, Accounting, and Payroll.  Each
has his/her own interpretation of what's right/wrong with FWC, and
different attitudes towards computers (READ: Politics)

 (To pull this off the instructor must take on multiple roles; a
change in voice, or hat can help; it works even better if some other faculty
member can drop in occaisionaly to take on some other roles.)

  2) SOME of the business problems described by Mr. Gone's associates
can clearly by helped by a computer system.  Some clearly CANNOT.  And
there is a large gray area in between...!

  3) Although the initial vision includes only a work order system, it
becomes clear that unless a W.O. system is tied to Inventory,
Preventative Maintenance, General Ledger, etc. etc. ... well you get
the idea.  This induces a dilemma for the groups.  You need to keep
the problem small enought that it can be managed and completed by the
due date.  On the other hand, Mr. Gone, (i. e.  the professor) has
made it clear that the better evaluation (i.e. GRADES!) will go to the
more complete solutions!  Clearly a balance is needed, and one of the major
learnings of the project is how to manage that balance.

As mentioned earlier, our instructor played the "role" of I. M. Gone,
as well as several other characters.  During some class sessions,
representatives of each company were allowed to interview Mr. Gone or
other company reps one-on-one, but in front of the class.  In this
way, each company gets the information it needs, and gets to observe
various interview techniques.  This provides the opporutnity to
critique various approaches of information gathering and interview
techniques.  It may also be good, if time permits, to schedule a
limited amount of interview time outside of class, to provide
"competitive advantage" to companies that can ask more insightful
questions; another approach would be to provide email access to the
FWC representatives.

Credit for this idea goes to Dr. Malcolm Lane, who implemented it in
his Software Engineering class at West Virginia University in Fall 198(7?)
or thereabouts.

BTW, Our class was mixed graduate/undergraduate; we worked in homogenous
groups and were graded appropriately for our levels.

Also, I found that one of the key learnings that the course afforded was in
how "groups" work together; In my group there was a major personality and
style clash, and early on things seemed dismal... after working through it
we were able to rechannel that energy, and actually come up with an excellent
product, not only in spite of, but as a direct result of the very different
perspective that the two clashing members offered (to give you the flavor,
it started as a DEC vs. IBM religious war...)  Other groups had similar
learnings.

Also, the hardware and software "pricing" portion was the ONLY time in my
academic career that I ever saw anything remotely resembling a budget,or
ever had to consider even for a second that computers and programmers time
actually cost MONEY!  When our team actually sat down and computed the relative
costs of a PC LAN vs. a  VAX vs. an IBM Mainframe solution, the wars got a
lot less religous, and a lot more "real world like".  I highly recommend
some kind of exercise of this sort be included somewhere in the curriculum.

Good luck!

***********
Phill Conrad, Graduate Student, University of Delaware.  pconrad@cis.udel.edu

Newsgroups: comp.software-eng