Problem solving and IPO
Programming Fundamentals · about 7 min
An examination verb identifies an action, but the whole specification determines the algorithm. “Display” tells you to produce output; it does not tell you which loop to choose. Underline the input, selection rule, output format and stopping condition. Write a small input–process–output plan. For each requirement, identify the variable or statement that will satisfy it.
A trace table records the state after each iteration. Include the loop counter, current item, running total and any flag. Trace a tiny example by hand before using a large dataset. A counter measures how many items match; an accumulator combines their values. Both need initial values. Tests should include an ordinary case, every boundary, no matches and invalid input. This process gives you evidence of correctness rather than confidence based on one successful run.
Key points- Translate action verbs into requirements.
- Create an IPO plan and trace table.
- Choose tests before writing code.
Worked example: iCount := 0; iTotal := 0; for i := 1 to 5 do begin if i mod 2 = 0 then begin Inc(iCount); iTotal := iTotal + i; end; end; Declare i, iCount and iTotal as Integer. At i=1 the state is (0,0); i=2 gives (1,2); i=3 leaves it unchanged; i=4 gives (2,6); i=5 leaves (2,6). The loop has five iterations but only two matches.
A keyword list is a prompt to think, not a rule that every “count” question needs SQL GROUP BY or every “unknown” question needs the same loop.
Practice: Count and total the multiples of 3 from 1 through 10. State the final counter and total.
Answer: Change the upper bound to 10 and the condition to i mod 3 = 0. Matches are 3, 6 and 9: counter 3, total 18. Initialising inside the loop would incorrectly reset earlier results.
Recap: Turn requirements into state changes; trace the state and test the boundaries.