Input, Process and Output

One-sentence summary

Almost every program and robot takes in some information (input), works on it (process) and produces a result (output).

Why does it matter?

When we want to understand what a program does, we can ask three questions: What does it take in? What does it do with it? What does it give back? These three parts together are called the input–process–output model. Because the English words are Input, Process and Output, it is often shortened to IPO.

This model looks simple, but it is powerful. From a calculator to a robot vacuum, you can split almost any system into these three boxes. Breaking a messy problem into these three parts shows you where to begin.

What are input, process and output?

Three boxes

Think of a system as a single box. Information enters from the left, something happens inside, and a result comes out on the right.

[ Input ]  ->  [ Process ]  ->  [ Output ]

• Input: The information the program takes in from outside. A number typed on a keyboard, a distance measured by a sensor, a button press.
• Process: The calculation or decision made with the input. Adding, comparing, or rules like "if this value is small, do that."
• Output: The result of the process. A message on the screen, a lit LED, a spinning motor.

Everyday example: A toaster

Think about a toaster. The input is the bread you put in and the browning time you choose. The process is the wire heating up and cooking the bread for that time. The output is the toasted bread that pops out. Change the time (the input) and the output changes too.

Everyday example: An automatic door

An automatic door at a shop uses the same model. The input is someone stepping in front of the motion sensor. The process is the decision "if the sensor sees someone, open the door." The output is the door opening. When no one is there, there is no input, so the door stays closed.

IPO in robotic systems

Robots show this model very clearly. We can split a robot into three parts:

Example: Distance sensor → decision → motor

Imagine a robot that avoids obstacles. The sensor (input) measures the distance ahead, the control board (process) makes a decision, and the motor (output) acts on it.

Start
distance ← read from front sensor
If distance is less than 10 centimetres
    stop the motors
    turn on the red LED
Otherwise
    move forward
End

Here the input is distance, the process is the If ... Otherwise decision, and the output is the motor and the LED. The comparison operator you met in the previous lesson (<) is used exactly at this decision point.

Validating the input

We cannot assume the input always arrives the way we expect. A user might type the wrong thing, or a sensor might read a broken value. That is why a good program validates its input: it checks whether the input makes sense before using it.

Example: we want to ask the user for an age and print its double. But if the user types a letter instead of a number, the program crashes. We should first check whether the input is really a number.

text = input("Enter a number: ")

if text.isdigit():
    number = int(text)
    print("Double:", number * 2)
else:
    print("Please enter digits only.")

This program has all three parts: the input is input, the process is number * 2, and the output is print. The extra line if text.isdigit() is the input validation. We only do the calculation for valid input; otherwise we give a friendly warning.

Mini practice

Write the task below in Python, or design it first as pseudocode.

Make a "ticket price" program:

1. Take the user's age as input.
2. Check that the input is a digit (validation).
3. If the age is under 12, print "Child ticket: 50 TL"; otherwise print "Full ticket: 100 TL".

When you finish, ask yourself: What is my program's input, process and output? What happens if the input is wrong?

Practice lab: Input, Process and Output

The best way to retain Input, Process and Output is to turn the idea into a small, measurable task. In this activity you will connect What are input, process and output? with Everyday example: A toaster and produce a clear algorithm, pseudocode and a test table. The aim is not only to make the result work. You should also be able to explain why you made each decision, what you tested and which observation would make you revise the design.

Challenge scenario

Work with this scenario: a decision flow that counts repetitions in a sports drill. Because the main goal of the lesson is to “Learn the input–process–output model and how sensors, control and outputs connect”, begin by defining the problem in one sentence. Then write the input, the process and the output separately. Mark anything you do not know as an assumption rather than presenting it as a fact.

1. Plan: Record the starting state, expected result and the concepts you will use.
2. Build the smallest version: Make only the essential behaviour work before adding decoration or extra features.
3. Prepare three tests: Choose a normal case, a boundary case and an invalid or unexpected case.
4. Record the result: Put the expected and actual results side by side and name a likely cause when they differ.
5. Change one thing: Revise one decision and repeat the test instead of changing several parts at once.

Success criteria

• Are the steps clear and unambiguous?
• Are the start and finish conditions defined?
• Were normal, boundary and invalid cases tested?
• Is there an unnecessary step or repetition?
• Can another person follow the algorithm and obtain the same result?

After completing “Input, Process and Output”, explain the work to a classmate using only the section headings. If the classmate can follow the decisions in the scenario of a decision flow that counts repetitions in a sports drill, the explanation is clear enough. Fix an unclear point by dividing the relationship between What are input, process and output? and Everyday example: A toaster into smaller steps rather than adding jargon.

Common mistakes

Not checking the input

Assuming the user will always enter good data is the most common mistake. If a letter reaches an int(input(...)) line, the program throws an error and stops. Validating first makes the program sturdy.

Not thinking about the output format

Producing the right result is not enough; you also have to show it clearly. Instead of printing 72000000, a message like "Double: 72" is better. Output is written for the person reading it.

Confusing input with output

A sensor is an input, a motor is an output. Mixing them up blurs the question "what does the system take in and what does it produce?" Always think about which direction the information flows.

Safety note

When you test the output of a motorised, electronic system, place the robot on a fixed surface with its wheels off the ground; it may move unexpectedly on the first try. Make motor, battery and circuit connections together with an adult, and never work with mains electricity.

Lesson summary

• Almost every system splits into three parts: input, process and output (the IPO model).
• Input is information from outside; process is the calculation or decision made with it; output is the result produced.
• In robotics the sensor is the input, the control board is the process, and the motor/LED/screen is the output.
• A good program validates its input before using it.
• Output should be prepared in a form that is clear to the person reading it.

Check questions

1. What are the three parts of the IPO model?
2. Which part of the IPO model does a distance sensor match?
3. Is a motor in a robot an input or an output? Why?
4. What does validating the input mean, and why is it important?
5. What happens if the user types "abc" into the line int(input("Number: "))?

Answers

1. Input (information taken in from outside), process (the calculation or decision made with it), and output (the result produced).
2. It matches the input; a sensor gathers information from the outside world.
3. It is an output; the motor turns the result of the program's decision into physical movement, producing a result for the outside world.
4. Validating the input means checking whether it is sensible and of the expected type before using it. It matters because bad input can crash the program or make it produce a wrong result.
5. The program throws an error and stops, because "abc" cannot be converted to a whole number. That is why we should validate the input first.

Source and verification note

For “Input, Process and Output”, verification focuses on whether the relationship between What are input, process and output? and Everyday example: A toaster remains consistent across examples. The algorithms in this lesson are checked by tracing sample inputs by hand and comparing them with expected outputs. Pseudocode is used to make the reasoning sequence visible without tying it to one programming language.

Next lesson

Writing Pseudocode: We learn how to describe a problem in clear, ordered steps before moving to a programming language.