Handwerk · 04. April 2013

SW-Qualität in PHP-Projekten | Testbasierte Entwicklung verkaufen [03]

Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.

Aufwände für Software-Entwicklung

Buchcover | Link zu Amazon — Link zu Amazon

Realistische Aufwände erfolgreich zu verhandeln fällt vielen Software-Teams schwer. Viele herkömmliche Verträge und Anforderungsdefinitionen beziehen sich vorwiegend auf die Beschreibung von Funktionen und Funktionalitäten, die mit der Software realisiert werden sollen.

Durch diese Reduktion in der Darstellung werden wesentliche Elemente der Software-Ent- wicklung nicht genannt. Tabelle 1 zeigt die Kostenbeiträge in der Software-Entwicklung.

	Sichtbar	Unsichtbar
Positiv	Neue Funktionen Neue Funktionalität	Grundlagen-Funktionen (Framework, interne API)
Negativ	Fehler	Technische Schulden

Tabelle 1: Kostenbeiträge in der Software-Entwicklung

Zum einen ist es die Aufgabe des Software-Teams im Sinne der Geschäftsziele des Auftraggebers beziehungsweise der Auftraggeberin einen positiven Beitrag zu leisten. Der positive Beitrag zu den Geschäftszielen geschieht für den Auftraggeber beziehungsweise die Auftraggeberin sowohl deutlich sichtbar als auch im Geheimen:

Funktionen und Funktionalitäten sind in der GUI der Software sicht- und nutzbar. Viele Software-Teams scherzen daher: „Das Maß für Qualität zeigt sich in der perfekten GUI am Abgabetag des Projekts!“ Tatsächlich hat diese Qualität eine besondere Bedeutung für den Auftraggeber beziehungsweise die Auftraggeberin. Sie ist sichtbar. Hier kann der Auftraggeber beziehungsweise die Auftraggeberin mitsprechen.

Für Software-Teams ist die sich daraus ergebende Überbetonung diesen Kostenblocks schwer nachvollziehbar. Gehört es doch zu ihrer täglichen Arbeit, sich mit allen vier Bereichen auseinanderzusetzen.
Darüber hinaus entwickelt das Software-Team Grundlagen-Funktionen. Dazu gehören die Bereitstellung eines Frameworks genauso wie die Definition einer API zur Verarbeitung von Daten. Diese Funktionalitäten sind für den Auftraggeber beziehungsweise die Auftraggeberin nicht direkt sichtbar.

Macht das Software-Team allerdings einen Fehler bei den Grundlagen-Funktionen, so werden diese indirekt in der GUI beziehungsweise in Daten sichtbar. Für den Auftraggeber beziehungsweise die Auftraggeberin ist dieser Teil der Software-Entwicklung Mystik. Man löst durch eine GUI-Aktion eine Funktion in der Software aus, die womöglich an ganz anderer Stelle einen Fehler produziert.
An der grundlegenden Entscheidung über ein Vorgehensmodell wie einer testbasierten Entwicklung nach den architektonischen Software-Entscheidungen wird der Auftragge- ber beziehungsweise die Auftraggeberin beteiligt. Die nachfolgenden Ergebnisse – sowohl die Vorteile als auch die Nachteile – sind dem Auftraggeber beziehungsweise der Auftraggeberin nicht bekannt. Nachteile können zum Thema werden, wenn sie direkten Einfluss auf die externe Qualität nehmen.

Das Software-Team hat nicht nur für einen positiven Beitrag zum Geschäftsziel zu sorgen – das Software-Team muss auch dafür sorgen, dass möglichst kein negativer Beitrag für das Projekt entsteht:

Fehler jedweder Art während des Betriebs sind ein negativer Beitrag zum Software- Projekt. Diese Fehler sind sichtbar. Oftmals sind sie auch Anlass für Ärger und Konflikte zwischen dem Software-Team und dem Auftraggeber beziehungsweise der Auftraggeberin. Es kostet Aufwand, diese Fehler zu beheben.

Es liegt im Interesse aller Beteiligten, dass das Software-Team möglichst wenige Fehler macht. Das Software-Team muss sicherstellen, möglichst viele Anforderungen korrekt umgesetzt zu haben. Falls Fehler vorhanden sind, sollten diese schnell behebbar sein. Um das zu gewährleisten, muss die Software qualitätsvoll umgesetzt sein.
Ist ein System von geringer interner Qualität, ist es technisch hoch verschuldet. Lange Fehlerbearbeitungszeiten zeugen davon. Technische Schulden sind damit ein unsicht- barer, negativer Beitrag zum Geschäftsziel.

Es liegt im Interesse des Software-Teams und des Auftraggebers beziehungsweise der Auftraggeberin, dass Fehlerbehebung im und Erweiterungen am System schnell und zu- verlässig realisierbar sind.

Damit die Arbeit des Software-Teams durch den Auftraggeber beziehungsweise die Auftraggeberin gewertschätzt und damit auch angemessen bezahlt werden kann, müssen diese Leistungen und die resultierenden entsprechenden Aufwände bekannt sein. Wäh- rend der Angebotsvorbereitung sollte daher das Software-Team für alle vier genannten Kostenblöcke entsprechende Vorgehensmodelle entwickeln. Diese sind während der Ver- handlung mit dem Auftraggeber beziehungsweise der Auftraggeberin abzustimmen. Tabelle 2 zeigt Beispiele für Vorgehensmodelle zur Steigerung eines Geschäftsbeitrags.

	Sichtbar	Unsichtbar
Positiv	Workshop: User Stories richtig schreiben Feedback-Schleife (Zeit) für Korrektur der User Stories einplanen	Technischer Workshop zur Erläuterung des Frameworks ATAM zur Darstellung der Entscheidun- gen (siehe auch Teil 5)
Negativ	Unit- und Integrationstests Selenium Testprotokolle manueller Tests	Regelmäßiges Review Pair Programming

Tabelle 2: Beispiele für Vorgehensmodelle zur Steigerung eines Geschäftsbeitrags

Durch die Offenlegung dieser Maßnahmen bekommt der Auftraggeber beziehungsweise die Auftraggeberin ein klares Bild von den tatsächlichen Arbeiten im Software-Team. Eine gemeinsame Entscheidung für das richtige Aufwandsmaß fällt so leichter.

Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.

Tags: SWQualitaetInPHPProjekten, JudithAndresen

Kommentar schreiben

Kommentare: 0