|
Panelist Instructions
for "Software Engineering of Internet Applications" at MIT
Site Home : Teaching :
6.171 : One Item
|
Thank you for agreeing to serve as a panelist for final presentations in
MIT Course 6.171, "Software Engineering of Internet Applications". Our
students are generally seniors majoring in Computer Science. In just a
short time, they will be out there hanging out a shingle as some of the
most expensively educated engineers in the United States.
Three months ago, the students were presented with a client, a business
person with a real problem to solve. As a team of two or three, they
were responsible for translating the client's aspirations into concrete
specifications for a database-backed Web site that could be built and
launched to real users by now, with challenging client aspirations
deferred into a specification for a version 2.0.
The semester is just about over. Your role is that of a business
manager or a venture capitalist deciding whether or not to continue
funding for the team's work. You are also trying to figure out if you
like the way that this group of engineers thinks and works. The team
will give you a presentation that has the following structure:
- elevator pitch, a 30-second explanation of what problem has been
solved and why the system is better than existing mechanisms available
to people
- demo of the completed system (see the
"Content Management" chapter for some tips on making crisp
demonstrations of multi-user applications) (5 minutes; make it clear
whether or not the system has been publicly launched or not)
- a slide showing system architecture and what components were used to
build the system (1 minute)
- discussion of the toughest technical challenges faced during the
project and how they were addressed (2 minutes; possibly additional slides)
- tour of documentation (2 minutes) — you want to convince the
audience that there is enough for long-term maintenance
- the future (1 minute) — what are the next milestones? Who is
carrying on the work?
At the end, your job is to provide constructive criticism. What could
they have done better? Do not cut them any breaks because they are
students. Most of them won't be students as of two weeks from now.
They are going into organizations such as Google and Microsoft where
mediocrity will not impress anyone.
We suggest that, as a presentation proceeds, write down numerical scores
(1-10) for how well a team has done at the following:
- This team has communicated clearly what problem they've solved.
- The demo gave me a good feeling for how the system works.
- This team has done an impressive job tackling engineering challenges.
- This team has documented their system clearly and thoroughly.
- This team has take the trouble to get real feedback from real users.
- I'd really like to hire these people for my own organization.
Don't be shy about interrupting with short questions during a team's
presentation. If the presentation were from one of your subordinates
or a startup company asking for funds and you'd interrupt them, then
interrupt our students.
Examples of previous projects
All of these systems are still up and running as of November 2005.
philg@mit.edu