Softwareentwicklung: Prozess, Modelle und Qualität

Eine Phase ist ein Arbeitsabschnitt mit einem bestimmten Schwerpunkt. Eine mögliche Gliederung der Softwareentwicklung umfasst sieben Phasen. Teams können sie unterschiedlich organisieren; die Gliederung schreibt noch kein bestimmtes Vorgehensmodell vor.

In der Planung legt das Team Ziele und Umfang fest: Welches Problem soll das Programm lösen, und was gehört zum Projekt? In der Analyse sammelt und untersucht es Anforderungen, also Vorgaben an das Programm. Beim Entwurf plant es den Aufbau, etwa Bildschirmanzeigen und die Speicherung von Daten. Bei der Programmierung schreibt es Code, also Anweisungen in einer Programmiersprache.

Beim Test vergleicht das Team das tatsächliche Verhalten mit dem erwarteten Verhalten. Die Bereitstellung macht das Programm für seine vorgesehenen Nutzer zugänglich. Zur Wartung gehören Arbeiten nach der Bereitstellung, etwa Fehlerkorrekturen, Anpassungen und das Prüfen von Updates, also neuen Programmständen.

Tests können beginnen, sobald ein ausführbarer Teil vorliegt. In vielen Vorgehensmodellen begleiten sie die weitere Entwicklung. Die Bezeichnung „Testphase“ bedeutet deshalb nicht, dass sämtliche Tests erst nach der gesamten Programmierung stattfinden.

Eine Anforderung beschreibt, was ein Programm leisten oder welche Eigenschaft es besitzen soll. Eine funktionale Anforderung legt ein gewünschtes Verhalten oder Ergebnis fest, etwa das Speichern eines Eintrags. Eine Qualitätsanforderung beschreibt eine weitere geforderte Eigenschaft, etwa die Geschwindigkeit einer Anzeige. Zeitvorgaben zählen wir hier zu den Qualitätsanforderungen; manche Einteilungen führen Leistungsanforderungen auch als eigene Art auf.

Ein Akzeptanzkriterium legt fest, welche Bedingung erfüllt sein muss, damit eine Anforderung als umgesetzt angenommen wird. Formuliere dafür die Ausgangslage, die Handlung und das erwartete Ergebnis möglichst genau. Bei einer Zeitvorgabe gehören auch die vereinbarten Prüfbedingungen dazu, etwa Datenmenge und Testgerät.

Wörter wie „schnell“ oder „übersichtlich“ legen für sich genommen keinen eindeutigen Maßstab fest. „Bei 20 Einträgen erscheint die vollständige Liste auf dem vereinbarten Testgerät innerhalb von 2 Sekunden nach dem Öffnen“ ist dagegen überprüfbar. Die Zeitgrenze ist eine frei vereinbarte Beispielvorgabe, kein allgemeiner Qualitätsstandard. „Wir testen die Anzeige vor der Freigabe“ nennt eine Tätigkeit, aber noch keine Bedingung für das Bestehen.

Sicherheitsanforderungen können beide Arten betreffen. „Das Programm verweigert den Zugriff ohne gültige Anmeldung“ beschreibt ein Verhalten und ist funktional. Die allgemein geforderte Vertraulichkeit gespeicherter Inhalte betrifft eine Qualität: Unbefugte sollen die Inhalte nicht erfahren. Entscheidend ist die konkrete Aussage, nicht das Wort „Sicherheit“.

Ein Vorgehensmodell ordnet die Arbeit an einem Softwareprojekt. Das Wasserfallmodell ist linear: Die Phasen bilden eine feste Folge, und eine Phase wird abgeschlossen, bevor die nächste beginnt. Das erleichtert es, Arbeiten und Übergaben vorab zu planen. Spätere Änderungen können jedoch aufwendig sein, wenn dafür bereits abgeschlossene Arbeit überarbeitet werden muss.

Das Wasserfallmodell kann vorteilhaft sein, wenn Ziele und Anforderungen gut geklärt und voraussichtlich stabil sind. Es passt außerdem zu einer Zusammenarbeit, bei der Auftraggeber Ergebnisse vor allem an vereinbarten größeren Zwischenständen prüfen. Solche Zwischenstände heißen Meilensteine. Das Modell verhindert spätere Änderungen nicht; es macht sie aber häufig weniger flexibel.

Iterativ bedeutet, Arbeitsschritte wiederholt zu durchlaufen. Im hier verglichenen agilen Vorgehen entwickelt das Team kleine nutzbare Teile, lässt sie prüfen und berücksichtigt Rückmeldungen bei der weiteren Planung. Anforderungen können sich dabei weiterentwickeln. Dafür müssen Auftraggeber zu häufigem Austausch bereit und erreichbar sein.

Agile Arbeit braucht ebenfalls Planung, Entwurf und Tests. Diese Aufgaben werden wiederholt und können für verschiedene Teile zeitlich nebeneinander stattfinden. Nicht jedes agile Vorgehen nutzt feste Arbeitszeiträume: Manche organisieren die Arbeit als fortlaufenden Fluss. Entscheidend für diesen Vergleich sind kleine Entwicklungsschritte und regelmäßige Rückmeldungen.

Versionsverwaltung zeichnet gespeicherte Änderungen am Code und ihre Urheber auf. Ein Team kann frühere Programmstände vergleichen und wiederherstellen. Das hilft auch, widersprüchliche Änderungen mehrerer Entwickler zu erkennen und geordnet zusammenzuführen. Solche Konflikte verschwinden dadurch nicht von selbst; das Team muss sie lösen.

Tests vergleichen tatsächliches und erwartetes Verhalten. Neben üblichen Eingaben sind Grenzfälle wichtig, also Eingaben am Rand des vorgesehenen Bereichs, sowie ungültige Eingaben und unerwartete Handlungen. Ein Test kann zum Beispiel prüfen, wie das Programm auf ein leeres Pflichtfeld reagiert. Bestandene Tests zeigen das Ergebnis der geprüften Fälle. Sie beweisen nicht, dass jedes mögliche Verhalten fehlerfrei ist.

Bei einem Code-Review prüft ein anderer Entwickler den Code. Er kann beispielsweise Verständlichkeit, Aufbau, passende Namen und vorhandene Tests untersuchen. Ein Review ergänzt die Ausführung von Tests: Das Lesen des Codes kann andere Probleme sichtbar machen als ein Testlauf. Auch ein Review garantiert keine vollständige Fehlerfreiheit.

Refactoring bezeichnet den schrittweisen Umbau der inneren Struktur, bei dem das beobachtbare Verhalten erhalten bleibt. Beobachtbar ist, was das Programm bei gleichen Eingaben unter gleichen Bedingungen nach außen tut, etwa welche Ergebnisse oder Meldungen es liefert. Ein solcher verhaltenserhaltender Umbau soll den Code verständlicher und leichter änderbar machen. Eine zusätzliche Funktion gehört dagegen nicht zu diesem Umbau, weil sie das Verhalten erweitert.

Kleine Änderungen und wiederholte Tests unterstützen den Umbau. Eine einzelne unveränderte Ausgabe beweist aber noch nicht, dass sämtliches Verhalten gleich geblieben ist. Vorhandene Tests können auch nach dem Hinzufügen einer Funktion weiterhin bestehen. Ihr Bestehen macht aus der Erweiterung keinen verhaltenserhaltenden Umbau.