IT-Projekte: Die Harmonie zwischen Produktivität und Qualität

Produktivität und Qualität sind zwei essentielle Kennziffern in jedem Softwareprojekt. Wir sollten daher immer in der Lage sein, in konkreter Form und mittels einer einfachen Datenanalyse Fragen wie diese zu beantworten: Wie ist es um die Produktivität bei dem Projekt bestellt? Welche Qualität hat das entwickelte Programm oder haben die neu implementierten Funktionen?

Die Antworten auf diese Fragen sollten nicht aus dutzenden von Indikatoren bestehen, von denen viele unterschiedliche Funktionen in dem Projekt aufweisen und schwierig zu vergleichen sind, sondern aus einem einfachen Datengerüst, das auf alle Projekte angewendet werden kann. Wenn es um die Frage nach möglicher Verschwendung von Arbeitsaufwand geht, erwartet man in ähnlicher Form eine Prozentzahl (geplanter Aufwand im Vergleich zu wirklich eingesetztem Aufwand) unabhängig von der Technologie, dem Typ oder der Größe des Projektes. Wenn wir Qualität und Produktivität verschiedener Projekte vergleichen, sollten wir in der Lage sein zu erkennen, warum die Produktivität oder die Qualität der einen besser ist als die der anderen. Diese offensichtlich einfache Frage (also die nach dem Warum) ist grundlegend, um Verbesserungsprozesse voranzubringen, vor allem wenn die Informationsbasis solide ist und man der Versuchung widerstanden hat, kleinere Schönheitskorrekturen anzubringen, um auf dem Foto schöner auszusehen.

Produktivität und Qualität immer zusammen denken

Produktivität und Qualität sollten sich nicht alleine auf den Weg machen, das eine ohne das andere. Wenn man die Produktivität zu sehr betont, ohne die Qualität des finalen Produktes zu beachten, riskiert man letztlich verbesserungswürdige Produkte. Wenn man sich im Gegensatz dazu allein auf die Qualität konzentriert, könnte das Ergebnis in Produkten bestehen, die kaum wettbewerbsfähig sind, was aber offensichtlich in bestimmten Fällen durch die kritische Masse des Produktes selbst begrenzt wird. Das oberste Ziel ist es daher, gleichzeitig die höchste Produktivität und die höchste Qualität zu erzielen.

Kennzahlen sind essenziell, müssen aber bewertet werden

Obwohl zu Beginn die Kennzahlen für Produktivität und Qualität eines Projektes den Eindruck vermitteln können, sie seien banal und einfach, sind sie das nicht immer. Für irgendeine dieser Zahlen benötigt man den Umfang des realisierten Softwareprojektes, der Anwendung oder der neu implementierten Funktionen. Andererseits ist es wichtig, den Umfang des Produktes nicht in Relation zu den eingesetzten Ressourcen zu setzen. Nicht immer ist das mit dem größten Aufwand realisierte Produkt tatsächlich größer oder umgekehrt. Stellen wir uns für einen Moment eine identische Software vor, die von zwei Unternehmen entwickelt wird. Obwohl das erste Unternehmen 10 Prozent weniger Zeit braucht als das zweite, um das Projekt zu entwickeln, ist der Umfang der beiden Projekte identisch. Unter den gebräuchlichsten Methoden, um den Umfang eines Programms mit neuen Funktionen oder schon existierenden, modifizierten Funktionen festzustellen, finden wir solche, die auf dem erstellten Code basieren: je mehr neu erzeugter oder veränderter Code desto größer der Umfang. Unter diesen Methoden basiert eine auf den reinen Zeilen des Codes (LOC; Lines Of Code), wobei es verschiedene Kriterien gibt, was als Codezeile angesehen wird, wiederum basierend auf den Sätzen desselben oder inklusive des Backfiring. Es ist klar, dass diese Methoden zumindest diejenigen zufrieden stellen, die das Einfache kompliziert gemacht haben oder den Programmiercode nicht korrekt strukturiert haben, indem sie die gleichen Befehle an verschiedenen Stellen wiederholen. Andererseits haben wir den funktionalen Umfang (FSM; Functional Size Measurement), der als Standard innerhalb der ISO/IEC 14143-1:1998 und 14143-1:2007 definiert ist. Diese Größe basiert auf den Funktionen, die das Programm dem Nutzer zur Verfügung stellt. Zugleich sind die verschiedenen Standardmethoden des funktionalen Umfangs als ISO/IEC-Standards anerkannt. iStock_000030568844_Small Eingesetze Ressourcen messen

