@ jasn9776 Amazing!
On Algorithms:
I start off making a list of all the functions/tasks I’ll need to do. Take 2017’s purchase module question, for example. Before I started, I jotted down some bullet points in the margins— a loop for the customer to keep choosing items and quantities, a subprogram to compare quantity and stock, etc. Try and step through what you want your program to do, and write down those tasks as you go.
Then, I start writing my algorithm in pencil. This gives me the flexibility to adjust my code or add new lines, and ensure my structure is correct instead of angry crossed-out lines of code that can be hard to read. Of course, time is of the essence, so if you’re struggling for time, you’ll have to make allowances for something. Do this at your own discretion.
And definitely, some of the HSC questions are notoriously poorly worded (looking at you, 35e!). The 2016 question did actually specify it was a sequential file, so you’d apply the relevant knowledge in that case. But if they don’t specify, this is when knowing the syllabus and what your “options” are is pretty important. E.g. if they just said “a file”, you’d know it has to be either sequential or relative, and infer based on the context of the question.
Another thing about the questions, they usually try and relate it to a real-world example, so you can sometimes use background knowledge and common sense to help guide your decision making.
If worse comes to worst, write your assumption at the top. E.g. “Note: assuming the file is less than 100 lines long and is sequential.”
On Studying:
From the sounds of it, you should practice the more applied sections of the paper (system modelling tools, algorithms, metalanguages). At this point, cramming a lot of theory won’t be very helpful, but you definitely want to make sure you know the three sections I just mentioned, as they’re a huge part of the paper.
A lot of the theory is pretty intuitive— e.g. “we should make sure to credit contributors to avoid copyright”, so if you’re pressed for time you should be fine. If in the exam, you can’t think of any more theory, throw in some examples. Tie it to the case study, if they’ve given you one.
Other sections that are less intuitive and are worth double checking: software development approaches and trends, fetch execute cycle, system/program/module level testing, and the design specs (know your interface elements!).
An exercise I’ve found helpful: go through the syllabus dot points, and highlight each dot point in either green, yellow, or red. Green for “I know this! I can answer this!”, yellow for “I know some of this, still a bit iffy”, and red for “I have no clue what this is!”. Based on that, prioritise what you cram, and make sure at least for the red points that you can attempt an answer.
Hope this helps! Best of luck