Zum Inhalt springen

Technische Probleme in Softwareprojekte übersetzen

Aus MOOCsWiki Staging
Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.
aiMOOC-Siegel aiMOOC

Technische Probleme in Softwareprojekte übersetzen

QR-Code


Einleitung

Zielgruppe: Auszubildende im 1. bis 2. Ausbildungsjahr. Voraussetzungen: Dateien, einfache Tabellen und Einheiten wie Millimeter verstehen; keine Programmierkenntnisse. Zeitbedarf: vier bis sechs Lernstunden plus Ausarbeitung. Alle Aufgaben gehen offline mit Papier oder lokalem Texteditor und ohne bezahltes KI-Konto.

Lernprodukt: eine Anforderungsskizze einer Messwertprüfung für eine rein lokale, simulierte App. Du formulierst Anforderungen, zerlegst Arbeit und definierst überprüfbare Ziele. Am Ende kannst du einen Normalfall, einen Fehlerfall und eine vom eingesetzten Tool unabhängige Abnahme selbst begründen.

Vorwissen aktivieren: Öffne nach Möglichkeit die bereits vorhandene Grundlagen-Lerneinheit und unterscheide in einem Satz Beobachtung, Problem und Lösungswunsch. Deren Inhalt war bei der Recherche nicht abrufbar; dieser Kurs behauptet deshalb keine unbekannten Details daraus.

Sicherer Rahmen: Alle Werte sind synthetisch; das Lehrbauteil ist fiktiv und ungefährlich. Es wird keine reale Maschine angesteuert, kein tatsächliches Produkt freigegeben und kein sicherheitsbezogener Prüfentscheid getroffen. Fachnutzen zählt mehr als Codemenge.


Technischen Bedarf erkennen


Beobachtung und Problem präzisieren

In der fiktiven Lehrwerkstatt „Lernlabor“ notieren Lernende künstliche Längenwerte. Zwei Personen bewerten 10,20 mm unterschiedlich. Beobachtung: Die Einordnungen widersprechen sich. Vermutung: Die Grenzregel wurde unklar kommuniziert; die Ursache ist noch nicht erwiesen. Fachliches Problem: Eine gemeinsame, nachvollziehbare Regel fehlt. Ziel: Dieselben Eingaben liefern dieselben begründeten Ergebnisse.

Eine Anforderung beschreibt eine benötigte Funktion oder Eigenschaft. Stakeholder sind betroffene Personen, etwa Lernende und Lehrkraft. Die Systemgrenze trennt die geplante lokale Auswertung von Sensoren, Produktion, Internet und echten Qualitätssicherungsentscheidungen. Frage zunächst, wer eine Entscheidung braucht, wofür und woran Erfolg erkennbar ist – nicht, welche Programmiersprache beliebt ist.


Fachziel und bewusste Nicht-Ziele

Das Programm soll für fiktive Messwerte eine verständliche Kennzeichnung erzeugen. Es soll nicht messen, steuern, automatische reale Ausschussentscheidungen auslösen oder personenbezogene Betriebsdaten verarbeiten. Eine funktionale Anforderung betrifft etwa die Bereichsprüfung; eine nichtfunktionale Anforderung etwa lokale Offline-Nutzung. „Benutzerfreundlich“ ist noch kein konkretes Kriterium, „zu jedem gültigen Wert erscheinen Wert, Einheit und Urteil“ schon.

Deutsches Flussdiagramm mit Ablaufkästen und Verzweigungen

Bild: Ein Flussdiagramm zeigt Entscheidungen. Ohne Bild: Eingabe erfassen → Format prüfen → Grenzregel anwenden → Ergebnis ausgeben.


Anforderungen klar und testbar formulieren


Aus Wünschen prüfbare Aussagen machen

