TIPS

• You need to create:

  • Wire frames for your GUI (Paper or draw.io)

  • Program structure diagram (UML class diagram, flowcharts). Use your program structure to set up your Trello board / task decomposition

  • A trello Board or Github Project or similar where you show task decomposition (Decomposing the task into smaller components) and the board will help you manage the outcome

    • You can add more components to your decomposition at any time. If you realise that adding a component is necessary, please state why the component was added in your documentation

    • Likewise, you can also combine components if it makes sense to do so. Again, you'd want to justify your decisions

    • Ideas for breaking down a task.

      • Significant programs would generally have 7 - 10 components that we need to code so that it could be combined into a working outcome.

      • Often components can be changed into functions for use in the final program.What inputs might you need and how will you check that the user provides valid data?

      • What calculations / processing might be needed

      • What output should be given to the user?

      • Have you included easy to follow instructions for first time users?”

• For each component you MUST have

  • A screenshot of your Trello board (it shows you are using a project management tool)

  • A test plan that has been written BEFORE you start coding the component

  • Evidence that you have tested your code using your test plan

• Use github for version control (remember to UNTICK the 'Keep this code private' box so that your code is public).

• We can control the width and height of our dialogues by specifying dimensions in the code. Alternately, width and height details can be left out and Python will resize to fit our content.

• Comment your code!!

• Testing can be videoed - this is often faster and easier than taking screenshots

• You MUST be able to show evidence of trialling / testing and working in an iterative way. Some components might have very little / no trialling whilst for others you may have considered a number of possible options.

• If (or more realistically, when) your development is different from your original plan, you should make a note of what has been changed and why it has been changed. This is a normal part of developing an outcome.

• When you develop your GUI, think about how it can be refined to make it easy for users (eg: can you prevent users from making errors rather than having to rely on error correction later on) If you have an Entry widget, you MUST have error testing!

• Remember to create at test plan BEFORE you code. Think 'what do I expect my code to do?' to help generate the test plan.

• Incorporating images into a program is optional BUT it can improve / further refine an outcome.

There is often more than one way to code a given solution

• From time to time, you will try one thing and then realise there is a better or easier or nicer way of doing that same thing. In these cases you should show ALL your trials

• When you try multiple options, you will end up choosing the best one. In your documentation you should note down what you tried and state which option you will use in your completed outcome. Where possible, explain WHY you made that choice.

• WHY you made that choice.

Excerpt From: Jennifer Gottschalk. “Level 2 Programming & Planning.” iBooks.

Go to this link for a help document on how to optimise Trello

There are some interesting features on Trello that you may or may not know.

You can link your google documentation to your trello board so you don’t forget ever again to submit your documentation. Add the essential Google POWER UP to your Trello board.

You can link up a google chat or hangout onto Trello with this POWERUP. Great for communication with your team buddies.

You can have a survey tool linked to your board using Survey Monkey as a POWERUP.

Relevant Implications (use purple)

Below is an example of what this might look like. Whilst some of the explanations can be recycled from other projects, you should try and customise the material so that it references the outcome you are working on. The focus should be on explaining the implication. Later on, you will be able to talk about how the implications have been addressed.

Functionality (works as expected)

involves ensuring that the program allows the teacher to enter student and their results and the program will correctly calculate the top mark as well as class average. By testing and debugging each component of the code, we ensure . . .

This implication has been addressed by comprehensive testing to ensure that the outcome works on a range of relevant expected, boundary and unexpected/invalid input cases (see testing evidence in log)

Usability (error prevention)

involves making it possible for people to use an outcome without needing to ask for help. For my teachers' program this would mean that the teacher can easily input student name and result, and invalid inputs are not allowed. This would make the program less frustrating how? Programs that are easier to use are more popular and sell better

Usability/Aesthetics

The GUI was carefully designed to ensure that it is aesthetically pleasing and that is it also easy to use. Where possible, the chances of user error have been minimised by having buttons and only one input box. If a user enters an invalid input, an error messages appears which explains what the problem is and suggest how to fix it (usability, error prevention and recover from error)

Accessibility

means ensuring that all users can access the outcome and it's content. One issue with sharing Python programs is that if the program is simply uploaded to a web server or shared via email, users would need to install Python to be able to play it. We can overcome this limitation by making the code available through a web platform like repl.it

The content can be accessed via a public github repository and can also be copied/pasted into repl.it which means users can run the program in their browser without needing to download special software

Social implications

relate to how our outcome might affect society as a whole. In the case of this teachers; program it is hoped that the program will benefit teachers as it should make it easy to . . . example I opted for relaxed formal error messages suitable for my audience. Language is gender neutral and easy to understand.

The outcome addresses social considerations by allowing users to easily XXXXX (useful for the wider community) and by providing a bit of history/help with a button

IP

At times I have adapted code snippets that have been shared online (usually via stack overflow) In those cases comments pointing to the original source of the code have been provided (addressing the IP/ethics implication

Excerpt From: Jennifer Gottschalk. “Level 1: Programming & Planning.” iBooks.

Synthesise Notes