CPSC 329 Software Development Fall 2017

CPSC 329 Project 3: Ultimate Pente

Objectives

This project focuses on creating flexible, extensible software. Additional goals include gaining experience with client-server networking and threads, additional practice with the software development process, and continuing to think about and work on effective teamwork.

Teamwork and Collaboration

This is a group project. Teams are:

Team members are expected to contribute fully to their team.

For the team parts of the project, getting help from or discussing ideas with others not in your group is allowed with limits as detailed in the collaboration policy. Parts of the project designated as "individual" (such as the reflection) should be done solely by the person handing it in.

In all cases, coming to office hours is always OK. (And encouraged!)


Specifications

Software

You work for a game company which specializes in adaptations of classic board games. Based on the response to an initial limited release, it has been decided that the next full-featured release will be Pente.

Interested in selling as many copies of the software as possible, the company has identified three kinds of target users:

Your task is to implement this new product, which the marketing team has dubbed "Ultimate Pente". The following elements are essential to include:

You will need to identify any other features and requirements necessary for supporting the goals of the users identified above.

In addition, the program should be designed with an extensible framework so that it is easy to build on it for future releases for the software. Support reasonable (likely) future extensions such as additional game variations; you do not need to plan for every possible thing you can think of.

Process

As part of the development process, you should identify user goals, features, and requirements and should produce CRC cards, a use case diagram, use cases, sequence diagram(s), and a class diagram.

As with the other projects, you are required to use a collaborative tool such as Google Drive for the meeting minutes and other team documents not part of your Eclipse project, and SVN for your code and other files that are part of your Eclipse project.

For SVN, use ultimatepente as the name of the subdirectory within the repository (this should go under one team member's repository directory) and "single project layout" when you share the project. Make appropriate use of version control, including committing and making branches when it is appropriate to do so. Informative commit comments are expected.

Implementation

You are expected to follow the course coding standards.

Pre- and postconditions and other structural invariants should be checked. Automated testing should be incorporated into the development process. Overall, testing should be incorporated in a way that is easy to use during development and easy to remove for release. This means mechanisms like throwing IllegalArgumentExceptions for preconditions violations, using assert to check invariants, and separating the implementation of test cases from the code being tested. Printing out messages is useful for debugging but should not be considered part of testing.

Teamwork

As with the other projects, you should continue explicitly working on team skills. In particular:

Note on dividing up tasks: It is ultimately up to the team to decide how to divide up the work of completing the project and to do so in such a way that everyone is satisfied about the others' contribution to the team. However, keep in mind that this is also an important opportunity for learning and practice, so everyone should make sure that they feel comfortable with all of the different elements of the project (including the understanding and design phases). Practices like working in pairs and peer review of various components can help ensure that everyone is able to be involved in each phase.


Resources

Game Rules

Pente (and variations) game descriptions and information:

Getting Started

An important first step will be to research Pente and its common variants/related games. What are these variants/games? How are they played? Identify similarities and differences. Include the information you gather in your team meeting minutes.

Also be sure to think through how the user will use the program in all of the different modes of usage (local human opponent, online human opponent, computer opponent). Don't forget to address things like making sure people playing online are using the same set of rules! Remember that scenarios and use cases are meant to reflect what the customer wants from the software, not what the developer wants to present - so think about what a player would expect/find convenient.


Due Dates, Deliverables, Handin, and Grading

Due Wed Nov 15 at the start of class

By this point you should have completed the understanding and design phases of the project.

One handin per group:

Due Fri Dec 8 at the start of class

This is the main project handin. You should have a complete program!

One handin per group.

Due Thu Dec 14 at 10pm

The last stage involves reflection on aspects of the process and result. (Additional reflection on the process will be part of the final exam.)

One handin per person.

Hand in a hard copy of everything except the teamwork assessment on Canvas. Be thoughtful in your responses; a rough estimate is approximately two pages of writing in total (but what you say is more important than the exact length).

Grading

"Process and Teamwork" addresses all aspects of the development process, including the understanding, design, and implementation phases. There should be evidence of understanding and proper utilization of the process and the various artifacts of the process - you should have all of the components (user goals, features and requirements, CRC cards, etc) and your user goals should look like user goals, your features and requirements should look like features and requirements, your CRC cards should look like CRC cards, etc. There should also be evidence of the appropriate use of tools - version control is used correctly and appropriately, including proper repository structure, frequency of commits, use of branches, and informative comments. Reasonable choices should have been made about user goals, program functionality, use cases, etc in light of the overview provided. The various documents should be complete, with all of the core functionality accounted for. Individual contribution to the team is included.

"Design" addresses the design of both code and the UI. Both designs should demonstrate the application of relevant design principles, and should support all of the functionality identified as necessary for supporting the user goals even if that functionality is not fully implemented (e.g. your design should support rules variations even if you only end up implementing one such variation). In particular, the class design you produce should demonstrate appropriate application of both the modularity-related and the flexibility-related design principles discussed in class. (Though you should take into account the other design principles as well.) For the UI design, the user's experience should reflect the UI design principles discussed in class. The designs should support all of the required and essential functionality, even if you don't end up implementing all of that functionality. Your writeups should be thoughtful and should thoroughly address the points asked for.

"Functionality" covers what the software does. It should meet the specifications given, have enough functionality to be useful for its intended purpose, and work correctly and robustly. Coding standards are followed. Pre- and postconditions and other structural invariants are checked. Automated testing is employed where appropriate. Testing is incorporated in a way that is easy to use during development and easy to remove for release.

For a C for the "Functionality and Design" portion of the grade, have a working minimal version of the game. This means:

For a B, have the C-level functionality plus:

For an A, have the B-level functionality plus:

Note that these are base levels - bugs, not following coding standards, lacking evidence of testing, poor design (code or UI), etc will lower the grade even if code is there.

Extra credit is possible for additional features beyond the basic requirements (more game variations, fancier computer players, other functionality, fancier user interface, etc), however, note that extra credit will be limited if the requirements are not met - make sure you focus on the essential parts first and budget your time so that you end up with a working program that meets the specifications. Be sure to identify any extra credit elements in your writeup.

All members of the group will receive the same grade for elements handed in as a group; the individual handins (design critiques and individual contributions to the team components) will be graded individually. (Contributions to the team will count under the "Participation" part of the overall course grade.)


Valid HTML 4.01!