Some advice on "OOPU":ing

Although the OOPU covers pretty much all instances of Software Engineering, the main focus is on Object Oriented Analysis and Design. Since the students are to form small "companies" that are contracted by the instructors to conduct software projects, most of the needed Analysis and Design will occur in the first half of the course. This is where the emphasis lies. A completed implementation is less important (a working prototype is nice to have though). If one wants to be sure to pass the course, ones team should concentrate their effort on the first half of the course and produce sound and thorough deliveries covering that effort. If one by force of habit focuses on a complete and perfectly working implementation of the contracted piece of software and neglects remaining aspects of project-handling, handing in thin and sloppy deliveries, ones team runs the risk of flunking the course.

Here follows some advice I and my team (Void) learned the hard way when we took the course back in -96 (I have also included some afterthoughts I made as teaching assistant in -98):

• Choose a realistic project. Do not be over-optimistic when selecting which project-proposal to take on. Try to settle for something you probably will have time to complete and do really good. Otherwise you are in for a hard time and even if you will get a prototype working, your overall performance will suffer considerably.

• Visit the lectures. Since Jürgen covers all things needed to know to complete the course in the lectures, why not take advantage of that? It is pretty stupid to skip the lectures just because there is no final exam. Then you will have to find all necessary information yourselves in order to finish the different project subtasks. At least some team-members should follow each lecture, so that the team will gain access to the easy-served knowledge.

• Plan ahead. This should really be a full-time course. Since it is not and since many students work or takes not one but two classes aside of this one, you'd better plan ahead carefully. It is better to finish a delivery right away instead of waiting to the last minute. However, since the teams are pretty small, it is usually possible to cope with the work. See to it that you will have regular team-meetings and remember to take meeting-minutes. After all, these should be handed in too, you know.

• Be aware of needed interactions with other teams. Each team should hire another team to do a small part of the project (sort of the whole course in the small). Each team should also evaluate another teams prototype. No teams should hire or evaluate each other (or hire and evaluate the same team). MOST IMPORTANT, these interactions are to be initiated and performed by the teams themselves WITHOUT any interference of the course instructors. Somehow, the students usually have trouble with this. However, this is part of the examination. If a team completely fails to interact with the others, they run the risk of flunking.

• Keep an eye on your own efforts. This course is a team effort. Either the whole team passes or all members flunk. Your team depends on you. Do not let them down. Do your share of the work. At least be open about your difficulties and make it possible for your team to work out some compromise.

• Keep an eye on your team-mates efforts. This course is a team effort. Either the whole team passes or all members flunk. Do not put up with lazy or disloyal team-mates. If your team cannot make them work, call for a meeting with a course instructor. There is no point in hiding it or for parts of the team to try to do the task of the whole team.

• Agree on one document template. All teams will produce a lot of papers. These are more easily accepted if they look good and professional. They should also all look alike, despite being written by different team members. Therefor, agree on one template design and word-processor (LaTeX, FrameMaker, MS-Word) from the start of the course.

• Do not keep double versions of the deliveries. There is no point in increasing the teams workload by keeping one web version and one paper version of each delivery. Instead, convert your paper documents into pdf and put the pdf-files on the web. However, use caution when converting. Use software that supports pdf or the Acrobat Distiller whenever possible. As a last resort, tools like ps2pdf could be used, but make sure that no pages get garbled when printed.

• Do not hand in sloppy deliveries. There exists lots of spelling-checkers. Use them. On the PC- and Mac-scenes they are commonly included in the word-processors. On UNIX-based platforms, use ispell. Finally, for gods sake, read your delivery through a few times before handing it in, preferable aloud. You will be amazed how many embarrassing errors that will turn up! I as an instructor will not flunk papers just because of spelling-errors or illegal syllabication but each discovered error will rise the threshold of acceptance somewhat.

• Put some effort into the final report. The final report should not consist of all previous deliveries stapled together. Instead, the final report should be an independent and complete document describing all aspects of the team and their work. That is, the final report should be well-composed and well-written with a natural thread of thought running through it. However, if one does not want to rewrite all information contained in the previous deliveries in the final report, one can include them as appendices and refer to them throughout the report.