American checkers (also known as English Draughts) board game

1

CS 5551 Team Project

This team project aims to help you gain a firm understanding of the key principles and practices

for developing clean, dependable software through an incremental and iterative process. It might

be worth listing your experience with this project in your resume for future job hunting.

1. Grouping

Each team should have 3-5 members. You are not supposed to work alone even if you can.

Teams must be formed before the third week of the semester.

Each team should choose a name that can appear in public. Each team should have a coordinator,

e.g., for taking the lead in setting up group meetings, making contact with the instructor, and

integrating the project reports. Each team coordinator should email the instructor the name of

their team and the names of all the team members.

2. Problem Description

Your customer is asking you to develop software simulating the American checkers (also known

as English Draughts) board game. The game is described in the following wiki pages:

https://en.wikipedia.org/wiki/English_draughts

https://en.wikipedia.org/wiki/Draughts

There are some differences between these pages. Your team will need to clarify what rules your

project follows.

Everyone needs to get familiar with the game because software development requires a solid

understanding about the business logic of the application. The general knowledge about the game

will be tested through quizzes, the midterm exam, and the final exam. You may play against

existing programs1 to get some ideas for the game. However, you should not copy any code from

the existing resources.

Your project should consider using an algebraic notation for the game board. It is useful for not

only communication among team members, but also requirements specification, design,

programming, and testing. The following shows a possible notation.

1 Examples: (1) https://play.google.com/store/apps/details?id=mkisly.american.checkers&hl=en_US (2)

https://cardgames.io/checkers/ (3) https://www.mathsisfun.com/games/checkers-2.html

2

An alternative notation is given below. It is similar to the one widely used for chess2. For

example, a8 is an unoccupied light square. a1-h8 is a diagonal line of dark squares.

a b c d e f g h

8

8

7 7

6 6

5 5

4 4

3 3

2 2

1 1

a b c d e f g h

The basic project requirements are as follows:

• The software should be implemented as a standalone application, a web-based application, or a mobile app.

• The software should allow a user to play the checkers game against either another user or a computer opponent. The rules of the game must be followed strictly. The minimum

functions include game playing via a graphic user interface, game recording (e.g., date,

time, and all moves), and replay of an existing game step by step (e.g., forward and

backward).

• User account management is optional for extra credit. If implemented, it should use a SQL or NoSQL database system to manage user account information, including

username, email address, and password. You may define your own username and

password policies. Security requirements (strong passwords stored in an encrypted

format) should be considered.

• The software design should consider the extensibility for other variants of the game as described at https://en.wikipedia.org/wiki/Draughts although the implementation of

variants is not required.

• The implementation must use a general-purpose object-oriented programming language (e.g., Java, C#, C++, or Python) and maximize the practices of object-oriented

programming.

• The development environment must include a unit test framework (e.g., Junit for Java) and a code coverage tool (e.g., EclEmma for Eclipse/Java).

• You should use a public project hosting site such as github.com and a version control system such as git.

• You should apply the software engineering principles and practices introduced in class throughout the development process, such as design by contract, agile principles, design

patterns, refactoring, and secure design.

3. Deliverables

2 https://en.wikipedia.org/wiki/Algebraic_notation_(chess)

3

The development process consists of project planning (sprint 0) and three iterations (sprints 1-3).

In each sprint, the minimum conditions of “Definitions of Done” for the implementation of

required user stories include all acceptance criteria passing (through automated tests or

completed performance of manual tests) and all unit-level tests passing, in addition to the

required documentation.

At the end of each sprint, your team will demonstrate your working software to the instructor and

submit a project report including the main software artifacts. The demonstration should show

that your working software has met the minimum conditions of “Definitions of Done” of the

corresponding sprint and present any unique features or enhancements of your project. The

detailed instructions and templates of the project reports will be provided in separate documents.

The reports will be incremental, expanded and improved upon from one sprint to the next.

• Sprint 0: Make decisions on the programming language, GUI library, IDE, unit test framework, code coverage tool, programming style, and project hosting site (e.g., at

github.com); Learn GUI programming in the language of your choice (e.g., lines, text,

and buttons)

• Sprint 1: Specify all requirements of the target product in terms of user stories and their acceptance criteria and implement the first set of basic functions: user registration, login,

logout, and visualization of new game board. Note that the board class should be

separated from its graphical user interface.

• Sprint 2: Implement all the functionality for a logged-in user to play a complete game against another logged-in user, save the game, retrieve the game record, relay a selected

game.

• Sprint 3: Enhance the software to allow a registered user to play against a computer opponent. The computer opponent should make a reasonable attempt at beating the

human player. Optimal or perfect play is not required.

4. Deadlines and Grading Policy

• Deadlines:

Sprint 0 report: Midnight, Thursday September 23

Sprint 1 report: Midnight, Tuesday October 12

Sprint 2 report: Midnight, Tuesday November 9

Sprint 3 report: Midnight, Tuesday December 7

For sprints 1-3, your team will have up to a few minutes to show off your working code.

It should focus on demonstrating that your software has met the minimum conditions of

“Definitions of Done” of the corresponding sprint and presenting any unique features or

enhancements of your project for consideration of extra credit. The demonstration should

be consistent with the corresponding project report.

• Project Grades

4

Sprint 0: 2%

Sprint 1: Demonstration 5%, Report 20%

Sprint 2: Demonstration 8%, Report 25%

Sprint 3: Demonstration 10%, Report 30%

• Individual Grades

An individual may not receive credit unless the team’s project report presents explicit

evidence of his/her contribution to the team project (e.g., listed as a developer). The

minimum expectation is 400 or more lines of production and test code.

Each student will rate the performance of each of the other members of his/her group

with a rating between 0 and 1. The average of the ratings each student receives from

other members will be multiplied by the project grade to determine individual grades. To

safeguard against a capricious rating, if a group member receives one and only one buddy

rating below 0.8, it will be discarded.

• Extra credit: Up to 5% may be added to your final grade for quality or other enhancements, for exceptionally well-written reports, for well-implemented user account

management, and for overall impression of the project, which the instructor deems to be

deserving of special recognition.

5. Suggestions on the First Team Project Meeting

Before the meeting, everyone should have done their homework -- getting a good understanding

about the game and reading the project documents carefully. Everyone should become a good

player of the game as soon as possible.

During the meeting, the team may focus on the following topics (of course, you may add other

items to your agenda). Remember to have someone take notes during the meeting.

• Discuss the game logic (https://en.wikipedia.org/wiki/English_draughts, https://en.wikipedia.org/wiki/Draughts) and play a few games together using a sample

program on the Internet.

• Discuss the requirements of the team project based on these documents: CS5551TeamProject Introduction (this document), CS5551TeamProject Sprint 0.docx,

and CS5551TeamProject Sprint 1.docx. The goal is to get a common understanding. If

anything is unclear, contact the instructor.

• Make decisions on the programming language, GUI library, IDE, unit test framework, code coverage tool, and programming style guide.

Sample programming style guides:

o Google Java Style Guide: https://google.github.io/styleguide/javaguide.html o Google C++ Style Guide: https://google.github.io/styleguide/cppguide.html

5

o Google Python Style Guide: https://google.github.io/styleguide/pyguide.html

• Set up a project hosting site (e.g., at github.com)

• Decide when to meet and how team will communicate

• Create a list of action items and assign each member specific tasks that should be done before the next meeting

• Schedule the next meeting

After the meeting, edit and approve the meeting minutes by the whole team (e.g., via email).