1.3 Program Design and Development

There's no single correct way to build a program. Some teams follow a careful plan; others explore and experiment first. But most processes include the same phases:

• Investigating and reflecting: find out what users need and what limits the program has to work within.
• Designing: plan how the program will meet those needs.
• Prototyping: build a working version, often rough at first.
• Testing: check whether it works and whether it meets the needs, then reflect on what to change.

Iterative development means going around the cycle again and again. After testing or getting feedback, you go back to an earlier phase, like redesigning a screen users found confusing, and improve the program. Each pass refines the whole thing.

Incremental development means breaking the program into small pieces and making sure each piece works before adding it to the rest. You might build and test the login screen, then the search feature, then the results page.

The two often go together. You can build in increments and still revise earlier pieces when feedback comes in.

Before designing, developers investigate to learn the program's constraints (limits like budget, deadline, device or data available) and the concerns and interests of the people who will use it. Ways to investigate include surveys, interviews, user testing of a prototype and directly watching people do the task.

What they learn becomes the program requirements: descriptions of what the program must do, including how users will interact with it. The full set of requirements is called the program's specification.

The design phase then plans how to meet the specification. It can include brainstorming, storyboarding screens, sketching the layout of the user interface, splitting the program into modules (separate parts with their own jobs), and planning how it will be tested.

Program documentation is a written description of what a code segment, event, procedure or program does and how it was developed. Comments are documentation written inside the code for people to read. The computer ignores them, so they don't change how the program runs.

Document as you go, not just at the end. Good documentation helps you remember why you wrote something, and it helps teammates understand, fix and extend code they didn't write.

Some programming environments, including some block-based ones, don't support comments. Then you document another way, such as in a separate document.

If you use code that someone else wrote, or code you wrote together with a partner, you must say so. The acknowledgment can go in the documentation, such as a comment, and should name where the code came from or who wrote it.

For the Create task, this includes starter code from your teacher, code from an online example, an API or open-source library, and code produced with a generative AI tool. Using any of these without credit counts as plagiarism, and the penalty is a 0 for the whole Create task, written responses included.