Paper: Impact Analysis in the Software Change Process: A Year 2000 Perspective, Shawn A. Bohner
Interessante Betrachtugnsweise des Papers.
Es wird davon ausgegangen, daß die Software dazu da ist, Fehler zu korrigieren. Sonst könnte
man ja alles in HW machen. Daß die Software aber ursprünglich nur das Dilemma gelöst hat, für
jeden Spezialfall (jede Applikation) eine neue HW erforderte, wird hier ignoriert. Software
ist der Problemlöser für die Wartung. Und daher kann sie geändert werden.
Der Artikel geht auf die verschiedenen Software-Engeneering-
Probleme - und Lösungen ein. Eines ist die Wartung. Da könnte man doch gleich das Y2K-Problem
einflechten ... Allerdings - wenn man schon so weit ist, dann kann man gleich in den Software-Change
Process eingreifen.
Es wird als erster Schritte ein Change-Request eingeleitet. Diesem folgt der Change-Process. In diesem
kommen natürlich auch Wartungs-Aktivitäten. das Resultat kommt zum End-User. Dieser findet unter Umständen
Fehler oder fehlende Featuers, die wiederum einen Change-Request veranlassen.
Betrachten wir den Software Change-Process genauer.
Dieser beinhaltet etliche Subaufgaben. Ich habe diese gegenüber dem Paper etwas vereinfacht:
Management Software Change.
Das um und auf bei der Softwareentwicklung. An diesem Punkt hängt jeder unterpunkt. Jeder Prozeß geht von ihm aus und führt wieder zu ihm zurück.
ISO9000 Zertifizierung, Abschätzung der Risiken, Verfahrensabläufe, Resourcenbereitstellung und Zeiteinteilungen sind die Schlagworte. Es erfolgt eine Berücksichtigung der Randbedingungen: Budget, Personal, Features.
Verständnis des SW-Changes und deren Auswirkungen: Der komplette SW-Change-Process muß innerhalb aller
Ebenen einer Firma verstanden sein. Es nützt nichts, wenn der Vorstand das Problem in seiner Tiefe nicht
verstanden hat.
Review der Dokumente, Identifizieren der betroffenen Module, Revision-Dtabase-Update, Software-Stabilitätstests, Change Requirements ... (Viel tiefere Ebene mit analysen etc.)
Spezifizierung und Design des Software Change.
Das Problem, in diesem Fall das Y2K Problem muß detailiert spezifiziert werden. Hier erfolgt auch das Design.
Analyse der Änderungen, Abhängigkeiten erkennen, Programme designen - alles zu Papier bringen!
Implementierung. Hier wird die Software tatsächlich verändert. Das Problem
wurde identifiziert, das Modul erkannt und die SW verändert. Modultest wurde durchgeführt.
Test. Der wichtigste Bestandteil nach dem Management. Aus ihm folgt das
neue System.
Erstellen von Testfällen, Updating, Integration, Akzeptanztests, ...
Etliches ist hier stark vereinfacht, ich bitte das im Original nachzulesen bei:
Shawn A Bohner Mitretek Systems, 7525 Colshire Dr., McLean, VA 22102-3481 bohner@mitretek.org. und Arnold, R. S., and Bohner, S. A., "Impact Analysis- Towards A Framework for Comparision," Proc. of the Conf. on Software manint., pp 292-301, Sept 1993.
2. Teil