Glanz: aiMOOC über GPT aiMOOC Action erstellt

2026-10-09T19:35:04Z

aiMOOC über GPT aiMOOC Action erstellt

Neue Seite

{{T}}

'''Anwendungsentwicklung und Softwarequalität – Ein Softwareprojekt fachlich präsentieren'''

{{BR}}
= Einleitung =

'''Zielgruppe:''' Ausbildung zum Fachinformatiker bzw. zur Fachinformatikerin, Fachrichtung Anwendungsentwicklung

'''Lernziel:''' Du kannst ein Softwareprojekt fachlich, verständlich und kritisch präsentieren. Dabei erklärst Du den Nutzen, die Architektur, die Testergebnisse und die offenen Risiken.

'''Praxisfall:''' Du entwickelst einen Prototyp für die Materialreservierung in einer fiktiven Ausbildungswerkstatt.

'''Lernformat:''' Sechs kurze Lerneinheiten, Visualisierungen, Videos, lokaler Python-Code, automatisierte Tests, interaktive Aufgaben und Präsentationstraining.

'''Vorkenntnisse:''' Grundkenntnisse in [[Python]], [[Programmierung]] und [[Softwareentwicklung]].

'''Sicherheit:''' Verwende ausschließlich fiktive Daten und eine lokale, ausdrücklich autorisierte Lernumgebung. Keine Produktivsysteme, fremden Netze, Zugangsdaten oder Kundendaten verwenden. Externe Lernmedien nur nach Freigabe öffnen. Dabei können Verbindungsdaten an die jeweiligen Anbieter übertragen werden.

{{BR}}
== Dein Lernpfad ==

{| class="wikitable"
! Einheit
! Thema
! Ergebnis
|-
| 1
| Projektnutzen
| Problem und Mehrwert erklären
|-
| 2
| Anforderungen
| Anwendungsfall darstellen
|-
n| 3
| Architektur
| Softwareaufbau visualisieren
|-
| 4
| Implementierung
| Lokale Demo ausführen
|-
| 5
| Softwarequalität
| Tests und Daten bewerten
|-
| 6
| Projektpräsentation
| Risiken und Entscheidungen begründen
|}

{{BR}}
= Lerneinheit 1: Projektnutzen verständlich machen =

'''Leitfrage: Welches Problem löst Deine Software?'''

In der fiktiven Ausbildungswerkstatt werden elektronische Bauteile benötigt. Eine Reservierung soll verhindern, dass mehr Material eingeplant wird, als verfügbar ist.

'''Projektziel:''' Ein einfacher Prototyp überprüft eine Reservierungsmenge und berechnet den verbleibenden Bestand.

'''Nutzen:''' Die Reservierungsregeln lassen sich einheitlich anwenden. Fehlerhafte Mengen können früh erkannt werden.

'''Wichtig:''' Das ist ein erwarteter Nutzen. Eine tatsächliche Zeitersparnis müsste erst durch Messungen nachgewiesen werden.

[[Datei:Software Development Life cycle.png|450px|rahmenlos|center]]

''Abbildung: Phasen der Softwareentwicklung. Quelle: Wikimedia Commons, Tazlavi, CC BY-SA 4.0.''

{{BR}}
== Mini-Aufgabe: Der überzeugende Projektsatz ==

'''Basis:''' Formuliere den Projektnutzen in höchstens 25 Wörtern.

'''Hilfe 1:''' Wer verwendet die Software?

'''Hilfe 2:''' Welcher Fehler soll verhindert werden?

'''Hilfe 3:''' Beginne mit „Unsere Anwendung unterstützt ...“.

'''Musterfeedback:''' Eine Aussage wie „Unsere Anwendung prüft Reservierungsmengen und verhindert Buchungen über dem verfügbaren Bestand“ ist nachvollziehbar, weil sie eine konkrete Funktion und deren fachlichen Nutzen verbindet. „Unsere Software ist modern“ bleibt dagegen unbelegt.

{{BR}}
= Lerneinheit 2: Anforderungen und Anwendungsfälle =

'''Leitfrage: Was muss die Anwendung leisten?'''

Die Anwendung soll eine Materialmenge reservieren, sofern genügend Bestand vorhanden ist.

{| class="wikitable"
! Anforderung
! Akzeptanzkriterium
|-
| Material reservieren
| Der neue Bestand ist korrekt berechnet
|-
| Überbuchung vermeiden
| Zu große Mengen werden abgewiesen
|-
| Eingaben prüfen
| Null und negative Mengen werden abgewiesen
|-
| Unbekannte Artikel erkennen
| Die Anwendung meldet einen unbekannten Artikel
|}

'''Projektgrenze:''' Der Prototyp besitzt noch keine Benutzerverwaltung, grafische Oberfläche, Datenbank oder gleichzeitige Mehrbenutzerverarbeitung.

[[Datei:UML Use Case diagram.svg|480px|rahmenlos|center]]

