In the spring of 2009, a friend who runs an ecommerce Web site asked one of the authors for help explaining why his application was running so slowly. He had paid an MIT-trained programmer with 20 years of experience $200,000 to build it and was paying a hosting service $1100 per month to run it. Despite the site having only one user every hour or so, being in a soft-launched state, pages took up to 5 minutes to load. Philip said "This will be easy. Just show me the design documentation." He replied "What do you mean?" Philip said he wanted the document where the programmer set forth what problem he was trying to solve, how large a data set was being handled, what each server did, what software had been selected and why, where the files and programs were on the server, and what the data model was. "There isn't any documentation," replied the business guy who had created the idea and written the checks to the programmer.

Queries to the programmer revealed that he was almost as ignorant of the answers to the preceding questions as his boss. He knew that he was using Ruby on Rails and MySQL, but not how many gigabytes of data were required to produce all of the public pages of the site. Philip eventually was able to get some good information from the hosting service's sysadmins, e.g., the size of the MySQL database and the amount of RAM on each virtual "slice" being used to run the HTTP servers and the RDBMS. By chucking the virtualized model and buying the cheapest Dell pizza box server with 16 GB of RAM (about $500 worth at the time), the amount of time required to produce a page fell from 5-10 minutes to no more than a few seconds. Hosting costs were reduced from $1100 per month to less than $100. However, our friend was not able to recover the months of customers who had been lost due to the poor performance of the service. What would have saved this business? An external design review.

Design Reviews

The last 5 weeks Serious in-class design reviews Establish achievable milestones Visible progress Demo for filming (for customers, ABET, dept.) Done

Design Reviews Pick a date Two classes if necessary 10 am or 2 pm Formally present designs Leave with a list of tasks to accomplish

Meeting Rules Critique the product, not the producer. Do not attempt to solve the problems, just find them. Record defects and issues on standard forms. Insist upon advanced preparation. Avoid focusing on issues of style.

Let’s be practical Present the design document - use lots of block diagrams Use your 5-min Open House demo to identify major capabilities Take questions / Record issues Set ongoing lab meeting times

Roles Moderator (not a team member) Team / Authors Recorder Inspectors (everyone else)

Moderator Briefly state the purpose of the meeting and the product that will be reviewed. Remind the participants that the purpose of the meeting is to find and record defects and issues, not to criticize one another or solve any problems found. Stop the review on time. Ask the team for a consensus on the product appraisal and mark it on the record form. Decide whether another meeting is required to complete the review. If not, have all participants sign the Review Summary Report form. It is your job to keep the meeting under control and moving along. If you see any inappropriate activities (solving problems, bogging down in discussions, criticizing the author, author getting defensive), break in. Remind the team of the purpose of the meeting or the guiding principle that is being violated. Then continue with the reading.

Presenting Team You can point out defects just as any other inspector. In general, you can give concise answers to questions from other inspectors. As one of the inspectors, your job is: –to point out any aspects of the work product being inspected that you think may be a defect (missing, wrong, extra). –to raise any issues that you believe require clarification, style issues that you believe adversely impact the product (not simply something done differently from how you might have done it), or questions that need to be answered. Identify the defect or issue by requirement number, a brief description (remember, the recorder has to write down the essence of what you say), and the type of error. Do not engage in problem solving or disputes about whether something is a "defect" or an "issue." When in doubt, capture the point and move on.

Inspectors To point out any aspects of the work product being inspected that you think may be a defect (missing, wrong, extra), and To raise any issues that you believe require clarification, style issues that you believe adversely impact the product (not simply something done differently from how you might have done it), or questions that need to be answered. Nothing is off limits Cursing is allowed

ProjectDate 10 amModeratorDate 2 pmModerator Air Sensor April 13Don iPad Talker CHC Website Community Info Database Single Switch Access April 6Tony Firefighter Monitoring System April 8 Steve Nursing Home Safety April 6Dulantha Talking Head Remote Controlled Wheelchair Badge Tracker Asthma Action Plan