Qualitätsmanagement für Software-Entwicklungsprozesse

    07. Januar 2002 von Harald Schmidt

    Die Einführung eines Prozessmodells im IT-Bereich impliziert den Wunsch nach einer zielorientierten Vorgehensweise bei der Durchführung eines Projekts. Hiermit soll erreicht werden, dass das Produkt, von der Anforderungsdefinition bis hin zur Wartung, in geordneten Arbeitsschritten entwickelt werden kann. Unterstützung bieten hierbei verschiedene Prozessmodelle.

    Prozessmodelle

    Prozessmodelle sind zum Beispiel

    • das "Wasserfallmodell"
    • das vom Wasserfallmodell abgeleitete "VModell"
    • und der iterative bzw. inkrementelle "Rational Unified Prozess"

    In den meisten Fällen wird ein von den oben genannten Modellen abgeleiteter Prozess als unternehmenseigenes Vorgehensmodell für die Entwicklung von Software eingesetzt. Dieser wird in vielen Fällen über die Jahre mit der Anzahl der Projekte verbessert bzw. verfeinert und etabliert sich so als Best Practice im Unternehmen. So bietet das VModell zum Beispiel die Möglichkeit, den Entwicklungsprozess einem massgeschneidertenTailoring zu unterziehen.

    Unterstützt werden diese Prozessmodelle durch qualitätssichernde Maßnahmen unterschiedlicher Art. So werden z.B. die Ergebnistypen der in den jeweiligen Phasen anfallenden Dokumente spezifiziert und müssen formal und inhaltlich den projekt- oder unternehmensweiten Qualitätsrichtlinien entsprechen.

    Ein Nachteil der oben genannten schwergewichtigen Prozesse sind die teilweise vernachlässigten oder nicht vorhandenen Rückkopplungseigenschaften zur vorhergehenden Phase im Entwicklungsprozess. Diese existieren zwar, werden aber oft nur in Form von Maßnahmen zur Budgetierung der einzelnen Entwicklungsphasen eingesetzt.

    Zusätzlich wird dadurch der Separation zwischen Auftraggeber und Auftragnehmer Vorschub geleistet. Somit wächst die Gefahr, dass der Auftraggeber nicht das gewünschte Produkt erhält. So passiert es nicht selten, dass erst der Abnahmetest des Kunden fehlende Funktionalitäten aufdeckt, die entweder nicht erkannt, nicht analysiert oder nicht realisiert wurden.

    Um dem entgegen zu wirken, kann man sich verschiedener Möglichkeiten bedienen, diese Unschärfen zu umgehen und so zu einer effizienteren Produktion und zufriedeneren Kunden zu gelangen. Qualitätsverbessernde Maßnahmen können grob in zwei Kategorien eingeteilt werden:

    • Maßnahmen zur Verbesserung des Entwicklungs-/Produktionsprozesses und
    • Maßnahmen zur Verbesserung der Ergebnisse.

    Die oben angegebenen schwergewichtigen Prozesse (heavy weight processes) können unter Umständen ganz oder zumindest teilweise durch leichtgewichtige Prozesse (leight weight processes) ersetzt werden.

    Hierbei sei aber darauf hingewiesen, daß nicht der komplette Prozess, von der Anforderung bis hin zur Wartung, auf einmal ersetzt werden kann. Vielmehr ist es sinnvoll, nach und nach dessen Teilprozesse, sowie deren Schnittstellen, zu konsolidieren. Wollte man den gesamten Prozess ersetzen, würde man für eine geraume Zeit die Entwicklung einstellen müssen. Dass sich dies kein Unternehmen leisten kann, steht wohl außer Frage.

    Vorgehensweisen

    Arbeitsprozesse zu verschlanken und so die wesentlichen Schritte im Entwicklungsprozess formalisiert zu manifestieren, ist nicht nur hinsichtlich eines besseren Kosten/Nutzen-Verhältnisses sinnvoll, sondern bedeutet auch die Konzentration auf das Wesentliche: das zu entwickelnde Produkt.

    Für die Ergebnistypen gilt es formalisierte Verfahren einzuführen, die den jeweiligen Schnittstellen der Teilprozesse entsprechen. Die während des Entwicklungsprozesses entstehenden Dokumente sollten nicht nur den oben genannten Ergebnistypen genügen, sondern aktiv in den Entwicklungsprozess eingebunden sein.

    So ist die Verbreitung von UML (Unified Modelling Language) u.a. auf die Tatsache zurück zuführen, dass sämtliche Dokumente (Anwendungsfälle, Sequenzdiagramme, Klassendiagramme, u.s.w.), die während des Entwicklungsprozesses anfallen, nicht nur die Schnittstellen und einzelnen Entwicklungsphasen abbilden, sondern innerhalb des Prozesses eine lange Lebensdauer haben. So werden Anforderungen und Anwendungsfälle, die in früheren Phasen der Entwicklung erstellt wurden, im Integrationstest wiederverwendet, um so die geforderten Eigenschaften des System zu verifizieren. Dies alles sind globale Maßnahmen, um die innere und äußere Qualität sicherzustellen.

    Beispiel

    Für den Softwareentwicklungsprozess gilt es zum Beispiel einen schwergewichtigen (heavy-weight) duch einen leichtgewichtigen (leight-weight) Prozess zu ersetzen. Ein Beispiel für einen leichtgewichtigen Prozess ist das Konzept des eXtreme Programming (XP).

    Dieses Konzept beinhaltet verschiedene technische und nichttechnische Vorgehensweisen, um die Qualität des auszuliefernden Produktes zu verbessern. Zu den technischen Verfahrensweisen zählt zum Beispiel, dass zuerst die Tests für eine zu realisierende Funktionalität implementiert werden. Erst danach wird die eigentliche Funktionalität implementiert. Der Vorteil besteht in der Fokussierung auf die wesentliche Eigenschaft der zu liefernden Funktionalität. Desweiteren können zeitaufwendige Implementierungsdetails gekapselt und im Laufe der Entwicklung leichter priorisiert werden.

    Gleichzeitig wird die Qualität der zugesicherten fachlichen Eigenschaft durch den zugrunde liegenden Test untermauert. Während der Entwicklung des Tests wird die API (Application Programmers Interface) definiert. Diese definiert die Schnittstelle zwischen dem Anwender und der dahinter liegenden technischen Realisierung der geforderten Eigenschaften des Systems. Man kann sich leicht vorstellen, dass die Anzahl der Tests die der API-Elemente um ein vielfaches übersteigt. Die Tests können unabhängig von Benutzungsschnittstellen durchgeführt werden. Beispielsweise kann ein Regressions- oder Progressionstest, bestehend aus hunderten oder tausenden von Testfällen, über Nacht durchlaufen. Das Testergebnis wird anschliessend in Form eines Protokolls den Entwicklern zur Verfügung gestellt. Diese können anhand der fehlgeschlagenen Testfälle erkennen, an welchen Stellen die gewünschte Funktionalität noch nicht vorhanden ist.

    Weitere Konzepte

    Dieses Verfahren ist im Gegensatz zu sogenannten "Capture-Replay-Tools" schon früh einsetzbar, denn die "Capture-Replay-Tools" simulieren Benutzerverhalten und setzen ein fertiges Produkt für den Test voraus. Nichttechnische Maßnahmen zur Qualitätsverbesserung im Rahmen der Software-Entwicklung sind z.B:

    • Arbeitszeitbeschränkungen auf 40 Stunden pro Woche
    • die Verteilung von Wissen innerhalb des Entwicklungsteams durch geeignete Massnahmen
    • die entsprechende zeitliche und technische Unterstützung
    • oder das Konzept des Pair-Programings.

    Das Pair-Programming ist auf der organisatorischen Seite des Entwicklungsprozesses ein Verfahren, bei dem zwei Mitarbeiter gemeinsam eine oder mehrere geforderte Funktionalitäten realisieren. Dabei muss es sich bei dem Team nicht unbedingt um zwei Programmierer handeln, sondern es kann auch aus einem Business-Analysten und einem Entwickler bestehen. Beide realisisieren gemeinsam einen Teilaspekt des Anwendungssystems. So werden ohne Kommunikations-Overhead die geforderten Eigenschaften des Systems, beispielweise in Form von mehrstufig verfeinerten Anwendungsfällen, realisiert.

    Auch die Kommunikation zwischen Auftraggeber und Auftragnehmer über das Produkt kann so durch eine gemeinsame Session vor dem Rechner mit sofortiger Umsetzung der besprochenen Lösung, verbessert werden. Mißverständnisse durch Fehlkommunikation werden minimiert.

    Managerale Komponenten

    Jedes Projekt wird von einem Management-Prozess begleitet und gesteuert. Die managerale Komponente eines Projekts ist die Schnittstelle zum Kunden. Statusmeetings sollen sicher stellen, dass die geforderten Teilziele erreicht wurden und Resourcenengpässe, technischer oder nicht-technischer Natur, aufdecken. Das Management wirkt auf den Verlauf eines Projekts sowohl fordernd (Termine, Budgetierung) als auch, im Sinne der Qualitätsverbesserung, fördernd (Kommunikation, Koordination, Resourcen) ein. Voraussetzung dafür ist eine über die diversen Teilaspekte und Probleme, die im Prozessverlauf auftreten, gut informierte, flexible Führung.

    Weitere Methoden

    Mit dem anhaltenden Bedarf an Resourcen für die erfolgreiche Umsetzung einer Softwareentwicklung und den damit verbundenen Kostensteigerungen in exponentieller Höhe, wird zunehmend der Wunsch nach Verfahren laut, die die Entwicklung von Software effizienter gestalten. Die oben angesprochene Etablierung von geeigneten Prozessmodellen, einer frühen Testphase und der engen Kommunikation mit dem Kunden sind nur einige Schritte auf dem Weg zur kosteneffizienten und erfolgreichen Durchführung eines IT-Projekts.

    Mehr und mehr setzt sich die Erkenntnis durch, das ein konsequentes und durchgängiges Qualitätsmanagement für die erfolgreiche Umsetzung eines Softwareprojekts unabdingbar ist.

    Jedes Teilergebnis des Entwicklungsprozesses wird unter Berücksichtigung der vorgegebenen Ziele hinsichtlich bestimmter Qualitätsmerkmale formal und inhaltlich auf deren Einhaltung überprüft. Werden diese Ziele nicht eingehalten, können Rückschlüsse auf eventuelle Resourcenengpässe oder Informationsdefizite abgeleitet werden.

    So können zum Beispiel Checklisten zwischen zwei aufeinander folgenden Entwicklungsphasen, beispielsweise von der Analysephase zur Designphase, dazu verwendet werden, dass sämtliche Aspekte der Analyse sich in der Modellierung wiederfinden. Checklisten können leicht in Form von Excel-Tabellen realisiert werden. Stellt man nun im Rahmen der Qualitätssicherung fest, daß die Ergebnisse der einen Phase nur zum Teil in der nachfolgenden Phase berücksichtigt wurden, so können die betreffenden Punkte aus der Checkliste in Form eines QS-Protokolls als Diskussionsgrundlage dokumentiert werden. Die QS-Protokolle können für ein späteres Benchmarking des gesamten Entwicklungsprozesses verwendet werden.

    Im Gegensatz zum Benchmarking, das den gesamten Entwicklungsprozess beurteilt, stehen Metriken, die zur Beurteilung der eigentlichen Software dienen. Metriken werden zur Größenbestimmung von Teilaspekten der Softwareentwicklung eingesetzt. So werden Metriken zur Aufwandsabschätzung, zur Beurteilung der Codequalität oder zur Bestimmung des Wartungsaufwands verwendet. Unter Zuhilfenahme von Function Points kann der Aufwand für die bevorstehende Entwicklung abgeschätzt werden.

    Function Points sind ein Maß für die Anzahl der zu realisierenden Eigenschaften eines Systems. Diese können gewichtet oder ungewichtet sein. Die Gewichtung ist unternehmens- oder projektspezifisch und somit individuell. Wie Function Points gezählt werden, wird von der IFPUG (International Function Point User Group) vorgeschrieben. Da die Function Points keine Aussage über den zeitlichen Aufwand einer Realisierung machen, ist es um so notwendiger, hierbei einen normierten Ansatz zu verwenden. Somit kann eine Liste von Function Points als Eingabe für ein Aufwandseinschätzungsverfahren, wie zum Beispiel COCOMO II, verwendet werden.

    Metriken, die eine Aussage bezüglich der Qualität des Codes machen, betrachten die Wiederverwendbarkeit, die Pfadabdeckung (werden alle Programmzeilen mindestens einmal ausgeführt), die Abhängigkeit der Komponenten untereinander oder die interne Komplexität. Die Schwierigkeit besteht darin, eine geeignete Anzahl von Metriken auszuwählen, die eine sinnvolle Aussage bezüglich des zu untersuchenden Codes zulassen. Denn eine Metrik allein ist niemals imstande, die gesamte Bandbreite von zu untersuchenden Qualitätsmerkmalen eines Programmcodes zu erfassen. Es sind immer mehrere Metriken notwendig, die dann gewichtet in eine Gesamtbeurteilung eingehen. Im Bereich der Wartung können ermittelte Fehlerraten beispielsweise zur Bestimmung der Grösse eines Wartungsteams herangezogen werden.

    All dies sind Beispiele für die Notwendigkeit eines konsequenten Qualitätsmanagements in allen Phasen der Softwareentwicklung. Es wurde gezeigt, dass auch mit einfachen Mitteln, wie zum Beispiel Checklisten oder komplizierteren Verfahren wie den Metriken, die Qualität des Prozesses im Auge behalten und gegebenenfalls darauf reagiert werden kann. Allerdings muss bemerkt werden, das der Prozess des Qualitätsmanagements nicht über den Dingen steht und sich selbst einer permanenten Überprüfung bezüglich seiner Stellung und Effizienz innerhalb eines Projekts stellen muss.

    Qualitätsmanagement und Wissensmanagement

    Ein häufig unterschätzer Aspekt des Qualitätsmanagements im Rahmen der Softwareentwicklung ist das damit verbundene Wissensmanagement, dass explizit oder implizit immer vorhanden ist. Gerade im Bereich der Softwareentwicklung, die ja permanent unter Zeitdruck steht, ist das Management von anfallendem Wissen entscheidend für den Fortbestand einer qualitätsgesicherten Produktentwicklung.

    So werden Erkenntnisse von Mitarbeitern bezüglich der Verwendung von Werkzeugen und Verfahren in Form von White Papers in einer Wissensdatenbank abgelegt. Die verwendete Wissensdatenbank kann in ihrer einfachsten Form eine organisierte Verzeichnisstruktur auf einem Netzwerklaufwerk sein, das jedem Team-Mitglied zugänglich ist. Die Organisation von Wissen kann aber auch durch eines von vielen auf dem Markt befindlichen Werkzeugen wie Lotus Notes oder OpenLink unterstützt werden. So können Schulungsunterlagen, die Ergebnisse eines Reviews oder Metriken in Form von ASCII-, HTML-oder PDF-Dokumenten abgelegt werden, die jedem Projektmitglied bei der nächsten Iterationsstufe der Entwicklung helfen, die Qualität des Produktes zu verbessern.

    Die oben genannten Produkte helfen, im Gegensatz zu einer einfachen Verzeichnisstruktur, durch die mitgelieferten Werkzeuge die Qualität und vor allem die Aktualität der vorhandenen Dokumente im Auge zu behalten. So kann u.a. jedes Dokument mit einem Status und gegebenenfalls mit einem künstlichem Verfallsdatum versehen werden. Wendet man nun ein Report-Script auf den gesamten Dokumentationsbestand an, lässt sich leicht herausfiltern, welche Dokumente qualitätsgesichert, beziehungsweise veraltet sind. Diese zyklische Überprüfung der vorhandenen Dokumente ist unbedingt notwendig und sollte eine Minimalanforderung an das Wissensmanagementsystem sein. Ohne diese Maßnahme würde die Wissensdatenbank an Wert verlieren. Oft genug sieht man den Wald vor lauter Bäumen nicht mehr, weil zu viele Dokumente von unterschiedlicher Qualität zu dem gleichen Thema in der Datenbank abgelegt wurden.

    So stellt sich die Frage nach einem geeigneten Prozess, der die Aquisition, Aufbereitung und Publikation von Informationen und Wissen realisiert. Dieser Prozess sollte unternehmensweit und nicht projektspezifisch sein. Gründe hierfür wären zum Beispiel die unternehmensweite Austauschbarkeit von dokumentierter Information. Eine einheitliche Kategorisierung kann verschiedensten Projekten innerhalb des Unternehmens helfen, die passenden Dokumente für einen Themenschwerpunkt zu finden. Interessiert sich zum Beispiel ein Team für das Thema Metriken und hat ein anderes Team schon hinreichend Erfahrungen damit gesammelt und in Form von White Papers dokumentiert, so braucht niemand mehr das Rad neu zu erfinden. Im besten Fall wird das vorhandene Wissen um die Erfahrungen des zweiten Teams ergänzt.

    Das gerade eben beschriebene Szenario stellt den Idealfall dar. Häufig tritt aber der Fall auf, dass die vorhandenen Dokumente nicht gepflegt werden. Ein aktives Wissensmanagement mit einem qualitätsgesicherten Prozess, der die oben genannten Arbeitsschritte Aquisition, Aufbereitung und Publikation enthält, ist für das Management einer Wissensdatenbank unumgänglich.

    Die Aquisition sollte entscheiden, welche Informationen das Wissen des Unternehmens sinnvoll ergänzen. Die Aufbereitung der Dokumente sollte nicht nur einem einheitlichem Erscheinungsbild dienen, sondern diese auch les- und druckbar machen. Desweiteren sollte dieser Arbeitsschritt auch der Kategorisierung der zu publizierenden Dokumente dienen. Die abschliessende Publikation selbst ist dann eher ein technischer Aspekt des Wissensmanagements. Sie kann entweder in Form eines aktualisierten Portals, via eMail oder on-Demand geschehen.

    Abschliessend sei bemerkt, dass auch das Wissensmanagement einem permanenten Qualitätsmanagement unterliegen sollte. So muss nicht nur gewährleistet sein, dass die Qualität des zugrunde liegenden Prozesses den aktuellen Bedürfnissen des Unternehmens genügt, sondern auch inhaltlich darauf geachtet wird, dass die Information publiziert wird, die dem Unternehmen hilft, seine Position am Markt auszubauen und zu stärken.

Kommentare

Das Kommentarsystem ist zurzeit deaktiviert.



Schlagworte

Dieser Beitrag ist den folgenden Schlagworten zugeordnet