''Abbildung: Allgemeines UML-Anwendungsfalldiagramm als Vergleichsbeispiel. Quelle: Slashme, Wikimedia Commons.''

'''Deine Aufgabe:''' Zeichne ein eigenes [[Anwendungsfalldiagramm]] für die Materialreservierung. Stelle einen Azubi als Akteur und das Reservieren von Material als Anwendungsfall dar.

{{BR}}
= Lerneinheit 3: Die Softwarearchitektur präsentieren =

'''Leitfrage: Welche Bausteine übernehmen welche Aufgaben?'''

[[Softwarearchitektur]] zeigt, wie ein System strukturiert ist und welche Verantwortlichkeiten seine Bausteine besitzen.

Das Beispiel besitzt eine einfache lokale Architektur:

<pre>
AZUBI
|
v
CLI-DEMO
|
v
reservieren()
Geschäftslogik
|
v
Python-Dictionary
Bestand im RAM
</pre>

'''CLI-Demo:''' Zeigt Eingaben und Ergebnisse im Terminal.

'''Geschäftslogik:''' Prüft Mengen und berechnet den neuen Bestand.

'''Datenhaltung:''' Verwendet ein Dictionary im Arbeitsspeicher. Der Bestand wird nicht dauerhaft gespeichert.

[[Datei:Model View Controller.svg|450px|rahmenlos|center]]

''Abbildung: Model-View-Controller als weiterführendes Architekturbeispiel. Unser kleiner Prototyp implementiert dieses Muster nicht. Quelle: MovGP0, CC BY-SA 3.0.''