Zu vage: „Prüfe Messwerte schnell und richtig.“ Präziser: „Bei gültigen Eingaben mit zwei Nachkommastellen zwischen 9,80 und 10,20 mm einschließlich beider Grenzen zeigt die App 'innerhalb' an.“ Dies sind frei gewählte Unterrichtsgrenzen, keine technische Norm. Ein Akzeptanzkriterium verbindet eine definierte Eingabe mit einer überprüfbaren Soll-Ausgabe. Eine User Story hält den Nutzen fest: „Als lernende Person möchte ich einen simulierten Messwert eingeben, um seine Einordnung nachvollziehen zu können.“ Die User Story ersetzt die Grenzregel nicht.

Anforderungsskizze Version 1.0:

Kennung Fachanforderung Nachweis
A-01 Die Übung läuft mit lokalen synthetischen Daten ohne Netz oder Sensor Ohne Internet und Hardware nutzbar
A-02 Sichtbares Eingabeformat: Dezimalkomma und genau zwei Nachkommastellen in mm 10,05 gültig; 10,205 ungültig
A-03 Gültige Werte 9,80 bis 10,20 mm einschließlich sind „innerhalb“ 9,80; 10,00; 10,20
A-04 Gültige Werte außerhalb dieses Intervalls sind „außerhalb“ 9,79 und 10,21
A-05 Leere, nichtnumerische und falsch formatierte Eingaben heißen „ungültige Eingabe“ leer; abc; 10,205
A-06 Jeder gültige Fall zeigt Kennung, Messwert, Einheit und Ergebnis Eine zweite Person kann das Urteil zuordnen
A-07 Ausgaben sind ausschließlich unverbindliche Lehrsimulationen Keine Maschinenverbindung oder Freigabefunktion

Die Entscheidung „genau zwei Nachkommastellen“ ist ausdrücklich Teil dieser Lernversion. Wird sie später verändert, müssen Anforderung und Tests zusammen angepasst werden. Abnahme heißt Vergleich mit den zuvor vereinbarten Soll-Ergebnissen. Sie ist unabhängig davon, ob eine Umsetzung in Python, Tabellenkalkulation oder auf Papier entsteht.

V-Modell mit gegenüberliegenden Entwicklungs- und Testschritten

Bildidee: Jeder fachlichen Anforderung steht eine passende Prüfung gegenüber. Ohne Bild: Verbinde A-02 mit dem Format-Test und A-03 mit Grenzwert-Tests.


Geführter Modellfall: synthetische Messdaten


Normalfall, Grenzfall und Fehlerfall

Das fiktive, ungefährliche Lehrbauteil L besitzt für die Übung einen zulässigen Längenbereich von 9,80 bis 10,20 mm. Eingaben sind ausschließlich erfundene Zahlen; keine reale Messung wird vorgenommen. Normalfall heißt eine erwartete gültige Eingabe; Grenzfall ein Wert auf einer vereinbarten Schwelle; Fehlerfall eine ungültige Eingabe oder unerwartete Verarbeitung. Ein gültiger Wert außerhalb des Bereichs ist nicht dasselbe wie eine ungültige Eingabe.

Test Eingabe Soll-Ausgabe Fachliche Begründung
S01 10,00 mm innerhalb Gültiger Wert im Intervall
S02 9,80 mm innerhalb Untere Grenze zählt mit
S03 10,20 mm innerhalb Obere Grenze zählt mit
S04 9,79 mm außerhalb Unterschreitet die Grenze
S05 10,21 mm außerhalb Überschreitet die Grenze
S06 abc ungültige Eingabe Keine Zahl
S07 leer ungültige Eingabe Kein Wert angegeben
S08 10,205 ungültige Eingabe Nicht zwei Nachkommastellen

