Übungsaufgaben zur Softwarequalität

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Softwarequalität“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/softwarequalitaet
- https://oer-informatik.de/teststrategie
- https://oer-informatik.de/usability-barrierefreiheit
- Stilbeispiel: https://oer-informatik.de/softwarequalitaet-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Softwarequalität
- ISO/IEC 25010
- Qualitätsmerkmale
- Qualitätsanforderungen
- Zielkonflikt
- Qualitätssicherung
- Wartbarkeit
- Leistungseffizienz

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

• Norm: ISO/IEC 25010 (Vorgänger ISO/IEC 9126 wird ebenfalls akzeptiert) (1 Punkt)

• vier von: funktionale Eignung (Funktionalität), Leistungseffizienz (Effizienz), Kompatibilität, Benutzbarkeit (Interaktionsfähigkeit), Zuverlässigkeit, Sicherheit, Wartbarkeit (Änderbarkeit), Übertragbarkeit (Flexibilität), Betriebssicherheit (ab 2023) (je 0,5 Punkte)

Je Zeile 1 Punkt (0,5 Punkte Merkmal, 0,5 Punkte Teilmerkmal):

Die Alternativen in Klammern sind richtig, wenn sie begründet werden: Bricht der Shop zusammen, ist er nicht mehr verfügbar; die Ursache ist aber fehlende Kapazität.

Je Merkmal 2 Punkte für die allgemeine Beschreibung und 1 Punkt für den Bezug, zum Beispiel:

Nur 1 Punkt für eine allgemeine Beschreibung, die lediglich den Namen wiederholt oder Effizienz als „schnell programmiert“ deutet.

Je Anforderung 2 Punkte (1 Punkt messbare Größe mit Grenzwert, 1 Punkt Bedingungen), zum Beispiel:

• Zu 1: „In einem Usability-Test schließen mindestens 8 von 10 Testpersonen ohne Vorkenntnisse eine Rahmenkonfiguration mit Farbwahl ohne Hilfe in höchstens 5 Minuten ab.“ Oder: „Die Abbruchquote im Konfigurator sinkt innerhalb von drei Monaten nach dem Start von derzeit x % auf unter y %.“

• Zu 2: „Bei 2.000 gleichzeitig aktiven Sitzungen wird jede Konfiguratorseite in 95 % der Abrufe in höchstens 2 Sekunden ausgeliefert; der Shop bleibt bei dieser Last mindestens 8 Stunden ohne Ausfall erreichbar.“

Nicht ausreichend sind Formulierungen ohne Grenzwert („Der Shop soll mehr Last aushalten“).

2 Punkte für die beiden Merkmale mit Wirkungsrichtung, 2 Punkte für die Erläuterung am Beispiel. Mögliche Konflikte:

• Benutzbarkeit gegen Leistungseffizienz: Die 3D-Vorschau macht die Konfiguration anschaulicher und senkt Abbrüche (Benutzbarkeit steigt). Sie braucht aber viel Rechenleistung und Datenvolumen, sodass die Seite auf älteren Smartphones und bei schwachem Mobilfunk langsam lädt (Leistungseffizienz sinkt).

• Benutzbarkeit gegen Übertragbarkeit: Die Vorschau funktioniert womöglich nur in aktuellen Browsern mit WebGL; auf anderen Geräten muss eine Ersatzdarstellung entwickelt werden.

• Benutzbarkeit gegen Wartbarkeit: Für jedes neue Bauteil und jede Farbe müssen 3D-Modelle erstellt und gepflegt werden; jede Sortimentsänderung wird aufwendiger.

Eine Lösung des Konflikts (z. B. 3D-Vorschau nur auf Wunsch, sonst Foto) kann zusätzlich genannt werden.

Je 1 Punkt für jede begründete Beurteilung (3 Punkte), je 1 Punkt für jede passend zugeordnete Testart (3 Punkte) und 1 Punkt für einen begründeten Vorschlag zur Merge-Regel. Beispiel:

• Cem – nicht haltbar: 100 % Anweisungsüberdeckung bedeutet nur, dass jede Anweisung bei den Tests mindestens einmal ausgeführt wurde. Ob die Tests das Ergebnis überhaupt mit einem richtigen Sollwert vergleichen, ob alle Bedingungskombinationen vorkamen und ob Anforderungen ganz fehlen (fehlender Code kann nicht überdeckt werden), sagt die Kennzahl nicht. Tests können Fehler zeigen, aber nie Fehlerfreiheit beweisen.

• Natalia – nur eingeschränkt richtig: Der Rabattfehler fällt nur auf, wenn es einen Testfall mit genau der kritischen Bestellmenge und einem korrekt berechneten Sollwert gibt. Steht etwa menge > 50 statt menge >= 50 im Code, erreicht man 100 % Anweisungsüberdeckung auch mit den Mengen 10 und 80 – der Fehler bei genau 50 Stück bleibt unentdeckt. Gezielte Grenzwerttests aus Äquivalenzklassen finden ihn eher.

• Bastian – nicht haltbar: Unit-Tests prüfen einzelne Klassen isoliert und meist mit wenigen Testdaten im Speicher. Wie sich der Shop bei Tausenden gleichzeitigen Sitzungen verhält (Leistungseffizienz), zeigen nur Last- bzw. Stresstests auf einer produktionsähnlichen Umgebung.

