Systematische Softwareentwicklung

7.4Iterationen

"Kein Mensch ist so beschäftigt, dass er nicht die Zeit hat, überall zu erzählen, wie beschäftigt er ist."
(Robert Lembke)

Die Versionskennungen bei Software werden typischerweise als v.rr dargestellt, wobei v die Nummer der Version und r die Nummer der Revision ist. Wenn also Fehler behoben wurden und villeicht einige Funktionen aufgrund der Rückmeldungen der Kunden noch mal angepasst wurden, wird eine neue Revision des Produktes auf den Markt gebracht. Einige große Hersteller haben noch kleinere Schritte eingeführt, weil der Aufwand für die Produktion einer neuen Version/Revision bei Millionenstückzahlen in verschiedenen Sprachen für mehrere Kontinente extrem aufwendig ist. So gab es von Microsoft ein Word 6.0a, in dem nur geringe Änderungen vorgenommen wurden, die in die laufende Produktion eingeflossen sind, aber nicht zum Ankurbeln der gesamten Marketingmaschinerie geeignet waren.

Oft wird auch die Build-Nummer (Herstellungsnummer) noch mit angegeben. Diese Nummer wird immer hochgezählt, wenn die Software wieder neu generiert wird. Wenn also Entwickler eine Änderung vorgenommen haben und alle ihre Quellen übersetzt haben, brauchen sie einen neuen fertigen Stand der Software, um ihre Änderungen erst selbst testen zu können und dann in die Qualitätskontrolle geben zu können. Zur Kommunikation ist eine eindeutige Identifizierung des Stands erforderlich, und genau hierfür wird bei jeder Erstellung eines neuen Standes die Build-Nummer hochgezählt. So wird beispielsweise bei Microsoft von einem Build-Team jede Nacht ein neuer Stand von Windows generiert, der dann von einem Burning-Team (Brenn-Team) noch in der gleichen Nacht auf CDs gezogen wird. [B21]

Meilenstein "Close Shop"

Lieferung auf CD-ROM

Zwischenabnahmen?

ca. fünf Iterationen pro Jahr

7.5Änderungsanforderungen

"Man muss sich einfache Ziele setzen, dann kann man sich komplizierte Umwege erlauben."
(Charles de Gaulle)

Änderungsanforderungen (englisch Change Requests) sind die Tücke eines jeden Software-Projekts. Wenn Sie bisher alles richtig gemacht haben und optimal im Plan liegen und endlich die Fachlichkeit und die Technik im Griff haben, kommt der Kunde jetzt garantiert mit neuen Ideen, damit Sie als Anbieter auch garantiert ins Schleudern kommen. Hier danke ich einem Kunden für den ehrlichen Spruch: "Kunde sein verdirbt den Charakter"!

Das Problem ist ja nicht die neue Idee, der geänderte Geschäftsprozess oder der bisher so zurückhaltende Anwender, der nun anhand der Prototypen die neuen technischen Möglichkeiten entdeckt hat - das Problem ist der Umgang damit! Ist die neue Idee nun wirklich neu oder ist darüber nicht schon ganz häufig gesprochen worden und das war schon immer so gemeint? Hat sich der Geschäftsprozess wirklich geändert oder haben Sie als Anbieter den Kunden nur nicht richtig verstanden? Ist der bisher so zurückhaltende Anwender wirklich nie gefragt worden und hat jetzt erst vom neuen System erfahren?

Wenn Sie als Anbieter die Anforderungen verbindlich fixiert, umfangreich analysiert und detailiert spezifiziert haben und wenn Sie all diese Prozesse in Stufen mit Zwischenabnahmen und Protokollen begleitet haben und wenn Sie wirklich nur einen einzigen Ansprechpartner haben, der seinerseits genau einen benannten Vertreter für jeden Akteur hat und wenn alle Dokumente und Prototypen all diesen Vertretern vorgeführt wurden, dann können Sie sehr genau feststellen, welche Anforderung wirklich neu oder geändert ist.

Sie können diese Änderungsanforderung "oben" in Ihren Prozess einstreuen und beobachten, welche Auswirkungen sie worauf hat: Passt die Änderungsanforderung überhaupt ins Hauptziel? Welcher Akteur stellt diese Änderungsanforderung? Welche Anforderungen kamen noch von diesem Akteur? Auf welchen Übersichts-AF und auf welche Funktions-AF wirkt sich diese Änderungsanforderung aus? Welche Detail-AF müssen alle wie geändert werden? Welche Daten werden dabei neu entstehen oder können verworfen werden? Was bedeutet dies für das Datenmodell? Welche Geschäftslogik muss geändert oder ergänzt oder verworfen werden? Welche Teile des Datenmodells und der Geschäftslogik und welche Teile in anderen tiern sind bereits implementiert und müssen wie umcodiert werden? Welche Team-Mitglieder sind also betroffen, wofür sind diese in nächster Zeit eingeplant und welchen Stundensatz haben sie? Welche neuen Testfälle zieht die Änderung nach sich und wie aufwändig ist die Qualitätssicherung jetzt? Welche Dokumentation muss in welchem Umfang geändert werden und welche Teile des evtl. bereits begonnenen Handbuchs müssen wie geändert werden?

Wie viel Zeit wird also alles in allem für diese Änderung benötigt und was kostet diese letztendlich? Wird das Produkt vielleicht sogar billiger, weil die Änderung eine Reduzierung mit sich bringt, die eintritt, bevor mit den betroffenen Stellen überhaupt irgendjemand begonnen hat? Eine Änderungsanforderung kann durchaus auch zur Minderung statt zur Mehrung führen, auch wenn dies eher untypisch ist.

Wenn Sie als Anbieter Ihrem Kunden also nachweisen können, dass es sich um eine Änderung handelt und vorrechnen können, welchen Einfluss diese Änderung auf Zeit und Kosten hat, dann kann der Kunde für sich abwägen, ob er die Änderung dennoch möchte oder nicht. Vielleicht möchte der Kunde die Änderung dann ja auch in einer späteren Version, zusammen mit einigen anderen Änderungen. Es soll nämlich schon Projekte gegeben haben, die vor lauter Änderungsanforderungen nie fertig geworden sind! Eine Änderung in einer Folgeversion ist zwar in der Regel teurer als eine Änderung in der aktuellen Version, aber eine Version später auf den Markt zu bringen als ursprünglich geplant und versprochen kann noch viel teurer werden!

Hier sei nochmals erwähnt, dass eine Änderungsanforderung natürlich umso teurer ist, je später sie in das Projekt "einschlägt". In der Pre-Analyse ist eine Änderung gedankenschnell vollzogen, in der Analyse kostet die Änderung der bereits erstellten Dokumentteile vielleicht einen Tag, nach dem Design kann es schon eine Woche sein und wenn weite Teile bereits codiert und im Handbuch verewigt sind, wird es bestimmt schon ein Monat sein. Ist das Produkt erst im Markt und muss in der nächsten Version kompatibel geändert werden, bedeutet es vielleicht ein halbes Jahr!