Software Design and Development: A Detailed Array of Tips and Tricks from First in StateBy Serena Gao in HSC
16th of April 2018
Serena graduated as first in the state for Software Design and Development, and achieved a 99.75 ATAR.
You can ask Serena a question on the original forum post, which can be found here.
If you’re reading this, you’re probably a Software Design and Development student. Or a friend of mine trying to find typos in this guide. Either way, hello and welcome! : )
Software is such a great course (and increasingly relevant!), but it’s definitely tough at times. I topped the state in SDD in 2017; here are some of my tips and tricks to the class of 2018 and beyond.
General Class Time
1. Have an Organised Set of Notes
You hear this with every class. But with Software, you’ll have a much easier time if yours is organised according to the syllabus. Exam questions tend to refer to a very specific dot point. If you know what theory you have under that dot point, you know you’re writing exactly what the markers are looking for.
E.g. Last year they asked about how cloud computing can be used– this actually refers to the “Trends in Software Dev” and “the changing nature of applications”, even though it wasn’t mentioned in the question. (That was one of the questions that stumped me initially because- huh? Cloud computing?)
2. Taking Notes
I had two main documents: my “info-dump” notes (essentially copying all of the stuff on the board) and a refined set of detailed notes. After school/during frees, I would go through and transfer key information to the other document, reword things, simplify examples, and consult with the syllabus to see what content was extra and what was necessary. Sometimes your teacher might not go in the exact order of the syllabus, and that’s okay!
Just a thing about Software notes: take them digitally. You’re going to be coding, writing algorithms, and taking notes. It’s easier to have them all in one folder.
Also, if you’re using Google Docs, there’s an add-on called “Code Block” which takes a piece of text and colour codes it based on key elements in the programming language. Makes it easier to separate blocks of code from your theory notes (and it looks nicer).
3. Paying Attention in Class
One of the unique things about Software (and tech classes in general) is that you have access to computers! And the internet! Which you’re allowed to use! During class!!
Make sure you’re actually listening to the lesson. One of the routines I started was to write down any funny moments/quotes we had during the period. It helped strengthen my memory of the theory, and by the end of the year, I had a huge list of great memories in that class! One of my favourite quotes was “Let’s say we have 2562.9. (That’s my IQ)”.
How does one study for Software?
Well, pretty much how you’d study for other subjects: Practice. Especially the sections you’re not good at. Software is about computers, and computers operate on a very logical basis. So if the theory/answer doesn’t have common sense, you might wanna double check.
1. Knowing your Content
Now that you have an amazing set of notes, use them to study for your exams! By the time this guide goes up, half yearlies are over (oops), so your next exam should be trials. This is a method that I used a lot:
Make a digital copy of your notes, and go through it, deleting whatever information you know already. Whatever remains is what you should concentrate on studying. Use flashcards, teach a friend or rubber duck, whatever techniques that work for you! Keep deleting stuff as you grow more confident with the content, and hopefully by the time you get to your exam, you’ll only have a few pages of finer details to review right before the exam.
2. HSC/Trial Papers
Practice papers are great, but there’s only so many you can do before the questions get outdated. Do them all anyway, but be prepared to disagree with the answers (and see some truly horrifying interface designs *cough* 2004 hsc paper *cough*).
The suggested answers for past HSCs can be a good indicator for how much detail you need to know about a certain topic. I had a lot of extra information for Data Streams in Option 2, so this was a good way to prioritise the most important pieces.
For the HSC
Use Pseudocode. No question. It takes up less space, questions usually give you lined spaces, and it’s much easier to follow the flow of logic.
When you’re doing these questions, plan out the kinds of subprograms/constructs you might need in the margins (it usually aligns with the bullet points they give you in the question). Please don’t forget that subprograms exist and that you can use them to simplify your code, make it more readable, and write less lines overall.
Now, if you can afford the time, write your first drafts in pencil. That way you can correct mistakes before going over them in pen– You don’t want to write the first draft in ink and then realise you needed to declare 5 variables at the beginning, and are now faced with the choice of squeezing 5 lines of pseudocode in the tiny space between two lines, or stuffing them at the bottom/side and hoping the message gets across.
And indent your lines if it should be indented. Please.
Algorithms are always in the exam, and they usually add up to a lot of marks. Do as many algorithms questions as you can, and look at sample answers to see if there was a better way you could have done it. E.g. For one practice question I used three arrays, when I could have used a multidimensional array with varying lengths. There’s always a way to improve your algorithm.
2. System Modelling Tools
Context diagrams, DFDs, structure charts, system flowcharts, IPOs, you know the drill. At least one of these will be tested in the HSC. DFDs seem to be the most tested, but make sure you’re comfortable with all the rest. (Hint, they haven’t tested data dictionaries or system flowcharts in a while)
Same deal as with algorithms. Try and plan out the inputs/outputs/data flows before you start, especially if it’s more complex like a DFD or structure chart. Use pencil first if possible, but otherwise these questions tend to give a little more space, so you have some flexibility.
System flowcharts are grossly outdated it’s not even funny. But they can still test you on it. As a rule of thumb, you’re never going to need to draw the symbols for punched card, magnetic tape, or input/output that’s not the online input/output (because everything’s online nowadays). It’s helpful to know what they are, but I’d be surprised if a question included them.
Alright, I know what you’re thinking for this section: I get to make a game!! And it’s only internally marked, so I can make anything I want without fear of the NESA judges criticising it!
It’s a once in a lifetime opportunity– make sure you do it well. Time management is so important, because we usually pursue a super ambitious goal that we don’t have enough time to do. Use the Gantt Chart you made, or another calendar to plan out deadlines for your project. I divided my major project into subprograms (e.g. mainline, function1, function2, etc) and aimed to get one of those parts done every week (use stubs as a placeholder for the unwritten sections).
If you’re working in teams/pairs, please back up your work. Use github if you’re tech-savvy, or upload zipped and named versions of your code to google drive/dropbox (that’s what I did because I didn’t realise github was a thing hahaha).
Testing will be a chore at times. You get tired of seeing the same screen over and over (and wHY is everything breaking I only changed the colour of this box whAT HAVE I DONE-). Get other people to test it, because you never know what parts they might get stuck on. My project was an adventure game, and a lot of people stayed on a screen that said “…” because they thought it was loading more dialogue.
You also don’t have to stick with the programming language that you learn in class. My partner and I asked to use a different language because the one we learnt was not cut out for the kind of game we were looking for. We had so much more fun coding, the program looked a lot better, and we learnt one new programming language out of the whole experience.
Software was easily one of my favourite subjects, and it is so worth the effort. You’re doing a great job, and know that you’re always welcome on the SDD forum (I’ll be around to answer any technical questions you may have throughout the year!).
And remember, Artificial Intelligence will probably control us all in a few years so consider this course your defense against our future overlords : D