1. Group 2 : Team Battleship Team Members: Zhen Cai Christopher Campbell Justin Doll Jason Miller Nicholas Rimer Raeginald Timones

2. Reggie Timones

3. Current System  Battleship board game by Milton Bradley  Physical board game  2 human players

4. Proposed System  Needs  User modes  Operational Scenarios  1 player  2 players

5. Operational Features Must Have: Graphical User interface Game pieces Artificial Intelligence Menu Milton Bradley rules Would Like to Have: Salvo variation Online play Adjustable AI difficulty Sound

6. Analysis Graphics Game setup time Expected Improvements: Game types Customization Disadvantages: Sound Human strategy vs. AI strategy Limitations: Meet deadlines Time management Equal task divisions Risks:

7. Nicholas Rimer and Zhen Cai

8. Project Plan ArtifactDuration (days) Main Program Structure5 Basic GUI14 Basic AI14 Phase one Testing14 Advanced GUI (Images)14 Advanced AI (Multiple Difficulties)14 Phase two Testing14 Final Revision and Delivery7

9. Timeline

10. Tools and Computing Environment  Programmed in the Java Environment  Will run on any operating system with Java installed

11. Software Life Cycle  There will be one final version that will have a lifetime warranty  Extensive testing will be done to find any errors  If a fatal error is found after release a new version may be released

12. Quality Assurance  Two Phases of testing  All members will conduct their own tests  Errors will be compiled and fixed

13. Training Plan  The program will have a tutorial on how to play  A user manual will list all other properties of the software including a how to on running the program  No other specific training is required

14. Security  No implemented security  The software's warranty will be void if the code is modified

15. Risk Management  Extensive testing to reduce failures  New version releases over the internet to reduce the cost of failures

16. Maintenance Plan  Maintenance will only be done given that fatal errors occur after the final release  A new version will be released

17. Jason Miller and Justin Doll

18. Product Overview  Assumptions  Java Runtime  Stakeholders Our Product DevelopersCustomersUsers

19. Samples from Event Table Game start User selects to start a new game. Application displays the setup screen for the user and allows them to place their ships. Application loads configuration for a new game, in a single player game initializes the AI and allows it to place its ships on the board. Begin turns User places ships and chooses to start the game. Application displays the game board and begins turns. Game checks to make sure users have properly placed ships and locks them in place. Then randomly chooses who get to play first. AttackDuring a player’s turn they choose where to attack. The board displays either a hit or a miss where the attack occurs. The game checks the opposite player’s board to see if the attack hits a ship and responds appropriately.

20. Use Case Diagram

21. Sample Specific Requirements No: 002 Statement: System should have a main menu with options to start a new game (1 player or two players), see instructions, or exit the game Source: System Dependency: 001 Conflicts: None Supporting Materials: None Evaluation Method: Main menu is provided and options are available Revision History: Jason Miller, 10/1/09, Created No: 003 Statement: System should have a start game menu that allows players to set up their field (by placing boats one by one or randomly) Source: System Dependency: 001 Conflicts: None Supporting Materials: None Evaluation Method: When a new game is started the start game menu appears Revision History: Jason Miller, 10/1/09, Created

22. 3.1 Functional Requirements: Check placement of ships.Play the game.Exit gracefully. Input attack and output hit or miss. Keep track of ships remaining. Validate attack so that same spot can’t be attacked twice. 3.2 Interface Requirements: Software will run in the JRE. 3.3Physical Environment Requirements: Software will run on any system that meets the requirements of the JVM and has it installed.

23. 3.4 Users and Human Factors Requirements: System should support any level of user with basic knowledge of computers. 3.5 Documentation Requirements: System will provide information on installing and running the required software so any user should be able to run the software. 3.6 Data Requirements: Game state must be stored at every turn to ensure game consistency Game data must be cleared at the end of each game to ensure that the next game is not changed.

24. Christopher Campbell

25. Objective of the Test Plan  Identify activities that will help produce an application with the following:  Usability  Acceptable Performance  Functionality  Complete our objective through the following  Creating test cases  Identifying errors, bugs, issues  Regression and unit testing

26. Test Environment  Software  Any OS that supports the Java Runtime Environment (Windows, Mac OSX, Ubuntu)  Hardware  Any modern PC with at least 512 MB of RAM and at least 1.6 GHz Processor  Testers  Developers  Users

27. Stopping Criteria  Issues found, issue ticket created on Google Code page  Issues are discussed as a team, prioritized then tested individually  Critical issues are deemed solved after extensive regression testing

28. Testing Cycle Find Issue Correct Issue Regression Test Test new Features

29. Issue Priority Critical Issues that cause the program not to start Issues that cause the program to crash Issues that prevent the game from finishing Intermediate Issues that cause the game not to enforce the rules AI issuesGUI issues Low Graphical glitches that do not interfere with the game being played Layout issues (overlapping GUI components) Any issue that is from advanced features that are not specified in the requirements

30. Sample Test Cases TC03Check title screen.Testing involves testing the title screen interface. Check if the correct buttons are displayed for the gameplay modes, and they function as desired. Title screen displays correctly, buttons function correctly. TC06 Random pieces are placed correctly If player chooses to have the game randomly place their pieces, it should be tested that they are all placed in the boundary, and in the right orientation Random pieces are all placed correctly TC07 Players alternate providing game input Testing involves checking that the player turns alternate after a player inputs a location on the game grid. Player turns alternate TC08Player input is correctTesting involves checking that both player's inputs on the grid are properly recognized, placed, and calculated as a hit or miss Hits or misses determined correctly

31. Sample Test Cases TC17AI behavior correctness Testing involves checking how correct the behavior of the AI is. It should, to its best ability, attempt to sink ships. AI behaves correctly TC18AI behavior difficultyTesting involves that AI is not to easy, and that provides a challenge AI not to easy. Regression Testing TC19 Buttons and UI functions Testing involves testing of all buttons and UI functions of the application All buttons and functions work TC20All rules enforced Testing involves checking of the enforcing of all rules of the game All rules are followed TC21Game modes Testing involves all game modes are working and fully functioning All game modes work TC22UI elements are displayed correctly All GUI elements are displayed correctly to the user(s) and are not distorted, or displayed in anyway incorrect All GUI elements look correct