Softwareberichte liefern heute meist nur Ergebniskontrolle im Rahmen des Projekt-Managements. Ohne aussagekraeftige Daten laufen Produktivitaets- und Qualitaetsanalysen jedoch ins Leere. Robert Huerten* zeigt auf, wie ein modernes Berichtswesen beschaffen sein muss, damit es dem Software-Management als Entscheidungsgrundlage und der Unternehmensfuehrung zur Kostenkontrolle dienen kann.

Die Software-Entwickler fuehlen sich berufen, moderne und effektive Arbeitsablaeufe zu realisieren, doch vergessen sie dabei meist sich selbst. Erst in juengster Zeit werden Begriffe wie Controlling, Arbeitsanalyse, lang- und mittelfristige Planung sowie Produktivitaetssteigerung aufgegriffen und umgesetzt - weil auch bei der Software die Kostenentwicklung staerker verfolgt wird als in den letzten Jahrzehnten.

Das Verhaeltnis der Software-Entwickler zu betriebswirtschaftlichen Begriffen spiegelt sich deutlich wider im jeweiligen Berichtswesen, das sie sich selbst geschaffen haben. Es ist in der Mehrzahl aller Faelle nur auf eine Ergebniskontrolle aus der Sicht der Projektleitung ausgerichtet. Historien ueber abgeschlossene Projekte fehlen zumeist, Statistiken und Berichte sind unvollstaendig. So klagen beispielsweise Beratungsunternehmen, die Software-Benchmarking anbieten, dass ihnen jede Voraussetzung fuer ein sinnvolles Arbeiten fehlt.

Die Produktkontrolle fehlt in aller Regel

Die Mehrzahl der Berichte im Softwarebereich dient also nur zur Unterstuetzung des Projekt-Managements. Sie sind zweidimensional auf die Termin-/Kostenkontrolle ausgerichtet. Die dritte Dimension, die Produktkontrolle, fehlt.

Im Verlauf der Projekte bilden die Berichte die wichtigste Unterlage fuer den Projekt-Manager. Aus den Berichten kann er ersehen, ob die Zeitplaene zu halten sind. Die Berichtsabschnitte entsprechen meist den Phasen des jeweiligen Vorgehensmodells. Eine tiefere Untergliederung nach Arbeitsarten ist nur in wenigen Unternehmen anzutreffen. Ebensowenig unterscheiden die Betriebe nach Projektarten oder Entwicklungsplattformen.

Istzeiten werden zwar aufgeschrieben, dienen aber ausschliesslich der Kostenverteilung und nicht der Analyse des Projektverlaufs. Eventuelle Planabweichungen werden nicht festgehalten, also lassen sie sich auch nicht nutzen, um die Projektablaeufe zu verbessern. Fuer derartige Analysen sind die in den Berichten erfassten Informationen zu duerftig.

Ein Gesichtspunkt, der in den heutigen Berichtswesen voellig fehlt, ist die Verfolgung der Produktentwicklung im Hinblick auf Inhalt beziehungsweise Umfang sowie Qualitaet. Aus dem Berichtswesen ist nicht zu ersehen, ob sich die Realisierung an den urspruenglichen Vorgaben orientiert oder ob Aenderungen und Erweiterungen das Projekt aufblaehen. Ebensowenig lassen sich anhand der Berichte Qualitaet und Stabilitaet der Softwareprodukte ueber den Lifecycle verfolgen.

Fazit: Das Berichtswesen in der Software-Entwicklung hat so gut wie ueberall eine aeusserst geringe Aussagekraft. Es beschraenkt sich meist auf zwei Informationen: Zum einen wird erfasst, welche Mitarbeiter in welchen Projekten oder Projektphasen gearbeitet haben. Zum anderen wird aus diesen Aufzeichnungen und den Planzahlen fuer jedes Projekt ein Soll-Ist-Vergleich fuer Aufwand und Termine erstellt.

Im Vergleich zum Berichtswesen in der Industrie ist die Praxis in der Software-Entwicklung rudimentaer. Auch in ansonsten straff gefuehrten Unternehmen haben die Software-Entwickler zu grossen Spielraum in der Gestaltung ihres Berichtswesens. Zudem hatte das Berichtswesen in der Vergangenheit in der Mehrzahl der Faelle keinen ueber alle Entwicklergruppen und Zeitraeume hinweg einheitlichen Aufbau.