Prüfung der drei Kernkriterien:

  1. Normalfall: S01 mit 10,00 mm ist gültig und innerhalb des geschlossenen Intervalls; die erwartete Anzeige ist „innerhalb“.
  2. Fehlerfall: S06 enthält Buchstaben statt eines Messwerts. Die Anzeige „ungültige Eingabe“ verhindert, dass aus fehlenden Daten ein erfundener Wert wie null wird.
  3. Toolunabhängige Abnahme: Eine zweite Person erhält die acht Eingabekarten mit der Tabelle der Soll-Ausgaben. Sie kann jede Ausgabe in einem Papiermodell oder einem beliebigen lokalen Programm vergleichen. Maßstab ist das vereinbarte Ergebnis, nicht der Programmcode.

Entscheidung erläutern: 10,20 ist wegen der eingeschlossenen Obergrenze „innerhalb“. 10,21 ist eine gültige Zahl, aber „außerhalb“. „abc“ ist weder innerhalb noch außerhalb, weil es kein gültiger Messwert ist. Schreibe diesen Unterschied in eigenen Worten auf.


Ablauf ohne Code planen

Erfasse die Eingabe, prüfe zunächst das Format und zeige bei einem Fehler die vereinbarte Meldung. Vergleiche nur gültige Werte mit beiden Grenzen. Stelle anschließend Kennung, Einheit und Urteil dar. Eine falsche Interpretation eines ungültigen Wertes als null wäre ein fachlicher Fehler. Spezifische Rundungsregeln außerhalb der genau zwei Nachkommastellen sind nicht definiert und dürfen nicht erfunden werden.

Animation zum Aufbau eines Flussdiagramms

Animation: Vorgehen beim Flussdiagrammzeichnen; möglicherweise englischsprachig. Ohne Animation: Zeichne Start, Formatfrage, Grenzwertfrage und zwei Ergebnisfelder mit Pfeilen.

Audio als freiwilliges Medienbeispiel: zeigt, wie Tastatureingaben klingen können. Das Geräusch selbst ist kein Messwert und nicht erforderlich. Ohne Audio: Lies S01 bis S08 in der Tabelle.


Das Softwareprojekt in Arbeitspakete zerlegen


Aufgaben, Abhängigkeiten und Prioritäten

Ein Arbeitspaket ist eine kleine Aufgabe mit greifbarem Ergebnis. Ein Backlog sammelt diese Aufgaben in sinnvoller Reihenfolge. Die Grenzregel muss geklärt sein, bevor eindeutige Testkarten entstehen. Beispiel:

Paket Ergebnis Erledigt, wenn
P-01 Fachregel dokumentieren Grenzen und Einheit eindeutig sind
P-02 Formatregeln definieren Ungültige Eingaben benannt sind
P-03 Anzeige skizzieren Kennung, Einheit und Urteil lesbar sind
P-04 Testfälle erstellen Soll-Ergebnisse vorab feststehen
P-05 Gegenprüfung durchführen Eine andere Person Entscheidungen erklären kann

Minimum sinnvoller Funktionsumfang: Eingabe, Prüfung, Ausgabe. Zusätzliche Diagramme, Cloudspeicherung und KI-Funktionen sind nicht nötig. Auch eine vollständig ausgearbeitete Anforderungsskizze ohne programmiertes Produkt hat Fachwert, denn sie vermindert Missverständnisse vor einer Entwicklung.

Englisches Diagramm mit wiederkehrenden Schritten Planung, Test und Verbesserung

Bild: iteratives Vorgehen. Ohne Bild: Entwurf → Prüfung → Rückmeldung → korrigierte Anforderung.


Änderungswünsche nachvollziehen

Führe ein fiktives Gespräch: „Sind die Grenzen eingeschlossen? Was geschieht bei leerem Feld? Darf die App mit einer Nachkommastelle rechnen?“ Notiere Frage, Entscheidung und Datum. Ein neuer Wunsch nach drei Nachkommastellen betrifft A-02 und S08. Rückverfolgbarkeit bedeutet, die Beziehung zwischen Bedarf, Anforderung, Test und Änderung erkennen zu können. Keine Entscheidung darf nur still im Code verschwinden.

