1. Design Document Review

2. Design Documents – Common Issues
There are a number of remarks that are applicable to a wide range of the design documents. They may not apply to yours at all, or may only apply to a degree. Think about whether you suffer from any of these common issues in addition to the remarks written on your design document…
Should there be a mechanism for a novice user to see the rules of the game?
Would a “hint” button be helpful to show the human player where the computer would move it was it’s turn?
This might be helpful for debugging and testing.
Did you state that an applet was necessary – not a stand alone application?
How does the user select a place to move?
Who moves first? What color are they?
CS351 - Software Engineering (AY2004)

3. Design Document – Common Issues
Since this is an applet, do you need to say anything about redrawing the screen if it is uncovered or maximized? Should anything happen if the window is closed – especially if your game is playing any kind of sound?
Did you may explicit the computer strategy you want implemented?
You should not provide code or pseudo-code in the design document.
You should not leave the strategy to the implementer “to sort something out”.
Is the design document self-consistent and self-contained? The handout that we provided should be treated like a customer interview. Someone should be able to implement your design given only your design document.
CS351 - Software Engineering (AY2004)

4. Design Document – Common Issues
Can your design be realistically completed in the time available?
Your design document should focus on the observable behavior you want.
Your design should not focus on implementation matters.
Focus on the What, not the How.
What happens if a player attempts an invalid move? Sound?
Should there be a delay between the human’s move and the computer’s response.
Several “strategies” failed to take into account the knowledge provided by the client (i.e., the handout) regarding the value of squares, the poor approach of grabbing as many squares as possible all the time, … You should be trying to address the client needs for a game that plays “reasonably well”.
CS351 - Software Engineering (AY2004)

5. Design Document – Common Issues
Several design documents borrowed heavily from our handout and from several web sites for Othello. It is supposed to be your design, not someone else’s.
In general, there is room for improvement. We are sure that you’ll uncover a range of other issues as you start to implement your system.
Make sure that you work with the implementer of your design and update your design to be more complete and helpful.
Remember that you will need to assess the design you have to work with respect to how complete and consistent it is (and you’s will be assessed against the same criteria).
CS351 - Software Engineering (AY2004)

6. CS351 - Software Engineering (AY2004)
Implementation
The implementation should be done from the design document alone (you should not need the handout we provided, nor your personal knowledge of the game).
All questions you have about the expected behavior of the game should be answered by the design document.
Beware of any assumptions you make.
What the designer wants should be carefully and fully elaborated in the design document, how it is implemented should be entirely your choice.
Note that describing techniques such as minimax is appropriate since it states the technique required, but the design document shouldn’t give you the code. However, you shouldn’t be shy to discuss the algorithm with the designer if you’re not familiar with it.
CS351 - Software Engineering (AY2004)