At first the idea that the students had to implement their projects to run on three platforms shocked me and as I expected they were not able to complete it. Choosing one platform at the beginning would have saved time and would have saved people f rom going down a lot of false paths. Besides, most software in the retail world are geared very specifically. And if the software is developed for a specific task-- such as these were developed to be a multimedia directory for students, alumni, faculty, and staff--then it is extremely specified to the user group. All efoorts to break these trends are valid but difficult.
The fact that the students were put into groups to develop this software was good seeing as how that is how it is in the real world.
Basically, from what I understood throughout the reading is that the Product Development Laboratory is a simulation of real product development much as the flight simulators for jet fighters simulate flight. However, this product which was intended for use, never had to be marketed or any of the other stuff that goes along with general development. Unfortunately, the project ran into many of the problems faced by developers, being that deadlines were not met due to a virus in the systems, software arriving that was damaged, and other such difficulties.
My suggestion is to make it required that the software run on one platform, the GUI specifications be very broad (in order to make sure that the actual software WORKS--->to focus the attention on the functionality), and that the students ARE flogged with red flags by the proffessors...after all, what are they for?
Products are released on a wide variety of operating systems and the maintenance for them comes in the form of upgrades. Whether this is very common or not, these are two real problems that programmers face in the real world. The point of the project discussed was to write a program that the students would have to be able to easily maintain on many platforms; this forced them to think about extensibility when designing. I assumed this was one of the many ideas that the project was supposed to emphasize. I do, however, completely agree that more emphasis should have been placed on functionality; and that the professors should have been more active in guiding the students.
I agree that some aspects of the program should have been easier, but I believe that it is important the specs be fairly stringent. There are many issues involved with building a program for general use, and it is important to be aware of them beforehand. I think that the professors should take a hands off approach as it would be in the real world, but perhaps a little more guidance would have been beneficial.
I believe that Amanda is onto something here. Working in group projects is a really good way to teach design because it forces people to work together on a project. If people are forced to work on a collaborative project early on in their careers, the designing stage is essential and it forces good design habits. I think that the specs for this project were a larger deterrent than the actual issues of group work. Making a reasonably attainable goal is the job of the instructor and this was not done in this case.
I think that your insight into some of the reasons why the PDL failed are very good. Certainly it would have been easier for the students to only program for one platform. Also, it might have been nice for the Profs. to help the students along but I believe, as stated, that was not the purpose of the Lab. And I think in saying that that I feel they overshot their goal. Their goal, as I understand it, was to provide as close to real life simulation as possible. And, from what I have read, I think they did a good job. So what does this teach us? That it is difficult to integrate industry type working standards into an educational arena. And to do so takes a lot of effort. One must find the proper mix of independence and hand-holding.