Overview

This is an individual assignment that requires you to implement your design using block-based coding using MIT Scratch (https://scratch.mit.edu/).  Scratch is a free programming language and online community where you can create your own interactive stories, games, and animations. For this assignment you will use Scratch to create the program you designed in Assignment 1 – Design Documentation

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

Assessment Details

Assignment Scenario Reminder

In Assignment 1 – Design Documentation, you designed an original program that in some way incorporated searching, the colour red, and your student id.  

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 program, but you do need to make some progress towards your goal.

You are not being assessed on how good your program 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:

CRICOS Provider No.   00103D | RTO Code 4909

1. Even though you are able to freely see and access existing Scratch programs, copying someone else’s work does not provide you with any benefit.  Copying existing work 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 program idea allows you to control the level of problem solving you need to perform.  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 are coding, 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 program, 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.

Assignment Requirements

Your task is to develop your design documentation further and to create your program in Scratch. THIS IS AN INDIVIDUAL ASSIGNMENT.

PART A

For this part of your assignment you need to submit one document with the following:

• Program title and description (an overview of your program). This should include an update on the idea you have chosen for your program, and an explanation of why you have chosen this idea (based on your current capabilities with programming and problem-solving) and any modifications you have made since you submitted your Assignment 1.
• One or more UML diagrams showing the behaviour of your program.  You may need to break your requirements down into smaller sub-tasks to achieve this, and should make it clear how diagrams fit together.
• Test cases and test results.
• Work journal discussing, analysing and reflecting upon the problem solving techniques you use during the hackathon. 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 and responses to challenges encountered 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. 

An example of the format for a single journal entry is included below:

Journal Entry: Day 8

Tasks Attempted Today: Getting Dragon to React when Touched

Finally made a breakthrough on the issue I had trying to get the Dragon 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

PART B

The final thing you will do is create a video recording OR present in Week 11 labs^[1]. 

This presentation will:

• introduce and demonstrate your program
• 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.
• discuss one problem solving technique or strategy used personally to address a problem faced during coding and how (and why) it was used.  

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.

For ODL students and those students who choose to do a video, you will have to include a link to your presentation within your word document created in PART A. Failure to do this, will result in zero marks for the presentation component of the assignment. 

Part A and Part B (if you are submitting a video) are due Friday of Week 11 @ 5pm.

Submission

Your assignment must be submitted as a Microsoft Word file or a .pdf file only, in the assignment submission box provided in Moodle.  Your work will be evaluated for originality using TurnItIn. There will be a separate assignment 

Marking Criteria

Refer to the marking rubric at the end of this document.

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. .

Marking Rubric for Part 1: Hackathon Documentation

Criteria	High (3 marks)	Medium (2 marks)	Low (1 marks)	Not demonstrated (0 marks)
Program title and description		A single idea for a program has been selected. An explanation has been provided that shows a high level of insight into why this program is appropriate based on the student’s current capabilities with programming and problem-solving. Any modification to original design has been justified	A single idea for a program has been selected. An explanation has been provided that shows limited insight into why this program is appropriate based on the student’s current capabilities with programming and problem-solving. Any modification to original design has been mentioned but not justified	A single idea for a program has been selected but no explanation of why this choice was made has been provided OR no / an inappropriate program idea has been selected. Modifications to original design have not been justified
Provide an appropriate UML model to represent the proposed program	UML diagram is provided and is an appropriate type of diagram for the purpose it has been used. The diagram appropriately reflects the program. Correct notation is used, and following the diagram would lead to implementation of appropriate solutions.	UML diagram is provided and is an appropriate type of diagram for the purpose it has been used. The diagram reflects the program as appropriate. There are some issues with clarity, or logic that would cause issues	Provide an appropriate UML model to represent the proposed program	A UML diagram is not provided and/or is not suitable  for the purpose it has been used.
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.
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.

                                                                                                                                                             Page 5 of 6

Criteria	High (3 marks)	Medium (2 marks)	Low (1 marks)	Not demonstrated (0 marks)
Test Cases		A comprehensive selection of test cases (including results) is provided to validate design (whether or not  code is fully implemented).	Test cases (including results) 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 and/or results are provided.
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.

Marking Rubric for Part 2: Hackathon Presentation – 5 marks

Criteria	High (3 marks)	Medium (2 marks)	Low (1 mark)	Not demonstrated (0 marks)
Introduction and demo			The program idea selected for the hackathon is clearly described. A demonstration is made	The program idea selected for the hackathon is  unclear. AND/OR No demonstration is made.
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.
Problem Solving Techniques	One key problem solving technique is identified and discussed in relation to how and why they were used, in  the context of the unique challenge identified. The appropriateness of this technique for this purpose is insightfully analysed.	One key problem solving technique is identified and discussed in relation to how and why they were used, in the context of the unique challenge identified. The appropriateness of this for this purpose is analysed but this analysis lacks depth.	One key problem solving technique is identified and discussed in relation to how and why they were used, in the context of the unique challenge identified. The appropriateness of this technique is questionable.	Problem solving technique not identified and discussed OR Problem solving technique is identified but not discussed as to how and why used  and / or not analysed.

                                                                                                                                                             Page 6 of 6

---

.

Get expert help for Assignment 1 – Design Documentation and many more. 24X7 help, plag-free solution. Order online now!