• Testarten: Aussage 1 → Usability-Test mit Testpersonen, die den Konfigurator noch nicht kennen (Benutzbarkeit). Aussage 2 → Last- und Stresstest mit simulierten gleichzeitigen Sitzungen (Leistungseffizienz). Aussage 4 → Integrationstest bzw. automatisierter Schnittstellentest gegen eine Testumgebung von Rahmenwerk OWL, der bei jeder Schnittstellenänderung läuft (Kompatibilität, Wartbarkeit).

• Vorschlag Merge-Regel: Eine Mindestüberdeckung (z. B. 80 % Zweigüberdeckung für geänderte Klassen) als Warnsignal behalten, zusätzlich die Testfälle im Code-Review prüfen (sind Sollwerte und Grenzwerte enthalten?). Integrations-, Last- und Usability-Tests laufen vor jedem Release zusätzlich.

• Deutscher Begriff: Wartbarkeit (auch Änderbarkeit) (1 Punkt)

• Erläuterung (2 Punkte): Wartbarkeit beschreibt, mit welchem Aufwand eine Software analysiert, korrigiert, verbessert und an neue Anforderungen angepasst werden kann. CampTube besteht aus kleinen, lose gekoppelten Modulen (Modularität); Fehler lassen sich meist einem Modul zuordnen (Analysierbarkeit), und neue Funktionen wie ein weiteres Untertitelformat lassen sich über die Plugin-Schnittstelle ergänzen, ohne den Kern zu ändern (Modifizierbarkeit).

Je Zeile 2 Punkte (1 Punkt Merkmal, 1 Punkt Erläuterung mit eigenen Worten, nicht bloß übersetzt):

• Nicht vorkommend: funktionale Eignung (Functional Suitability) und Kompatibilität (Compatibility) (je 1 Punkt).

• Beschreibung, zum Beispiel (2 Punkte):

  • Funktionale Eignung: Prüfen, ob CampTube alle benötigten Funktionen bietet und korrekt ausführt, z. B. Untertiteldateien hochladen und bearbeiten, Videos in Playlists je Barcamp ordnen, Freigabe nur mit Fotoeinwilligung der gezeigten Personen.

  • Kompatibilität: Prüfen, ob CampTube mit den vorhandenen Systemen zusammenarbeitet, z. B. Anmeldung über die Schulkonten (Single Sign-on), Übernahme der Aufzeichnungen aus dem Streaming-Server, Betrieb im Server-VLAN neben Info-Server und MQTT-Broker.

• Interaction Capability (Interaktionsfähigkeit) ersetzt die Benutzbarkeit (Usability); die Zugänglichkeit ist in Inklusivität und Nutzerunterstützung aufgeteilt (1 Punkt).

• Flexibility (Flexibilität) ersetzt die Übertragbarkeit (Portability) und enthält zusätzlich die Skalierbarkeit (1 Punkt).

• Safety (Betriebssicherheit) ist ein neues Merkmal: Die Software soll Zustände vermeiden, die Menschen, Sachwerte oder die Umwelt gefährden (1 Punkt).

• Beurteilung (2 Punkte): Ein Videoportal steuert keine Maschinen oder Geräte; ein Fehler gefährdet niemanden körperlich. Safety hat deshalb eine geringe Priorität. Wichtig ist dagegen Security (Schutz der Daten, z. B. von Aufnahmen Minderjähriger ohne Fotofreigabe) – die beiden Begriffe dürfen nicht verwechselt werden.

Je Maßnahme 1 Punkt, zum Beispiel:

• Zuverlässigkeit: Testinstallation einige Wochen betreiben und Verfügbarkeit überwachen; Datenbank absichtlich stoppen und prüfen, ob Videos weiterlaufen; Rücksicherung aus dem Backup üben.

• Benutzbarkeit: Usability-Test mit Lisa Brandt und weiteren Nutzenden, Bedienung mit Screenreader und nur per Tastatur, Prüfung nach WCAG 2.2.

• Leistungseffizienz: Lasttest auf der eigenen Hardware mit vielen gleichzeitigen Abrufen, Speicher- und CPU-Verbrauch messen.

Je Korrektur 1 Punkt:

• 1. Effizienz (Leistungseffizienz) beschreibt nicht die Entwicklungsgeschwindigkeit, sondern wie sparsam die Software im Betrieb mit Zeit und Ressourcen umgeht (Antwortzeiten, Speicher, Rechenleistung).

• (B) Der Schutz vor unberechtigtem Löschen gehört zur Sicherheit (Integrität, Rechtekonzept), nicht zur Zuverlässigkeit. Zuverlässigkeit beschreibt den stabilen, fehlerfreien Betrieb.

• (C) Portability (Übertragbarkeit) meint die Übertragung in eine andere Betriebsumgebung (anderes Betriebssystem, anderer Server, andere Cloud), nicht „tragbare Geräte“. Der Begriff kommt von „übertragbar“, nicht von „tragbar“. Dass das Portal auf Smartphones gut nutzbar ist, betrifft höchstens das Teilmerkmal Anpassbarkeit (an andere Bildschirmgrößen) oder die Benutzbarkeit.