Introduction to Program Design and Development

Welcome! In this chapter, we are exploring the "behind-the-scenes" work of making a computer program. If you have ever tried to build something complex—like a massive Lego set or a multi-course dinner—you know that jumping in without a plan usually leads to a mess. In Computer Science, we use a structured process called Program Design and Development to turn a cool idea into a working reality. Whether you are aiming for a career in software engineering or just preparing for your Create Performance Task, understanding these steps will make your life much easier!

The Development Process: Step-by-Step

Programs don't just appear out of nowhere. They are created through a series of intentional steps. Most developers use a process that is both iterative and incremental.

1. Iterative Development: This means you repeat steps as you learn more. You might design, code, and test, then realize you need to go back and change the design. It is a cycle of continuous improvement!
2. Incremental Development: This means you break the program into small parts and build them one at a time. Instead of trying to code a whole video game at once, you might start by just making the character move, then adding jumping, then adding enemies.

Analogy: Think of it like writing a research paper. You don't just write the final version in one go. You brainstorm (investigate), outline (design), write a rough draft (prototype), and edit (test/refine). That is an iterative process!

Phase 1: Investigating and Defining

Before you write a single line of code, you have to understand the problem. This involves investigating the situation to see what is needed. Developers often consult with users to find out what they want the program to do.

Key terms to know:
Program Requirements: These are the "must-haves." What are the specific goals of the program?
Specifications: These are the technical details. For example, "The program must accept a numerical input between \(1\) and \(100\)."

Phase 2: Designing the Program

This is where you plan the "how." You decide how the data will be organized and how the user will interact with the program. This often includes User Interface (UI) design—deciding where buttons go, what colors to use, and how the screens flow together. A good design makes a program easy and intuitive to use.

Phase 3: Prototyping and Developing

A prototype is a "rough draft" of your program. It might not have all the features yet, but it allows you to see if your main idea works. During this phase, you write program statements (the actual code) to handle the logic of your software.

Phase 4: Testing

In this phase, you run the program to see if it actually works the way you planned. You use test cases to check if the program handles different types of inputs correctly. (We cover how to fix the bugs you find in the chapter Identifying and Correcting Errors).

Key Takeaway: Developing a program is a cycle. You investigate, design, build a little, test it, and then repeat the process until the program is finished.

Program Inputs and Outputs

Every program works by taking something in (input) and giving something back (output). The "behavior" of a program is how it responds to these inputs.

Where do Inputs come from?

Inputs can be triggered in many ways:
From Users: Clicking a button, typing text, or using a touch screen (tactile).
From Devices: Sensors like a GPS, a microphone (audio), or a camera (visual).
From Other Programs: One program might send data to another program to process.

Many modern programs are event-driven. This means the program sits and waits for an "event" to happen (like a mouse click or a key press) before it executes a specific piece of code.

Documentation and Comments

Have you ever looked at code you wrote a month ago and thought, "What was I thinking?" That is why documentation is so important!

Program Documentation: This is a written description of how a program works, how to use it, or how it was built. It helps other people (and your future self) understand the logic of the code.
Comments: These are "notes" written directly inside the program code. The computer ignores them—they are only there for humans to read.

Why use documentation?
• It makes it easier to fix errors (debugging).
• It helps when collaborating with others.
• It helps you remember the purpose of complex code segments.

Quick Tip: For your AP Create Performance Task, you will be required to explain how your code works. Good documentation during the development process makes this much easier!

Quick Review: Common Pitfalls to Avoid

Don't skip the design phase! Students often want to start coding immediately, but a lack of planning leads to more errors later.
Don't build everything at once. Use the incremental approach. Get one small feature working perfectly before moving to the next.
Remember the user. A program might have "perfect" code, but if the user interface is confusing, the program is not successful.

Chapter Summary

• Program development is iterative (repeating steps) and incremental (building in pieces).
• The process involves investigating, designing, prototyping, and testing.
Requirements define what the program needs to do.
Inputs can come from users, sensors, or other programs.
Documentation and comments are essential for understanding and maintaining code.

Note: To learn more about working with others during this process, see the chapter "Collaboration and Diverse Perspectives." To learn about what happens when things go wrong, see "Identifying and Correcting Errors."