ITECH1101 – IT Problem Solving
[ad_1]
ITECH1101 – IT Problem Solving 2007
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 1 of 10
Hackathon Assignment Specification
Overview
This is an individual assignment that requires you to devise and attempt to implement a game using
block-based coding. You will design algorithms for your game, attempt to implement the algorithms
and then present an aspect of your work to your peers. There are three separate parts to this
assignment, coinciding with the stages of developing your solution:
Part 1: Design Documentation and Peer Review
Part 2: Hackathon Report
Part 3: Hackathon Presentation
Timelines and Expectations
Percentage Value of Task: Part 1: 15%, Part 2: 15%, Part 3: 10%. Total: 40%.
Due: This assignment has multiple due dates as follows:
Part 1:
Design Documentation*: Wednesday 13th May, 2020, 23:59 (Week 8)
| Peer Review: | Sunday 17th May, 2020, 23:59 (Week 8) |
| Part 2: | |
| Hackathon Report: | Sunday 7th June, 2020, 23:55 (Week 11) |
Part 3:
Hackathon Presentation: Sunday 7th June, 2020, 23:55 (Week 11)
Hackathon Peer Reviews: Sunday 14th June, 2020, 23:55 (Week 12)
Minimum time expectation: 20 hours
* Note: The design documentation is due as a draft at this time so it can be peer reviewed, however it
will not be marked until the conclusion of Part 3.
Learning Outcomes Assessed
The following course learning outcomes are assessed by completing this assessment:
• K2. Relate goal-setting and plan formulation to problem solving
• K3. Compare and contrast commonly used problem solving strategies
• K4. Describe tools and techniques that can be used to model and describe problems
• K5. Describe the value of reflection, attitude and self-efficacy towards success in problem
solving
• S1. Decompose a problem and create goals and plans to solve that problem
• S2. Devise and implement problem solving strategies which can be applied to a range of IT
problems
• S3. Develop and verify algorithms based on conceptual models used in programming
• S4. Construct documentation describing how to solve a problem
• A1. Apply problem solving strategies, tools and techniques to solve problems in a variety of
domains
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 2 of 10
Assessment Details
Assignment Scenario
Your local council would like to release some resources to assist the community during the ongoing COVID-
19 pandemic. Your task is to design and develop an original computer game using Scratch v3 that in some
way relates to the pandemic situation. Some ideas for this could include:
• A supermarket frenzy game in which the player attempts to obtain as much toilet paper as possible,
or, alternatively, races madly around the screen trying to obtain a single pack of toilet paper before it
disappears.
• A “virus attacks” game where the player tries to avoid being infected with the virus being spread
around by computer players that infect each other whenever they touch or stay within close proximity
for a predetermined time.
• A maze game where the player attempts to move through an increasingly crowded space without
touching anything
The idea for the game is entirely your choice within this scope, provided it can be implemented in Scratch v3.
Important Note Before You Begin
This assignment takes the form of a hackathon, meaning that you have a short period of time in which to
work on your idea and you may not have a finished product when it ends. This is absolutely fine – you do
not need to fully implement your game, but you do need to make some progress towards your goal.
The key here is that you are applying problem solving skills to work on your game. Some of you have never
coded in your lives, while others have had quite a bit of experience. You are not being assessed on how
good your game is, or how complicated its design, or anything else that assumes you already have a level of
coding ability. Instead, the focus is on your problem solving skills. When you encounter a challenge, how do
you respond? What strategies do you employ? How do you proceed when your first (or first several)
attempts are unsuccessful? For your assignment, this means two key things:
1) Even though you are able to freely see and access existing Scratch games, copying someone else’s
work does not provide you with any benefit. Copying existing code does not allow you to practise
your problem solving skills, and so you would not receive high marks for the submitted work. It is
what you, personally, achieve that counts, not what you’re able to source from someone else.
2) The complexity of your game idea allows you to control the level of problem solving you need to
perform. If you are a novice coder, pick a simple idea, or an idea that starts simply but can easily be
expanded. Conversely, if you are an experienced coder, your game will need to include some
complexity. Only you know your current capabilities, and so it is up to you to choose an idea that
interests you and that pushes you just beyond your current capabilities so that you have the
opportunity to demonstrate your problem solving skills. If, when you get to the coding activities, you
find that your choice was too simple, you can add further complexity. You will not be penalized for
submitting an incomplete implementation of your game, but you will be penalized if you have chosen
a task that does not provide you the opportunity to problem solve appropriately.
Using Scratch v3
Scratch (https://scratch.mit.edu/) is available for both online and offline use. Download Scratch from
here: https://scratch.mit.edu/download. Save your work to your computer as you go.
Some interactive tutorials are available within Scratch; and others are available here:
https://projects.raspberrypi.org/en/codeclub/scratch-module-1 to help you learn how to use the
Scratch interface and create programs.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 3 of 10
Part 1: Design Documentation and Peer Review
This stage requires you to create some initial draft documentation for your game.
You will create and document rules for your game, and develop algorithms for its implementation. These rules and
algorithms may continue to evolve throughout the course of the hackathon, so they do not need to be perfect, but you do
need to try to make these as complete as possible to get the best value out of the peer reviews and simplify the coding
stage of the hackathon. Your documentation will continue to be updated as needed throughout the hackathon.
You will also peer review the designs of two other students in the course.
Peer reviews will be completed individually.
Game Idea
You can select any game within the scope outlined in the Assignment Scenario section on page 2. Your game must:
• Be challenging for you, so that you are able to demonstrate your problem solving skills.
• Require you to use a variety of problem solving strategies / techniques to complete.
• Be creative. Fun is a huge element of a hackathon, so you want to select something that you will enjoy.
• Require you to code the behaviour using Scratch v3, and be within the capabilities of Scratch v3. You may not
use any other programming environment for this assignment.
Your game must also not be something that you can solve by following previously created instructions (even with minor
modifications) or downloading existing programs. For example, you cannot find a similar game on Scratch and copy it as
your own, or use a Scratch tutorial to provide your code. Looking at other examples and completing tutorials to help you
learn is fine, but copying other work is not counted as using problem solving skills. You need to think through what your
code requires for yourself.
Design Documentation
Once you have chosen your game, you must create documentation that outlines the rules and breaks down the logic of
the gameplay into algorithms you can use to implement your game. You may need to break your gameplay down into
smaller sub-tasks to achieve this, and should include statements that make the purpose of each task or subtask clear.
Your documentation must clearly describe an overview of your game, the game rules and include algorithms and a UML
model to represent the full functionality of the game you intend to implement during the hackathon. Your documentation
must be saved in .pdf format.
Note: You MUST upload your documentation before the due date and time documented on Page 1 of this
specification. The submission box will automatically allocate peer reviews based on the files submitted at the due
date and time, without any grace period. If you are late with your submission, an alternative submission box will
be available, however you might not be able to participate in the peer review process and would therefore not be
eligible for the marks associated with this task. Contact your lecturer for advice if you are in this situation.
Peer Reviews
As soon as the submission deadline has passed, you will have access to conduct a peer review on two other students’
design documentation. These reviews will be allocated to you automatically. You will also review your own design.
Your task is to review the documentation allocated to you and to evaluate it against a set of criteria provided in a marking
rubric. You should consider how well the documentation defines the game under review, how clearly algorithms
represent and address the game tasks and how effectively the UML diagrams describes the gameplay. You will also
have the opportunity to provide your own comments, and should take care to provide specific comments that highlight
both positive aspects and any potential issues with the proposed game and documentation.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 4 of 10
Note 1: Your mark will not be impacted by the feedback your peers provide on your work. You will be marked
based on how well you complete your peer reviews.
Note 2: Your draft documentation will not be marked by your tutor, nor will they be providing feedback on the
submitted version. This is draft documentation only, and you will probably be making changes to it based on the
peer review feedback you receive and what you learn throughout the hackathon. At the end of the hackathon,
you will submit a Hackathon Report which will include your finalised Design Documentation for your tutor to mark.
All feedback must be completed by the commencement of Week 9 in readiness for the hackathon. You should review the
feedback you have received and incorporate the feedback you receive into your design, as appropriate. You may – and
should – continue to update your documentation throughout the hackathon, based on your hackathon experiences, and
any additional ideas you obtain throughout the course of this assignment.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 5 of 10
Part 2: Hackathon Report
This part of the hackathon assignment requires you to discuss, analyse and reflect upon the problem solving techniques
you use during the hackathon. You will document your work in Microsoft Word, or another suitable text editor of your
choosing that enables you to include images in your work alongside text. This document will act as your Work Journal.
You will update and maintain your work journal on a frequent basis throughout the hackathon in dated journal entries,
covering an overview of the work you have been attempting, any challenges or problems you encounter, the output or
results of your work and screenshots of supporting documentation for your entry, e.g. the code you work on for each
entry, any diagrams / documentation you update, test cases and test results, tables you create, etc.
Note: The supporting documentation you include throughout your Work Journal is really important to demonstrate
your progression through the hackathon. It allows someone else to review your progress and the changes that
occur throughout the hackathon, so including screenshots as you progress provides a record of how your work
evolves throughout the hackathon and enables other people to understand the context in which your journal
entries are made.
Throughout these journal entries, you will make and analyse connections between the work you are performing and the
course concepts reviewed throughout the semester. For example, if you attempt to solve a problem using a graphical
model, your entry would identify the problem you were trying to solve, discuss the use of the graphical model and the
reason for its use and analyse how effective the graphical model was in helping you resolve the problem. It would also
include a screenshot of the graphical model you used.
You will also reflect on your learning throughout the hackathon. This includes reflecting on course concepts that you now
better understand as well as what you learn about yourself as a problem solver.
The work journal does not need to document every single aspect of the work you perform during the hackathon, and does
not need to address all of the marking criteria in every entry. Rather, the journal entries as a whole need to provide
insight into your experiences in the hackathon. An example of the format for a single journal entry is included below
(yours should include the actual images instead of just a list of the embedded images):
Journal Entry: Day 8 (18/05/2020)
Tasks Attempted Today: Getting Sprite to React when Touched
Finally made a breakthrough on the issue I had trying to get the Sprite to react appropriately when it is touched. I realized it had
to be an error with the logic of the code somewhere, so I revisited my activity diagram and worked through it step by step. It
seemed okay, so I then compared it carefully with the code I’d created in Scratch. It turns out I hadn’t set up the “if” statement
correctly, so the code to react was never being reached. I found it much easier using the activity diagram to compare with my
code because I could then just concentrate on making sure the code exactly followed the activity diagram’s structure. When I
had tried reviewing the code directly without the activity diagram, I got lost (without realizing) trying to keep track of what the
code was doing and the logic of what I wanted the code to actually do. It was such a relief to fix this issue and it gave me
confidence that I can actually do this if I put the effort into thinking about it.
My next task was to make the reaction occur over a larger distance. I wasn’t sure how big to create the reaction zone, so I
created a table of different values for the reaction zone and recorded the results for each. In doing this, I determined that the
zone size I wanted was halfway between two values I’d tested, and was able to confirm this through testing. This combination of
trial and error with recording the results in a table worked effectively as it gave me some structure around choosing a suitable
value rather than just guessing.
Embedded Images: Activity Diagram, Screenshot of current code, Table of Reaction Zone results
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 6 of 10
Part 3: Hackathon Presentation
At the conclusion of the hackathon, you will provide a short video presentation discussing your hackathon experience.
Your presentation must be uploaded to YouTube as an UNLISTED (not public or private) video.
This presentation will:
• provide a brief description of the game you chose for the hackathon.
• identify a personally-significant moment experienced during the hackathon and discuss what made this
significant. A significant moment may include events that were challenging, particularly emotive (satisfying,
frustrating, etc) or that had a large impact on the work performed during the hackathon.
• identify one problem you encountered during the hackathon, and discuss the problem solving techniques or
strategies you used to address this problem and how (and why) these were used.
• reflect on personal learning and responses to challenges encountered during the hackathon, including
understanding of course concepts, personal skills in problem solving and the role of mindset.
Your presentation should not exceed 5 minutes. You are welcome to use any presentation aids at your disposal, but
using such aids is not mandatory.
You are also required to complete a peer review of two presentations conducted by other students. These will be
automatically allocated once the submission deadline has passed. Peer review rubrics will be provided.
Note: You MUST upload a link to your presentation video before the due date and time documented on Page 1 of
this specification. The submission box will automatically allocate peer reviews based on the files submitted at the
due date and time, without any grace period. If you are late with your submission, an alternative submission box
will be available, however you might not be able to participate in the peer review process and would therefore not
be eligible for the marks associated with this task. Contact your lecturer for advice if you are in this situation.
Submission
Part 1: Design Documentation and Peer Review
Your initial draft design documentation must be submitted in the Design Documentation Workshop link provided in
Moodle, as a .pdf file. Your peer reviews will also occur directly in this Workshop link. Note that your tutor will only be
assessing the peer reviews you complete in this submission, since the documentation is only required to be a draft.
Part 2: Hackathon Report
You must create a single .zip file (NOT .rar, .gzip etc) that includes the following:
• Your completed work journal in Microsoft Word or a comparable editor. If you are using a comparable editor,
you must save your work journal as a .pdf file for submission.
• Your documentation, including all code, models, test cases and test results. This includes the final version of
the design documentation, incorporating any changes to the documents that occurred during the hackathon, and
the final version of any supporting documentation referenced in your work journal.
This .zip file must be submitted in the Hackathon Report assignment submission dropbox provided in Moodle.
Part 3: Hackathon Presentation
Your presentation must be submitted in the Video Presentation Workshop link provided in Moodle, as a link to an
unlisted YouTube video. Your peer reviews will also occur directly in this Workshop link.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 7 of 10
Marking Criteria
See Appendix at the end of this document. Three marking rubrics are provided, covering:
1) Design Documentation & Peer Review
2) Hackathon Report
3) Hackathon Presentation
Feedback
Marks will be uploaded in fdlMarks and a completed marking feedback sheet uploaded in Moodle
within 2 weeks of the assessment due date.
Plagiarism:
Plagiarism is the presentation of the expressed thought or work of another person as though it is one’s
own without properly acknowledging that person. You must not allow other students to copy your work
and must take care to safeguard against this happening. More information about the plagiarism policy
and procedure for the university can be found at http://federation.edu.au/students/learning-andstudy/online-help-with/plagiarism.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 8 of 10
APPENDIX – MARKING RUBRICS
Marking Rubric for Part 1: Design Documentation and Peer Review.
| Design Documentation |
4 | 2 | 1 | 0 |
| Game objective and rules developed |
A statement of the game objective has been provided, along with a detailed description of the rules. These clearly identify and describe the gameplay to be implemented, enabling the development of robust solutions. |
A statement of the game objective has been provided, along with a description of the rules. These provide a reasonable description of the game, but some further clarification would be needed to develop robust solutions. |
No game objective has been provided OR A game objective has been provided but rules of the game have not been provided OR The game objective and / or the rules have been provided but these are ambiguous or do not clearly describe the gameplay. |
|
| Complete Peer Reviews x 2 |
Two peer reviews of design documentation have been completed. These both demonstrate critical analysis of the design documentation and provide meaningful feedback. |
Two peer reviews have been completed. The analysis and / or feedback lack analysis. OR One peer review has been completed. This demonstrates critical analysis or the design documentation and provides meaningful feedback. |
One peer review has been completed. This lacks critical analysis of the design documentation or provides superficial feedback only. |
Peer reviews not completed. |
| Complete Self Review | A review of own design documentation has been completed. This demonstrates critical analysis of the design documentation. |
A review of own design documentation has not been completed OR A review of own design documentation has been completed but does not demonstrate critical analysis. |
||
| 4 | 3 | 2 | 0 | |
| Develop algorithms to implement the gameplay described. |
Algorithms are provided. These clearly relate to the gameplay, are unambiguous, clear, complete and logical. These algorithms should successfully implement the gameplay described. |
Algorithms are provided. These clearly relate to the gameplay and mostly achieve the required solution but contain a small number of issues with clarity, completeness or logic. |
Algorithms are provided. These can be related to the gameplay but are a) unclear or ambiguous b) incomplete c) logically incorrect. |
Algorithms not provided OR algorithms are provided but the relationship between these and the gameplay is unclear. |
| Provide an appropriate UML model to represent the proposed gameplay |
A UML diagram is provided and is an appropriate type of diagram for the purpose it has been used. The diagram appropriately reflects the gameplay. Correct notation is used, and following the diagram would lead to implementation of appropriate solutions. |
A UML diagram is provided and is an appropriate type of diagram for the purpose it has been used. The diagram reflects the gameplay as appropriate. There are some issues with clarity, or logic that would cause the solutions to fail, OR some of the notation used is incorrect. |
A UML diagram is provided however the choice of diagram type is not appropriate for the way it has been used. |
No UML diagram provided OR the UML diagram does not clearly relate to the gameplay described. |
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 9 of 10
Marking Rubric for Part 2: Hackathon Report
| Work Journal | 5 | 3 | 1 | 0 |
| Problem Solving Techniques |
A variety of problem solving techniques are identified and discussed with explicit connection to the related modelling documentation, code and / or test cases. Meaningful connections are analysed between course concepts and the application of these concepts to solve problems experienced during the hackathon. Use of problem solving techniques has led to significant progress towards implementing a solution. |
Problem solving techniques are identified and discussed with explicit connection to the related modelling documentation, code and / or test cases. Attempts to relate course concepts with experiences solving problems in the hackathon are made but these lack depth and / or understanding. Use of problem solving techniques has led to reasonable progress towards implementing a solution. |
A limited selection of problem-solving techniques are identified and discussed. |
Application of problem solving techniques is not evident through the journal OR Problem solving techniques are identified and discussed but links are not made between these techniques and how they have been applied to specific modelling documentation, code and / or test cases. |
| 3 | 2 | 1 | 0 | |
| Perseverance through Challenges |
Journal entries demonstrate that the problem selected for the hackathon presented many challenges. This may have been achieved by adapting the initial problem to a more difficult standard. Experiences resolving challenges are discussed and demonstrate a thoughtful approach to identifying and trialling possible solutions. A strong willingness to persist through difficulties and adapt approaches when required is evident. |
Journal entries demonstrate that the problem selected for the hackathon presented several challenges. This may have been achieved by adapting the initial problem to a more difficult standard. Experiences resolving challenges are discussed. A willingness to persist through difficulties and adapt approaches when required is evident. |
Journal entries demonstrate that the problem selected for the hackathon presented few challenges. Experiences resolving challenges are discussed. A limited willingness to persist through difficulties and adapt approaches when required is evident. |
Journal entries do not identify challenges encountered during the hackathon OR Journal entries identify challenges encountered during the hackathon but do not provide details of how these were approached and / or demonstrate willingness to persist through difficulties. |
| Test Cases | A comprehensive selection of test cases is provided to validate design (whether or not code is fully implemented). |
Test cases are provided to validate most of the design (whether or not code is fully implemented). Additional test cases would be required for confidence that the code behaves as required. |
Limited or no test cases are provided. | |
| Test Results | Completed test results are provided for a comprehensive selection of test cases, in so far as code attempted. Errors may still exist in the code. |
Test results are provided to validate most code behaviour, in so far as code attempted. Errors may still exist in the code. |
Limited or no testing completed. | |
| Reflection | On-going, frequent reflection is evident throughout the journal and includes analysis of how the experiences contributed to student’s understanding of course concepts. |
Few, or infrequent, attempts at reflection have been included in the journal OR analysis is either not provided or limited. |
Reflection has not been attempted. | |
| Supporting Documentation |
Appropriate documentation is incorporated in the journal in support of the problem solving activities. This documentation is updated when / if appropriate to reflect new learnings and feedback |
Incomplete or no supporting documentation is provided. |
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 2007.docx Page 10 of 10
Marking Rubric for Part 3: Hackathon Presentation
| Presentation | 3 | 2 | 1 | 0 |
| Hackathon Game Identification |
The game idea selected for the hackathon is clearly described. |
The game idea selected for the hackathon is unclear. |
||
| Personally-Significant Moment |
The presentation includes identification and discussion of a personally-significant moment during the hackathon. |
Personally significant moment during the hackathon identified but limited discussion of this event occurs. |
A personally significant moment during the hackathon is not identified. |
|
| Personal Challenge Identified |
A challenging problem encountered in the hackathon is identified and described. |
No unique challenging problem from the hackathon is identified and described. |
||
| Problem Solving Techniques |
At least three key problem solving techniques are identified and discussed in relation to how and why they were used, in the context of the unique challenge identified. The appropriateness of these techniques for this purpose is insightfully analysed. |
At least three key problem solving techniques are identified and discussed in relation to how and why they were used, in the context of the unique challenge identified. The appropriateness of these techniques for this purpose is analysed but this analysis lacks depth. |
One or two problem solving techniques are identified and discussed in relation to how and why they were used, in the context of the unique challenge identified. The appropriateness of these techniques for this purpose is analysed. |
Problem solving techniques are not identified and discussed OR Problem solving techniques are identified but not discussed as to how and why used and / or not analysed. |
| Reflection | An insightful reflection analyses the hackathon experience and the student’s personal responses to the challenges encountered. The impact on learning, understanding of course concepts and the role of mindset are meaningfully reviewed. |
A reflection analyses the hackathon experience and the student’s personal responses to the challenges encountered. The impact on learning, understanding of course concepts and the role of mindset are reviewed but this lacks depth. |
No reflection is included OR A reflection is included but does not make connections to learning, understanding of the course concepts and mindset. |
|
| Peer Reviews x 2 | Two peer reviews are completed. These show meaningful analysis of the presentations reviewed. |
Peer reviews are not completed (two required) OR Peer reviews are completed but do not meaningfully analyse the presentations provided. |
[Button id=”1″]
[ad_2]
Source link
"96% of our customers have reported a 90% and above score. You might want to place an order with us."
