Upload
stash
View
68
Download
0
Embed Size (px)
DESCRIPTION
Team Members: Zhen Cai Christopher Campbell Justin Doll Jason Miller Nicholas Rimer Raeginald Timones. Group 2 : Team Battleship . Battleship Visualization. Reggie Timones. Concept of Operations. Current System. Battleship board game by Milton Bradley Physical board g ame - PowerPoint PPT Presentation
Citation preview
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