Hackathon problem statements for cse

Hackathon Assignment

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.

https://eportfolios.federation.edu.au/
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.

http://federation.edu.au/students/learning-and-study/online-help-with/plagiarism
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.