"Technologien bewegen und entwickeln sich, wie alles, nach evolutionären Gesetzen."
(Matthias Horx in [B26])

SPICE

"SPICE" steht für "Software Process Improvement and Capability Determination" (Verbesserung des Softwareprozesses und Bestimmung der Leistungsfähigkeit) und stellt eine internationale Initiative zur Entwicklung eines Standards zur Beurteilung der Softwareprozesse dar. Im Wesentlichen handelt es sich um einen Satz von Dokumenten, die als Vorlage verwendet werden können und 1995 erstmalig vorgestellt wurden. Darin wird nicht nur die Softwareentwicklung betrachtet, sondern beispielsweise auch die Evaluierung von Softwareprodukten, so dass dieser Dokumentensatz für alle interessant ist, die in irgendeiner Form mit Software konfrontiert werden. Oder wie es in [L17] ausgedrückt wird: "This framework can be used by organizations involved in planning, managing, monitoring, controlling and improving the acquisition, supply, development, operation, evolution and support of software" (Dieser Rahmen kann von Unternehmen genutzt werden, die mit Planung, Organisation, Überwachung, Kontrolle und Verbesserung von Anschaffung, Lieferung, Entwicklung, Betrieb, Fortschritt und Unterstützung von Software beschäftigt sind).

Das SPICE-Projekt hat schließlich zur ISO 15504 [L25] geführt, die mittlerweile bei einigen größeren Unternehmen Verwendung findet. Aus der Sicht der systematischen Softwareentwicklung beschreibt die ISO 15504 ein Verfahren zur Einführung und kontinuierlichen Verbesserung eines Softwareentwicklungsprozesses und stellt damit ähnlich der ISO 9000 eine Richtlinie zur Etablierung einer Richtlinie dar. Unternehmen können damit ihre aktuellen Fähigkeiten zur Softwareentwicklung definieren (Ist), bestimmte Stufen auf dem Weg zu einem Ziel festlegen (Soll) und die Weiterentwicklung der Softwareentwicklung entlang dieses Weges systematisch und evolutionär betreiben. Zur Festlegung und Etablierung eines ersten Softwareentwicklungsprozesses im Unternehmen sollten Sie ein gängiges Vorgehensmodell an Ihr Unternehmen anpassen und dieses für jedes Projekt maßschneidern. Dazu finden Sie zwar viele Hinweise und Vorschläge in der ISO 15504, aber ohne Hilfe wird das selten gelingen.

Sie sollten also zunächst die Qualität Ihres Entwicklungsprozesses bestimmen und dabei ggf. neben den eigenen Anforderungen auch die des internen oder externen Kunden berücksichtigen: Wenn Sie Softwarekomponenten erstellen und zuliefern oder eine kundenspezifische Software erstellen, deren Quellen Sie zur Wartung übergeben, dann wird Ihr Kunde hier Ansprüche haben. Auch wenn er diese nicht von allein nennt, sollten Sie im Rahmen der Definition der technischen Anforderungen darauf zu sprechen kommen. Wenn Ihr Kunde keine Ansprüche äußert, sollten Sie explizit festhalten, dass es keine Anforderungen von Seiten des Kunden an den Softwareentwicklungsprozess gibt. Anforderungen an den Entwicklungsprozess sind in der Regel, dass die Ziele der Software mitsamt ihrer Erreichungsbedingungen definiert werden müssen, die daraus abgeleiteten und durch die Akteure gestellten Anforderungen an die Software mitsamt aller Änderungen lückenlos dokumentiert werden müssen, Akzeptanzkriterien für die Anforderungen zu definieren sind, die Ableitung der Anwendungsfälle aus den Anforderungen nachvollziehbar sein muss, die Testfälle zu den Anwendungsfällen für alle Akzeptanzkriterien Testszenarien enthalten müssen, ein Anwendungsfallmodell als UML-Diagramm für alle Anwendungsfälle erstellt und im Projektordner geführt werden muss, etc. Als Auftragnehmer können Sie dann Ihrem Kunden die Überwachung der Qualität beispielsweise dadurch beweisen, dass Sie in der Analysephase in den Routinen des Projektlenkungskreises die Anwendungsfallbeschreibungen an die Wand werfen und zeigen, wo in den Testszenarien auf die damit abgedeckten Akzeptanzkriterien der zugehörigen Anforderungen verwiesen wird; damit sind die Anforderungen an Verbindlichkeit, Lückenlosigkeit und Nachvollziehbarkeit sicherlich gemäß Vorgabe erfüllt.

