In this section we describe one way organize a Software Projects courses with Software Engineering and Computer Games as the text. What’s given here are some techniques and practices we’ve developed over multiple iterations of the course.
This material will not be of much interest if you’re reading this book on your own, but it will hopefully be useful for professors using the book in their own courses. It goes without saying, however, that nobody other than myself is likely to want to do things in this exact way.
The beginning part of the Software Projects course is devoted to getting everyone up to speed on the concepts and tools to be used.
One the one hand students need to get some understanding of the ideas of software engineering. A useful compact book for this is Steve McConnell, Software Project Survival (Microsoft, 1998). And on the other hand, students need to learn how to use a common, powerful software development system so that they can carry out a substantial project. A sound modern platform is Windows, using Microsoft Visual Studio with the Microsoft Foundation Classes (MFC).
This part of the course will take about half the semester. During this time the professor assigns two or three individual programming assignments that each student does and hands in separately. And at the end of this phase there is a midterm, testing the students knowledge both of software engineering ideas and of programming concepts.
The grades in phase one of the course help the professor find out what the individual levels of performance are, both for purposes of final grade assignment, and for use in dividing the class into small teams for the Software Projects phase of the course.
The individual programs might be graded according to three criteria that are weighted as indicated.
· Organization and Documentation 25%
· Program 50%
· Improvements 25%
Organization means handing in the program in the correct format.
Correct disk format. Normally this will mean giving the professor the executable and source code on a single floppy disk. The *.exe and any needed support files should be in the root. The source files should be cleaned (so as not include things like *.obj files) and they should be complete (they should include, for instance, the Res subdirectory). The source code should either be named Source or should have the same name as the project file (such as, for instance, Pop).
Correct executable format. The executable should be the Release version rather than the Debug version (so as not to be too big), and it must use all MFC libraries in the LIB rather than the DLL format (so that the program will run on all machines.) Any files (such as bitmaps) which the *.exe needs at start‑up must be present.
Correct documentation format. Student documentation should be printed on a laser printer.
Individual Project Documentation will be very brief, usually not more than one to three pages. It will include a brief description of the program is supposed to do: this is a kind of Requirement. It will also include a User’s Guide section, this is a kind of Specification. The habit of documenting a program needs to be started early: documenting a program is almost as important as building it.
The Program is of course the most important part of any programming assignment. Although the grader may sometimes look at your code, the standard practice will be to grade the programs simply by running the *.exe and seeing how the program behaves. Ordinarily in a programming assignment the professor will give the students a specification describing what features their programs should have; these are the first things the grader will look for. When there are a number of features, the program grade will be broken down into an appropriate number of points per feature. A certain number of points are allocated simply to having the program behave well and not do something ugly like crashing at exit.
Improvements are additional features that a student thinks of adding to his or her program. This is, in other words, a “creativity” category. Being creative and original is an important part of software engineering. The Improvements category is not an “extra credit” or optional category, but it is a standard part (25%) of the assignment that a student must fulfill in order to get the highest possible grade. Note that proper documentation is especially important for Improvements features, otherwise the grader may not know they are present. Another reason to have the Improvements grade is to reward students who do not copy from other students. A Improvement that shows up in only one program will earn more points than a Improvement that’s in lots of students’ programs. In this phase of the course, students should hoard their Improvements and not share them.
In the second half of the course, the professor divides the students into small teams, with each team working on a specific software project. During this part of the semester, class time is mostly used as lab time, in which the individual student teams discuss their programs. The professor moves from team to team, answering questions and makings suggestions. Occasionally he or she may give a short lecture on some topic of interest to all the teams.
During this phase of the course the professor will collect a series of assignments from each team. A typical sequence of assignments would be
· Suggested requirements (two iterations: individual and team).
· Requirement, specification, and design by teams.
· One or two Alpha programs with design and User’s Guide
· Beta program with fix list and User’s Guide
· Final release program with User’s Guide.
For the alpha, beta, and final presentations, the student teams will demonstrate the current version of their program to the class using a computer with a projector. All a team’s members stand in front of the class during a demonstration. One member does the talking, and another runs the machine. Over the course of the three or four classroom demos’ the team members should take turns performing the various roles.
How big should the teams be? First of all, it seems reasonable to have all the teams be more or less the same size, although sometimes they may differ by a count of one or at most two students.
Given that it’s best for each team to have a machine to use on their own during the class sessions, the individual team sizes normally should be no less than (Class Size)/(Available Machines). Although if the class must be taught in a room with only one or two machines, then of course this formula will not apply.
If the number of classroom machines is not an issue, a team size of three or four seems to be optimal. All things being equal, three‑member teams seem to work the best of all. When a team has more than three or four students, complete communication among the team members becomes too difficult. Another issue that arises with large teams is that on such teams there will very often be a student who ends up making no contribution to the project at all. There’s only so many pieces in which a small project of this size can be broken.
No team should ever be smaller than three people. The reason is that students sometimes miss class, and if there is a two‑member team, then when one student misses class, the other student has nobody to talk to.
How should the team members be assigned? It’s not necessarily a good idea to have the students pick the teams themselves. In the work world, one often has no prior acquaintance with the people one works with, and it’s not a bad idea to have some early experiences with this. And a possible danger with self‑selected teams is that this can lead to some students feeling left out.
A non‑controversial team‑selection procedure that works well is for the professor to tabulate the students’ total grade points from the first phase of the course, and to group students with closely similar point totals. Thus, if the intended team size were three, the three students with the highest grades would go onto one team, the students with the lowest three grades would go onto another team, and so on.
This approach seems to work better than trying to “balance out” the teams by putting a high‑scoring, low‑scoring, and average‑scoring student one each time. If all the students on a given team have similar levels of ability, this makes it more likely that each of the students can make an equal contribution to the team project. Of course the project done by the three highest‑scoring students is likely to be better than the project by the three lowest‑scoring students, but so what. The most important issue here is for each student to have a chance to get really involved with his or her project, and this is more likely to happen when the students work with others of roughly equal abilities.
There’s no need, however, to be overly strict about the team member selection process. Sometimes students can be allowed to switch teams either for personal reasons or to find a better match for their interests.
Before the teams are assigned, each student should write up an individual specification sketch for a project, so that he or she has a proposed idea to bring to the team to start with. The professor looks over, comments on, and grades these sketches.
The common requirement is to create a playable computer game. It is also required that this project be a “new” project and not be related to work that a student has done, or is currently doing, for some other class.
At this point the teams are assigned. The teams are assigned not so much on the basis of suggested requirements, as on the basis of current grade point average as discussed above.
Once the teams have been assigned, the students move to sit with their teams, exchange email addresses and phone numbers, find out a little about each others’ backgrounds, and then try and agree on a project for the team. Having the suggested specification sketches that they’ve written up provides support for those students who are shy about telling their new team members what they’re interested in working on.
The teams are requested to write up for the next class a specific description of a suggested requirement for the project they want to do. Ideally the project choice will be something that each team member feels fully able to “buy into.” If there is dissent, a team can propose two projects and let the professor pick or suggest a compromise project.
In the next class the professor goes over the teams’ suggested requirements and guides each team towards a requirement that is neither too easy nor too difficult. This process is carried out in public, with all students listening.
It will be more interesting for the class demos if no two teams adopt the same requirement. If the teams have different requirements there’s also less danger of one team being overly influenced by another team’s code.
Once each team has found a requirement that the professor finds acceptable, there’s still time for a little last‑minute team‑member switching. It’s important that each student on a team feels interested in the team’s project, and occasionally a few people can move to a new team.
Now let’s give a little more detail about the five kinds of assignments listed above.
As mentioned above, at the start of the team projects, the class goes through two iterations of project suggestions. First the separate individuals suggest projects, and then after the teams are formed, the teams suggest projects. With the professor’s advice and approval, the teams can then finalize their project requirements.
The professor will strongly discourage attempts by students to “kill two birds with one stone” and use another course’s project assignment in this course.
Here are some of the basic requirements; see also the Final Release grading categories below.
· The project must be original, and must be developed specifically for this course. The project cannot include or duplicate a project completed or currently being done by a team‑member for another class. The project must only include: AppWizard‑generated files, sample files provided with this book, code written by the team members during the semester. Use of certain other kinds of special‑purpose source code modules is permissible if approved by the professor.
· The project is to be a computer game based on the Pop framework. The objects of the game: player, food, enemies, obstacles, etc. will all be derived from the Pop framework’s cCritter class, and the game itself should be derived from the cGame class.
· The game should be playable. Its parameters must be tweaked so that the game is interesting to play. If we assume the score has a percentage range between 0 and 100, then we can specify “interesting to play” as follows. A game is interesting to play if a session lasts one to three minutes, and if a novice user scores below 50%, the score improves to the 70%s after playing a couple of times, and an experienced user can rarely score above 90%.
· The game should have multiple levels.
· The game should use sounds.
· The user controls a moving player critter with mouse and arrow-key movements, and the controls are easy to use.
· Programs should be resolution and processor independent, appearing the same irregardless of the screen resolution or the window size, and seeming to behave the same on a wide range of processor speeds.
· Program must show the player’s score, health, time remaining, and other important information in the status bar.
· (Optional) File | Load and Save should load and save parameter values.
· The program has to include a Help file that acts as a complete User Guide including sections on the concept, getting started, description of controls, and suggestions about things to try.
· Teams should agree to allow their completed executables to be posted on local network and the Web for free download. Teams should include contact email information in the game’s About dialog.
The team should now work on a detailed document giving a plan for their software development.
Once the team is fixed on a definite requirement, they need to write up a detailed version of the requirement. Typically this can be broken into three levels: features that will definitely be included, features to be added if time allows, and features that would be nice to add.
The specification takes the form of a tentative description of a user interface, as well as a kind of draft for a User’s Guide.
The design document should consist of C++ language prototypes of all the classes to be used; that is, draft versions of the *.h files, although the *.cpp files do not need to be written yet. Including a UML diagram of the class structure is also useful.
The design document should also include a description of the program flow; that is, a description of how the program will run itself, and how the user inputs will enter into the flow.
At this early stage, if possible, it’s also useful to have a simple running prototype of what the program might look like.
Usually there will be several dozen preliminary builds made for each official “alpha.” A alpha release is a somewhat finished‑off version of the program along with a current UML diagram of the class design plus a specification in the form of draft for a User’s Guide.
The alphas, betas, and final release will be demoed by the teams for the whole class; this provides a clear target time for getting the program together. The demos need not take very long.
When a program reaches the beta level you have feature‑freeze, meaning that you should not add any new features after this point. From the beta stage on, your goal is to debug the program, to smooth out the user interface so that it really works properly, to fix the User’s Guide so that it is helpful and accurate, and perhaps to provide some good sample files to load.
In theory, anyway. In the context of a projects course, students often do add a few more features for the final release. They should be warned that that this a high-risk project management behavior, and that they must be sure to adequately test all last minute features before the final demo. But it would be cruel and unreasonable to actually penalize a team for successfully adding a few new features after the Beta.
At this point the User’s Guide should be getting fairly polished. A User’s Guide should include
· Motivation and overview section
· Quick Start section about installing and starting the software
· Things To Try section with notes on the loadable sample files
· Detailed explanation of all controls
· Biographical notes about the individual team members, with contact info.
This version of the program should be, insofar as this is possible, brought to a commercial “shrinkwrap” level. For this release, the contents of the User’s Guide should be converted, pretty much as‑is, into a *.hlp or *.htm Help file. The program executable and help files plus any supporting sound or image file should be compressed into a *.zip file that can be posted on the local network and/or Web for download. The professor may put some of the files on his or her Web page for public download, or the students can to this themselves.
The team assignments will be graded more or less like the individual programming assignments, with grading categories of Mechanics, Stability, Documentation, Concept and Design, Playability, Interface, Appearance and Sound.
A good policy is to give each team member the same grade on the preliminary assignments, the alphas, and the beta. This makes life easier for the professor and prevents squabbling among the students.
A example of how one might assign points for the Final Release of a project might look like this. The Alpha and Beta builds can be scored in a similar fashion, but with not all of the Final Release grading categories being introduced until the Beta or until the Final Release stage.
Final
Release - 45 Points.
(4)
Mechanics
(1) All necessary
distribution files (*.EXE and *.HLP) are alone on one disk (possibly zipped
into one file together). The source is
a separate disk or a separate ZIP.
(1) The *.EXE should be
the Release Version, not the Debug Version.
The *.EXE has the same name as your program, using upper and lower case
letters.
(1) The program has its own
icon. The Caption bar has the name of
your program. The About box has the
name of your program and the names of the
team members.
(1) Complete copies of
source, executable, and printed documentation are brought in for each team
member, that is, you make four or five copies of everything, one for the
professor, one for each of you.
(5) Stability
(5) The program does not crash while being used,
nor does it show any incorrect behaviors.
(7)
Documentation
(1) There is printed
documentation and there is a *.HLP file. The *.HLP has the same name as your
program. The documentation has been
spell-checked.
(2) The documentation is
reasonably long. It includes Getting
Started, Things to Try, and Explanation of Controls.
(2) The documentation is
attractive in appearance. It is
formatted with section titles. The
printed documentation (and possibly *.HLP) includes pictures.
(1) Every team member’s
name is in the About dialog, the Help file, and in the printed documentation
with email address.
(1) There is a
computer-drawn or neatly hand-drawn UML diagram showing the classes you added
to the Pop Framework. The diagram
should include the names of any new or overridden methods which your derived
classes use, and should also include the names of significant data members you
have added.
(10)
Concept and Design
(2) There is a simple and
interesting overall concept.
(5) The game concept is in
some significant way original or challenging, and includes some kind of
substantial advance over the distributed Pop Framework code.
(3) Your UML diagram shows
a solid object-oriented-oriented design, and this design is actually used in
your code.
(10)
Playability
(3) The player critter is
easy and intuitive to control.
(3) The game is not too
easy or too hard to play.
(2) There are clear-cut
goals during the play.
(2) There are multiple
levels of play.
(4)
Interface
(2) You have removed
unnecessary items from the menus. You
have kept items that are useful. You
have added new items relevant to your game.
(2) The Status Bar gives
useful information.
(5)
Appearance and Sound
(1) The game has an
attractive background which does not make the critters hard to see.
(2) The critters are interesting and attractive
in appearance.
(2) Game events are marked
with interesting sounds that aren’t long and annoying. The Toolbar Mute switch turns all sounds
off.
The final release program may take the place of a written final exam, and is weighted more heavily than the earlier assignments. The final grade can also incorporate an additional category of points for Individual Team Contribution so that students can be given more or less points in this category according to how much they contributed to the team project. At this point in the semester, the professor will normally have a fairly clear idea of who did what on each team. A student’s ability to work harmoniously on the team can also affect his or her Contribution grade. In addition it is reasonable to take into account a student’s Attendance during the team project phase of the course — there is nothing more destructive for team progress than a team member who doesn’t show up for meetings.
It sometimes happens that two students on a team will get into an argument with each other, leading to a breakdown in communications. This is something that one does not want to do in a work environment, as it can lead to getting fired. The classroom team project represents a chance to practice at getting along with others. When team members get into a really severe feud, the professor’s reaction might reasonably be to lower the Contribution grade of both these students, irregardless of who is “right.” According to the way most employers look at personnel, anyone who is in an argument is, by definition, not right.