{{#ev:youtube|https://www.youtube.com/watch?v=KvoBrUd1-5E|500|center}}

''Fachvideo: Simon Brown – The C4 Model for Visualising Software Architecture. Das Video erklärt die Darstellung von Softwarearchitektur auf verschiedenen Abstraktionsebenen.''

'''Merke:''' Zeige in Deiner Präsentation zunächst das Gesamtsystem und danach nur die Architekturdetails, die Deine Entscheidungen erklären.

{{BR}}
== Mini-Aufgabe: Architekturentscheidung ==

'''Anwendung:''' Erkläre in zwei Sätzen, weshalb die Reservierungslogik als eigene Funktion umgesetzt wurde.

'''Hilfe 1:''' Denke an Wiederverwendbarkeit.

'''Hilfe 2:''' Die Funktion kann ohne Benutzeroberfläche getestet werden.

'''Hilfe 3:''' Vergleiche Geschäftslogik und Präsentationsschicht.

'''Musterfeedback:''' Die Trennung ist sinnvoll, weil dieselben fachlichen Regeln unabhängig von einer späteren Oberfläche geprüft werden können. Allerdings sind die Bausteine im Beispiel nur logisch getrennt und befinden sich noch in einer Python-Datei.

{{BR}}
= Lerneinheit 4: Ein lauffähiges Softwareprojekt demonstrieren =

'''Leitfrage: Kannst Du die zentrale Funktion live nachweisen?'''

Die folgende Demonstration läuft mit Python 3 und benötigt keine zusätzlichen Pakete, Datenbanken oder Netzwerkdienste.

'''Vorbereitung:''' Erstelle auf Deinem lokalen Rechner einen neuen, leeren Lernordner. Speichere den folgenden, zuvor geprüften Quelltext als projekt.py. Verwende ausschließlich diese fiktiven Materialdaten.

<syntaxhighlight lang="python">
import sys
import unittest

def reservieren(bestand, artikel, menge):
"""Berechnet neuen Bestand ohne Änderung der Eingabe."""
if type(menge) is not int or menge <= 0:
raise ValueError("Menge muss positiv sein")

if artikel not in bestand:
raise KeyError("Artikel unbekannt")

if menge > bestand[artikel]:
raise ValueError("Bestand reicht nicht aus")

ergebnis = dict(bestand)
ergebnis[artikel] -= menge
return ergebnis

class TestReservierung(unittest.TestCase):

def setUp(self):
self.daten = {"Arduino": 8, "Sensor": 5}

def test_erfolgreiche_reservierung(self):
neu = reservieren(self.daten, "Arduino", 3)
self.assertEqual(neu["Arduino"], 5)

def test_original_bleibt_unveraendert(self):
reservieren(self.daten, "Arduino", 3)
self.assertEqual(self.daten["Arduino"], 8)

def test_ueberbuchung(self):
with self.assertRaises(ValueError):
reservieren(self.daten, "Sensor", 6)

def test_ungueltige_menge(self):
with self.assertRaises(ValueError):
reservieren(self.daten, "Sensor", 0)

def test_unbekannter_artikel(self):
with self.assertRaises(KeyError):
reservieren(self.daten, "Motor", 1)

if __name__ == "__main__":
if sys.argv[1:] == ["--test"]:
unittest.main(argv=[sys.argv[0]], verbosity=2)

elif not sys.argv[1:]:
vorher = {"Arduino": 8, "Sensor": 5}
nachher = reservieren(vorher, "Arduino", 3)
print("Vorher:", vorher)
print("Nachher:", nachher)

else:
print("Aufruf: python projekt.py [--test]")
sys.exit(2)
</syntaxhighlight>

{{BR}}
== Lokale Demo starten ==

Öffne ein Terminal im Lernordner.

'''Demonstration:'''

<pre>
python -I -B projekt.py
</pre>

'''Erwartete Ausgabe:'''

<pre>
Vorher: {'Arduino': 8, 'Sensor': 5}
Nachher: {'Arduino': 5, 'Sensor': 5}
</pre>

'''Automatisierte Tests:'''

<pre>
python -I -B projekt.py --test
</pre>

Bei unverändertem Programm sollten fünf Tests mit „OK“ abschließen.

'''Hinweis:''' Die Option -I aktiviert den isolierten Python-Modus, -B unterdrückt das Schreiben von Bytecode-Dateien. Dieser Modus ist keine vollständige Betriebssystem-Sandbox. Führe ausschließlich vertrauenswürdigen lokalen Beispielcode aus.

[[Datei:Flowchart de.svg|450px|rahmenlos|center]]

''Abbildung: Beispiel zur Darstellung eines Programmablaufs. Quelle: Erik Streb, CC BY-SA 3.0.''

'''Mini-Aufgabe:''' Beschreibe den Ablauf Deiner Funktion als eigenes Flussdiagramm mit Eingabeprüfung, Bestandsprüfung und Ergebnis.

{{BR}}
= Lerneinheit 5: Softwarequalität durch Tests belegen =

'''Leitfrage: Was beweisen Deine Tests tatsächlich?'''

[[Softwarequalität]] umfasst unter anderem korrekte Funktionen, Zuverlässigkeit, Wartbarkeit und Sicherheit.

Ein erfolgreicher Test zeigt, dass das getestete Verhalten unter den jeweiligen Bedingungen dem erwarteten Ergebnis entspricht. Er beweist nicht die allgemeine Fehlerfreiheit.

[[Datei:Testing Pyramid.svg|450px|rahmenlos|center]]

''Abbildung: Testpyramide mit Unit-, Integrations- und End-to-End-Tests. Quelle: Abbe98, CC BY-SA 4.0.''

{{#ev:youtube|https://www.youtube.com/watch?v=6tNS--WetLI|500|center}}

''Fachvideo: Corey Schafer – Python Tutorial: Unit Testing Your Code with the unittest Module.''

{{BR}}
== Testfälle als Qualitätsnachweis ==

{| class="wikitable"
! Test
! Erwartetes Verhalten
! Ebene
|-
| Gültige Reservierung
| Bestand wird korrekt reduziert
| Unit-Test
|-
| Unveränderter Eingabebestand
| Originaldaten bleiben erhalten
| Unit-Test
|-
| Überbuchung
| ValueError wird ausgelöst
| Unit-Test
|-
| Ungültige Menge
| Null wird abgewiesen
| Unit-Test
|-
| Unbekannter Artikel
| KeyError wird ausgelöst
| Unit-Test
|}

'''Wichtig:''' Die fünf Tests prüfen nur einzelne Aspekte der lokalen Geschäftslogik. Integrationstests, Oberflächentests, Lasttests und Sicherheitstests fehlen.

{{BR}}
== Daten visualisieren ==

Die folgende Visualisierung verwendet ausschließlich fiktive Werte aus dem Programmbeispiel.

<pre>
Bestand in Stück

Arduino vorher ████████ 8
Arduino nachher █████ 5

Sensor vorher █████ 5
Sensor nachher █████ 5

Reserviert: 3 Arduino
</pre>

'''Interpretation:''' Der Arduino-Bestand sinkt um drei Stück. Der Sensor-Bestand bleibt unverändert.

'''Präsentationstipp:''' Zeige zu jeder Grafik die Ausgangsdaten, die Veränderung und die fachliche Bedeutung.

{{BR}}
== Mini-Aufgabe: Fehler gezielt erzeugen ==

'''Anwendung:''' Ändere in einer lokalen Kopie der Funktion die Berechnung von

<code>ergebnis[artikel] -= menge</code>

zu

<code>ergebnis[artikel] += menge</code>

Führe die Tests erneut aus und stelle anschließend die richtige Berechnung wieder her.

'''Hilfe 1:''' Welcher Test prüft den Bestand nach einer gültigen Reservierung?

'''Hilfe 2:''' Vergleiche das erwartete Ergebnis mit dem tatsächlich berechneten Wert.

'''Hilfe 3:''' Der Wert muss nach einer Reservierung kleiner werden.

'''Begründetes Feedback:''' Wenn der Erfolgstest jetzt fehlschlägt, hat die Testsuite den eingebauten Rechenfehler erkannt. Die übrigen Tests können trotzdem bestehen, weil sie andere Eigenschaften prüfen. Genau deshalb sind gezielt ausgewählte Testfälle wichtig.

{{BR}}
= Lerneinheit 6: Offene Risiken fachlich darstellen =

'''Leitfrage: Was kann die Anwendung noch nicht zuverlässig?'''

Ein professioneller Projektabschluss verschweigt keine Grenzen.

[[Datei:Risikomatrix.svg|450px|rahmenlos|center]]

''Abbildung: Risikomatrix. Quelle: Josef Kolerus, CC BY-SA 4.0.''

{| class="wikitable"
! Offenes Risiko
! Auswirkung
! Nächste Maßnahme
|-
| Gleichzeitige Reservierungen
| Mögliche widersprüchliche Bestände
| Zentrale Speicherung mit geeigneter Transaktionskontrolle
|-
| Fehlende dauerhafte Speicherung
| Bestand geht nach Programmende verloren
| Persistenz und Wiederherstellung konzipieren
|-
| Fehlende Rollenverwaltung
| Keine geregelten Berechtigungen
| Authentifizierung und Autorisierung planen
|-
| Unvollständige Testabdeckung
| Unentdeckte Fehler sind möglich
| Weitere Grenz-, Integrations- und Systemtests
|}

'''Risikobewertung:''' Priorisiere Risiken nach ihrer geschätzten Eintrittswahrscheinlichkeit und Auswirkung. Die Priorität ist eine begründete Einschätzung, kein bereits gemessener Wert.

{{BR}}
== Transferaufgabe: Der gleichzeitige Zugriff ==

Zwei Azubis möchten gleichzeitig die letzten verfügbaren Sensoren reservieren.

'''Aufgabe:''' Erkläre, warum die bisherige Dictionary-Lösung für einen Mehrbenutzerbetrieb nicht ausreicht.

'''Hilfe 1:''' Wo befinden sich die Daten?

'''Hilfe 2:''' Was geschieht, wenn zwei Vorgänge denselben Ausgangsbestand verwenden?

'''Hilfe 3:''' Denke an gemeinsame Speicherung und atomare Buchungen.

'''Begründetes Feedback:''' Eine überzeugende Lösung benennt das Risiko widersprüchlicher Buchungen und schlägt Transaktionen oder eine vergleichbare Synchronisierung vor. Zusätzliche Unit-Tests allein lösen das Problem nicht, weil auch die Architektur des Mehrbenutzerbetriebs angepasst werden muss.

{{BR}}
= Ein Softwareprojekt überzeugend präsentieren =

'''Deine Leitstruktur: Problem – Nutzen – Architektur – Nachweis – Risiko – Ausblick'''

Die folgende Zeiteinteilung ist eine siebenminütige Übungspräsentation, keine verbindliche Prüfungszeit.

{| class="wikitable"
! Zeitfenster
! Inhalt
! Geeignetes Medium
|-
| 0:00–0:45
| Ausgangslage und Ziel
| Problem-Nutzen-Folie
|-
| 0:45–2:00
| Anforderungen
| Anwendungsfalldiagramm
|-
| 2:00–3:15
| Architektur und Entscheidung
| Bausteindiagramm
|-
| 3:15–4:45
| Lokale Demo und Tests
| Terminal und Testtabelle
|-
| 4:45–6:00
| Offene Risiken
| Risikomatrix
|-
| 6:00–7:00
| Ergebnis und nächste Schritte
| Zusammenfassung
|}

{{#ev:youtube|https://www.youtube.com/watch?v=pJc0l2DASpo|500|center}}

''Fachvideo: Mark Richards – Lesson 31: Presenting Architecture.''

'''Präsentationsregel:''' Zeige keine langen Quelltextseiten. Erkläre eine zentrale Funktion, führe einen Test vor und begründe Deine technischen Entscheidungen.

Die IHK betont für die Projektpräsentation insbesondere die adressatengerechte Darstellung von Arbeitsergebnissen und die Begründung des Vorgehens. Beachte immer die aktuell geltenden Vorgaben Deiner zuständigen IHK.

{{BR}}
== Beispiel für Deinen Einstieg ==

„In unserer fiktiven Ausbildungswerkstatt sollen elektronische Bauteile zuverlässig reserviert werden. Ich habe dafür einen Python-Prototyp entwickelt, der gültige Reservierungen verarbeitet und unzulässige Mengen abweist. Ich erläutere Ihnen den Aufbau, die automatisierten Tests und die noch offenen Risiken.“

{{BR}}
== Checkliste für die Präsentation ==

# [[Zielgruppenanalyse]]: Ist klar, für wen Du präsentierst?
# [[Anforderungsanalyse]]: Ist das Ausgangsproblem verständlich?
# [[Softwarearchitektur]]: Werden wichtige Bausteine und Entscheidungen erklärt?
# [[Softwaretest]]: Zeigst Du nachvollziehbare Testnachweise?
# [[Risikomanagement]]: Benennst Du Grenzen und konkrete Maßnahmen?
# [[Präsentationstechnik]]: Sind Grafiken lesbar, Aussagen präzise und Medien rechtlich geklärt?

{{BR}}
= Interaktive Aufgaben =

{{BR}}
== Quiz: Teste Dein Wissen ==

{{MC}}

'''Welche Aussage beschreibt den fachlichen Nutzen des Projekts am besten?'''
(Reservierungen werden auf verfügbaren Bestand geprüft)
(!Das Projekt verwendet eine Programmiersprache)
(!Das Programm enthält mehrere Funktionen)
(!Die Anwendung startet im Terminal)

{{E}}
<br>

{{MC}}

'''Welche Funktion gehört zur Geschäftslogik?'''
(Prüfung und Berechnung einer Reservierung)
(!Anzeige eines Firmenlogos)
(!Gestaltung einer Präsentationsfolie)
(!Auswahl der Hintergrundfarbe)

{{E}}
<br>

{{MC}}

'''Was beschreibt eine Projektgrenze?'''
(Die Anwendung unterstützt noch keinen Mehrbenutzerbetrieb)
(!Die Anwendung besitzt alle denkbaren Funktionen)
(!Das Projekt hat grundsätzlich keine Risiken)
(!Die Software benötigt niemals Wartung)

{{E}}
<br>

{{MC}}

'''Was ist ein Ziel eines Architekturdiagramms?'''
(Bausteine und ihre Beziehungen verständlich darstellen)
(!Jede Quelltextzeile vollständig abbilden)
(!Sämtliche Testergebnisse ersetzen)
(!Alle Risiken automatisch beseitigen)

{{E}}
<br>

{{MC}}

'''Warum erstellt die Funktion eine Kopie des Bestands?'''
(Die ursprünglichen Eingabedaten bleiben unverändert)
(!Das Programm benötigt dadurch eine Datenbank)
(!Alle Reservierungen werden dauerhaft gespeichert)
(!Die Anwendung wird automatisch mehrbenutzerfähig)

{{E}}
<br>

{{MC}}

'''Welcher Aufruf startet die fünf lokalen Unit-Tests?'''
(python -I -B projekt.py --test)
(!python -I -B projekt.py --server)
(!python -I -B projekt.py --deploy)
(!python -I -B projekt.py --network)

{{E}}
<br>

{{MC}}

'''Was erwartet der Test bei einer Reservierung über dem verfügbaren Bestand?'''
(Einen ValueError)
(!Eine erfolgreiche Reservierung)
(!Eine automatische Bestandserhöhung)
(!Eine Verbindung zu einem Webserver)

{{E}}
<br>

{{MC}}

'''Was lässt sich aus fünf erfolgreichen Unit-Tests schließen?'''
(Die fünf geprüften Verhaltensweisen entsprachen den Erwartungen)
(!Die Software ist vollständig fehlerfrei)
(!Alle Sicherheitsrisiken wurden beseitigt)
(!Die Software ist für den Produktivbetrieb freigegeben)

{{E}}
<br>

{{MC}}

'''Welches Risiko besteht bei gleichzeitigen Reservierungen?'''
(Widersprüchliche Bestände durch konkurrierende Zugriffe)
(!Automatisch vollständige Datensicherung)
(!Grundsätzlich fehlerfreie Buchungen)
(!Garantiert bessere Systemleistung)

{{E}}
<br>

{{MC}}

'''Wie gehst Du bei einer professionellen Projektpräsentation mit offenen Risiken um?'''
(Du erläuterst Auswirkungen und geeignete nächste Maßnahmen)
(!Du verschweigst alle noch vorhandenen Probleme)
(!Du ersetzt fehlende Tests durch Werbeaussagen)
(!Du erklärst den Prototyp ungeprüft zum fertigen Produkt)

{{E}}
<br>

{{BR}}
== Memory ==

Ordne die Begriffe ihren fachlich passenden Bedeutungen zu.

<div class="memo-quiz">
{|
|-
| Projektnutzen || Mehrwert für die Zielgruppe
|-
| Anwendungsfall || Ablauf aus Sicht eines Nutzers
|-
| Geschäftslogik || Fachliche Regeln einer Anwendung
|-
| Unit-Test || Einzelprüfung einer Softwareeinheit
|-
| Grenzfall || Eingabe am Rand eines gültigen Bereichs
|-
| Restrisiko || Nach Maßnahmen verbleibende Gefährdung
|}
{{E}}
<br>

{{BR}}
== Drag and Drop ==

Ordne die Projektbegriffe den richtigen Beschreibungen zu.

<div class="lueckentext-quiz">

{| class="wikitable"
! Ordne die richtigen Begriffe zu.
! Thema
|-
| '''Bedarfsanalyse'''
| Problem der Ausbildungswerkstatt
|-
| '''Softwareentwurf'''
| Verantwortlichkeiten der Bausteine
|-
| '''Implementierung'''
| Entwicklung einer lauffähigen Funktion
|-
| '''Verifikation'''
| Abgleich mit erwarteten Testergebnissen
|-
| '''Risikobewertung'''
| Untersuchung möglicher negativer Auswirkungen
|}
{{E}}

<br>

{{BR}}
== Kreuzworträtsel ==

<div class="kreuzwort-quiz">
{|
|-
| Nutzen || Wie heißt der fachliche Mehrwert eines Projekts?
|-
| Architektur || Wie heißt die grundlegende Struktur eines Softwaresystems?
|-
| Unittest || Wie nennt man die automatisierte Prüfung einer einzelnen Softwareeinheit?
|-
| Risiko || Welcher Begriff bezeichnet die Möglichkeit eines unerwünschten Ereignisses?
|-
| Prototyp || Wie heißt eine vorläufige Ausführung zur Erprobung einer Lösung?
|-
| Bestand || Wie heißt die verfügbare Menge von Material?
|}
{{E}}
<br>

{{BR}}
== LearningApps ==

Nutze die thematische Suche nach weiteren Lernübungen. Externe Angebote nur mit Freigabe öffnen und dort keine persönlichen oder betrieblichen Daten eingeben.

<iframe> https://learningapps.org/index.php?s=Anwendungsentwicklung+und+Softwarequalität+Ein+Softwareprojekt+fachlich+präsentieren </iframe>

{{BR}}
== Lückentext ==

<quiz display=simple>
{'''Vervollständige den Text.'''<br>
|type="{}"}
Im Ausbildungsbeispiel wird eine einfache { Materialreservierung } entwickelt.

Der fachliche { Nutzen } beschreibt den Mehrwert des Softwareprojekts.

Ein { Anwendungsfall } verdeutlicht eine Funktion aus Nutzersicht.

Die { Softwarearchitektur } beschreibt den grundlegenden Aufbau des Systems.

Eine eigene Funktion verarbeitet die { Geschäftslogik } der Reservierung.

Das Python-Programm speichert seinen aktuellen Datenbestand im { Arbeitsspeicher }.

Automatisierte Einzeltests heißen auch { Unit-Tests }.

Die fünf Beispieltests werden mit dem Framework { unittest } ausgeführt.

Eine erfolgreiche Testsuite beweist nicht die vollständige { Fehlerfreiheit } einer Anwendung.

Gleichzeitige Zugriffe können zu widersprüchlichen { Beständen } führen.

Die Bewertung offener Risiken berücksichtigt deren mögliche { Auswirkungen }.

Eine überzeugende Projektpräsentation begründet technische { Entscheidungen }.
</quiz>

<br>

{{BR}}
= Offene Aufgaben =

Bearbeite die Aufgaben in aufsteigender Schwierigkeit. Verwende für praktische Versuche ausschließlich lokale Kopien und fiktive Daten.

{{BR}}
=== Leicht – Basisaufgaben ===

# [[Projektnutzen]]: Gestalte eine Folie, die Ausgangslage, Zielgruppe und erwarteten Nutzen der Materialreservierung erklärt.
# [[Anwendungsfall]]: Zeichne ein einfaches Anwendungsfalldiagramm mit einem Akteur und einer Reservierungsfunktion.
# [[Softwarearchitektur]]: Erstelle ein eigenes Bausteindiagramm aus CLI, Geschäftslogik und Datenhaltung.
# [[Softwaretest]]: Führe die fünf lokalen Tests aus und erstelle einen kurzen Testbericht mit erwarteten und tatsächlichen Ergebnissen.

{{BR}}
=== Standard – Anwendungsaufgaben ===

# [[Präsentationstechnik]]: Erstelle eine dreiminütige Projektpräsentation mit maximal vier inhaltsorientierten Folien.
# [[Testfall]]: Ergänze im lokalen Programm einen Test für eine negative Reservierungsmenge und erkläre das erwartete Ergebnis.
# [[Datenvisualisierung]]: Erstelle eine eigene Grafik zu den fiktiven Bestandsveränderungen und interpretiere sie fachlich.
# [[Softwaredokumentation]]: Produziere ein kurzes Bildschirmvideo der lokalen Demo ohne persönliche Daten, Zugangsdaten oder externe Veröffentlichung.

{{BR}}
=== Schwer – Transferaufgaben ===

# [[Nebenläufigkeit]]: Entwirf eine Architektur für gleichzeitige Reservierungen und begründe den Einsatz geeigneter Transaktionsmechanismen.
# [[Risikomanagement]]: Entwickle eine Risikomatrix für eine spätere Mehrbenutzerversion und priorisiere drei Verbesserungen.
# [[Qualitätssicherung]]: Entwirf einen Testplan für eine zukünftige Version mit Datenbank, Benutzerverwaltung und Oberfläche.
# [[Fachgespräch]]: Simuliere ein Prüfungsgespräch mit einer anderen Person, zeichne die Antworten nach Einwilligung lokal auf und verbessere Deine Argumentation.

{{BR}}
== Selbstkontrolle und begründetes Feedback ==

{| class="wikitable"
! Niveau
! Prüffrage
! Begründetes Feedback
|-
| Basis
| Wird ein konkreter Nutzen genannt?
| Gut ist ein überprüfbarer Zusammenhang zwischen Problem und Lösung. Allgemeine Werbeaussagen sind kein fachlicher Nachweis.
|-
| Anwendung
| Stimmen Demo, Grafik und Tests überein?
| Gut ist eine konsistente Darstellung von Eingaben, erwarteten Ergebnissen und beobachtetem Verhalten. Widersprüche müssen untersucht werden.
|-
| Transfer
| Werden Architekturentscheidung und Restrisiko begründet?
| Gut ist eine Lösung, die Auswirkungen, Alternativen und technische Grenzen einbezieht. Eine bloße Aufzählung von Technologien genügt nicht.
|}

{{:Offene Aufgabe - MOOC erstellen}}

{{BR}}
= Lernkontrolle =

Die Lernkontrolle prüft vor allem Zusammenhänge, Begründungen und die Übertragung auf neue Situationen.

# [[Wirtschaftlichkeit]]: Erkläre, wie Du den behaupteten Zeitgewinn einer Materialreservierung in einem späteren Pilotversuch fair messen würdest.
# [[Softwarearchitektur]]: Begründe, weshalb die lokale Dictionary-Lösung für einen Prototyp ausreichen kann, für den dauerhaften Mehrbenutzerbetrieb jedoch nicht.
# [[Teststrategie]]: Zeige anhand zweier zusätzlicher Tests, wie Du die bisherige Absicherung sinnvoll erweiterst, und erkläre die Grenzen dieser Tests.
# [[Fehleranalyse]]: Untersuche die Folgen einer versehentlich addierten statt subtrahierten Reservierungsmenge und beschreibe, wie Tests den Fehler sichtbar machen.
# [[Risikomanagement]]: Priorisiere fehlende Persistenz, fehlende Berechtigungen und konkurrierende Buchungen für einen geplanten Einsatz und begründe Deine Reihenfolge anhand eines konkreten Nutzungsszenarios.
# [[Projektpräsentation]]: Erkläre die gleiche Architektur einmal gegenüber einem Ausbilder mit technischem Hintergrund und einmal gegenüber einer fachlichen Leitung ohne Programmierkenntnisse.

<br>
<br>

{{BR}}
= Lernnachweis =

Für einen aussagekräftigen Lernnachweis reichst Du folgende eigene Arbeitsergebnisse ein:

# Eine Problem- und Nutzenbeschreibung mit prüfbarem Projektziel.
# Ein Anwendungsfall- und ein vereinfachtes Architekturdiagramm.
# Den lokal ausgeführten Python-Prototyp mit fiktiven Beispieldaten.
# Ein dokumentiertes Testprotokoll einschließlich mindestens eines untersuchten Fehlers.
# Eine selbst erstellte Datenvisualisierung mit fachlicher Interpretation.
# Eine priorisierte Übersicht offener Risiken und geeigneter Maßnahmen.
# Eine kurze, adressatengerechte Projektpräsentation mit begründeten Architekturentscheidungen.
# Eine persönliche Reflexion zu Qualitätsnachweisen, Grenzen und weiteren Entwicklungsschritten.

'''Bewertungsmaßstab:''' Entscheidend sind fachliche Richtigkeit, Nachvollziehbarkeit, prüfbare Belege, Begründung technischer Entscheidungen und ehrlicher Umgang mit offenen Risiken.

<br>
<br>

{{BR}}
= OERs zum Thema =

{{BR}}
== Wikipedia ==

Der folgende Artikel ergänzt die Grundlagen zur Softwarearchitektur.

<iframe> https://de.m.wikipedia.org/wiki/Softwarearchitektur </iframe>

Weitere geeignete Wikipedia-Themen: [[Softwarequalität]], [[Softwaretest]], [[Unit-Test]], [[Anwendungsfalldiagramm]], [[Softwarearchitektur]] und [[Risikomanagement]].

{{BR}}
== Geprüfte Fachquellen ==

# [https://www.ihk.de/freiburg/fachkraefte-entwickeln/ausbildung/zwischen-und-abschlusspruefungen/zwischen-und-abschlusspruefungen-a-z/fachinformatiker-in-6815514 IHK Südlicher Oberrhein – Fachinformatiker/in]: Anforderungen an Projektpräsentation, Fachgespräch und adressatengerechte Darstellung.
# [https://www.ihk.de/nordwestfalen/bildung/ausbildung/ausbildungsberufe-a-z/handreichung-fachinformatiker-anwendungsentwicklung-6562294 IHK Nord Westfalen – Betriebliche Projektarbeit]: Hinweise zur Projektpräsentation in der Fachrichtung Anwendungsentwicklung.
# [https://docs.python.org/3/library/unittest.html Python-Dokumentation – unittest]: Offizielle Beschreibung automatisierter Unit-Tests.
# [https://docs.python.org/3/using/cmdline.html Python-Dokumentation – Kommandozeilenoptionen]: Beschreibung des isolierten Python-Modus und weiterer Optionen.
# [https://c4model.com/ C4 Model – Simon Brown]: Architekturansichten und verständliche Visualisierung von Softwaresystemen.
# [https://martinfowler.com/articles/practical-test-pyramid.html Martin Fowler – The Practical Test Pyramid]: Fachlicher Hintergrund zu unterschiedlichen Testebenen.
# [https://owasp.org/projects/asvs OWASP ASVS]: Weiterführende Anforderungen zur Sicherheitsprüfung von Webanwendungen.

{{BR}}
== Bildquellen und Medienrechte ==

Die verwendeten Wikimedia-Commons-Dateien wurden anhand ihrer Dateibeschreibungsseiten ausgewählt. Beachte bei Weiterverwendung insbesondere Namensnennung, Lizenzlink und gegebenenfalls die Weitergabe unter gleichen Bedingungen.

{| class="wikitable"
! Medium
! Urheber
! Lizenz
|-
| [https://commons.wikimedia.org/wiki/File:Software_Development_Life_cycle.png Software Development Life cycle.png]
| Tazlavi
| CC BY-SA 4.0
|-
| [https://commons.wikimedia.org/wiki/File:UML_Use_Case_diagram.svg UML Use Case diagram.svg]
| Slashme
| Unter anderem CC BY-SA und GFDL
|-
| [https://commons.wikimedia.org/wiki/File:Model_View_Controller.svg Model View Controller.svg]
| MovGP0
| CC BY-SA 3.0
|-
| [https://commons.wikimedia.org/wiki/File:Flowchart_de.svg Flowchart de.svg]
| Erik Streb
| CC BY-SA 3.0
|-
| [https://commons.wikimedia.org/wiki/File:Testing_Pyramid.svg Testing Pyramid.svg]
| Abbe98
| CC BY-SA 4.0
|-
| [https://commons.wikimedia.org/wiki/File:Risikomatrix.svg Risikomatrix.svg]
| Josef Kolerus
| CC BY-SA 4.0
|}

Die jeweiligen Datei- und Lizenzseiten enthalten die vollständigen Nutzungsbedingungen. Bei der Verwendung außerhalb von Wikimedia-Projekten müssen die geltenden Lizenzpflichten eingehalten werden.

'''YouTube-Medien:''' Die drei eingebetteten Fachvideos stammen aus konkret recherchierten YouTube-Einträgen. Sie werden lediglich zur Ansicht eingebunden und nicht als offen lizenziert ausgewiesen. Einbettung und Wiedergabe setzen voraus, dass der jeweilige Anbieter dies erlaubt. Keine Videos ungeprüft herunterladen oder weiterverbreiten.

'''Datenschutz und Lernumgebung:''' Externe YouTube-, Wikipedia- und LearningApps-Angebote können Verbindungsdaten verarbeiten. Verwende diese nur nach entsprechender Freigabe. Der lokale Python-Prototyp benötigt selbst keine externe Datenübertragung. Er ist ein Lernbeispiel, kein produktionsreifes Reservierungssystem.

{{BR}}
= Verknüpfte Lernbereiche =

{| align=center
{{:D-Tab}}
'''[[Anwendungsentwicklung]]'''
# [[Anforderungsanalyse]]
# [[Anwendungsfalldiagramm]]
# [[Softwarearchitektur]]
# [[Python]]
# [[Programmierung]]
'''[[Softwarequalität]]'''
# [[Qualitätssicherung]]
# [[Softwaretest]]
# [[Unit-Test]]
# [[Testautomatisierung]]
# [[Risikomanagement]]
'''[[Projektmanagement]]'''
# [[Projektplanung]]
# [[Wirtschaftlichkeit]]
# [[Softwaredokumentation]]
# [[Projektpräsentation]]
# [[Fachgespräch]]
'''[[IT-Sicherheit]]'''
# [[Datenschutz]]
# [[Zugriffskontrolle]]
# [[Datenintegrität]]
# [[Nebenläufigkeit]]
|}

[[Kategorie:Informatik]]
[[Kategorie:Anwendungsentwicklung]]
[[Kategorie:Softwareentwicklung]]
[[Kategorie:Softwarequalität]]
[[Kategorie:Softwaretest]]
[[Kategorie:Softwarearchitektur]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Berufsausbildung]]
[[Kategorie:Fachinformatiker]]
[[Kategorie:Präsentation]]

{{BR}}
= aiMOOC-Projekte =

[[Kategorie:AI_MOOC]] [[Kategorie:GPT aiMOOC]]
{{MT}}

Anwendungsentwicklung und Softwarequalität – Ein Softwareprojekt fachlich präsentieren - Versionsgeschichte

Glanz: aiMOOC über GPT aiMOOC Action erstellt