Administrator: Add English DGB 4 translation

2026-09-11T18:09:10Z

Add English DGB 4 translation

Neue Seite

{{DISPLAYTITLE:DGB 4: Programming Simple Applications}}
← [[DGB 4. Klasse/en|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 ==

{| class="wikitable"
! 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.

== See also ==

[[DGB 4: Programme und Kontrollstrukturen/en|Designing Programs with Combined Control Structures]]
[[DGB 4: Kreative Zusammenarbeit/en|Creative Collaboration with Media and Software Tools]]
[[DGB 4: Abstraktionsebenen und Softwareschichten/en|Application Software, System Software and Hardware Layers]]

[[Kategorie:Digitale Grundbildung]]
[[Kategorie:DGB 4]]

DGB 4: Programme und Webanwendungen/en - Versionsgeschichte

Administrator: Add English DGB 4 translation