Während der Implementierung wird das strukturelle Gerippe des Designs mit funktionalen Details aus der Spezifikation aufgefüllt. Hierbei gibt es grundsätzlich zwei Vorgehensweisen: Manuelle Codierung in einer Programmiersprache und Codegenerierung aus Modellen (UML-Diagramme). Die zweite Vorgehensweise kommt nicht ganz ohne die erste aus, erspart aber das Schreiben der Code-Rahmen und hält die Verbindung zum Modell. Als Qualitätskriterien für die Implementierung stehen dabei im Vordergrund:
Korrektheit: Was in der Spezifikation steht, muss korrekt umgesetzt werden. Requirement Engineering hat unter anderem die Aufgabe, das zu dokumentieren.
Fehlerfreiheit: Fehler passieren, der Autor eines Codes liest sein Produkt aber grundsätzlich kontextbehaftet. Zwei zusätzliche Augen im Rahmen von Code Reviews sehen offensichtliche Fehler auf Anhieb.
Fehlervermeidung: Die bei uns vorwiegend genutzte Sprache C/C++ beinhaltet etliche Konstrukte, die Fehlerrisiken darstellen. Sourcecode-Checker (z.B. MISRAChecker) decken solche Risiken auf.
Fehlertoleranz: » . . . Der Wert wird nie im Leben größer als 95!« Nicht dran glauben, abprüfen und mit einer geordneten Fehlerbedingung zurückkommen, wenn es doch passiert, und das ist frühestens beim ersten Abnahmetest der Fall.
Portierbarkeit: Gerade bei C gibt es Konstrukte, die architekturspezifisch sind. Bekanntestes Beispiel ist der Datentyp int, der bezüglich Wortlänge von der Sprache her undefiniert ist.
Verständlichkeit: codieren, nicht chiffrieren! Der Code sollte verständlich und selbstdokumentierend sein. Sprechende Namen, übersichtliche Gliederung, nachvollziehbare Einrückung, wenn Kommentare, dann aussagekräftig. Die Tests sind eigentlich nicht als Phase zu bezeichnen, da sie den gesamten Entwicklungsprozess begleiten, in unterschiedlicher Tiefe und mit unterschiedlicher Abstraktionstiefe.
Modultest: Muster des Whitebox-Tests; jedes codierte Modul wird in einer geeigneten Testumgebung auf seine Korrektheit geprüft.
Integration – setzt den Bausatz aus Modulen zum Gesamtsystem zusammen und beweist, dass die Softwarebausteine so zueinander passen, wie das geplant war.
Inbetriebnahme, Abnahme: Sie beweist, dass die Software in ihrer Laufzeitumgebung das richtige tut.
Wartung: Sie ist keinem Entwicklungsprozess mehr zugeordnet, reagiert auf Änderungen der Laufzeitumgebung, beseitigt unentdeckte Fehler.
Die Qualitätskriterien dabei sind eine hohe, möglichst vollständige Testabdeckung, Reproduzierbarkeit und die vollständige Protokollierung. Bei einem Rückblick auf das V-Modell ergeben sich damit folgende Zusammenhänge: Je tiefer man im V ist, umso verzahnter und umso mehr bestimmt die Entwicklungsphase, welche Tests durchzuführen sind. Je höher man im V ist, desto intensiver muss die Planung der Tests sein und umso abstrakter (viel Code-Umfang) sind die Tests. Auch die Tests lassen sich manuell oder automatisiert durchführen, wobei letzteres bei der Komplexität heutiger Systeme unbedingt zu bevorzugen ist. Auch Tests und Testfälle lassen sich mit UML darstellen/modellieren.
In allen genannten drei Produktivphasen entsteht Qualität, jeweils unter verschiedenen Gesichtspunkten. Alle Phasen haben als wesentlichen Bestandteil die Kommunikation zwischen Menschen. Ein gesundes Qualitätsbewusstsein und die uneingeschränkte Kommunikationsbereitschaft kommen jeder QA-Maßnahme zuvor und unterstützen sie damit. Kleinere Organisationseinheiten sind dabei einfacher und sicherer zu handhaben als große. UML als gemeinsames Kommunikationsmittel ist standardisiert und eingeführt. UML ohne geeignete Werkzeuge ist jedoch wenig sinnvoll. Das bietet den Einstieg in modellbasierte Methodiken an: Modellbasierte Entwicklung über alle Phasen vereinheitlicht und vereinfacht damit das Vorgehen und führt zu einer höheren Prozessqualität.