Program Design and Development: Study Guide (Computer Science Principles 1.3)

How is a program really developed?

Programs rarely appear fully formed. Developers follow a development process, a way of organising the work. Some processes are ordered and intentional: the team plans each step before starting. Others are exploratory: the developer tries ideas, sees what happens and decides next steps from what they learn. Real projects often mix the two.

Whatever the process, the work commonly passes through four kinds of activity:

1. Investigating and reflecting. Finding out what is needed, by whom and under what constraints.
2. Designing. Planning how the program will meet those needs.
3. Prototyping. Building an early, partial version to try out ideas.
4. Testing. Running the program with defined inputs to check it behaves as expected.

These are phases, not a one-way staircase. A tester who finds that users cannot understand the layout sends the team back to design. That looping is the heart of the next idea.

Iterative and incremental

Two words that students often swap are different in meaning.

• An iterative process refines and revises the program or design repeatedly, based on feedback, testing or reflection. It may require revisiting earlier phases. Think of a cycle: design, prototype, test, learn, design again.
• An incremental process breaks the problem into smaller pieces and makes sure each piece works before adding it to the whole. Think of building a wall one brick at a time and checking each is level.

A project can be both: build one feature at a time (incremental), and revise each after user feedback (iterative).

Investigation, requirements and specification

Good design starts with investigation. Developers need to understand the constraints (time, devices, budget) and the concerns and interests of the people who will use the program. Ways to investigate include surveys, user testing, interviews and direct observation.

Investigation produces program requirements: statements of how the program must function, which may include the user interactions it must provide. A program’s specification defines those requirements. The design phase then outlines how to meet the specification. Requirements are also needed to choose sensible test inputs later: you cannot say whether the program is correct unless you know what it is supposed to do.

What the design phase may include

The design phase can include any of the following:

• Brainstorming ideas;
• Planning and storyboarding, sketching how screens or steps follow each other;
• Organising the program into modules and functional components;
• Diagrams of the user interface layouts;
• Developing a testing strategy for the program.

Notice that design happens before a lot of code is written, though in an iterative process it is revisited.

Documentation and acknowledgement

Program documentation is a written description of the function of a code segment, event, procedure or program and how it was developed. Comments are a form of documentation written inside the program for people to read; they do not affect how the program runs. Developers should document throughout development, not only at the end, because it helps people (including their future selves) understand, fix and extend the code. Not every programming environment supports comments, so other ways of documenting, such as a separate text file, may be needed.

If you use a code segment that someone else wrote, or that was developed collaboratively, you must acknowledge it. The acknowledgement can be placed in the documentation and should include the origin or the original author’s name. In these resources, comments appear in Marlbridge’s rendering of the reference notation as text between /* and */; the official sheet your teacher provides is the authority for exam notation.

The same habits matter for the Create performance task you complete in class. Keep a record of your design decisions, test cases and sources as you go, and check your teacher’s current task instructions for exactly what is required and what help is allowed.

Worked example 1: sorting a project into phases

Scenario. A student team builds an app that tells people which recycling bin to use. They (1) interview staff at the local recycling centre and watch residents sorting waste, (2) sketch three screens on paper and list the app’s modules (search, results, help), (3) build a version with only the search screen and show it to five residents, (4) discover that residents do not know product names but recognise pictures, (5) change the design so that users can search by choosing a picture, and (6) build the results screen next, only after the search screen works.

Task. Name the phase of each numbered activity, then say where the process is iterative and where it is incremental.

Step 1: classify.

Activity	Phase	Why
1 Interviews and observation	Investigating and reflecting	Direct observation and interviews gather the needs of users
2 Sketching screens, listing modules	Designing	Storyboarding and organising into modules
3 Building the search screen and showing residents	Prototyping (and a first test)	An early, partial version tried out
4 Finding residents prefer pictures	Testing / reflecting	The result of user testing
5 Changing the design	Designing (again)	Going back to an earlier phase
6 Building the results screen after the search screen works	Prototyping	Next piece, built only once the previous one works

Step 2: iterative. Activity 5 returns to design because of feedback from testing. That is iterative.

Step 3: incremental. Building one screen at a time and moving on only when it works (activities 3 and 6) is incremental.

Check. The process is both iterative and incremental, and it is not a strict one-way sequence. A common error is to call the whole project “incremental” because it has steps; the test is whether each piece is verified before the next is added.

Worked example 2: documenting and acknowledging code

Scenario. A student writes a code segment that finds the average of a list of quiz scores. The idea of checking that the list is not empty came from a classmate, Priya Nair. The student writes:

/* Purpose: displays the average of the quiz scores in the list scores.
   Idea for the empty-list check came from Priya Nair (classmate). */
IF (LENGTH(scores) > 0)
{
  total ← 0
  FOR EACH s IN scores
  {
    total ← total + s
  }
  DISPLAY(total / LENGTH(scores))
}
ELSE
{
  DISPLAY("No scores yet")
}

Task. Explain what the comment does and does not do, and say whether the acknowledgement is adequate.

Step 1: what the comment does. It states the purpose of the segment in plain words and records where an idea came from. A reader who skips the code still learns what it is for.

Step 2: what it does not do. It does not change how the program runs: if every comment were deleted, the output would be identical.

Step 3: is the acknowledgement adequate? It names the origin (a classmate, by name) and what was borrowed (the empty-list check). That meets the requirement that an acknowledgement include the origin or author. If the student had copied several lines from a website, a good acknowledgement would name the site or author and say which lines.

Step 4: improve. A strong comment would also explain why the check exists (“avoids dividing by zero when no scores have been entered”), since explaining why is more useful to a future reader than repeating what the statement already says.

Check. The comment describes the segment; it does not claim anything the code does not do.

Choosing a process for a project

Neither an ordered nor an exploratory process is better in every case. An ordered and intentional process suits a project where requirements are clear and mistakes are costly, such as software for a medical device: plan carefully and check each step. An exploratory process suits a project where the best idea is not yet known, such as a new game or an art tool: try things, discard what does not work and keep what does. Exploration leaves room for experimentation and risk-taking, which can lead to ideas that careful planning would not have produced, but it makes a schedule harder to predict.

Many real projects start exploratory (to learn what users want) and become more ordered as the requirements settle. Whichever is used, the same four kinds of activity appear, and iterative and incremental habits help: revise from feedback, and add only pieces that work. When a question asks you to recommend an approach, tie the recommendation to a feature of the scenario, such as unclear requirements or high cost of failure, and not to a general preference.

Common misconceptions

• “Development is a straight line: plan, code, test, done.” Real processes loop back. Testing can send you back to design.
• “Iterative and incremental mean the same.” Iterative refines through feedback; incremental adds small working pieces.
• “Prototyping and testing are the same.” A prototype is an early version; testing is checking it with defined inputs or users.
• “Comments make a program run differently or faster.” Comments are for people and do not affect execution.
• “Documentation is something you do at the end.” It should be written throughout development.
• “Acknowledgement is only needed for large copied programs.” Any code segment developed by someone else, or collaboratively, should be acknowledged.
• “Requirements are the same as the design.” Requirements say what the program must do; the design says how.

Where this leads

Topic 1.4 takes the testing phase further: how to choose test inputs, and how to find and fix different kinds of error. Practise this topic with the practice questions, recap with the revision notes, and review your skills on the checklist. The next topic is Identifying and Correcting Errors.