Deutsches Zusatzvideo: Lastenheft und Pflichtenheft, Marius Ebert, 18.10.2010. Es erklärt vereinfacht den Unterschied von Auftraggeberbedarf und Umsetzungsantwort. Der Titel erwähnt IHK-Weiterbildung; dieses eigenständige Lehrangebot ist damit nicht zertifiziert. Die Video-Metadaten sind auffindbar, die künftige Abspielbarkeit kann sich ändern. Ohne Video: Bedarf formulieren, Umsetzung planen, Akzeptanzkriterien vereinbaren.


Abnahme und selbstständiger Transfer


Werkzeugunabhängiges Abnahmeprotokoll

Eine Abnahmekarte enthält Test-ID, referenzierte Anforderung, Eingabe, erwartete Ausgabe, beobachtete Ausgabe, Abweichung und Urteil. Beispiel: T-05 verweist auf A-04, Eingabe 10,21 mm, Soll „außerhalb“. Zeigt eine spätere App „innerhalb“, ist der Test nicht bestanden. Ein möglicher Programmfehler bleibt zunächst eine Hypothese: Sicher feststellbar ist nur die Soll-Ist-Abweichung. Bei einer rein handschriftlichen Ausführung notiere ausdrücklich „Simulation“ statt eines behaupteten realen Softwaretests.

Drei Selbstprüffragen: Ist der Normalfall mit Zahl und Einheit eindeutig? Ist der Fehlerfall gegenüber dem fachlichen Ergebnis „außerhalb“ abgegrenzt? Kann eine zweite Person unabhängig vom verwendeten Tool über Bestehen oder Nichtbestehen entscheiden? Nur wenn du alle drei Fragen begründet beantwortest, ist die Anforderungsskizze abnahmefähig.


Transfer und verantwortlicher KI-Einsatz

Entwirf analog eine lokale Prüfung einer synthetischen Temperaturtabelle in Grad Celsius. Du musst eigene Grenzen festlegen und Testwerte neu bestimmen, anstatt die Millimeterwerte zu übernehmen. Als zweite Idee prüfe erfundene Lagerkennungen auf fehlende Einträge. Erkläre jeweils Nutzerziel, Systemgrenze, Normalfall, Fehlerfall und toolunabhängige Abnahme.

Eine KI kann Sätze vorschlagen, aber weder fachliche Zahlen freigeben noch die Verantwortung für Tests übernehmen. Das NIST-Profil zu generativer KI behandelt Risiken solcher Hilfsmittel, nicht die Normierung unserer Millimeterwerte. Die MCP-Sicherheitsregeln betreffen Zugriffe zwischen KI-Werkzeugen; für die Offline-Übung besteht keine Pflicht, einen solchen Dienst einzusetzen. Verwende weder vertrauliche Betriebsdaten noch echte Schülerdaten.

Zukunftsakzent: Bewerte Software am fachlichen Nutzen, den klaren Anforderungen und den nachgewiesenen Ergebnissen – nicht an Menge des Codes.

Interaktive Aufgaben


Quiz: Wissen prüfen

Prüfe dein Verständnis mit genau zehn Fragen. Die interaktive Auswertung zeigt deine Rückmeldung nach Bearbeitung.

Was ist der wichtigste Fachnutzen der Übungs-App? (Synthetische Messwerte nachvollziehbar nach einer vereinbarten Regel einordnen) (!Möglichst viel Programmcode schreiben) (!Reale Maschinen selbstständig nachstellen) (!Messdaten ins Internet übertragen)



Welche Aussage ist ein gutes Akzeptanzkriterium? (10,21 mm ergibt die Anzeige außerhalb) (!Die App soll besonders schön wirken) (!Das Projekt soll ganz modern sein) (!Das Team soll möglichst schnell arbeiten)



Welcher Wert liegt noch innerhalb der definierten Grenzen? (10,20 mm) (!10,21 mm) (!9,79 mm) (!10,30 mm)



