BATTLESHIP VISUALIZATIONGroup 2 : Team Battleship

Team Members: Zhen CaiChristopher CampbellJustin DollJason MillerNicholas RimerRaeginald Timones  

CONCEPT OF OPERATIONSReggie Timones

Current System

Battleship board game by Milton Bradley

Physical board game 2 human players

Proposed System

Needs User modes Operational Scenarios

1 player 2 players

Operational Features

Must Have:

Graphical User

interface

Game pieces

Artificial Intelligenc

e

Menu

Milton Bradley

rules

Would Like to Have:

Salvo variation

Online play

Adjustable AI difficulty

Sound

Analysis

•Graphics•Game setup timeExpected

Improvements:

•Game types•CustomizationDisadvantag

es:

•Sound•Human strategy vs. AI strategy

Limitations:

•Meet deadlines•Time management•Equal task divisions

Risks:

PROJECT MANAGEMENT PLANNicholas Rimer and Zhen Cai

Project Plan

Artifact Duration (days)

Main Program Structure 5

Basic GUI 14

Basic AI 14

Phase one Testing 14

Advanced GUI (Images) 14

Advanced AI (Multiple Difficulties) 14

Phase two Testing 14

Final Revision and Delivery 7

Timeline

Main Program

Basic GUI

Basic AI

Phase one Testing

Advanced GUI

Advanced AI

Phase two Testing

Final Revition

10/1/2009 10/11/2009 10/21/2009 10/31/2009 11/10/2009 11/20/2009 11/30/2009

Start Date

Tools and Computing Environment Programmed in the Java Environment Will run on any operating system

with Java installed

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

Quality Assurance

Two Phases of testing All members will conduct their own

tests Errors will be compiled and fixed

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

Security

No implemented security The software's warranty will be void

if the code is modified

Risk Management

Extensive testing to reduce failures New version releases over the

internet to reduce the cost of failures

Maintenance Plan

Maintenance will only be done given that fatal errors occur after the final release

A new version will be released

SOFTWARE REQUIREMENTS SPECIFICATIONS

Jason Miller and Justin Doll

Product Overview

Assumptions Java Runtime

Stakeholders

Our Produ

ct

Developers

Customers

Users

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.

Attack During 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.

Use Case Diagram

Sample Specific RequirementsNo: 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

3.1 Functiona

l Requirem

ents: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 Requirem

ents:

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. 

3.4 Users and

Human Factors

Requirements:

System should support any level of user with basic

knowledge of computers.

3.5 Document

ation Requireme

nts:

System will provide

information on installing and running the

required software so

any user should be able

to run the software. 

3.6 Data Requireme

nts:

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.

TEST PLANChristopher Campbell

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

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

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

Testing Cycle

Find Issue

Correct Issue

Regression Test

Test new Features

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 issues

GUI 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

Sample Test Cases

TC03 Check 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

TC08 Player input is correct

Testing 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

Sample Test Cases TC17 AI behavior

correctnessTesting involves checking how correct the behavior of the AI is. It should, to its best ability, attempt to sink ships.

AI behaves correctly

TC18 AI behavior difficulty Testing involves that AI is not to easy, and that provides a challenge

AI not to easy.

Regression TestingTC19 Buttons and UI

functionsTesting involves testing of all buttons and UI functions of the application

All buttons and functions work

TC20 All rules enforced Testing involves checking of the enforcing of all rules of the game

All rules are followed

TC21 Game modes Testing involves all game modes are working and fully functioning

All game modes work

TC22 UI 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