All the Samples, Templates, Class Slides, Lab Notes and Ramblings to Explain Them
Last modified: 11/8/01
Class Slides in Powerpoint
Lab Notes in Word
The supplements start off with a roadmap to this document set.
Then, links are provided to a set of documents for each milestone deliverable. The document set for each milestone is different, depending on what we thought was appropriate. Some of them have templates and annotated templates and examples and instructions . . . and some of them have just an example and a roadmap. This is because
All the samples are set up around a game coded in java, Dots & Boxes. The game is presently misbehaving (Professor Kaplan had some new requirements for it), but the .jar file for it will be here. This is the help file for it.
All the document samples are in Microsoft Word '97. To look at them on a machine running Word, just click on the link. To save them as Word documents, right click on the link and "Save Target As". The drawings (Design Documents 1 and 2 are both largely drawings) are just .jpg files with an HTML wrapper, so if you want to print them, just save them from your browser. If you are a unix user, you can download StarOffice to view and use the documents. I have version 5.2 of StarOffice running on my ME Windows machine, so I'll happily review electronic copies of StarOffice documents that you send me and that I can view with that set up.
On all of the milestones, you are asked to submit a time log and a set of meeting agendas/minutes. These are usually worth 5 points apiece - so 10% of your grade is a no-brainer, but if you don't turn them in, it'll be really hard to get an "A".
The time log is literally that: a list that shows how much time each person spent on the project. This should be a running total, so we can tell how long you spent on each milestone and how long you spent on the entire project. The time logs are used to track the time of each individual, both when meeting as a group and working alone. An observation: the successful teams in the past have spent most of their time working together in the beginning, really getting to understand the requirements, then tapering off and doing most of coding individually.
The meeting agendas/minutes is a list of the meetings your group held, the meeting date, the topics you planned to discuss and any decisions or action items that came out of the meeting. Action items must be tagged with who's responsible for clearing them.
One of the hardest things for software engineers to do is make accurate estimates of the amount of time it takes to do a task - we tend to just think of the time we are actually typing the code. When we consistently underestimate times, we lose credibility. By having you track your time, particularly the time you spend in your group, we hope you'll start developing an appreciation for how long things really take.
We make you do agendas because when you meet, you can't afford to waste time - you're not just wasting your own time, your wasting that of your team members, as well. To avoid wasting time, you need to figure out in advance what you're going to talk about so (1) everyone can prepare properly and (2) you invite only the people who have to be there. By the way, telephone conversations can count as meetings, too - they don't have to be face-to-face in the same room.
You have to do minutes to help you remember what you agreed to do and so that you can remember who got assigned responsibility for what. This is really important when it comes time for the milestones to be delivered.
Mostly by an "existence" criteria. I look at them to make sure that you understand that both group and individual times are recorded, that you *are* having some meetings, that you are documenting decisions and that you're taking action items. The documentation of decisions and action items can be little bullet phrases - I don't have to understand them, I just want to feel like you do.