Die eingesetzten Ressourcen im Verhältnis zum Umfang des Projektes ergeben die Produktivität. Diese ist wesentlich um die Produktivität unterschiedlicher Typen von Projekten zu vergleichen: lokalisierte vs. nicht lokalisierte; große vs. kleine Projekte; Projekte, die in einer Region der Welt entwickelt wurden vs. solche, die in einer anderen entwickelt wurden. Außerdem ist es notwendig, die Produktivität der Projekte anhand von Standardindikatoren zu vergleichen oder die Tendenzen der Produktivität zu erkennen, nachdem Änderungen bei der Entwicklung oder der Methodologie vollzogen wurden. Das Ziel dabei aus Sicht der Zahlen liegt im Erkennen von Optimierungsmöglichkeiten sowie in der Fähigkeit Fragen zu beantworten wie: Um welche Größe hat sich die Produktivität verbessert, nachdem eine neue Methode implementiert wurde oder eine Reihe von Veränderungen in Kraft getreten sind? Um wie viel Prozent sind Agile-Projekte produktiver – oder weniger – als Waterfall-Projekte? Viele dieser Fragen belegen eindeutig die ROIs von Veränderungen und umgesetzten Verbesserungen, obwohl diese Produktivität Hand in Hand mit der Qualität vorankommen sollte, so wie oben erwähnt.

Qualität ist messbar

Bei einem Großteil der Fälle ist der Indikator für Qualität mit dem Standardkonzept der Fehlerhäufigkeit verbunden, welche sich aus der Anzahl der Fehler im Vergleich zum Umfang des Produktes ableitet. Obwohl wir es mit einer Standardgröße des Marktes (Defect Density) zu tun haben, liefert diese als solche in vielen Fällen nur wenig kohärente Ergebnisse. In diesem Fall ist es notwendig das Konzept “Fehler” zu verfeinern, wie zum Beispiel bei der Messgröße “Fehleranzahl”. Denn in manchen Fällen kann etwas als 1 Fehler gezählt werden (zum Beispiel wenn eine Tabelle vier falsch angebrachte Spalten aufweist), was andererseits auch als 4 Fehler angesehen werden kann (einer für jede der vier falschen Spalten, insbesondere wenn diese zu verschiedenen Zeiten entdeckt wurden). Oder man richtet sich nach dem Aufwand, der notwendig ist, um den Fehler zu beheben (ein Fehler, der sich in 15 Minuten beheben lässt, in Unterschied zu einem, für den man mehrere Tage benötigt). Die Fehlerauswirkungen sind eine weitere fundamentale Größe: Manchmal stehen wir vor ästhetischen Fehlern (die Ausrichtung einer Spalte, wie in dem Beispiel oben) während in anderen Fällen ein Fehler wesentlich schwerwiegendere Konsequenzen haben kann (zum Beispiel ein Rechenfehler). Man kann auch noch weitere Faktoren einfließen lassen wie zum Beispiel die Projektphase, in der der Fehler entstand, der notwendige Testaufwand für die andere Teile des Programms (regression test), die Nichtverfügbarkeit des Systems usw. Derartige kohärenten und vergleichbaren Informationen machen es möglich, die Fehler richtig einzuordnen.

Harmonie zwischen Produktivität und Qualität essenziell

Obwohl wir momentan in einen Bereich niedriger Produktivität gezwungen werden, mittels niedriger Produktivkosten um konkurrenzfähig zu sein, ist die Harmonie zwischen Produktivität (die sich früher oder später in Kosten übersetzt) und Qualität essenziell, um das beste Verhältnis zwischen Qualität und Preis zu erhalten, um das Ziel einer höheren Produktivität und gleichzeitig einer höheren Qualität zu realisieren. Aber deshalb, wie wir oben festgestellt hatten, sollten wir fähig sein, mit einfachen Daten auf so einfache Fragen zu antworten wie: Wie ist es um die Produktivität bei diesem Projekt bestellt? Welche Qualität hat das entwickelte Programm oder die neu implementierten Funktionen? Oder auch: Um wie viel hat sie die Produktivität und/oder die Qualität nach der Implementierung bestimmter Änderungen verbessert?

Core Application Renewal

Finanzhäuser gleichen teils Technologiemuseen: Die digitale Transformation beginnt im Backend. Zu unserem neuesten Whitepaper:

Read more