ITECH1101 – IT Problem Solving

ITECH1101 – IT Problem Solving 2018/17
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 Page 1 of 10
Hackathon Assignment Specification
Overview
This assignment requires you to identify a challenging problem and attempt to solve it using a robot. You will design a possible solution, attempt to implement that solution 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
Some of this assignment requires group work. However you will be assessed individually.
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: Monday 3rd September, 2018, 12:00 (noon)
Peer Review: Sunday 9th September, 2018, 23:55
Part 2:
Hackathon Report: Sunday 30th September, 2018, 23:55
Part 3:
Hackathon Presentation: In your timetabled Week 11 lab.
Minimum time expectation: 20 hours
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 1817 Page 2 of 10
Assessment Details
Part 1: Design Documentation and Peer Review
This stage requires you to select a problem to solve using one of the available Mindstorms Robots, design a possible solution to this problem and submit this solution design for peer review. You are also required to peer review the designs of two other students in the course.
The design documentation is to be completed in groups of 2-3 students. Your team will be allocated from your lab group.
Peer reviews will be completed individually.
Problem Selection
Identify a problem to solve as a team. You can come up with any problem of interest (perhaps a design thinking workshop could help generate ideas?), or use the ideas below as suggestions. Your problem must:
• Be challenging for you. You are being assessed on your application of problem solving skills, so any problem that is too easy will not give you the opportunity to demonstrate this.
• 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. Controlling the robot’s movements through a remote is not permitted (although a limited amount of this may be done in support of coded behaviours)
• Work within the capabilities of your robot. You are not permitted to modify the robot builds, other than to switch between the available attachments as appropriate. You may add temporary enhancements, such as using glad wrap, putting on temporary decorative clothing or applying a rubber band, provided the changes do not affect the structure of the robot, do not impair its capacity to function, do not leave any mark or residue on the robot and can be quickly applied and removed.
Your problem must also not be something that you can solve by following previously created instructions or downloading existing programs. For example, you cannot just use the code examples provided in the Mindstorms tutorials, even if you recreate them yourself, and you cannot download existing code from the internet.
Ideas:
• Sort objects in different locations based on colour
• Build something by collecting pieces and assembling / layering them in a specific location
• Play hide-and-seek, using an IR sensor to locate the IR remote
• Battle another robot (two teams from one lab group could each program one robot to compete). Just remember not to damage the robots!
• Follow a path through an unseen obstacle course – perhaps use colour, or object sensing (or both?) to determine movements
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 Page 3 of 10
Design Documentation
Once you have selected a problem, your team must create documentation that outlines the logic of a solution to your problem. You may need to break your problem down into smaller sub-problems to achieve this, and should prepare problem statements for these sub-problems. This documentation must clearly identify the problem(s) you are attempting to solve, and include algorithms and UML models to represent the full functionality of the program(s) you intend to implement during the hackathon. Your documentation must be saved in .pdf format.
Completed design documentation must be uploaded to the two links provided in Moodle by noon Monday 3rd September 2018 to allow time for peer reviews to be completed. Each student needs to submit the same version of their group design document twice (Hackathon – Solution Designs Workshop and Assignment Part 1: Design Document). The reason for this is that the Hackathon – Solution Designs Workshop submission is where you will peer-review other design documents (including your own) and the Assignment Part 1: Design Document submission is where your tutor will mark your groups’ design.
Peer Reviews
From noon on Tuesday 4th September 2018 (or an alternative time as advised by your lecturer), you will have access to conduct a peer review on two other students’ design documentation (through moodle). These reviews will be allocated to you. You will also review your own design. These designs will be selected from different teams where possible, which means each team will usually receive feedback from six other people. You will complete the peer reviews individually.
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 problem(s) under investigation, how clearly algorithms represent and address the problems(s) and how effectively UML diagrams are documented to solve the problem(s). You will also have the opportunity to provide your own comments, and should take care to provide specific comments that highlight both the positive aspects and the potential issues of the proposed solution(s) and documentation.
Note: Your mark will not be impacted by the feedback your peers provide on your work. Your tutor will be marking your design documentation separately, and it is your tutor’s mark that will contribute to your assessment. You will be marked based on how well you complete your peer reviews.
All feedback must be completed by 23:55 Sunday 9th September 2018, in readiness for the hackathon to begin in the next workshop. You should review the feedback you have received and incorporate the feedback you receive into your design, as appropriate. You may continue to update your documentation throughout the hackathon, based on your hackathon experiences, and any additional ideas you obtain through seeing the designs completed by other people (Note: this does not mean copying their work. It does mean that you can be inspired by it, and make improvements to your own design based on what you’ve learned).
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 Page 4 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. This will occur through a work journal, to be documented in your ePortfolio. This task is to be completed individually.
You will update and maintain your work journal on a frequent basis throughout the hackathon, documenting:
• an overview of the work you have been attempting
• challenges or problems you encounter
• the output of your work.
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.
You will also reflect on your learning throughout the hackathon. This learning can include both course concepts that you understand better due to applying them during the hackathon, and learning about yourself as a problem solver.
To create your Work Journal:
1) Log on to Mahara (ePortfolio System) at https://eportfolios.federation.edu.au/
2) Select Content, then + Create journal
3) Give your journal a name, e.g. ITECH1101 Hackathon Experiences
4) Click Create Journal
To present your Work Journal ready for submission:
1) Select Portfolio then Pages
2) Select + Create page
3) Give the page a name, e.g. ITECH1101 Hackathon Experiences.
4) Click Save. The Edit Content tab will load.
5) Select the Edit layout tab. Select an appropriate layout (the first option, with just a full page, will suit most people), then click Save.
6) The Edit Content tab will reload. From the menu on the left, select Journals, then drag the Journal submenu item onto the blank page layout section until the journal outline is highlighted.
7) Select the Hackathon Journal (ITECH1101 Hackathon Experiences).
8) Click Save on the Journal: Configure screen.
9) Select Share page, then select the name of your tutor using the Share with box. Click Save.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 Page 5 of 10
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 and it is these experiences as a whole that will be evaluated. An example of the format for a single journal entry is included below:
Supporting Documentation
Effective completion of your work journal will involve referencing documentation that you have created for the hackathon. Examples of this include UML models, tools for problem solving, code, test cases and test results.
You are required to upload the documentation you discuss into the work journal. This documentation may change as you work through the hackathon, so uploading it in the entries 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.
Journal Entry: Day 8
Tasks Attempted Today: Coding of requirements 5, 8.
Finally made a breakthrough on the issue I had trying to get the robot to stop as per requirement 5. 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 Mindstorms. It turns out I hadn’t set the switch up correctly inside the loop, so the code to stop 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 finally fix this issue and it gave me confidence that I can actually do this if I put the effort into thinking about it.
We started working on requirement 8 this afternoon in our lab. Using the sensor is tricky because we weren’t sure about its working range, so we wrote a program and tried it out on the robot a few times, changing the distance setting to see what happened and recording our results, using a table as our graphical organizer. This combination of trial and error with recording the results in a table worked effectively as we now understand what the different values mean and can incorporate this into our program.
Attachments: Activity Diagram for Requirement 5
Code for Requirement 5
Code for Requirement 8
Table for Sensor Distance Results
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 Page 6 of 10
Part 3: Hackathon Presentation
At the conclusion of the hackathon, each person must provide a short individual presentation about their hackathon experiences in their scheduled laboratory.
This presentation will:
• introduce the main problem that the team attempted to solve 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 personally encountered during the hackathon, and discuss the problem solving techniques or strategies used personally to address this problem and how (and why) these were used. Note: team members must not choose the same problem to discuss. You will need to coordinate with your team to ensure different problems are selected.
• 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.
Each presentation should not exceed 5 minutes. Any presentation aids readily available to students may be used, but students are responsible for ensuring these will work in the labs and having a backup available in the event of an issue.
You are also required to complete a peer review of two presentations conducted by other students in your laboratory class. You will be allocated two student presentations to review at the start of the laboratory class. Peer review forms will be provided in the class.
Submission
Your initial design documentation must be submitted in the Workshop and Assignment link provided in Moodle, as a .pdf file. Your peer reviews will also occur directly in this Workshop link.
Your work journal must be created in the Mahara ePortfolio and submitted in Moodle at the assignment dropbox provided. This must be separate from your ePortfolio journal entries.
Your documentation, including all code, models, test cases and test results, must be zipped into a single file and submitted in the assignment dropbox provided. 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. You will also submit a copy of the feedback you provide to your peers on their presentations in the week 11 lab in this link.
Your presentation will be assessed during your scheduled lab class in week 11.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 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-and-study/online-help-with/plagiarism.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 Page 8 of 10
APPENDIX – MARKING RUBRICS
Marking Rubric for Part 1: Design Documentation and Peer Review. Design Documentation 4 2 1 0
Problem statements clearly identify details of the problem(s) to be solved
Problem statements have been provided. These clearly identify and describe the problems to be solved, enabling the development of robust solutions.
Problem statements have been provided. These provide a reasonable description of the problems to be solved, but some further clarification would be needed to develop robust solutions.
No problem statements have been provided
OR
Problem statement(s) have been provided, but these are ambiguous OR do not clearly explain the problems to be addressed.
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 solve each of the problem statements provided.
Algorithms are provided. These clearly relate to the problem statements, are unambiguous, clear, complete and logical. These algorithms should successfully address the problem statements.
Algorithms are provided. These clearly relate to the problem statements 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 problem statements 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 problem statements is unclear.
Provide appropriate UML models to represent the proposed solutions
UML diagrams are provided and are appropriate for the problem statements being addressed. The diagrams appropriately reflect the algorithms. Correct notation is used, and following the diagrams would lead to implementation of appropriate solutions.
UML diagrams are provided and are appropriate for the problem statements being addressed. The diagrams reflect the algorithms 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.
UML diagrams are provided however the selection of diagrams is not appropriate for the problem statements provided.
No UML diagrams provided OR UML diagrams do not clearly relate to the problem statements provided.
ITECH1101 IT Problem Solving
CRICOS Provider No. 00103D ITECH1101 Hackathon Assignment Specification 1817 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.
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.
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 including updated design 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 1817 Page 10 of 10
Marking Rubric for Part 3: Hackathon Presentation
Presentation 3 2 1 0
Hackathon Problem Identification
The problem selected for the hackathon is clearly identified and defined.
The problem 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.
Unique Challenge Identified
A challenging problem encountered in the hackathon is identified. Team members may not discuss the same problem.
No unique challenging problem from the hackathon is identified.
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.