Presentations
A central goal of 600.392: Senior Design Project is to practice and improve (if possible) your presentation skills. You will have to give several presentations during the semester, starting with a short "warmup presentation" in the first week. Each team will present their project three times, once fairly early in the semester to provide background and explain what they are trying to do, once toward the middle to show progress and explain how the project changed so far, and once toward the end to show the outcome of all their work and summarize the "lessons learned" from the project. Each of you will also give a lecture on a topic related in some way to software development or project management, so overall each student will participate in 5 presentations.
Warmup Presentations
Warmup presentations are about 5 minutes long and are presented individually. They can be on just about anything related to computer science in some way, you are free to pick whatever topic you are comfortable with. You are not required to have slides or handouts for these, but if you feel like doing more... Go ahead! :-) See the course schedule for when these are, the number of lectures set aside depends on enrollment.
Project Presentations
Project presentations are about 20 minutes long and are presented as a team; each team member should present for roughly the same amount of time. There are three different project presentations, each of which has slightly different requirements (see below). However, they should all be done using slides, and you should try to practice and time the presentation before you actually give it; things should go very smooth, that's the point. If you include a demo, make sure that goes smooth as well! See the course schedule for when these are, the number of lectures set aside depends on enrollment.
Proposal Presentation
The goal of your proposal presentation is to convince someone with buckets of money to fund your project. This presentation is "fake" to some extent as you will pretend that the idea for your project is yours alone, not that of your client. The presentation should address five main questions:
- What is the (sad) state of the world now, without your project?
- What is your magnificent and innovative idea?
- How will the world be a (much) better place once your idea is implemented?
- Why is your team uniquely qualified to run this project?
- What is your overall plan for the project?
If you want, you can also include how that person with buckets of money can fill even more buckets after the project is over, but that's not required. You are presenting to an audience that has some limited experience with technology, but no deep understanding of how things work. For example, you can assume that they understand the purpose and benefits of networking machines, but that they have no clue what an IP packet is or what makes box A a router and box B a switch. The "plan" in question five should outline what you expect to have done when.
Status Presentation
The goal of your status presentation is to explain how your project is going to colleagues in the same organization who work on other, potentially related projects. In other words, the audience is quite a bit more technically mature than what you assumed for the proposal presentation. This presentation is "real" because you treat the project as something given to you by an external client and you concentrate on how the actual development is going from your perspective. The presentation should address four main questions:
- What is the project about?
- What is your system currently able to do?
- What is the architecture of your system?
- How did you have to adjust your initial plan so far?
- What other lessons have you learned so far?
For the first question you should summarize the idea of the project following (to some extent) your earlier proposal presentation. Of course you must "compress" what you did there to fit into this presentation, so hit the highlights and one or two examples, but defer details to the question and answer period. Concentrate on the functionality users will expect from the system!
For the second question you should summarize the capabilities of your current version and contrast them with what the project wants to achieve overall. This is a good chance to revise your estimates: Are you going to be able to build the whole thing? What parts will you try to leave out since you're timeboxing? What parts that the client didn't specify yet are you going to try to sneak in? Your reasons for these decisions/plans are important as well!
For the third question you should summarize the overall architecture of your system. This may take the form of one or more UML diagrams illustrating particular aspects, or it may be possible for you to cover at least the high-level structure without going into too many low-level details. It's really up to you how much you say here, but if you think there are parts of your design that are really nifty, those should show up here. If you don't have nifty parts, present what you have as a design anyway.
For the fourth question you should briefly summarize your initial plan (from the proposal presentation), how you are doing right now if measured against that plan, and how you are changing the plan given your experience with the project so far. Again the "new plan" should outline what you expect to have done when.
For the fifth and final question you can basically cover whatever you think you learned so far. You can talk about external libraries and whether they are good or bad, and in what way. You can talk about the development process and what works or doesn't work. You can talk about earlier designs you scrapped and why. You can talk about team dynamics and your experience as a team. You can even talk about your client (remember, this is a presentation your client technically doesn't see) and what you think they are doing right or wrong about the project. Of course you need to stay "professional" with all of this, name-calling is not allowed!
Final Presentation
To be determined, I am probably changing the format for this presentation compared to earlier offerings of the course.
Lecture Presentations
Lecture presentations are 20-40 minutes long and are presented individually; for the current offering, each presentation lasts the full 40 minutes. Each presentation covers some topic in software development or project management that is of interest to the participants in the course. The presentation should be done using slides, and you should practice and time the presentation before you actually give it; things should go very smoothly, that's the point; if you include a demo, make sure that goes smooth as well. Here is a list of topics you can sign up for, but feel free to email us suggestions for other topics of interest. Obviously you cannot pick a topic that is already taken this semester...
Open Topics
- Automated Unit Testing
- Specification Languages
- An Introduction to Design Patterns
- The Personal Software Process
- The Capability Maturity Model
- Responsibility-Driven Design
- Zero-Defect Programming
- Software Craftsmanship
- Advanced Debugging Strategies
- Object-Oriented Design Heuristics
- ...more to come...
Confirmed Topics
- Overview of Free Software and Open Source Licenses (Andrew Chung, Fall 2006)
- SCRUM (Terence Lee, Fall 2006)
- Analysis Patterns (Glenn Gentzke, Fall 2006)
- The Psychology of Computer Programming (Brian Suk, Fall 2006)
Previously Covered
The following topics were covered in a previous course offering and are not currently available except if you explicitly request the topic and you have a good reason for doing so.
- Issue Tracking Systems (Constantinos Michael, Spring 2006)
- An Overview of UML (Raymond Buse, Spring 2006)
- The Case against XP (George Shafer, Spring 2006)
- Refactoring: What, when, and how? (Terry McGill, Spring 2006)
- Intellectual Property Rights (Joseph Choe, Spring 2006)
- The Psychology of Computer Programming (Sam Cassatt, Spring 2006)
- Cleanroom Software Engineering (Chris Weiland, Spring 2006)