Richtlinie: Wichtige Entscheidungen in Implementierung
Diese Richtlinie beschreibt wichtige Punkte, die bei der Anpassung der Implementierungsaspekte des Prozesses zu berücksichtigen sind.
Beziehungen
Hauptbeschreibung

Verwendung der Arbeitsergebnisse festlegen

Sie müssen entscheiden, welche Arbeitsergebnisse verwendet werden sollen und wie. Außerdem müssen Sie jedes Arbeitsergebnis so anpassen, dass es den Anforderungen des Projekts entspricht.  

Die folgende Tabelle enthält eine Liste der empfohlenen und optionalen (die nur in bestimmten Fällen verwendet werden können) Arbeitsergebnisse aus der Disziplin Implementierung. Weitere Hinweise zur Anpassung finden Sie im Abschnitt "Anpassen" auf der Seite mit der Beschreibung des jeweiligen Arbeitsergebnisses.

Arbeitsergebnis Zweck

Anpassen (optional, empfohlen)

Implementierungsmodell

(Implementierungssubsystem, Implementierungselement)

Das Implementierungsmodell setzt sich aus Quellcode, ausführbaren Programmen und allen anderen Arbeitsergebnissen zusammen, die erforderlich sind, um das System in der Laufzeitumgebung zu erstellen und zu verwalten.

Eine Implementierung setzt sich aus Implementierungselementen zusammen, zu denen Code (Quellendateien, Binärdateien und ausführbare Programme) und Dateien gehören, die Informationen enthalten (z. B. eine Startdatei oder eine Readme-Datei).

Ein Implementierungssubsystem ist eine Sammlung von Implementierungselementen und anderen Implementierungssubsystemen und wird verwendet, um das Implementierungsmodell durch Aufteilung in kleinere Teile zu strukturieren.

Alle Softwareprojekte haben ein Implementierungsmodell mit Implementierungselementen, das als Minimum ein wenig Quellcode und ein paar ausführbare Programme umfasst.

Einige Projekte enthalten außerdem Subsysteme, Bibliotheken und visuelle Modelle.

Subsysteme sind hilfreich, wenn sehr viele Implementierungselemente organisiert werden müssen.

Build-Plan für Integration Definiert die Reihenfolge, in der die Komponenten implementiert werden sollen, welche Builds beim Integrieren des Systems erstellt und wie diese Builds bewertet werden sollen.

Optional.

Empfohlen, wenn Sie die Integration planen müssen. Der Build-Plan für Integration sollte nur weggelassen werden, wenn die Integration trivial ist.



Umfang der Einheitentests festlegen

Legen Sie den Umfang der Einheitentests und den Grad der Codeabdeckung auf einer Skala fest, die von formlos bis 100 % Codeabdeckung reicht. Diese Skala wird im Testplan beschrieben.

Der Grad der Codeabdeckung für die Einheitentests wird häufig vom Bedarf der Integrations- und Systemtester gesteuert, an die der Code übergeben wurde. Die Systemtester sind bei Ihrer Arbeit von der Qualität des Codes abhängig. Wenn der Code zu viele Mängel h at, senden die Integrations- und Systemtester den Code zu häufig an die Implementierer zurück. Dies ist ein Anzeichen für einen mangelhaften Entwicklungsprozess. Zur Lösung dieses Problems müssen die Implementierer unter Umständen angehalten werden, gründlichere Einheitentests durchzuführen.

Natürlich können Sie nicht erwarten, dass Code, der Einheitentests unterzogen wurde, völlig frei von Mängeln ist. Es muss jedoch eine "ausgewogene" Balance zwischen Einheitentests und Qualität erreicht werden.

Der Grad der Codeabdeckung während der Einheitentests kann in den unterschiedlichen Phasen variieren. Selbst ein sicherheitskritisches Projekt, das eine hundertprozentige Codeabdeckung in der Konstruktions- und Übergangsphase erfordert, setzt einen solchen Grad in der Ausarbeitungsphase nicht voraus, da in diesem Stadium viele Klassen nur teilweise implementiert werden.

Überprüfung des Codes festlegen

Legen Sie fest, in welchem Umfang der Code geprüft werden soll.  

Codeüberprüfungen haben die folgenden Vorteile:

  • Umsetzung und Förderung eines einheitlichen Codierungsstils im Projekt. Codeüberprüfungen sind eine effiziente Methode, um die Mitglieder des Projektteams zur Einhaltung der Richtlinien für die Programmierung zu bringen. Dabei ist es wichtiger, die Ergebnisse aller Autoren und Implementierer zu prüfen als alle Quellcodedateien.
  • Fehler finden, die von automatisierten Tests nicht gefunden werden. Codeüberprüfungen finden Fehler, die bei Tests nicht aufgedeckt werden.
  • Austausch von Kenntnissen und Wissenstransfer von den erfahrenen Mitarbeitern an die weniger erfahrenen.

Codeüberprüfungen haben die folgenden Nachteile:

  • Sie nehmen Zeit und Ressourcen in Anspruch.
  • Wenn sie nicht sorgfältig durchgeführt werden, können sie ineffizient sein. Es besteht die Gefahr, dass Codeüberprüfungen "nur durchgeführt werden, weil sie durchgeführt werden müssen", und nicht als effiziente Ergänzung der automatisierten Tests.

Weitere Informationen zu Codeüberprüfungen finden Sie auch in Aufgabe: Code prüfen.

Codeüberprüfungen können den Wert des Projekts erheblich steigern. Alle Projekte, die den Grad von Fehlern und Pflegeproblemen in Bezug auf Codeüberprüfungen messen, behaupten, dass sie damit die Leistung erhöhen. In vielen Organisationen ist es jedoch aus verschiedenen Gründen schwierig, Codeüberprüfungen in die Tat umzusetzen:

  • Es werden nicht genügend Daten erfasst, um festzustellen, ob die Codeüberprüfungen tatsächlich funktionieren.
  • Es werden zu viele Daten erfasst.
  • Implementierer sind sehr eigen, was ihren Code betrifft.
  • Die Überprüfungen bleiben in Formalitäten stecken.
  • Die Administration der Überprüfungen bedeutet zu viel Aufwand.

Beachten Sie die folgenden Punkte, um den meisten Nutzen aus Codeüberprüfungen zu ziehen:

  • Erfassen Sie nur adäquate Daten.
  • Ermitteln Sie die Leistung der Überprüfungen und zeigen Sie die Ergebnisse an.
  • Setzen Sie Überprüfungen auf eine "schlanke" Weise ein.

Weitere Informationen finden Sie in der Anleitung: Prüfebenen.