|CPSC 329||Software Development||Fall 2017|
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.
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!)
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:
Beginners who have never played Pente (or a related game) but who are interested in giving it a try.
Players who are familiar with Pente or one of its variations, and would like to play one of those versions against another person. That person might be a particular friend or anyone who is available; what's important is that the player can play a game when they want to. (It is possible that a friend may be sitting in front of the same computer, though it is more likely that is not the case.) The player may also want to try out and learn a new variation.
Enthusiasts who are knowledgeable about one or more variations of the game, and who are interested in playing competitively. (Though they may also play non-competitively at times.) It is unlikely the opponent will be sitting at the same computer. Win-loss records and rankings are important to enthusiasts, as is the ability to play against particular opponents. Enthusiasts may also be interested in observing a game being played by two other players, for fun or to try to learn about the tactics of a future opponent.
Your task is to implement this new product, which the marketing team has dubbed "Ultimate Pente". The following elements are essential to include:
Support the standard 2-player version of Pente.
Support game variations: a player should be able to select a whole set of rules by name (e.g. "Pente", "gomoku") or a combination of rules à la carte. (Support both options.)
Support both human and computer players.
Support both networked play (client-server, with the server coordinating the game play and the clients handling only the user interface) and local play (which should not require the player to start up separate client and server programs).
Players connecting to the server should be able to choose their opponent from a list of waiting players (or begin waiting if none are available).
A server which supports multiple simultaneous games, and which does not crash or stop accepting connections if there's a problem with one game.
Support observers, who can select a (networked) game currently in progress and subsequently see the same view of the gameboard as the players but can't participate in the game.
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.
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.
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.
As with the other projects, you should continue explicitly working on team skills. In particular:
Take minutes at team meetings - record the time and length of the meeting, who is present, project status, things discussed, tasks assigned, etc. Someone should be designated as the note-taker for each meeting. (This can be the same person all the time or it can rotate.)
At the beginning of the project, the whole team should:
Identify skills relevant for this project, get to know each other with respect to those skills, and assign roles (e.g. team leader) and responsibilities for various tasks. (See the note below about dividing up tasks.) Include these assignments and the rationale behind them in your meeting minutes.
Identify a few (1-3) specific practices from the teamwork and Agile readings (from 9/1) to employ for this project. Document the practice(s) you select and why you selected them in your meeting minutes. (Choose practices to address concerns or problems that have arisen in the past, or that help reinforce things that have gone successfully.) Incorporate those practices as you work on this project.
Plan a timeline for how you will complete the various development steps and deliver a completed project on time. Include the planned schedules in your meeting minutes.
At the end of the project, each team member should complete the individual reflection and assessment described in the "Deliverables" section.
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.
Pente (and variations) game descriptions and information:
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.
By this point you should have completed the understanding and design phases of the project.
One handin per group:
Your understanding and (code) design documents: features and requirements, CRC cards, a use case diagram, use cases, sequence diagram(s), and a class diagram. Hand in a hard copy of these things. (Include all of your CRC cards; cross out elements or whole cards as you change your mind about things, and hand in even the crossed-out cards.)
Skeleton code with complete method and class specifications (auto-generate from the class diagram). Create a tag design in the repository to hand in your code and any other files present in your Eclipse project.
Your UI design (sketches and another other relevant description). Hand in a hard copy.
The network protocol. Identify what messages will be sent between client and server. Be specific - describe the format of what will be sent and not just "a message indicating..." Hand in a hard copy.
This is the main project handin. You should have a complete program!
One handin per group.
Your code, handed in by creating a handin tag in the repository.
The minutes from your team meetings. Hand in a hard copy.
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.
A critique of your user interface. Is it is good design? What was the rationale behind the design choices made? Make reference to the design principles discussed in class. Also discuss tradeoffs - perhaps you made a decision that was worse with respect to one principle because something else was more important.
A critique of the code organization. Is it a good design? Make reference to the design principles discussed in class. Also specifically discuss why you think you've achieved an extensible framework - identify what extensions you expect and why they are easy to accommodate. Also discuss tradeoffs - perhaps you made a decision that it worse with respect to one principle because something else was more important.
Complete the "project 3 teamwork assessment" survey on Canvas (in the "Quizzes" section). Answer the questions for each person in your group including yourself. The survey is anonymous.
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).
"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.)