General    Project    Technical    Requirements    and    Expectations (changes since Sprint 1 highlighted in grey)

There are several expectations, conditions and restrictions that apply to all project teams throughout the entirety of the project (i.e. all sprints).

1.  The object-oriented programming languages you are approved to use for the project (throughout all of the sprints) are Java, Python, C++, C#, TypeScript, Smalltalk and Eiffel.

2.   The application you will eventually develop must be implemented as a standalone application that is able to run locally on a single device and does not require separate server-side code to be written. Teams wanting to attempt server-side implementations should consult with the teaching

team and gain pre-approval.

3.   All work done  (from Sprint  1 onwards) must be committed and pushed to the official Monash GitLab      repository      provided     to      each     project     team     at     the     following     URL:

https://git.infotech.monash.edu/fit3077-s1-2023/<YOUR-MOODLE-GROUP-NAME>/project

4.   Unless explicitly stated otherwise (in writing) by the teaching team, any work done, committed and pushed to any personal Git repository or only available on personal working environments will not be accepted for assessment. Work should be done consistently throughout each sprint, and not started near the due date and rushed through.

5.   Each member of the team must contribute to the design and implementation of all deliverables, and must not work in silos. Teams must not delegate entire portions of a particular task or type of

deliverable (e.g., user stories) to a single team member. For example, in Sprint 2, each member

of  the  team  is  expected  to  contribute  to,  and  work  on  their  fair  share  of implementing the tech-based WIP, some architecture/class diagram work, and some rationales. A single member must  not  bear  the  sole  responsibility  of  implementing  the  entire  tech-based  WIP, the entire

architecture/class diagram and/or writing all rationales.

6.  Although each project team is offered the flexibility in choosing technologies that they will use for the project, all teams need to be able to demonstrate how they would be able to adequately and properly  apply  object-oriented  design  and  architecture  with  their  chosen  technologies.  The teaching team reserves the right to make the final decision whether or not a team’s choice of technologies for the project is suitable/acceptable.

7.  Any issues that arise which will potentially affect the progress or performance of your team must be raised as soon as possible to the teaching team.

Project Overview, Description and Requirements

Monash University is planning to run an exhibition during Open Day in August that showcases student talent from various faculties, including the Faculty of IT. All prospective students, their family members and other visitors are all welcome to attend. Additionally, the Faculty of IT has invited a guest of honour by the name of Dr. Mills, an influential expert in object-oriented design, to the exhibition. Rumour has it that  Dr.  Mills is an avid fan of traditional games and hence, the faculty wants to ensure that there is something showcased in the exhibition that will be of interest to them.

After an extensive planning and negotiation process, the faculty has decided to approach your team to help develop a 9 Men’s Morris (9MM) game client application. For this project, your team has also been given some flexibility in terms of how the final game client will look like and what technologies will be used, but the game needs to be completely developed and ready by mid-June. The faculty would like to check-in with your team regarding the progress of the game client development every few weeks so that everything  remains  on  track  and  any  issues  hindering  the timely completion of this project can be mitigated as quickly as they arise.

Since Dr. Mills is particularly passionate about object-oriented design and there is a possibility that Dr. Mills might want to speak to your team regarding how the game client has been developed, the faculty has also requested that the game client be developed with proper software development practices and object-oriented approaches/principles in mind throughout this project.

The  faculty would  like  a  standard  implementation  of the  9MM  game  and would  like  your team to implement additional functionality, as follows:

1.   Basic Requirements for Basic Prototype (Sprint 3 deliverable): The game client must be fully able to play 9MM according to the standard rules, and the game should be playable within the same game client instance by two players that will take turns in making their respective moves.

2.  Advanced  Requirements  for  Final  Prototype  (Sprint  4  deliverable):  Select  ONE  of the following advanced requirements to add to the Basic Prototype. Teams of 4 members will need to implement any TWO of the advanced requirements.

a.   Considering that visitors to the student talent exhibition may not necessarily be familiar with 9MM, a tutorial mode needs to be added to the game. Additionally, when playing a match, there should be an option for each player to toggle “ hints” that show all of the legal moves the player may make as their next move.

b.   Players  are  allowed  to  undo  their last move and the game client should support the undoing of moves until there are no more previous moves available. The game client also needs to be able to support saving the state of the currently active game, and be able to fully reload any previously saved game(s). The game state must be stored as a simple text file where each line in the text file represents the current state of the board and stores information about the previously made move. It is anticipated that different file formats will be required in the future so any design decisions should explicitly factor this in.

