Softwarequalität ist, wie gut eine Software ihre Anforderungen erfüllt. Gebräuchliche Gütekriterien:

• Korrektheit: Sie tut, was verlangt wurde.
• Zuverlässigkeit: Sie kommt mit Fehleingaben und Ausfällen zurecht (Robustheit).
• Effizienz: Sie braucht angemessen wenig Zeit und Speicher.
• Sicherheit: Sie schützt Daten und widersteht Angriffen.
• Benutzbarkeit: Nutzer erreichen ihre Ziele leicht.
• Wartbarkeit: Sie lässt sich verstehen, ändern und erweitern.
• Portabilität: Sie läuft auf verschiedenen Systemen.

Die Kriterien können einander widersprechen, etwa Effizienz und Wartbarkeit. Wer Software entwickelt, trägt Verantwortung für ihre Folgen: Fehler in Fahrzeugen, Medizingeräten oder Banken können Menschen gefährden oder Geld kosten. Dazu gehören Qualitätssicherung, offener Umgang mit Risiken und der Schutz personenbezogener Daten.

Softwareergonomie gestaltet Oberflächen so, dass sie zu Menschen und Aufgaben passen. Benutzungsfreundlichkeit heißt: Nutzer erreichen ihre Ziele wirksam, effizient und zufrieden. Grundsätze der Dialoggestaltung (aus der Norm ISO 9241-110) sind unter anderem:

• Aufgabenangemessenheit: Die Software unterstützt die Aufgabe ohne unnötigen Aufwand.
• Selbstbeschreibungsfähigkeit: Nutzer erkennen, wo sie sind und was als Nächstes möglich ist.
• Erwartungskonformität: Die Software verhält sich so, wie man es von ähnlichen Programmen gewohnt ist.
• Steuerbarkeit: Nutzer bestimmen Tempo und können abbrechen oder zurückgehen.
• Fehlertoleranz: Fehleingaben richten keinen Schaden an, und Meldungen sagen, wie man den Fehler behebt.

Barrierefreiheit heißt, dass auch Menschen mit Einschränkungen die Software nutzen können, etwa bei Blindheit, Farbsehschwäche, Schwerhörigkeit oder eingeschränkter Beweglichkeit. Dazu dienen Alternativtexte für Bilder (für Screenreader), ausreichender Kontrast, Bedienung allein mit der Tastatur, skalierbare Schrift, Untertitel und der Grundsatz, Informationen nie nur durch Farbe zu zeigen. Für Webseiten gibt es dazu die Web Content Accessibility Guidelines (WCAG).

Ein Test führt die Software mit gewählten Eingaben aus und vergleicht das Ergebnis mit dem erwarteten. Tests können Fehler finden, aber nicht beweisen, dass keine mehr vorhanden sind. Man testet in Stufen:

• Unit-Test: prüft eine kleine Einheit, etwa eine Funktion oder Klasse, für sich allein.
• Integrationstest: prüft, ob Einheiten über ihre Schnittstellen zusammenarbeiten.
• Systemtest: prüft das ganze System gegen die Anforderungen.

Testfälle wählt man systematisch. Eine Äquivalenzklasse fasst Eingaben zusammen, die gleich behandelt werden, ein Vertreter genügt. Grenzwerte liegen an den Rändern der Klassen, dort sind Fehler häufig. Bei Black-Box-Tests kennt man nur die Spezifikation, bei White-Box-Tests auch den Code. Bei der testgetriebenen Entwicklung (TDD) schreibst du zuerst einen Test, der fehlschlägt, dann gerade so viel Code, dass er besteht, und räumst danach auf. Alle Tests laufen nach jeder Änderung erneut, damit neue Fehler auffallen.

Refaktorierung verbessert die innere Struktur des Codes, ohne sein Verhalten zu ändern: bessere Namen, doppelten Code in eine Methode ziehen, lange Methoden teilen. Die Tests zeigen, dass nach dem Umbau alles noch funktioniert. Dokumentation besteht aus Kommentaren, die das Warum erklären, aus Beschreibungen der Schnittstellen, einer Übersicht über den Aufbau und einem Handbuch für Nutzer. Sie muss zusammen mit dem Code gepflegt werden, sonst führt sie in die Irre.

Ein Entwurfsmuster ist eine bewährte Lösung für ein wiederkehrendes Entwurfsproblem.

• Observer: Ein Objekt, das Subjekt, führt eine Liste von Beobachtern. Ändert sich sein Zustand, ruft es bei jedem Beobachter eine Methode wie $\texttt{aktualisieren}$ auf. Beobachter melden sich an und ab. Das Subjekt kennt nur die Schnittstelle der Beobachter, nicht deren Klassen, die Kopplung ist lose.
• Model-View-Controller (MVC): Das Model hält Daten und Fachlogik, die View stellt sie dar, der Controller nimmt Eingaben entgegen und ruft das Model auf. Die View beobachtet das Model. So lassen sich Darstellung und Logik getrennt ändern und testen.

Versionsverwaltung (zum Beispiel Git) speichert jede Änderung als Version, den Commit, mit Autor, Zeit und Nachricht. So kann man zu früheren Ständen zurückgehen. In Branches entwickelt man Linien parallel und führt sie per Merge zusammen. Das Repository enthält die ganze Geschichte. Bugtracking verwaltet Fehler als Tickets mit Beschreibung, Schritten zum Nachstellen, Priorität, Zuständigem und Status.

Eine Schnittstelle (API) legt fest, wie man einen Teil von außen benutzt (Methoden, Parameter, Rückgaben), ohne seine Umsetzung zu kennen. Modularisierung zerlegt ein System in Module mit hoher Kohäsion (ein Modul, eine Aufgabe) und loser Kopplung (wenige Abhängigkeiten), die nur über Schnittstellen zusammenarbeiten. Module lassen sich einzeln testen, austauschen und im Team verteilen.