Analyse- und Planungsdaten lassen sich mit dem allgemein praktizierten Berichtswesen nicht gewinnen. Dazu reichen der Detaillierungsgrad der erfassten Daten beziehungsweise der Projektbeschreibungen nicht aus. Als Konsequenz daraus muss das Berichtswesen kuenftig weiter aufgefaechert werden, so dass es nicht nur Informationen zu den Kosten, sondern auch zur Verbesserung der Produktivitaet und der Softwarequalitaet ermoeglicht.

Ein modernes Berichtswesen darf nicht laenger nur ein Mittel zur Unterstuetzung von aktuellen Arbeitsgaengen sein. Es muss vielmehr auch Informationen liefern, aus denen das Management die Ursachen fuer Veraenderungen in der Produktivitaet und der Softwarequalitaet herauslesen kann. Beispielsweise sollte daraus hervorgehen, ob die Anschaffung von Tools zu einer Verbesserung der Produktivitaet gefuehrt hat oder ob sich der Aufwand fuer die ISO-9000- Zertifizierung in einer Qualitaetsverbesserung niedergeschlagen hat.

Zudem ist es sinnvoll, nach Projektarten, Entwicklungsumfeld, Teamzusammensetzung etc. zu differenzieren. Da die echten Neuentwicklungen immer seltener werden, sollten kuenftig auch die Projektklassen Softwarewartung sowie Standardsoftware und Outsourcing einbezogen werden.

Setzt man voraus, dass eine gute Produktqualitaet kein Zufall ist, so sollte das Berichtswesen verdeutlichen, warum eine Abweichung vom angestrebten Qualitaetsstandard auftritt. Also sind - unabhaengig von den Berichten zur Kosten- und Terminentwicklung - auch auf die Qualitaet ausgerichtete Berichte zu fuehren. In der operativen Phase der Software muss der Zusammenhang zwischen Wartungsaktivitaeten, Wartungsaufwand und Produktqualitaet sichtbar werden.

Statistische Klassenbildungen im Berichtswesen sind auch im Hinblick auf eine Qualitaetsanalyse notwendig. Allerdings muessen die Klassen hier nicht dieselben sein wie bei der Beobachtung der Produktivitaet. Vor der Bildung von Klassen muessen die Unternehmen und Behoerden erkennen, welche Faktoren ("Cost Drivers") Einfluss auf Produktivitaet und Qualitaet haben und was als Standard anzusehen ist.

Ein modernes Berichtswesen muss die Produkte, das Entwicklungsmilieu, den Projekt- und den Nutzungsverlauf beschreiben. Sinnvollerweise wird zunaechst ermittelt, welche Standards im Unternehmen erwartet werden. Auf der Basis dieser Grundinformationen lassen sich dann die Abweichungen aktuell erfassen. Beispiele fuer solche Standards sind: einheitliche Nutzung von SQL, durchschnittliche Teamgroesse von fuenf Mitarbeitern, Arbeiten nach dem Phasenkonzept und Nutzung einer einheitlichen Datenstruktur.

Die Klassen stehen nicht unabhaengig nebeneinander, sondern durchdringen sich gegenseitig. Fuer die Praxis bedeutet dies: Die Berichtsdatenbank muss so konzipiert sein, dass sie schnelle Umgruppierungen und Sortierungen zulaesst.

Jeder einzelne Anwender muss selbst die Ziele setzen, auf die sich sein Berichtswesen ausrichten soll. Nur er weiss, welche Informationen fuer die Optimierung seines Softwarebereichs noetig sind. Wenn trotzdem Betriebsvergleiche gewuenscht werden, so ist es wichtig, dass vergleichbare Berichte vorliegen. Das heisst: Die Berichtswesen der Firmen, die an dem jeweiligen Vergleich teilnehmen, sind aufeinander abzustimmen.

Bezueglich jedes Softwareprodukts sollten abgrenzbare Berichte fuer folgende Stadien erstellt werden:

-anstehende Projekte,

-laufende Neuentwicklungen,

-laufende Ergaenzungen oder Aenderungen,

-kontinuierliche Wartung waehrend der Nutzung und

-ruhende, nicht mehr aktive Software.

Die Summe aller Berichte ist als ein Anlageverzeichnis der Software zu betrachten. Es gibt die Entwicklung der Softwareprodukte wieder - von ihrer Planung bis zu dem Zeitpunkt, von dem an sie nicht mehr genutzt werden. Damit bilden die Berichte also sozusagen das Softwareportfolio.