Wenn der Entwicklungsprozess mitsamt seiner Qualität definiert ist und die Überwachung dieser Qualität organisatorisch sichergestellt ist, kann mit der Entwicklung der Software gemäß diesem Prozess begonnen werden. Dann werden in der Analysephase wahrscheinlich auch Testfälle geschrieben, die Testszenarien zu den Akzeptanzkriterien aus den zugehörigen Anwendungsfallszenarien enthalten. Dadurch wird dann letztendlich die Qualität der Software mitsamt der Messbarkeit der Qualität der Software bestimmt. Was für den Entwicklungsprozess gilt, findet sich halt auch in der damit entwickelten Software wieder. Fließen dann die Erfahrungen aus der Softwareentwicklung zurück in den Entwicklungsprozess, so kann auch dieser selbst kontinuierlich weiter verbessert werden. So wird man feststellen, dass nicht immer die gesamte Qualität erforderlich ist und deshalb bei Zwischenständen ggf. die Durchführung der "wichtigsten" Testszenarien genügt. Wenn man also die Testszenarien priorisiert und die zur Durchführung erforderliche Zeit stoppt und notiert, so kann man jederzeit aussagen, mit welchem Zeitaufwand welche Qualitätsstufe nachgewiesen werden kann - ist doch wohl ein Fortschritt, oder?

Sie sind jetzt wahrscheinlich einerseits verblüfft, weil alle anderen Leute bei Softwaretests in der Regel nur von Fehlern in der Software sprechen (deshalb suchen auch die meisten das Kapitel an dieser Stelle), andererseits sind Sie aber sicherlich auch überzeugt, weil das eben Beschriebene zum einen nichts anderes ist, als Toyota mit TQM und KVP schon seit vielen Jahren macht, und zum anderen sofort einleuchtet, dass für eine nach diesem definierten Verfahren entwickelte Software die besten Voraussetzungen für eine hohe Qualität gegeben sind. Denn auch ein Projektleiter kann jetzt beispielsweise testen, ob seine Analytiker Fehler machen, denn wenn sich in den Anwendungsfallbeschreibungen keine Verweise auf Softwareanforderungen finden, ist eine Anforderung an den Entwicklungsprozess nicht erfüllt - und die Nichterfüllung einer Anforderung ist ein Fehler. Also hat der Projektleiter durch Testen einen Fehler gefunden und damit festgestellt, dass die Qualität nicht der geforderten entspricht. Diese Qualitätsüberwachung führt zu einer Korrektur durch den Analytiker, indem die Verweise auf die Softwareanforderungen mitsamt den Akzeptanzkriterien ergänzt werden, wodurch Folgefehler beim Schreiben der Testfälle vermieden werden (hier würden sonst wahrscheinlich Testszenarien fehlen).

Sicherlich haben Sie jetzt erkannt, dass die Definition und Einführung eines Softwareentwicklungsprozesses mit der Definiton seiner Qualität nichts ist, was man mal eben selbst während eines Projektes nebenbei mitmacht. Das "Consolidated product" SPICE als "Technical Report" für "Software Process Assessment" (dt.: Softwareprozessbewertung) füllt mit seinen 9 Parts ausgedruckt immerhin auch einen ganzen Ordner. Andererseits sollte man nicht am Reißbrett einen Prozess planen und diesen allen Projektleitern einfach ab dem nächstbesten Projekt vorschreiben. Am besten bestimmt man zunächst durch ein Process Assessment in Form von Interviews der verschiedenen Akteure den aktuellen IST-Stand des vorhandenen Softwareentwicklungsprozesses und führt ein Review (dt.: Durchsicht) der verschiedenen Phasen, Teilphasen und eingesetzten Instrumente durch (und ich meine damit nur im Geringsten die Softwaretools).

