BU CS 511 Team Presentations

Software Engineering -- CS511
Boston University -- Fall 2001

Team Presentations

Past Talks

9/27

10/4, 10/11, 10/18, 10/25

11/1 (rough outline, speaker notes), 11/8, 11/15, 11/29 (slides, notes)

12/6 Team 10 slides and notes, 12/6 Team 11 slides and notes

General Notes

Your talk should be 20 to 30 minutes long (35 minutes maximum), with questions and discussion to follow this.

Practice your talk out load, standing alone in a room (or with team members). Record it on a tape recorder (or video) and listen (or watch) yourself. This helps to work out kinks. Time your talk as you practice.

Allow the whole team to review the outline, since the grade will apply to the whole team.

Hand in a hard copy of your outline to me at the start of your talk.

Be careful about talking too fast.

While it is not required, presenters often make PowerPoint slides for their talk. I can get an overhead computer monitor to display them.

After your talk (or before) email me a copy of the files you presented (MS Word, or PowerPoint, or HTML). I will post it on the class web site. You will not receive a grade until you do this.

Treat the presentation as if you are presenting to a meeting at work. Wear nice clothes, make a good impression.

Suggested Outline for a Presentation

Introduction.
a) What is this talk about?
b) Why does it matter to us?
c) What will you cover? (show a short outline of the talk)

References. What did you read or study? Where did you find it?

Main topic. Teach us about this subject in some depth. This is the longest part of the talk.

Analysis. What do other experts think about this? What do you think and why?

Grading of the Presentation

Your grade will be based on:

Presentation. The visual aids should be easy to read and you should speak slowly and clearly. Your appearance and manner count here.
Organization. The talk should move in a logical sequence and be easy to follow.
Content / depth -- The right amount of material. If you try to say too much, you will run long or be rushing. If you say too little, you won't use the available time. Most of us know the broad outlines of these topics already. Give us some technical insight. Examples are very helpful in explaining new topics.
Analysis -- Show that you thought about this topic and bring your own ideas to the talk.
References -- A variety of sources. Show that you did some research in the library or Internet.

Topics

Teams may choose from one of these topics, or propose their own. (Make sure I approve the topic before starting work on it.) Teams will choose topics in order of presentation (so Team 1 gets the first pick, etc.)

Mythical Man Month (book). The classic work in software engineering. I want some team to choose this topic.

Death March (book). A new classic. Entertaining and relevant to situations you will run into at work. (You don't have to read all the email msgs in each chapter).

Extreme programming. An up-and-coming methodology. See www.xprogramming.com/.

Licensing of software engineers. Will probably receive more and more attention in the coming years. Read relevant chapters from After the Gold Rush by Steve McConnell, and find other articles on this topic.

Adaptive Software Development (book), by James Highsmith. He claims that managing Internet development projects is very different from managing traditional software development, and that he has the answers for how to do it. See more information at http://www.adaptivesd.com/adaptive_software_development_bo.htm.

Human risks from poorly engineered software. An important topic. See Nancy Leveson's home page (http://sunnyday.mit.edu) for interesting links, and a long list of software accidents at news:comp.risks. Give a couple examples, summarize why these accidents happen, and suggest solutions.

Structured analysis, see Yourdon for classic works.

Software re-use.

Function point estimating model. Capers Jones has written a lot about this, www.spr.com.

COCOMO estimating model.

The Personal Software Process (PSP) from Carnegie-Mellon. This is like the CMM, but aimed at individual programmers. (www.sei.cmu.edu)

ISO 9001/9000-3 quality standard for software. Same idea as CMM, but different approach.

Any of the software engineering books published by IEEE Computer Society. See list at http://computer.org/cspress/. Make sure you choose an SE book, not conference proceedings or a collection of articles.