Das Berichtswesen sollte schon bei der Planung einsetzen, damit konkrete Informationen ueber den "Anwendungsstau" eingeholt werden koennen. In ein Verzeichnis mit dem Titel "anstehende Projekte" sollten alle Projekte aufgenommen werden, deren Realisierung sinnvoll und wuenschenswert waere. Das ist eine wichtige Grundlage fuer Planungsgespraeche. Der "globale" Anwendungsstau loest sich dadurch in konkrete Projekte auf.

Wartungskosten wurden meist pauschal budgetiert

Eines der groessten Versaeumnisse besteht darin, dass bislang nur wenige Aufzeichnungen zur Wartung vorliegen. Unter diesem Begriff wurden undifferenziert alle Aktivitaeten subsummiert, die nach der Uebergabe der Software an die Anwender anfielen.

Erst in juengster Zeit unterscheiden die Unternehmen nach funktionalen Ergaenzungen oder Aenderungen einerseits und Fehlerbehebung oder technischen Anpassungen andererseits. Folglich wurden die Wartungskosten fuer Softwareprodukte bislang auch nicht kalkuliert, sondern mit zehn bis 15 Prozent von den Erstellungs- oder Anschaffungskosten budgetiert.

Die abschliessende Erstellung von Berichten ueber nicht mehr genutzte Software dient dem Aufbau einer Erfahrungsdatenbank, aus der Planungs- und Entscheidungsgrundlagen gewonnen werden koennen. Damit laesst sich beispielsweise die Frage beantworten, ob ein neues Tool Einfluss auf die Produktivitaet oder die Qualitaet hat und welche Produktivitaet eine Entwicklungsumgebung hervorbringt.

Projektgegenstand und Anwendungsumfang

Der Projektgegenstand laesst sich global durch die Beantwortung folgender Fragen beschreiben:

-Fuer welche Wirtschaftsbranche oder Verwaltung wurde die Software erstellt?

-Auf welchen Geschaeftsbereich ist sie ausgerichtet?

-Welchem Zweck soll sie dort dienen?

-Wer wird sie nutzen?

Fuer diese und aehnliche Fragen sollten im Sinn von Checklisten bereits verschiedene Antworten vorgegeben werden, damit einheitliche Daten in das Berichtswesen einfliessen.

Die Groesse einer Software kann unter drei Gesichtspunkten beschrieben werden: Aus der Sicht des Anwenders wird der Funktionsumfang angegeben, den die Software zur Verfuegung stellt

(Function Points). Fuer den Entwickler ist die Summe der Befehle und Datenelemente wichtig

(Lines of Code, Datapoints etc.).

Das Rechenzentrum schliesslich interessiert sich fuer die Hardware- Erfordernisse (notwendige Groesse der Haupt- und Plattenspeicher).

Die Beschreibung von allgemeinen Qualitaetsanforderungen birgt Probleme, weil eine fuer alle Unternehmen gueltige Formulierung und Bewertung aufgrund subjektiver Vorstellungen nicht moeglich ist. Qualitaetsansprueche koennen beispielsweise in Zeitverhalten oder Gestaltung der Benutzeroberflaeche beziehungsweise der Dokumentation bestehen.

Innerhalb einer Organisation sollte es jedoch moeglich sein, Qualitaetsansprueche zu formulieren. Abweichungen von dem allgemeinen Qualitaetsstandard eines Hauses muessen sich als Verschiebungen in der Produktivitaet der Software-Entwickler erkennen lassen und sind bei Planungen zu beruecksichtigen.

Nicht alle Teile eines Produkts stellen dieselben Anforderungen an die Qualitaet. So hat zum Beispiel das Qualitaetsmerkmal "Zeitverhalten" im Batchteil eines Produkts einen ganz anderen Stellenwert als im Dialogteil. Deshalb ist es sinnvoll, die Qualitaetsmerkmale auf die jeweiligen Projekte zu beziehen, in denen ein Produkt aufgebaut wurde, also nicht global auf das Produkt.

All die Faktoren, die Einfluss auf die Kosten, den Zeitaufwand und die Qualitaet einer Software-Entwicklung haben, sind in dem Begriff Entwicklungsmilieu zusammengefasst. Dazu zaehlen unter anderen das Betriebssystem, die Programmiersprachen und Entwicklungstools, die Groesse der Teams sowie die Erfahrungen der Mitarbeiter.

Bei den heute ueblichen unterschiedlichen Hard- und Softwarestrukturen sind in einem Unternehmen meist mehrere Entwicklungsmilieus zu erkennen. Jeder Software-Manager sollte die Faktoren, die sein Entwicklungsmilieu bestimmen, genau kennen und beobachten. Denn durch Veraenderungen in den Faktoren beeinflusst er die Produktivitaet der Software-Entwicklung. Die Arbeitsorganisation bei der Software-Entwicklung ist ein wichtiger Einflussfaktor. Darunter ist beispielsweise das Vorgehensmodell, aber auch die Aufteilung zwischen Fremd- und Eigenentwicklung zu verstehen.