Was ist die korrekte Reaktion auf abc? (Die Meldung ungültige Eingabe anzeigen) (!Ohne Hinweis null einsetzen) (!Den Wert als innerhalb bewerten) (!Den Wert als außerhalb bewerten)



Welche Eingabe ist eine gültige Zahl außerhalb des Bereichs? (9,79 mm) (!Leeres Eingabefeld) (!abc) (!10,205)



Welche Informationen benötigt ein toolunabhängiger Test? (Eingabe und zuvor vereinbarte Soll-Ausgabe) (!Eine bestimmte Programmiersprache) (!Die Zahl der Quellcodedateien) (!Ein bestimmtes Markenprodukt)



Warum sind Anforderung und Test zu verknüpfen? (Damit Änderungen und Nachweise nachvollziehbar bleiben) (!Damit man Prüfungen weglassen kann) (!Damit Eingaben geheim bleiben) (!Damit möglichst viele Funktionen entstehen)



Welche Aufgabe gehört in die erste Projektphase? (Den Fachbedarf und die Grenzregel klären) (!Echte Bauteile automatisch aussortieren) (!Ein teures KI-Abonnement auswählen) (!Fremde Kundendaten herunterladen)



Was ist ein Fehlerfall nach A-05? (Ein leeres Eingabefeld) (!10,00 mm) (!9,80 mm) (!10,20 mm)



Was ist in dieser Unterrichtseinheit ausgeschlossen? (Die Freigabe oder Steuerung echter Maschinen) (!Eine handschriftliche Skizze) (!Ein begründeter Grenzfall) (!Eine simulierte Abnahme)




Memory

Finde die zusammengehörigen Paare.

Anforderung Überprüfbare Aussage über eine Systemfunktion
Stakeholder Vom Projekt betroffene Person
Grenzfall Wert genau an der festgelegten Bereichsgrenze
Fehlerfall Fall mit ungültiger Eingabe oder unerwartetem Verhalten
Abnahmetest Prüfung einer vorher vereinbarten Soll-Ausgabe
Rückverfolgbarkeit Verbindung von fachlicher Regel und ihrem Test




Drag-and-Drop

Ordne jeder Teilaufgabe das richtige Ergebnis zu.

Teilaufgabe zuordnen Ergebnis
Fachregel klären Gültigen Wertebereich dokumentieren
Eingabeformat prüfen Fehlende Zeichen oder falsche Präzision erkennen
Anzeige planen Wert, Einheit und Urteil verständlich darstellen
Testkarten erstellen Erwartete Ausgaben vorab niederschreiben
Änderungen verfolgen Betroffene Anforderungen und Tests verknüpfen




Kreuzworträtsel

Ergänze sechs Fachbegriffe, jeweils genau ein Wort.

Messwert Wie heißt eine Größe, die im Modell mit Millimeter angegeben wird?
Grenzwert Wie heißt die obere oder untere Schwelle?
Abnahme Wie heißt die Schlussprüfung anhand vorher definierter Kriterien?
Fehlerfall Wie heißt eine bewusst untersuchte ungültige Eingabe?
Datensatz Wie heißt ein zusammengehöriger Eintrag mit Kennung und Wert?
Protokoll Wie heißt die schriftliche Dokumentation des Soll-Ist-Vergleichs?




LearningApps

Suche nach passenden Übungen. Verfügbarkeit und fachliche Qualität externer Inhalte können wechseln. Offline-Alternative: Ordne die Begriffe aus der Drag-and-Drop-Tabelle schriftlich zu.


Lückentext

Setze die Begriffe aus den Fachkapiteln ein.

Fachbegriffe ergänzen
Eine überprüfbare Systemaussage ist eine

.
Die verwendete Längeneinheit heißt

.
Die eingeschlossene obere Grenze beträgt

.
Eine nichtnumerische Eingabe ist

