The iterative cycle: create, test, improve

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. Which describes iteration in a project?

A Build it once and never change it

B Make a version, test it, get feedback, improve it, then repeat

2. You finish the first version of your class quiz app. What should you do next?

A Test it and ask classmates for feedback

B Hand it in straight away because it is finished

3. Which is the better file name for saving versions of your poster design?

A poster_final, poster_final2, poster_REALLYfinal

B poster_v1, poster_v2, poster_v3

4. Testers say your app has a confusing menu AND the colours are hard to read. What is the best approach?

A Change one thing, save it as a new version, then test again

B Change everything at once and hope it all works

5. True or false: Iteration only happens once, after the project is finished.

A False: it is repeated during the project

B True: you only improve at the end

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1poster_v1.png, poster_v2.png, poster_v3.png		ASaving numbered versions so each improvement is kept and you can go back to an earlier one
2Create → Test → Feedback → Improve → Repeat		BThe iterative cycle: make a version, test it, collect feedback, improve it, then go round again
3Change one thing at a time so you can tell which change made the difference		CToo many changes at once. If testers dislike v3 you cannot tell which change caused the problem. Change one thing per version.
4Stop iterating when the solution meets its purpose and testers have no important problems left		Dif (testers_happy and meets_purpose) then stop else make_next_version
5Saved over the old file: game.html (no earlier versions kept)		Ev2: made the button bigger (nothing else changed)
6v3: new colours, new menu, new logo, new sounds all at once		FOverwriting the old version means you cannot go back if the new change breaks something. Save numbered versions like game_v1, game_v2.

Definitions

iteration

Fill in the Blanks

Complete each line of code by filling in the missing parts.

______ improve(app) UNTIL goal_met

version ← 1 version ← version _ 1 save(version)

create(version1) ____(version1) improve(version1)

WHILE ___ goal_met improve(app) ENDWHILE

IF ________ THEN stop() ENDIF

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A version ← 1

B REPEAT

C test(version + 1)

D improve(version)

E version ← version + 1

F UNTIL goalMet

Question 2

A apply(oneChange)

B save("app_v" + version)

C publish(version)

Question 3

A save("game")

B test(version)

C version ← version + 1

Question 4

A feedback ← getFeedback()

B IF purposeMet THEN

C restart()

D ELSE improve(design)

Question 5

A test(version)

B feedback ← ignoreUsers()

C improve(version, feedback)

Answer Key

The iterative cycle: create, test, improve

Section A: Quick Questions

B — Make a version, test it, get feedback, improve it, then repeat

A — Test it and ask classmates for feedback

B — poster_v1, poster_v2, poster_v3

A — Change one thing, save it as a new version, then test again

A — False: it is repeated during the project

Section B: Match the Pairs

poster_v1.png, poster_v2.png, poster_v3.png → Saving numbered versions so each improvement is kept and you can go back to an earlier one

Create → Test → Feedback → Improve → Repeat → The iterative cycle: make a version, test it, collect feedback, improve it, then go round again

Change one thing at a time so you can tell which change made the difference → v2: made the button bigger (nothing else changed)

Stop iterating when the solution meets its purpose and testers have no important problems left → if (testers_happy and meets_purpose) then stop else make_next_version

Saved over the old file: game.html (no earlier versions kept) → Overwriting the old version means you cannot go back if the new change breaks something. Save numbered versions like game_v1, game_v2.

v3: new colours, new menu, new logo, new sounds all at once → Too many changes at once. If testers dislike v3 you cannot tell which change caused the problem. Change one thing per version.

Section C: Definitions

iteration — Making a version, testing it, getting feedback and improving it, then repeating the cycle until it does its job. Save numbered versions and change one thing at a time.

Section D: Fill in the Blanks

REPEAT
  improve(app)
UNTIL goal_met

version ← 1
version ← version + 1
save(version)

create(version1)
test(version1)
improve(version1)

WHILE NOT goal_met
  improve(app)
ENDWHILE

IF goal_met THEN
  stop()
ENDIF

Section E: Spot the Error

C — This tests a version that does not exist yet. Each cycle should test the current version: test(version).

C — The cycle is create, test, improve. Publishing without testing skips the test step. It should be test(version).

A — Saving with no version number overwrites the old file, so you cannot go back. Use a numbered name like "game_v" + version.

C — When the design meets its purpose you should stop iterating. Restarting wastes effort. It should be stop().

B — Iteration needs feedback from real users to know what to improve. Ignoring them breaks the cycle. It should be askUsers().