Die Einordnung eines Softwareentwicklungsprozesses in Level hilft bei der Positionsbestimmung des Unternehmens. Dabei reicht das Spektrum von völlig chaotisch (Level 0) bis hin zum kontinuierlichen Verbesserungsprozess (Level 5). Die meisten Unternehmen finden sich übrigens auf Level 1 wieder, weil der Prozess lückenhaft ist und der Erfolg der Projekte mehr von den Fähigkeiten der einzelnen Teammitglieder abhängt als von einem wohl definierten, verstandenen und überwachten Prozess (Level 2 bzw. 3). Ziel eines jeden Unternehmens sollte es sein, mindestens auf Level 2 zu kommen, damit die erzeugten Produkte auch den Anforderungen entsprechen.

Nach der Einstufung in die SPICE-Level kann ein Plan entwickelt werden, wann und wie welche Teile des Prozesses auf welches Level gehoben werden sollen. Diese Umsetzung etabliert man am besten durch zusätzliche Coaches während der Projekts - also "on the job"! Dann werden die Projektleiter und Projektteilnehmer damit nicht allein gelassen und auch nicht in der Durchführung des Projekts gebremst, der erfahrene Coach kann zum neuen Prozess jeweils sofort die passenden Instrumente vorbildhaft einfließen lassen und dadurch auch die Praktikabilität des individuellen Prozesses testen. Diese Vorgehensweise schafft Akzeptanz bei den Mitarbeitern und bietet vor allem die Möglichkeit, dass die Mitarbeiter nachher selbst den Kollegen diese tollen Neuerungen weiter geben und dadurch die Instrumente und damit letztendlich auch den Prozess selbst zum Unternehmensstandard etablieren.

Die zusätzliche externe Führung ist gerade für eine kontrollierte und ständige Weiterentwicklung des Prozesses immens wichtig, damit die Mitarbeiter sich nicht zu sehr mit dem Prozess statt ihrem eigentlichen Projekt auseinandersetzen, andererseits aber dennoch auch der Prozess voran kommt. Bei größeren Unternehmen kann sich damit natürlich auch ein eigener Mitarbeiter oder gar ein ganzes eigenes Team beschäftigen (quasi als Stabsstelle, als Optimizing Team oder als Zentraler Dienst). Von dieser Rolle werden dann beispielsweise die Stufenpläne und Instrumente ausgearbeitet, die zu einem unternehmensweit einheitlichen Softwareentwicklungsprozess führen oder diesen im Rahmen eines KVP weiterentwickeln. So können Sie in SPICE einsteigen und die Level hochsteigen.

1-2-3   Aspire (Anstreben)     Act (Handeln)     Achieve (Erreichen)

Damit die vorherigen Absätze nicht so sehr nach Eigenwerbung aussehen, zitiere ich hier einfach mal Bruce Eckel [M5]: "I've learned that the most valuable consulting service I can offer is that of reviews. This generally takes from 2-5 days and involves ... A review is also valuable as a team communication tool, to help people understand parts of a project they might not otherwise have the opportunity to study. ..." (dt.: "Ich habe gelernt, dass der wertvollste Beratungsdienst, den ich liefern kann, das Review ist. Dieses dauert im Allgemeinen 2-5 Tage und beinhaltet ... Ein Review ist auch als Kommunikationsinstrument für das Team sehr wertvoll. Es hilft den Leuten Teile des Projekts zu verstehen, für deren Betrachtung sie ansonsten nie die Gelegenheit bekommen hätten. ...").