c.   A single player may play against the computer, where the computer will randomly play a move  among  all  of the  currently  valid  moves  for the  computer,  or  any  other  set  of heuristics of your choice.

d.  Allow a game of 9MM to be playable using two different game client instances - one made by your team and the other made by another team. Moves made on one game client need to be able to appear on the other game client as soon as they are made.

e.   Develop   a   3D   version   of  the   9MM   game.   This   advanced  functionality   is  only recommended for 4 people teams. Teams wishing to attempt this should discuss with the teaching team by the end of Sprint 2.

f.    If you have a brilliant and equally ‘sized’ functionality idea for the additional advanced feature, you can pitch it to the teaching team. Additional advanced functionality not listed above must be discussed with the teaching team and approved in advance, e.g. by end of Sprint 2.

Recording Sprint Contributions (hurdle)

Each team is required to have a single contribution log page for all team members in the wiki section of the team’s  project  in  Monash  GitLab that documents the contributions of each  member towards the particular sprint.  The link to the wiki section of each team is as follows:

https://git.infotech.monash.edu/fit3077-s1-2023/<YOUR-MOODLE-GROUP-NAME>/project/-/wikis/

Each team member should update the contribution log by adding entries that describe the pieces of work said team member had done, the start time and date, amount of time spent, who performed the work and if applicable, any other notes.  Each team member is not expected to immediately record each piece of work into the contribution log as soon as it is done, but is expected to record into the contribution log all of the unlogged work done thus far at least once or twice per week. You SHOULD NOT update the contribution log on behalf of other team members.

Notes

●    The  entirety  of  the  sprint  submission  will  be  marked  holistically  and  all  deliverables  are considered during assessment ofsubmitted work.

●    For the submission to be considered complete, rationales must be submitted as part of all sprint deliverables that require them.

●   The rationales submitted in Sprint Two will now carry marks.

Submission  Instructions  (changes  since  Sprint  1  highlighted  in grey)

To avoid losing marks, please ensure that you follow the submission instructions below carefully:

Monash GitLab Repository

●   As  mentioned  in  the  General Project  Technical Requirements  and Expectations  section,  all project work needs to be pushed to your team’s provided Monash GitLab repository.

●    If you use any software tools to create any of your wireframes, diagrams or word documents, you MUST  export  the  wireframes  and  diagrams  as  JPEG,  PNG  or  PDF  file(s)  and  the  word documents as PDF file(s). Ensure these exported files are then pushed to your team’s repository in addition to the raw files from these tools. Otherwise you may lose marks for not providing your deliverables in a correct and/or readable format.

●   Neat and legible hand-drawn diagrams are acceptable but must be scanned at a high resolution and also pushed to your team’s repository.

●    For the purposes of final submission, all text-based/written/drawn sprint deliverables should be compiled into a single PDF document and subsequently pushed to the repository.

Moodle

●    In addition to all project work being pushed to Monash GitLab by the due date, your project work must also be submitted by the due date to Moodle. Sprint 2 Moodle submission checklist:

○    The current state of your repository downloaded from Monash GitLab as a ZIP file.

○    A single compiled PDF file containing all text-based/written/drawn sprint deliverables.

●   Only  one  team  member  (on  behalf of their  project team) needs to make the submission to Moodle. Submissions must be in the fully submitted state - drafts will NOT be accepted.

●   When submitting, please ensure that all files you intend to submit are included in the submission and your submitted file(s) can be properly opened/extracted/read before clicking submit.

Sprint Contribution Log

●   The contribution log must be done using the team’s Monash GitLab wiki. The URL to the wiki is: https://git.infotech.monash.edu/fit3077-s1-2023/<YOUR-MOODLE-GROUP-NAME>/project/-/wikis/

●   You may create/use a separate wiki page for each team member’s contribution log, or use a single wiki page where each team member has their own section to log their contributions into.

●    Each team member must record in the contribution log the details of their own contributions towards the sprint. Each team member must update their log at least once or twice a week and a team member must not update the log on behalf of other team members.

Further Notes

Lateness

Penalty of 10% of the total available marks per day late or part thereof after the due date, including the weekends  .