Reference no: EM133119999

Project - Personal Software Process & Quality

Exception Handling, GUI Development

This compressed folder should contain the following:

1. A folder called core containing:
a. CheckersLogic.java (game logic module)
b. CheckersComputerPlayer.java (logic to play against computer; generate computer moves)

2. A folder called ui containing
a. CheckersTextConsole.java (console-based UI to test the game)
b. CheckersGUI.java (graphical user interface for the game)
3. A folder called docs with Javadoc documentation files (index.html and all other supporting files such as .css and .js files generated by the tool). Submit the entire folder.

4. ProjectDeliverable4.docx (or pdf) with Completed Time Log, Estimation worksheet, Design form, Defect Log, Personal Code Review and Project Summary provided at the end of this assignment description.
a. Make sure to provide responses to the reflection questions listed in ProjectDeliverable4 file (this document).
5. A few screen shots showing test results of your working game.
6. A readme file (optional; submit if you have any special instructions for testing).

Checkers Game:
Checkers is a strategy board game for two players which involve diagonal moves of uniform game pieces and mandatory captures by jumping over opponent pieces. It is played by two opponents, on opposite sides of the 8x8 checkered gameboard. One player has the dark pieces (or ‘x' tokens); the other has the light pieces (or ‘o' tokens). Each player has 12 pieces. Players alternate turns. A player may not move an opponent's piece. A move consists of moving a piece diagonally to an adjacent unoccupied square. If the adjacent square contains an opponent's piece, and

CHECKERS BOARD WHEN GAME STARTS (PUBLIC DOMAIN)

the square immediately beyond it is vacant, the piece may be captured (and removed from the game) by jumping over it.
Only the dark squares of the checkered board are used. A piece may move only diagonally into an unoccupied square. The player without pieces remaining, or who cannot move due to being blocked, loses the game. Pieces move one step diagonally forwards, and capture an opponent's piece by moving two consecutive steps in the same line, jumping over the piece on the first step. Multiple enemy pieces can be captured in a single turn provided this is done by successive jumps made by a single piece; the jumps do not need to be in the same line and may "zigzag" (change diagonal direction). Pieces can move/jump only in forward direction.
Aim of the game: is to capture all the opponent's pieces or render them unable to move.
How the game ends:
- The first player to lose all of his or her pieces loses the game.
- If a player is put in a position where they cannot move, they lose.

Program Requirements:
To the previously developed Java-based Checkers game, add a module to provide a graphical user interface (GUI) using JavaFX. Create a separate class called CheckersGui.java in the ui package that generates the GUI.
• Continue to make use of good Object-Oriented design
• Provide documentation using Javadoc and appropriate comments in your code.
• Generate HTML documentation using Javadoc tool
• Make sure you provide appropriate Exception Handling (using try-catch blocks) throughout the program
• You can decide on the layout of the user interface and game board.
• At the start of the program,
o Ask the user if they would like a GUI or console-based UI. Then show the corresponding UI.
o Next, ask if they want to play against a computer or another player and respond accordingly.

Personal Process:

Follow a good personal process for implementing this game. You will be using PSP2 in this assignment. So, in addition to tracking your effort and defects you will have to estimate the effort and defects for the GUI module-recall that in PSP1 you only estimated the effort, but not the defects. Don't forget to provide exception handling routines and conduct a personal code review.
PSP Forms
• Please use the estimating worksheet contained herein to estimate how much time, and how big your program might be.
• Please include in the design form any materials you create during your design process. It's at the end of this document.
• Please use the code review checklist contained herein to statically analyze your code for common mistakes.
• Please use the time log (provided at the end of this document) to keep track of time spent in each phase of development.
• Please use the defect log (provided at the end of this document) to keep track of defects found and fixed in each phase of development.
• When you are done implementing and testing your program, complete the project summary form to summarize your effort and defects. Also answer the reflection questions.
Phases
Follow these steps in developing the game:
Plan-understand the program specification and get any clarifications needed.

1. Estimate the time you are expecting to spend on the GUI development task.

2. Estimate the defects you are expecting to inject in each phase you go through while developing the GUI

3. Estimate the size of the program (only for new code that you will be adding).

4. Enter this information in the estimation columns of the project summary form. Use your best guess based on your previous programming experience. There is no penalty for having an estimate that is not close to the actual. It takes practice to get better at estimation.

5. Use the provided estimating worksheet.

Design-create a design (for the new modules being added) in the form of flow charts, breakdowns of classes and methods, class diagrams or pseudocode. Provide this design in the PSP design form provided at the end of this document. Keep track of time spent in this phase and log. Also keep track of any defects found and log them.
Code-implement the program. Keep track of time spent in this phase and log. Also keep track of any defects found and log them.
Code Review-use the code review guidelines provided later in the document to conduct a personal review of your code and fix any issues found. Provide comments in the checklist about your findings. There should be a minimum of 4 comments.
Test-test your program thoroughly and fix any bugs found. Keep track of time spent in this phase and log. Also keep track of any defects found and log them.
Postmortem-complete the actual, and to date columns of the project summary form and answer the reflection questions.

Estimating Worksheet
PSP2 Informal Size Estimating Procedure
1. Study the requirements.
2. Sketch out a crude design.
3. Decompose the design into "estimatable" chunks.
4. Make a size estimate for each chunk, using a combination of:
a. visualization.
b. recollection of similar chunks that you've previously written
c. intuition.
5. Add the sizes of the individual chunks to get a total.

Reflection Questions

1. How good was your time and defect estimate for various phases of software development?

2. How good was your program size estimate, i.e., was it close to actual?

3. How many issues did you find in your code during code review?

Attachment:- Personal Software Process and Quality.rar