FIT3077 Software Engineering

147 views 8:02 am 0 Comments July 24, 2023

FIT3077 Software Engineering: Architecture and Design Sprint Four (30%) Specifications Due: 11:55 pm, Thursday, 8th June 2023 Faculty of Information Technology, Monash University Semester 1, 2023 Sprint 4 Deliverables (30% of final unit mark) This sprint consists of both a team and an individual component (reflection). We recommend that you submit the team component well ahead of the sprint deadline in order to have sufficient time to complete the individual component. Please note the submission instructions for Sprint 4 at the bottom of this document – they are different from what we have used for earlier sprints. All tasks are mandatory. 1. 2. 3. Revised User Stories for advanced requirement(s) ● Revised User stories to cover the advanced requirement(s) only, following the recommended user story template and guidelines. If your stories have not changed since sprint one, submit them anyway and clearly indicate to us that there was no change. Tech-based Final Game (software) ● Fully functional/playable implementation of the Nine Men’s Morris (9MM) game according to the basic requirement (as implemented by Sprint 3) with full implementation of the advanced functionality(s). Please make it clear what your advanced functionality(s) is/are. ● Provide an executable that does not require an IDE or any third party libraries (e.g., PyGame, JavaFX) to be installed separately. ● Submit clear instructions on how to build and run the executable. If we cannot run the executable, the tech-based final prototype will be assessed as a fail (below ‘poor’). Architecture and Design Rationales ● Revised Architecture (if applicable): If you have made any changes to the software architecture, submit a revised Class Diagram for the 9MM game, including Class names, attributes, methods, relationship between classes, and cardinalities. You must briefly highlight what has changed (e.g. using colour or annotations, before vs after). ● DesignRationales(explainingthe‘Whys’): ● Explain why you have designed the architecture for the advanced requirement(s) the way you have. ● Explain why you have revised the architecture, if you have revised it. (What has changed would have been shown in the revised class diagram. This one is about why it changed). ● Explain when your advanced feature was finalised (e.g. it is the same as we decided from sprint one; or we changed it in Sprint 3) and how easy/difficult it was to implement. e.g. was it easy to implement due to good design practice/pattern(s) that you have applied in 1 the earlier Sprints (provide evidence)? Or was it difficult (such that you needed to rewrite the majority of the code) for the advanced feature? ● Reflection Form (Individual): Fill in this Google Form (https://forms.gle/NGf3Y1b4htrQdLPy5) as individuals (not one per team). It asks about your contributions to the project, your understanding of software architecture and design concepts, and your learnings in the project. Once you submit this Google Form, you will receive a copy of the filled responses via email. Please submit the responses as part of your individual Sprint 4 submission to Moodle. 4. Video Demonstrations ● Prepare and submit a video that demonstrates very briefly your final game’s core implementation (as you have already demo-ed this in Sprint 3) and focuses mostly on the advanced feature (in more time and detail). ● Maximum 6 minutes for teams of three (e.g. roughly 2 minutes per team member) or maximum 8 minutes for teams of four. Teams of two should aim for approx. 4 – 5 minutes. ● You can submit the demonstration video through Moodle (note the 500MB Moodle file upload size limit), or as an unlisted video on YouTube if file size is too large. If submitting the demonstration as an unlisted YouTube video, please ensure that your video link is committed to your Monash GitLab repository and also included in your Moodle submission. ● Using a number of game situations, demonstrate that your implementation correctly follows the rules of the game. Provide screenshots of your application that illustrate the advanced feature(s). ○ Note: use multiple game executions to do so if you need. ● You must demonstrate (briefly) in the video the technology stack (operating system, IDE etc.) you used for development and testing of your implementation. ● You must demonstrate in the video that your implementation compiles, runs, and correctly follows the rules of the 9MM game. ● When recording the demonstration, each team member will need to contribute/participate during the demonstration. Each team member will also need to verbally explain at least one key part of the implementation and have their computer camera enabled while doing so. General Guidance ● Your implementation will need to fully meet the basic requirement, where all standard rules of the 9MM game have been implemented. ● Implementation of the advanced requirement(s) is required in this last sprint. Teams of 3 are required to implement one advanced requirement, and teams of 4 are required to implement two advanced requirements. ● As a guide, aim for the design rationales to be roughly between 2 – 4 pages of text (A4, Times New Roman 12 points font). ● To avoid losing marks, ensure that multiple Git commits are made throughout the Sprint by all team members, and that all submission instructions as per the submission checklist are followed. We will check the status of your Git repository, especially the commit logs, and ask for clarification of individual contributions if we are unsure how much each team member has contributed towards the Sprint 4 outcomes. ● In this assessment, you can use generative artificial intelligence (AI) in order to consider design alternatives/options and explore their advantages and disadvantages only. Your final design decisions should be your own (show if it matches AI recommendation) along with your rationale description. ● Any use of generative AI must be appropriately acknowledged (see Learn HQ). ● Other than the rubric in the following pages, the rest of this document is mostly the same as with previous sprints (any changes since Sprint Three are highlighted in grey). 2 Assessment Guide Poor Acceptable Good Very Good Excellent Revised User Stories (group) User stories written to cover some of the advanced feature functionality; without consideration of the recommended format or the INVEST acronym; with redundancy. User stories written well to cover the key advanced feature; applying some aspects of the INVEST acronym. User stories written in the recommended format; covering the complete advanced feature functionality; applying most aspects of the INVEST acronym; without redundancy. Tech-based Final Game (group) Any of these: Poor interface that does not support playtesting of sprint four requirements. 9MM board not set up correctly. Tokens are not movable. Game rules not implemented. Advanced feature(s) has been attempted but not completely implemented. No source code provided. No instructions on how to build and run the executable has been provided. A final interface that includes the 9MM board and tokens with the ability to play the 9MM game as per the rules with some inadequacies in rules or gameplay implementation. Advanced feature(s) has been completely implemented with some known (documented) issues. Code has some significant bugs/issues. Known defects are fully documented. Source code corresponds to the provided architecture. A final interface that includes the 9MM board and tokens with the ability to play the 9MM game as per all the rules. Advanced feature(s) has been completely implemented with no more than one minor (documented) bug/issue. Code has no more than one significant bug/issue. Known defects are fully documented. Source code corresponds to the provided architecture and partially follows some good coding practices. A final interface that includes the 9MM board and tokens with the ability to play the 9MM game as per all the rules. Advanced feature(s) has been completely implemented with no more than one minor (documented) bug/issue. Code has no more than one minor bug/issue. Known defects are fully documented. Source code fully corresponds to the provided architecture and follows well-defined coding standards relevant to the programming language used. A final interface that includes the 9MM board and tokens with the ability to play the 9MM game as per all the rules. Advanced feature(s) has been completely implemented with no bugs/issues. Codebase has no bugs/issues. Source code fully corresponds to the provided architecture; explicitly states the established coding standards applied, and includes detailed information on how an executable can be generated and executed. Include in-line comments to describe the purpose of the important methods. 3 Revised Architecture (group) A clear and neat revised Class Diagram for the 9MM game; incorrect use of notations; incomplete classes, attributes, methods, relationships, and cardinalities. Not highlighting what changed. Design does not correspond to the actual implementation; Class diagram is reverse engineered or generated from final implementation. A clear and neat revised Class Diagram for the 9MM game, using correct notations, with most classes, attributes, methods, relationships, and cardinalities. Clearly highlighting what changed. Design roughly corresponds to the actual implementation. Class diagram is not reverse engineered or generated from final implementation. A clear and neat revised Class Diagram for the 9MM game, using correct notations, with most necessary classes, attributes, methods, relationships, and cardinalities. Clearly highlighting what changed. Design corresponds to the actual implementation, with some minor deviation. Class diagram is not reverse engineered or generated from final implementation. A clear and neat revised Class Diagram for the 9MM game, using correct notations, with all necessary and sufficient classes, attributes, methods, relationships, and cardinalities. Clearly highlighting what changed. Design corresponds to the actual implementation. Class diagram is not reverse engineered or generated from final implementation. A clear and neat revised Class Diagram for the 9MM game, using correct notations, with all necessary and sufficient classes, attributes, methods, visibility modifiers, relationships, and cardinalities. Clearly highlighting what changed. Design corresponds to the actual implementation. Class diagram is not reverse engineered or generated from final implementation. Design Rationales (group) Design rationales for several required areas (revised architecture) are missing; poor or no rationales provided. Design rationales covering most required areas that present reasonable rationales. Design rationales covering all required areas that present good rationales. Design rationales covering all required areas that present strong rationales. Design rationales covering all required areas that present strong and compelling rationales. Evidence of why your chosen design in earlier Sprints helps facilitate the implementation of advanced features. Reflection form (individual) Some of these: no or poor responses; no or little reflection. Reasonably good responses that highlight key aspects (asked for); Reasonably good reflection on key aspects. Good responses that include both key aspects (asked for) and thoughtful and considered reflection on them. Demos (group) Some of these: Poor quality video/audio/content/delivery . Team members missing. Camera off so members are not discernable. Key information missing. Video is too short or too long. Difficult to access/download/play. Reasonably good audio and video quality; covers most requirements; includes all members; members can be seen presenting; keeps close to the recommended time limit. Good audio and video quality; covers all requirements; includes all members; members can be seen presenting; interesting and fun presentation; keeps close to the recommended time limit. 4 General Project Technical Requirements and Expectations (changes since Sprint 3 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 (except for the Sprint 4 individual reflections) 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. member. 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. For all group-based deliverables, each member of the team must contribute to the design and , and must not work in silos. Teams must not delegate entire portions of a particular task or type of deliverable (e.g., implementation) to a single team implementation of all such deliverables As is the case for all previous sprints, in Sprint 4, each member of the team is expected to contribute to, and work on their fair share of revising the user stories (if applicable), implementing the game, the revised architecture (if applicable) and diagram work, some rationales, and the demonstration video. A single member must not bear the sole responsibility of revising all user stories, fully implementing the entire game, the entire architecture/diagrams, writing all rationales, or creating the whole demonstration video. 5 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. 6 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 of submitted work. ● For the submission to be considered complete, rationales must be submitted as part of all sprint deliverables that require them. ● In Sprint Four, the rationales submitted continue to be assessed. Submission Instructions (changes since Sprint 3 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. 7 ● 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. ● Moodle ● 1. 2. 3. 1. ● Please ensure that your Moodle group name is prefixed in the names of all the files you submit to Moodle. Moodle group name format: <CAMPUS>_<DAY><TIME>_Team<NUMBER> ● ● ● 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. For the purposes of final submission, all text-based/written/drawn sprint deliverables except individual reflections should be compiled into a single PDF document and subsequently pushed to the repository. 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. For Sprint 4, there will be two separate submission boxes, a group submission box, and an individual reflection submission box. Sprint 4 Moodle group submission checklist: The current state of your repository downloaded from Monash GitLab as a single ZIP file. A single compiled PDF file containing all text-based/written/drawn sprint deliverables, except your individual reflections. Demonstration video, submitted in one of the following ways: ■ Uploaded as an unlisted YouTube video where the URL, prior to Moodle submission, has been committed to Monash GitLab and included in the compiled PDF. ■ Directly through the Moodle submission itself (if the total size of the video and all other deliverables is ≤ 500MB). Sprint 4 Moodle individual reflection submission checklist: A single PDF file containing your individual reflection responses that were submitted to Google Forms. For the group submission, 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. For the individual reflection submission, each team member must make their own individual submission to Moodle. Again, submissions must be in the fully submitted state – drafts will NOT be accepted. 8 Further Notes Lateness Penalty of 10% of the total available marks per day late or part thereof after the due date, including the weekends. 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 contact: ● if you are at Clayton campus, the Clayton team at <[email protected]> ● If you are at Malaysia campus, Chong at <[email protected]> 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. 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-artifici al-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. For further information on our policies and procedures, please refer to the following link: https://www.monash.edu/students/study-support/academic-integrity

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *