DesignToImplementation

DesignToImplementation - CSE 219 Computer Science III...

Info iconThis preview shows pages 1–7. Sign up to view the full content.

View Full Document Right Arrow Icon
CSE 219 Computer Science III Design to Implementation
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Midterm Results TBA
Background image of page 2
Evaluating a Design During the design of a large program , it is worthwhile to step back periodically & attempt a comprehensive evaluation of the design so far Called a design review Design reviews are common practice in most industries (not just software) Reviews should be conducted by a team, not just an individual Team should be made up of those working on the project as well as those who are not All should be familiar with the design itself Write up a TPS report for management
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
A note about teams Labor is sometimes measured in man-hours, man-months, or man-years Doom 3 took 5 years and more than 100 man- years of labor to develop Company Spokesman: "It will be ready when it's done," Why not double the size of the team and halve the lead time (concept date to release date)?
Background image of page 4
The Mythical Man-Month Influential book by Fred Brooks from 1975 http://search.barnesandnoble.com/textbooks/booksearch/isbnInquiry.asp?userid=YG5k1H8AG Assume that a software program might take one expert programmer a year to develop 12 man-months Market pressures might be such that we want to get the program finished in a month, rather than a year 1 programmer * 12 months ≠ 12 programmers * 1 month When you throw additional programmers at a project that is late, you are likely to make it more late Why? Brooks says remove promised-but-not-yet-completed features, rather than multiplying workers bees Also, at least one team member must have detailed knowledge of the entire system (all the modules)
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Evaluating a Design Purpose is not to discover the perfect design (it doesn’t exist), but rather to determine if the existing design is adequate Critical Issues: Is it correct? Will all implementations of the design exhibit the desired functionality? Is it efficient? Are there implementations of the design that will be acceptably efficient? Is it testable & maintainable?
Background image of page 6
Image of page 7
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 05/10/2008 for the course CSE 219 taught by Professor Mckenna during the Spring '08 term at SUNY Stony Brook.

Page1 / 25

DesignToImplementation - CSE 219 Computer Science III...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online