DGB 4: Programming Simple Applications

← Digital Literacy – Year 4

Programming becomes more meaningful when it solves a concrete problem. Students identify a need, define input, processing and output, choose a suitable tool, build a small application and improve it through testing and user feedback.

Curriculum reference

Area	Classification
Competence area	Production
Perspectives	T, I
Focus	Developing simple applications as solutions to everyday problems
Competence	Translate a practical problem into a simple program or web application using input, processing and output, then test and improve it.

Learning objectives

Students can:

formulate a clear problem that can be solved digitally;
choose a suitable programming environment or web technology;
apply the input–process–output model;
plan a simple application before implementation;
use variables, conditions, loops and functions as appropriate;
create simple interactive user interfaces;
develop in small iterations;
design and run meaningful test cases;
debug errors systematically;
evaluate usability and fitness for purpose;
document development from first idea to improved version;
present and explain the final application.

Learning content

From problem to digital solution

Start with the user's need rather than the technology. Define what the application should help someone do, what information it needs and what result it should produce.

Choosing suitable tools

A block-based environment, Python script or simple web application can all be appropriate. Choose according to the task, available time and required interface.

Input, processing and output

The IPO model helps structure an application: collect valid input, process it according to rules and present meaningful output.

Planning applications

Sketch screens, variables, decisions and test examples before coding. Pseudocode and simple wireframes reduce rework.

Typical building blocks

Variables store values, conditions make choices, loops repeat operations and functions group reusable behaviour. Input validation prevents many avoidable errors.

Web applications

HTML can structure an interface, CSS can improve presentation and JavaScript can provide interaction. A simple local webpage can therefore act as a small application without a server.

Iterative development

Build a minimum working version, test it, then add features. Keeping each step small makes progress and errors easier to understand.

Testing and debugging

Test expected use, boundaries and invalid input. Record what was expected, what happened and how the problem was corrected.

Usability and purpose

A correct program can still be difficult to use. Labels, feedback, error messages and simple navigation should support the user.

Classroom activities

Find a problem

Identify a small school or everyday problem that could be supported by software.

Expected outcome: A problem statement.

IPO sketch

Define input, processing and output before coding.

Expected outcome: An application sketch.

Build a mini calculator

Implement a small calculator and add input validation step by step.

Expected outcome: A working calculator.

Web form with feedback

Create a local form that responds directly to user input.

Expected outcome: An interactive page.

Develop a quiz

Plan questions, scoring and feedback, then implement a simple quiz.

Expected outcome: A usable quiz.

Plan with pseudocode

Write the main algorithm and compare it with final code.

Expected outcome: A plan-to-code record.

Create test cases

Test normal, boundary and invalid values.

Expected outcome: A test table.

Improve usability

Ask another student to use the program and revise unclear elements.

Expected outcome: A usability revision.

Peer review an application

Review purpose, correctness, readability and interaction.

Expected outcome: A peer-review sheet.

Present a program or web app

Demonstrate the problem, solution and one design decision.

Expected outcome: A short technical presentation.

Design an everyday tool in a team

Create a prototype such as a converter, planner or checklist.

Expected outcome: A team prototype.

Document before and after

Show how the first version changed through tests and feedback.

Expected outcome: A development log.

Self-check

I can turn a practical problem into a small application plan.
I can use input, processing and output deliberately.
I can implement the necessary programming structures.
I test normal and invalid inputs.
I improve usability as well as correctness.
I can explain how my application developed over several versions.