Xref: utzoo misc.jobs.contract:375 comp.edu:3407
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!abvax!icd.ab.com!ejp
From: ejp@icd.ab.com (Ed Prochak)
Newsgroups: misc.jobs.contract,comp.edu
Subject: Re: Group projects
Message-ID: <1565@abvax.UUCP>
Date: 24 Jul 90 21:35:59 GMT
References: <1990Jul8.063302.4076@xavax.com> <2616@igloo.scum.com> <1990Jul11.233006.17884@nmt.edu> <18454@rpp386.cactus.org> <1522@abvax.UUCP> <1990Jul17.120036.8944@pdn.paradyne.com>
Sender: news@abvax.UUCP
Reply-To: ejp@icd.ab.com (Ed Prochak)
Organization: Allen-Bradley Company, Industrial Computer Division
Lines: 69

In article <1990Jul17.120036.8944@pdn.paradyne.com>,
reggie@dinsdale.paradyne.com (George W. Leach) writes:
 [stuff deleted]
>       Several junior and senior level courses required group projects.
> Perhaps the best one was a course where the group first had to come up
> with a project and write the requirements/specifications.  After this
> portion of the project was graded the instructor took them back and
> redistributed them to other groups who then had to implement the project
> from the spec!  Negotiations between the group who originated the spec
> and the group that implemented the project were encouraged.  It was a
> great learning experience.
> 
> 
>       BTW:  I had been burnt on a number of group projects in the past
> due to one member either just not showing up or not pulling his/her
> weight.  The group would receive a grade as a group, so the group was
> responsible.  Having to deal with the situation can be very much like
> real life.

In the same lab course I mentioned there was a second group.
(about 5 people in their group vs. 3 in ours) They decided to
go the safe route and do the traditional microcoded microprocessor.
Somewhere along the way, they lost sight of the goal. For example,
one evening as our group was getting code prepared for burning
proms, they were all excited about getting their reset circuit
working. I mean that was all they had on the board was just
a reset circuit!!  At the end of the semester, they still had
very little built. They got an incomplete.

(And we were scared that we would get a bad grade because
 we didn'd finish the second half of our project. With the
 instructor's help that last day of class, we found out why
 we could not communicate with the graphics chip. Still, we
 got a lot completed and working at that point.)

> 
> [stuff deleted]
> 
> >I really don't see why there is a problem in software courses
> >with team projects. If there are also exams and other grading
> >sourses within the same course (e.g. presentations, verbal exams),
> >then at project completion, the instructor should have some idea
> >of the ability of each student and how each may have contributed.
> 
>     Ah, but that would be more difficult for the instructor, wouldn't
> it?  Remember all the discussions over the years about automatic grading
> programs, true/false and fill in the blank questions on tests versus
> problem solving?
> 
> George W. Leach					AT&T Paradyne 
> (uunet|att)!pdn!reggie				Mail stop LG-133
> Phone: 1-813-530-2376				P.O. Box 2826
> FAX: 1-813-530-8224				Largo, FL 34649-2826 USA

yea, I remember automatic grading, etc. Still, That's just an
excuse for avoiding thorough evaluations. And I haven't seen too many
software courses that used fill-in-the-blank style tests.  It is
probably more prevalent to have automatic grading in the Social
science classes nowadays?? (my undergraduate degree was 1976, so
my view is somewhat dated).

But George, we do agree that it can be done.


Edward J. Prochak   Voice: work-(216)646-4663  home-(216)349-1821
               Email: {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com
USmail: Allen-Bradley, 747 Alpha Drive, Highland Heights,OH 44143
Wellington: ENGINEERING is "the ability to do for one dollar,
                            what any damn fool can do for two."