Software-Entwicklungs-Prozess
Einführung
Ein Softwareentwicklungsprozess beschreibt das Vorgehen bei der professionellen („ingenieursmäßigen“) Anwendungsentwicklung. Es dient dazu, die Softwareentwicklung übersichtlicher zu gestalten und in der Komplexität beherrschbar zu machen. Das Ergebnis des Software-Entwicklungsprozess ist eine Lösung, die den Anforderungen des Auftraggebers genügt und einen geringen Wartungsaufwand nach sich zieht.
Phasen
Es gibt unterschiedliche Typen von Softwareentwicklungsprozessen. Folgende Phasen sind grundsätzlich in allen Softwareentwicklungsprozessen vorhanden.
Anforderungsanalyse
Ziel ist es, die Anforderungen des Auftraggebers für alle beteiligten verständlich, übersichtlich und vollständig zu erfassen. Die Anforderungen müssen niedergeschrieben oder in Modellen spezifiziert werden. Der Fokus liegt auf der fachlichen Beschreibung. Wenn möglich, ist auf technische Details zu verzichten. Bereits die Analyse kann objektorientiert unter Einsatz der UML erfolgen. Anwendungsfall, Aktivitäts- und Klassendiagramme sind geeignet, das zu erstellenden System fachlich zu beschreiben.
Gilt es eine Datenbank zu entwickeln wird in dieser Phase meist das Entity-Relationship-Diagramm eingesetzt, um benötigte fachliche Daten zu sammeln und deren fachlichen Zusammenhang deutlich zu machen.
Ermittlung
Beim Sammeln der Anforderungen ist der Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung. Folgende Kriterien sind zu erfüllen:
vollständig: Alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.
eindeutig definiert / abgegrenzt: Präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.
verständlich beschrieben: Damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamten Anforderungen lesen und verstehen kann.
atomar: Es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein „Atom“ sollte die Entscheidbarkeit einer Anforderung sein.
identifizierbar: Jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung oder Nummer).
einheitlich dokumentiert: Die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.
nachprüfbar: Die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden. Testfälle müssen aus den Abnahmekriterien ableitbar sein.
rück- und vorwärtsverfolgbar: Es muss nachverfolgbar sein, ob eine Anforderung vollständig erfüllt wurde (vorwärts). Ebenso soll für jede implementierte Funktionalität kontrollierbar sein, aufgrund welcher Anforderungen sie erstellt wird (rückwärts), um Überflüssiges zu vermeiden.
konsistent: Die definierten Anforderungen sind untereinander widerspruchsfrei.
Prüfung
Es folgt die Qualitätssicherung der Anforderungen nach diesen Qualitätsmerkmalen:
korrekt: Die Anforderungen müssen untereinander widerspruchsfrei sein.
machbar: Die Anforderung muss realisierbar sein.
notwendig: Was nicht vom Auftraggeber gefordert wird, ist keine Anforderung.
priorisiert: Es muss erkennbar sein, welche Anforderungen die wichtigsten sind. Ziel der Priorisierung ist es, häufig benötigte oder dem Kunden besonders wichtige Funktionen vor den weniger häufig benötigten bereitzustellen.
nutzbar, nützlich: Auch bei teilweiser Realisierung soll bereits ein produktives System entstehen.
Die Bewertungen stehen teilweise in Konkurrenz zueinander. Das Ergebnis der Anforderungsaufnahme ist eine Liste mit Anforderungen aus Kundensicht, die in ein Lastenheft überführt werden. Das Ergebnis der Analyse stellt die Grundlage für das Pflichtenheft dar, welches im Rahmen der folgenden Designphase erstellt wird.
Design
Softwaredesign (auch Softwareentwurf) ist der Prozess zur Planung einer Software-Lösung. Softwaredesign ist in aller Regel erforderlich, um die Komplexität, welche die meisten Computerprogramme aufweisen, für die Programmierer handhabbar zu machen und das Risiko von Fehlentwicklungen zu verringern. Insbesondere im Hinblick auf die Wartbarkeit einer Lösung, ist der Prozess des Designs gewissenhaft zu durchlaufen.
Auf Grundlage der Anforderungsanalyse erarbeitet der Auftragnehmer zusammen mit dem Auftraggeber über verschiedene Vorgehensweisen ein Konzept. Hier wird festgelegt, mit welchen Techniken und Algorithmen diese Anforderungen erfüllt und programmiert werden sollen. Der Auftragnehmer hält die Ergebnisse dieses Konzepts in dem sogenannten Pflichtenheft fest.
Spätestens in der Designphase sollte auf objektorientierte Ansätze zurückgegriffen werden, um das System zu planen. UML Klassendiagramme beschreiben fachlich relevante Klassen und ergänzen sie um technische Notwendigkeiten. Komplexe Objektinteraktionen können in Sequenzdiagrammen geplant werden. Eng abgrenzbare Algorithmen können auch in einem Struktogramm modelliert werden.
Grundlegende Architekturentscheidungen werden getroffen. Die Datenhaltung in einer Datenbank kann mit Hilfe von ERMs modelliert werden.
Am Ende der Designphase steht ein Lastenheft, das beschreibt, wie der Auftragnehmer, die beschriebenen Anforderungen (Pflichtenheft) umsetzen wird. Erst dann erfolgt gegebenenfalls eine Beauftragung durch den Auftraggeber.
Programmierung
Nach der erfolgreichen Beauftragung können die Software-Entwickler beginnen, die Lösung gemäß Design-Vorgaben umzusetzen. Hierfür werden in der Regel objektorientierte Programmiersprachen wie z.B. Java in Kombination mit Entwicklungsumgebungen eingesetzt. Meist wird weitere Systemsoftware benötigt, um Mehrschichten-Architekturen zu realisieren. Datenbankmanagementsysteme (DBMS) sind ein fester Bestandteil komplexer Systeme. Um Projektstände zwischenzuspeichern und gemeinsam auf einer Codebasis arbeiten zu können, werden zudem häufig Versionsmanagementsysteme eingesetzt.
Jeder Entwickler stellt sicher, dass die Anforderungen des Kunden gemäß der Designvorgaben in seinem Zuständigkeitsbereich umgesetzt werden.
Die eigentliche Programmierung lässt sich noch in weitere Phasen unterteilen.
Die Übersetzungszeit (engl. compile time) als Phase bis zum Zeitpunkt der Übersetzung des Quelltextes und
die link time für den Zeitpunkt, zu dem das Programm aus seinen binären Programmkomponenten zu einer ausführbaren Einheit zusammengeführt wird.
Manchmal wird die Phase des eigentlichen Programmierens und Modellierens als precompile time bezeichnet.
Test
Während der Testphase wird geprüft und bewertet, ob die erstellte Software die definierten Anforderungen erfüllt. Neben einzelnen Komponenten und Modulen wird auch das gesamte System überprüft. Die gewonnenen Erkenntnisse werden zur Erkennung und Behebung von Softwarefehlern genutzt. Tests während der Softwareentwicklung dienen dazu, die Software möglichst fehlerfrei in Betrieb zu nehmen. Den Nachweis, dass keine Fehler (mehr) vorhanden sind, kann die Testung nicht erbringen. Es kann lediglich festgestellt werden, dass bestimmte Testfälle erfolgreich waren. Hierfür müssten alle Kombinationsmöglichkeiten aus vorliegenden Daten und Funktionsaufrufen durchgespielt werden, was in der Praxis nur für sehr kleine Systeme geleistet werden kann.
Systeme sollten nie von den Entwicklern getestet werden, die sie auch entwickelt haben (Thaller, G. E.: Software-Test. Verifikation und Validation.; 2002; ISBN 3-88229-198-2). Der Programmierer kennt sein eigenes Programm und er würde keine oder kaum Fehler finden, die er nicht schon während der Programmierung beseitigt hätte. Er ist in der Regel nicht in der Lage, sich von seinem Sourcecode in genügendem Maße zu distanzieren, um objektiv testen zu können.
Ein Testen ist nur dann sinnvoll, wenn für definierte Eingaben entsprechende Soll-Ausgaben definiert werden. Dies setzt die Existenz von Soll-Werten voraus. Ansonsten würde der Tester bei einer alleinigen Betrachtung der Ausgabeergebnisse versuchen, die Ergebnisse zu interpretieren und evtl. zu dem fehlerhaften Schluss kommen, dass sich das Programm „logisch korrekt“ verhält. Die Definition von Eingabewerten und Soll-Ausgaben sind idealerweise Bestandteil der Anforderungsanalyse.
Tests lassen sich grob in dynamische und statische Tests einteilen. Dynamische Tests werden zur Laufzeit durchgeführt. Statische Tests werden ohne Computernutzung, nur durch Überlegungen durchgeführt.
Bereitstellung
Die Entwicklung wird meist in einer eigenen Umgebung betrieben. Es wird versucht, möglichst ähnliche Bedingungen zu schaffen wie bei der Zielumgebung. Wirklich alle Fehlerquellen wird man bei der Simulation der Zielumgebung nicht ausschließen können. Die Art der Anwendung beeinflusst die Bereitstellung erheblich. Webanwendungen stellen ganz andere Herausforderungen als z.B. eine Desktopanwendung. Wenn die Anwendung vollständig in die Zielumgebung integriert ist, ist die Bereitstellung abgeschlossen.
Das Programm befindet sich zur Laufzeit typischerweise in einer Verwendung in einem Kontext, der in dieser exakten Konstellation durch den Entwickler nicht (oder nur näherungsweise) vorhersehbar war.
Da nun beim Ausführen in diesen variierenden Kontexten bestimmte Programmeigenheiten – insbesondere Fehler – erstmals auftreten können, erhält der Entwickler häufig nur auf diesem Wege die Hinweise für notwendige Änderungen am Programm. Im weiteren Sinn kann somit auch die reguläre Ausführung eines Programms als Teil des Entwicklungsprozesses angesehen werden.
Abnahme
Der Auftragnehmer nimmt in der Regel das zu erstellende System in seiner Zielumgebung ab. In diesem Zusammenhang werden häufig Integrationstests durchgeführt, um zu testen, ob sich das System in der lokalen Umgebung verhält wie erwartet. Alle spezifizierten Anforderungen werden am System mit Hilfe von Blackboxtests überprüft. Mit der Abnahme der Software ist der Vertrag zwischen Kunde und Lieferant erfüllt.
Schulungen
Software ist ein soziotechnisches System. D.h. die Software beeinflusst durch die bereitgestellten Funktionen die Arbeitsweise von Menschen. Menschen beeinflussen durch ihre Anforderungen die Funktionsweise einer Software. Es gibt also eine Wechselbeziehung.
Jede Umstellung der Software ist mit dem Ablegen gewohnter Arbeitsweisen seitens der Anwender verbunden. Es muss sich lohnen, sich umzugewöhnen. Der Umgang mit der Software und ihre Vorteile müssen vermittelt werden, damit sie von ihren Anwendern angenommen und zu einem erfolgreichen Produkt wird.
Typen
Es gibt unterschiedliche Typen von Softwareentwicklungsprozessen. Eines der ältesten Modelle ist das Wasserfallmodell, das eine starre Abfolge der einzelnen Phasen annimmt. Weiterentwicklungen wie das Spiralmodell sehen hingegen Iterationen vor, d. h. ein und derselbe Arbeitsschritt (z. B. die Analyse) wird mehrmals durchlaufen und die Ergebnisse des Arbeitsschrittes pro Durchlauf verfeinert und verbessert.
Softwarelebenszyklusmanagement erweitert die Phasen über den gesamten Lebenszyklus einer Software. Das Vorgehensmodell definiert die Anforderungen an betriebliche Prozesse (das „WAS“) und beschreibt die konkreten, EDV-technisch realisierten Prozesse (das „WIE“).
Softwareentwicklungs-Philosophie entspricht einer Programmierer-Philosophie, einem bestimmten Ansatz, wie Software nach Ansicht der Akteure am besten entwickelt werden sollte. Diese Philosophien beinhalten sehr oft auch Prozesselemente und werden daher ebenfalls als Prozessmodell bezeichnet.
Extreme Programming
Prototyping
Rational Unified Process
Scrum