.
Das zuvor vereinbarte erwartete Ergebnis ist das

.
Die abschließende Prüfung vereinbarter Ergebnisse heißt

.
Die Verbindung von Anforderungen und Testfällen heißt

.
Unsere Werte sind ausschließlich

.



Offene Aufgaben

Bearbeite alle Aufgaben mit synthetischen Daten, allein oder im Rollenspiel.

Leicht

  1. Anforderung: Übersetze den vagen Wunsch „Die App soll gut prüfen“ in zwei testbare Aussagen.
  2. Messwert: Ordne 9,79; 9,80; 10,20 und 10,21 mm ein und erkläre deine Grenzentscheidung.
  3. Fehlerbehandlung: Erfinde drei ungültige Eingaben und formuliere passende Fehlermeldungen.
  4. Flussdiagramm: Zeichne den Entscheidungsfluss mit Formatfrage und Grenzprüfung; füge eine schriftliche Bildalternative hinzu.


Standard

  1. User Story: Schreibe eine Nutzerbeschreibung und drei klare Akzeptanzkriterien.
  2. Testfall: Erstelle acht Testkarten mit Kennung, Eingabe, Soll-Ausgabe und Begründung.
  3. Projektplanung: Zerlege die Messwert-App in fünf Arbeitspakete und begründe ihre Reihenfolge.
  4. Anforderungsanalyse: Führe ein Rollenspiel mit fiktivem Auftraggeber durch und dokumentiere drei geklärte Fragen.


Schwer

  1. Anforderungsmanagement: Untersuche A-01 bis A-07 auf Widersprüche und ergänze fehlende Entscheidungen.
  2. Grenzwertanalyse: Erkläre, warum 10,20 anders behandelt wird als 10,21 und warum abc nicht einfach außerhalb ist.
  3. Änderungsmanagement: Simuliere eine Umstellung auf drei Nachkommastellen und überarbeite alle betroffenen Testfälle.
  4. Softwarequalität: Übertrage das Vorgehen auf eine fiktive lokale Temperaturprüfung mit eigenem Soll-Ist-Katalog.




Text bearbeiten Bild einfügen Video einbetten Interaktive Aufgaben erstellen



Lernkontrolle

  1. Normalfall: Definiere S01 vollständig mit Eingabe, erwarteter Anzeige und fachlicher Begründung.
  2. Fehlerfall: Begründe für S06, warum die App nicht einfach null als Ersatzwert verwenden darf.
  3. Abnahmekriterium: Beschreibe die Prüfung S05 so, dass jede Person sie ohne Kenntnis des Programmcodes nachstellen kann.
  4. Grenzwertanalyse: Erkläre den Unterschied zwischen 9,79, 9,80, 10,20 und 10,21 mm.
  5. Rückverfolgbarkeit: Verknüpfe die Kennungen A-02 bis A-05 mit den passenden Tests S01 bis S08.
  6. Projektmanagement: Nenne zwei sachliche Abhängigkeiten zwischen den fünf Arbeitspaketen.
  7. Transfer: Formuliere einen eigenen Normalfall und Fehlerfall für eine synthetische Temperaturtabelle.


Lernnachweis

Abgabe: Anforderungsskizze einer Messwertprüfung. Erstelle auf ein bis drei Seiten eine Problemdefinition mit Nutzen, Zielgruppe und Systemgrenze, eine Liste von mindestens sechs Anforderungen mit Kennungen, fünf Arbeitspakete und ein toolunabhängiges Testblatt mit mindestens fünf Soll-Ist-Karten. Dokumentiere ausdrücklich mindestens einen Normalfall, beide Grenzwerte, einen gültigen Wert außerhalb und einen begründeten ungültigen Fehlerfall. Erkläre selbst, warum S06 nicht wie S05 behandelt wird.