Die Faehigkeiten der eingesetzten Mitarbeiter zu klassifizieren, ist eine diffizile Angelegenheit. Um Durchschnittswerte zu erhalten, ist es zweckmaessig, eine Beziehung zwischen dem Grad der Faehigkeiten und der Dauer der Zugehoerigkeit zur DV oder zur Firma herzustellen. Zu beachten ist, dass es sich dabei um personenbezogene Daten handelt.

Betriebssysteme, Programmiersprachen und Tools bestimmen als Arbeitsmittel entscheidend den Aufwand in der Software- Entwicklung. In der Vergangenheit wurde haeufig versucht, die Produktivitaet durch einen Wechsel dieser Arbeitsmittel zu verbessern. Wegen der lueckenhaften Berichte lassen sich heute nur in wenigen Faellen Aussagen darueber treffen, inwieweit sich diese Software-Investitionen gelohnt haben.

Heute befinden wir uns in einem Stadium des zunehmenden Einsatzes von Standardsoftware. Angesichts dieser Tatsache sollte in die Berichte folglich auch der jeweilige Aufwand fuer Anschaffung, Ergaenzungen und Veraenderung einfliessen.

Die Kompatibilitaet der Software zu unterschiedlichen Hardwareplattformen hat den Einfluss der Hardware auf die Kosten verringert. Trotzdem stellen Informationen ueber die Hardwarekonfigurationen nach wie vor eine wichtige Informationsbasis fuer die Entscheidungen des DV-Managements dar. In der Praxis zeigt sich, dass es immer noch die Hardware ist, die die Software massgeblich festlegt und von daher auch die Entwicklungsmilieus bestimmt. Bei den wenigen Anwendern, die bereits Entwicklungsmilieus definiert haben und damit arbeiten, tragen diese denn auch Hardwarebezeichnungen, also beispielsweise Host- oder Client-Server-Milieu.

Aufwandsverschiebungen lassen Trends erkennen

Informationen ueber den Projektverlauf zu gewinnen, ist aus zwei Gruenden sinnvoll: Zum einen kann der Projektleiter anhand solcher Unterlagen sein Projekt kontrollieren und steuern, zum anderen lassen sich auf der Grundlage dieser Informationen die Schwachstellen, aber auch die Staerken in der Software-Entwicklung erkennen. Damit steht also eine Entscheidungsgrundlagen fuer Produktivitaets- und Qualitaetsverbesserungen zur Verfuegung.

Die Beschreibungen des Projektverlaufes bauen auf den Berichten der Mitarbeiter auf. Um die Berichte als Management-Grundlage nutzen zu koennen, sind im Vergleich zur heutigen Situation nur wenige zusaetzliche Angaben notwendig.

Die Berichte muessen die Moeglichkeit schaffen, den Aufwand und den Verlauf der einzelnen Phasen oder Abschnitte eines Projektes zu verfolgen. Dafuer gibt es zwei wesentliche Gruende: Erstens erkennt der Projektleiter aus der Gegenueberstellung von Ist- und Planzahlen, ob er Termine und Kosten einhalten wird, und kann gegebenenfalls gegensteuern. Zweitens ist der Software-Manager in der Lage, anhand von Aufwandverschiebungen zwischen den Phasen Trends zu erkennen, auf die er mit personellen oder technischen Massnahmen reagieren muss.

Heute findet sich selten ein Berichtswesen, das die Arten der Taetigkeiten in den einzelnen Phasen festhaelt. Dabei benoetigt der Software-Manager solche Informationen eigentlich, um mittel- und langfristig Personal, Toolunterstuetzung oder Organisation zu planen.

Die Dauer der einzelnen Taetigkeiten sollten nicht global ueber einen laengeren Zeitraum verdichtet werden. Auch wenn sich Widerstand bei den Mitarbeitern regt: Es ist wichtig, die Taetigkeiten mit ihren Aufwaenden zeitgerecht, also tag- oder sogar stundengenau zu erfassen.

In der Software-Entwicklung sind dieselben Ansprueche an die Berichte zu stellen wie in der Fertigungsindustrie. Die Berichte dienen also nicht nur dazu, den Aufwand fuer die Aktivitaeten zu belegen, sondern auch dazu, Arbeitsrhythmen und -reihenfolgen sowie Unterbrechungen durch andere Projekte zu erkennen.

