FIT3077 Software Engineering: Architecture and Design
Sprint One (20%) Specifications
Due: 11:55pm Wednesday, March 27, 2024
Faculty of Information Technology, Monash University Semester 1, 2024
General Project Technical Requirements and Expectations
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 and Python. No other programming languages are allowed.
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. Across various submissions, you will be asked to provide an executable (together with a brief documentation what platform. the executable is for and how to run it).
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-2024/<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. You must use your Monash credentials to authenticate in your team’s Git repository and use the corresponding credential for committing work to the repository. Commits from other credentials will not be accepted and any contributions from non-identifiable credentials will be ignored.
6. 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 1, each member of the team is expected to contribute to, and produce some user stories,some architecture design, and some UI design, and a single member must not bear the sole responsibility of creating all user stories.
7. Although each project team is offered the flexibility in choosing between Java and Python for the project, all teams need to be able to demonstrate how they would be able to adequately and properly apply object-oriented design principles and architecture with their chosen technology. For example, creating a single class that contains all the required functionality will not be accepted as this does not constitute applying object-oriented design principles.
8. Each group-based submission (i.e. sprints 1, 3, and 4) must provide a recent screenshot of the “Contributor Analytics” visualizing the commit history of all team members (see example below)
9. 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 board 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 an application of the Fiery Dragon game. 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 early 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 Fiery Dragons 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 the Fiery Dragons game according to the standard rules, and the game should be playable within the same game client instance by two to four players that will take turns in making their respective moves.
2. Advanced Requirements for Final Prototype (Sprint 4 deliverable): Since Dr Mills is to be surprised by a few new twists to the Fiery Dragons game, a number of extensions are to be implemented for the final prototype. Therefore, the design of the game implementation must be flexible enough to cater for a variety of extensions, some given by the Faculty, some chosen by your team.
One extension that is very likely to be on the list is the option to have different board configurations (e.g., different number of volcano cards to form the volcano ring; not all volcano cards having 3 “squares”). Consequently, your design must be flexible enough so that you could easily accommodate different board configurations.
(Note: the teaching team will create a document with some extensions, but teams are more than welcome to contribute their own extensions)
Sprint 1 Deliverables (20% of final unit mark)
All tasks are mandatory.
1. Team Information
Document the following pieces of information related to your team.
○ Team Name and Team Photo
■ Come up with your own personal team name. Your team name must be professional. The name of the team you belong to in Moodle (with the format <campus>_<workshop session>_<team number>) is not an acceptable team name for this task.
■ Your team photo must not be edited/photoshopped. All team members must be present together physically at the time of taking the photo. Team photos via Zoom will not be accepted.
○ Team Membership
■ Document the basic information of each team member - for example name and contact details.
■ List out what the technical and professional strengths of each member are.
■ Provide a fun fact about each member that not many people know about.
○ Team Schedule
■ Document your team’s regular meeting schedule and regular work schedule.
■ Document how the workload will be distributed and managed within your team.
○ Technology Stack and Justification
■ Document what programming language, APIs, and technologies are you planning to use and how this maps to the team’s current expertise, and which ones you anticipate needing support from the teaching team.
■ Justify your team’s final choice of technologies that will be used.
■ NOTE: we recommend that you do some very basic prototyping with your chosen technologies to ensure (i) everybody in the team knows how to use them (not just in theory, also in practice!) and that (ii) you can create an executable - something that will be needed for sprints 2 to 4. Ideally, you test that an executable you have created can actually be run on another computer (that does not have your set-up). You want to get this out of the way so that there will be no surprises for any of the following sprints.
2. User Stories
Submit a list of user stories (20 to 25 stories) that covers both the basic Fiery Dragons gameplay and initial ideas for your own extensions. A majority of the user stories are expected to be devoted to the basic requirements for the Basic prototype.
3. Domain Model
Design and draw a domain model that covers both the basic Fiery Dragons gameplay and the listed extension requirements specified above.
Provide detailed justifications for the domain model that you come up with, with a focus on the following aspects:
- Provide a justification for each chosen domain entity and their relationships.
- Were there any specific choices that you had to make while modelling the domain and WHY?
- Explain any assumptions you have made, as well as any other part of your domain model that you feel warrants a justification as to WHY you have modelled it that way.
Please note that a Domain Model is NOT a UML Class Diagram - it does not have any functionality nor any attributes.
4. Basic UI Design
Draw low-fidelity (low-fi) prototype drawings of the proposed user interface for the application. The low-fi prototypes need to demonstrate both the basic Fiery Dragons gameplay and the chosen extension requirements specified above. The prototypes should cover all the key interaction scenarios of the Fiery Dragon game (e.g., set-up of game to start, uncovering dragon cards of various types, moving of dragon tokens, winning situation) and the advanced feature(s) of your choice. This can be achieved in one large drawing space or across multiple pages. Avoid redundancy, that is, do not create multiple prototypes for the same interaction. All drawings should be large and clear enough to understand and any writing should be legible. You may use pen and paper, or digital drawing tools.
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/home
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. Use a format that works for your team but it should be clear who has done what and when. 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 CANNOT 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 of submitted work.
● For the submission to be considered complete, rationales (i.e. justifications) must be submitted as part of all sprint deliverables that require them.
● The rationales submitted in Sprint One will not carry any marks. Instead, formative feedback on the rationales submitted will be provided. This will be followed by a workshop on how to write good rationales during one of the upcoming workshops. Subsequent rationales submitted in future sprints will be marked.
Submission Instructions
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 deliverables can be left as individual JPEG/PNG/PDF documents, or optionally compiled into a single PDF document and subsequently pushed to the repository.
Google Docs
If your team is using Google Docs for creating documentation, it is imperative that you clearly log each member’s contribution in the sprint contribution log as the commit history in your git repository may not tell the full picture of who committed what work. You also need to upload the latest version of the documentation into the repository (you cannot submit just links to your Google docs - you need to ‘print’ or ‘download’ your documents). Please remember that any documents that have not been committed to your Git repository do not exist for us and will not be assessed.
Please make sure that your documents are appropriately protected (only members of your team have access to them - no other student can be granted access to your documents as this would constitute enabling plagiarism which is a form. of academic misconduct). The teaching team will ask for access to the documents if we want to inspect them and access should be granted within a reasonable time frame.
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 by downloading the current state of your repository from Monash GitLab as a zip file and then submitting it.
● 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 a wiki page in the team’s Monash GitLab project repository:
https://git.infotech.monash.edu/fit3077-s1-2024/<YOUR-MOODLE-GROUP- NAME>/project/-/wikis/home
● Each team member must record details of their own contributions towards the sprint in their team’s contribution log. This must be done at least once or twice a week and a team member should not update the log on behalf of other team members.
Tools
The following tools can be used in support of making the sprint deliverables. Diagrams/wireframes created with other tools such as (but not limited to) Lucidchart, diagrams.net, Figma, etc. are acceptable. For diagrams involving UML notation, the UML 2.5.1 standard needs to be followed.
Lucidchart:https://www.lucidchart.com
Diagrams.net:https://www.diagrams.net/
Figma:https://www.figma.com
UMLet Standalone:https://www.umlet.com
UMLet Online:http://www.umlet.com/umletino/umletino.html
● UMLet VS Code Extension:
https://marketplace.visualstudio.com/items?itemName=TheUMLetTeam.umlet
● UMLet Eclipse Plugin:https://marketplace.eclipse.org/content/umlet-uml-tool-fast-uml- diagrams
● Visual Paradigm Online:https://online.visual-paradigm.com
Further Notes
Extensions
No extensions will be given in normal circumstances. An extension may be granted in special circumstances as per faculty policy. Extensions must be applied online at the following link: https://www.monash.edu/exams/changes/special-consideration . For any queries related to the assessments, please use the discussion form. on Ed - but please check whether anybody has asked the same (or a very similar question before - thank you.
For any team-specific questions, please email us as follows:
● if you are at Clayton campus, the Clayton team at <[email protected]>
● If you are at Malaysia campus, the Malaysia team at <[email protected]>
Lateness
Penalty of 10% of the total available marks per day late or part thereof after the due date, including the weekends.
Authorship
The work in this assessment is team-based and the final submission must be identifiable as a team’s own work. Breaches of this requirement will result in submitted work not being accepted for assessment and may result in disciplinary action. Refer to the Academic Integrity and Plagiarism/Collusion Section that follows for more details.
Academic Integrity and Plagiarism/Collusion
Academic integrity is about the honest presentation of your academic work. It means acknowledging the work of others while developing your own insights, knowledge and ideas. You should take extreme care that you have:
● Acknowledged words, data, diagrams, models, frameworks and/or ideas of others you have quoted (i.e. directly copied), summarised, paraphrased, discussed or mentioned in your assessment through the appropriate referencing methods,
● Provided a reference list of the publication details so your reader can locate the source if necessary. This includes material taken from Internet sites.
Generative Al tools are not restricted for this assessment taskin this assessment you can use generative artificial intelligence (Al) to assist you in any way. Any use of generative Al must be appropriately acknowledged (see Lean Ho)l
To fully acknowledge artificial intelligence models (such as Generative AI) which cannot be cited, you should include both a declaration of the generated material and a declaration of the technologies that were used. At a minimum, you should include a declaration of use that explains what technologies, if any, you have used to generate material in working on your assessment.
For more information about acknowledging the use of generative AI for assignments, please refer to
the following link:
https://www.monash.edu/learnhq/build-digital-capabilities/create-online/acknowledging-the-use-of- generative-artificial-intelligence
If you do not acknowledge the sources of your material, you may be accused of plagiarism because you have passed off the work and ideas of another person without appropriate referencing, as if they were your own. Monash University treats plagiarism as a very serious offence constituting misconduct. Plagiarism covers a variety of inappropriate behaviours, including:
● Failure to properly document a source;
● Copyright material from the internet or databases;
● Collusion between students.