|CPSC 329||Software Development||Fall 2017|
The primary goal of this project is to pull together the techniques and tactics relating to understanding and design into the construction of a larger program. A secondary goal is to continue thinking about and working on effective teamwork.
Specific goals include:
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. Two games have been proposed for the next big release: Igel Ärgern (also known as "Hedgehogs in a Hurry") and Pente.
Your task is to implement one of these games. (More information on the games can be found below.) Since the company would like to get the software on the market as soon as possible, it has been decided that the first release will include only functionality needed to support the user goal of "playing the game with friends seated around the same computer". Part of your task will be define exactly what that functionality will be. (Extra credit is possible for additional functionality.)
Your program should also have a well-designed UI - the company hopes to make money by selling a series of upgrades with additional features, but customers turned off by a poor user interface aren't likely to buy new versions of the game.
As part of the development process, you should identify features and requirements and produce CRC cards, a use case diagram, use cases, sequence diagram(s), and a class diagram.
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 project 1, 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 meet the first deadlines (code and UI designs), then develop a timeline for the rest of the project after fall break. 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.
As with project 1, 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 hedgehogs or pente 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.
Board game description and information:
Your program should support the goal of playing the standard version of Igel Ärgern with 2-6 human players (who are all sitting in front of the same computer).
Board game descriptions and information:
Your program should support the goal of playing Pente against another person (who is also sitting in front of the same computer) using the standard rules. You do not need to worry about supporting any of the alternate rules.
By this point you should have completed the understanding and code design phases of the project.
One handin per group:
By this point you should have completed the design of your program's user interface.
One handin per group:
(*) Handin by 10/13 is strongly encouraged, but it will be accepted until 10/16.
This is the main project handin. You should have a complete program!
One handin per group.
The last stage involves reflection on the process and result.
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.
A critique of the code organization. Is it a good design? Make reference to the design principles discussed in class.
Reflect on your experience with the development process. Did it go smoothly? What problems did you encounter? Were the various stages helpful? Were you able to stick to the planned schedule, or was there too much or too little time? Did you make changes to the initial user interface and/or class design? Why? What positive things should you be sure to do next time and what can you do differently to address the problems? Explain your answers, giving concrete advice as much as possible.
Reflect on your experience with working in teams. Was the experience successful? Were there difficulties? Did the teamwork practices you focused on help? What led to problems, and what can improve the experience next time? Explain your answers.
Complete the "project 2 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 three pages of writing in total (but what you say is more important than the exact length).
Understanding - 10%
Features and requirements fully cover the specified user goal. The use case diagram and use cases are complete and used appropriately.
Design - 35%
Code and UI designs are complete and exemplify the design principles discussed in class. CRC cards, sequence diagrams, and the class diagram are complete and used appropriately. All abstractions (data and procedural) have appropriate and sufficient specifications, expressed in class and method comments.
Software - 35%
Meets the specifications given in the "Software" section. Has enough functionality to be useful for its intended purpose. The user's experience reflects the UI design principles discussed in class.
Testing - 5%
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.
Reflection - 10%
Design critiques are thorough and correctly reflect design principles discussed in class. Reflection is thoughtful and considered.
Teamwork - 5%
Evidence of process, appropriate use of tools, individual contribution to the team. Version control is used correctly (including proper repository structure) and appropriately (including frequency of commits, use of branches, and informative comments).
Good programming style and following the course coding conventions is expected, and will be reflected in the functionality grade.
Some extra credit is possible for a fancier user interface and/or appropriate additional features beyond the minimal specifications, but note that extras will not count if the requirements are not met - make sure that you identify what is essential and budget your time so that you end up with a working program that meets the specifications.
All members of the group will receive the same grade for the understanding, design, software, and testing portions of the grade. All members of the group will also receive the same grade for the portion of the teamwork component that is based on the meeting minutes and the use of version control. The individual handins (design critiques, reflections, 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.)