Bewertungsraster (0–2 Punkte je Bereich, zehn Punkte): fachlicher Bedarf; Eindeutigkeit von Einheit und Grenzen; Normal- und Grenzfälle; begründete Fehlerbehandlung; toolunabhängige Abnahme. 0 = fehlt oder widersprüchlich, 1 = teilweise nachvollziehbar, 2 = vollständig und überprüfbar. Reflektiere: Welche Entscheidung muss vor einer echten Entwicklung noch geklärt werden?

Die Leistung wird nur als unabhängiges Unterrichtsprodukt betrachtet, nicht als offizielle Liebherr- oder IHK-Zertifizierung, Produktionsprüfung oder Sicherheitsfreigabe.


OER und Wikipedia

Recherche- und Quellenstand: 22.10.2026. Die Zahlen 9,80 bis 10,20 sind didaktisch erfunden, nicht aus technischen Normen abgeleitet.

  • ISO/IEC/IEEE 29148:2018, zweite Ausgabe, November 2018, 2024 bestätigt: Requirements Engineering. Ein Nachfolgeentwurf befindet sich 2026 in der Entwicklung und ist noch keine neue veröffentlichte Ausgabe.
  • IREB CPRE Foundation Level, Lehrplan 3.3.0 (Downloadseite mit deutscher Fassung): Ermitteln, Dokumentieren und Prüfen von Anforderungen. Dieser aiMOOC ist kein IREB-Prüfungskurs.
  • Atlassian, User Stories: niedrigschwellige Ergänzung zu Nutzerperspektive und Akzeptanzkriterien, herstellerbezogene Quelle, keine Norm.
  • NIST AI 600-1 (Juli 2024): freiwilliges Risikomanagementprofil für generative KI; nur relevante Vertiefung zu KI-Hilfstexten, keine Regel für Messwerte.
  • MCP Security Best Practices (Dokumentationspfad 28.07.2026, eingesehen am 22.10.2026): Risiken bei Werkzeugverknüpfungen; nur optionale Vertiefung, keine notwendige Technik der lokalen Übung.
  • Wikipedia Anforderungsmanagement und Softwaretest: deutschsprachige Einführung; Versionsstände können sich ändern.
  • Vorgegebene MOOCwiki-Grundlage: nicht abrufbar während dieser Recherche; darum nicht inhaltlich ausgewertet.

Verifizierte Commons-Dateiseiten und Rechteangaben:

Medium Urheber Lizenznachweis Alternative
File:Flowchart de.svg Erik Streb CC BY-SA 3.0 Ablauf als Text
File:V-Modell.svg Michael Pätzold, S. Seyfert CC BY-SA 3.0 Anforderung-Test-Tabelle
File:Iterative Process Diagram.svg Krupadeluxe CC BY-SA 4.0 Entwurf-Test-Rückmeldung als Text
File:Untitled-‑-Made-with-FlexClip.gif DaniLumber CC BY-SA 4.0 Flussdiagramm selbst skizzieren
File:Computer keyboard.ogg russiandoll; Transfer Fæ Gemeinfrei laut Dateiseite Nur optionales Tastaturgeräusch, keine Fachinformation

Alle verwendeten Dateien stammen von Dritten; Namensnennung und Lizenzbedingungen der Commons-Dateiseiten beachten. Die Dateiseiten bieten Vorschaubilder und weitere Formate. Die eingebundenen Bilder enthalten Alternativtexte und die wesentlichen Aussagen stehen zusätzlich im Fließtext. Video: Marius Ebert: Lastenheft und Pflichtenheft, veröffentlicht 18.10.2010; Metadaten überprüft, fortdauernde regionale Abspielbarkeit nicht garantiert; der Kurs funktioniert vollständig ohne das Video. Keine offiziellen Zertifikate oder Institutionenpartnerschaften werden behauptet.


Verknüpfte Lernbereiche


aiMOOC-Projekte



Schulfach+




aiMOOCs



aiMOOC Projekte