Qualitaet und Nutzungsgrad

Diese Informationen sind ebenfalls wichtig fuer das Software- Management. Beispielsweise leidet die Produktivitaet in einer Neuentwicklung stark darunter, wenn Mitarbeiter immer wieder kurzfristig fuer Wartungsaktivitaeten an abgeschlossenen Projekten benoetigt werden.

Eine hohe Bedeutung ist dem Aufbau eines Berichtswesens fuer die Wartungsarbeiten einzuraeumen. Wenn mehr als die Haelfte der Programmierkapazitaeten fuer Wartungsarbeiten eingesetzt wird, dann muss diesem Bereich sicherlich besonderes Augenmerk gelten. Eine Analyse setzt jedoch detaillierte Informationen ueber Art und Zeitpunkt der Aktivitaeten voraus. Dabei wird sich zeigen, dass die heutige Annahme eines gleichbleibenden Aufwands ueber die Jahre der Nutzung hinweg nicht mehr zu halten ist.

Fuer das Management des Softwarebereichs reicht es nicht, nur Informationen ueber laufende Software-Entwicklungen zu bekommen. Andere wichtige Kriterien sind beispielsweise die Qualitaet und der Nutzungsgrad der Software.

Die Ursachen dafuer, dass eine Softwaregruppe aktiv werden muss, koennen nicht nur in Veraenderungen der Funktionalitaet liegen, sondern auch in einem Wandel des Nutzungsumfelds. Beispiele dafuer sind unter anderen ein Anwachsen der Anwenderzahl, eine Verlagerung auf verschiedene Standorte, ein hoeherer Datenanfall als geplant. Der Software-Manager muss die Korrelation zwischen dem Software-Aufwand und den Veraenderungen in den Mengengeruesten kennen, damit er rechtzeitig auf geschaeftliche Trends reagieren kann.

Mittelverschwendung wird offensichtlich

Zudem verlangt ein Qualitaets-Management auch Informationen ueber die zeitliche Verteilung der Fehlermeldungen und ueber deren Abarbeitung. Dabei sollte der Zusammenhang zwischen Entwicklungsmilieu und Qualitaetsniveau deutlich werden. Fuer das Berichtswesen heisst das: Der Zeitpunkt der Fehlermeldung, die Fehlerart, die Haeufigkeit und der Korrekturaufwand muessen erfasst werden.

Der Aufwand fuer die Wartung ist nach Aktivitaeten getrennt nachzuweisen. Fuer eine gerechte Verteilung des Aufwandes empfiehlt es sich, auch die Verursacher festzuhalten.

Da das deutsche Bilanzrecht keine Aktivierung der selbstentwickelten Software fordert, wissen die Unternehmen selten, welches Vermoegen in den Softwareprodukten steckt. Es ist meist auch nicht bekannt, in welchem Umfang die Software- Investitionen genutzt wurden. Einer bei Projektbeginn vorgelegten Nutzungsanalyse steht keine Aufstellung der effektiven Nutzung gegenueber. Ein vollstaendig gefuehrtes Softwareportfolio ist Informationsquelle fuer drei Bereiche im Unternehmen:

-Die Geschaeftsleitung gewinnt Einblick in den Softwarebereich. Sie erkennt, welche der bekannten Aufgaben noch nicht realisiert sind, welche Investitionen laufen, welche Mittel in die einzelnen Softwareprodukten geflossen sind und in welchem Umfang die Softwareprodukte genutzt wurden.

-Fuer das Software-Management ist das Softwareportfolio Planungs- und Fuehrungsgrundlage sowie Erfahrungsdatenbank.

-Die Produktverantwortlichen koennen es als Planungs- und Arbeitsgrundlage nutzen.

Ein modernes Berichtswesen hat zwei wesentlich neue Aspekte: Es bietet eine Erfahrungsdatenbank fuer die Planung, und es verzeichnet alle Softwareprodukte ueber den Lebenszyklus im Hinblick auf Kosten sowie Nutzung. Es wird dem Softwarebereich die gleiche Transparenz geben, wie sie in den anderen Abteilungen Standard ist. Daduch verliert das Software-Management eine unangenehme Eigenschaft: die Undurchschaubarkeit fuer Aussenstehende. Das globale Budget wird aufgebrochen - und jede Mittelverschwendung offenbar.

*Robert Huerten ist Geschaeftsfuehrer der Huerten & Partner Unternehmensberatung GmbH, Riedstadt-Leeheim.