Software Engineering Newsletter

Transkript

1 Software Engineering Newsletter Case Consult Heft 57 In dieser Ausgabe: Aktuelles aus Wissenschaft und Praxis Wo bleibt nun Software-Engineering?... 2 Ergebnisorientierte Softwareentwicklung... 3 Neue Berufsbilder in der Informationstechnologie... 4 Technologietrends Folgen der Internet-Technologie... 4 Notizen aus der Softwareprovinz... 5 Harry Sneeds Entwicklungslabor Die Anbindung von Legacy-Programmen ans Internet... 6 Neue Werkzeuge für die Aufwandsschätzung von Wartungsprojekten... 6 Eine generische Software-Repository für alte und neue Softwaresysteme... 7 Interessante Termine und Veranstaltungen Evolution En@bling Seminare mit Harry M. Sneed... 5 Bericht über die 23. Internationale Software-Engineering-Konferenz in Toronto... 7 Deutsche Beiträge zu dem Internationalen Workshop on Program Comprehension... 8 Aufruf zum Besuch der 17. Internationalen Software-Maintenance-Konferenz in Florenz... 8 IEEE veranstaltet Workshop on Software Reengineering an der TU Stuttgart... 8 Beiträge für die 6. Europäische Konferenz in Budapest gesucht... 8 Vorwort Liebe Leserinnen und Leser, ein amerikanisches Sprichwort sagt, wer selbst etwas kann, tut es, wer selbst etwas nicht kann lehrt es oder schreibt darüber. If you can do it, do it, if you can t, teach it, if you can t teach you can also write about it. Es gibt dazu noch eine Steigerung. If you can neither teach nor write, you can always consult it. In letzter Zeit ist Software Engineering in die Kritik geraten. Viele behaupten, es sei in der modernen, schnelllebigen Zeit garnicht mehr angebracht. Dies hat Prof. Weber veranlaßt, einen Artikel mit dem Titel Quo Vadis Software Engineering (GI Software Engineering Notes) zu veröffentlichen. In dem ersten Artikel nehme ich dazu Stellung. Sicherlich hat sich in letzter Zeit vieles geändert, nicht nur die Technik, auch wir müssen uns alle bemühen, uns ständig anzupassen. Es ist sogar fraglich geworden, ob das traditionelle Angestellenwesen bei virtuellen, verteilten Projekten noch einen Sinn hat. In letzter Zeit habe ich Tools für den Aufbau einer objektorientierten Repository entwickelt (Impaktanalyse mit Kostenschätzung von Wartungsaufträgen und die Kapselung bestehender COBOL- und PL/I-Programme hinter einer XML-Schnittstelle). Auf der nächsten internationalen Reengineering und Maintenance Konferenz wird darüber berichtet. Ich würde mich sehr freuen, Sie auf einer der nächsten Konferenz oder einem Case Consult-Seminar persönlich begrüßen zu können. Mit besten Grüßen aus Wiesbaden Wiesbaden, im Juli 2001

2 Aktuelles aus Wissenschaft und Technik Wo bleibt nun Software-Engineering? Als Folge der Notwendigkeit neue unerforschte Gebiete im e-commerce zu erschließen und neue Softwareprodukte immer schneller zum Einsatz zu bringen, geriet Software-Engineering als Entwicklungsmodell immer mehr ins Hintertreffen. Manche böse Zungen behaupten, sie sei sogar tot. Es fragt sich in der Tat, welche Rolle Software-Engineering im Zeitalter der Extremprogrammierung noch spielt. Um diese Frage beantworten zu können, müssen wir zunächst fragen, was Software-Engineering bedeutet. Die Väter des Software-Engineering haben auf der NATO-Konferenz 1969 gemeint, Software-Engineering sei die ingenieurmäßige Durchführung von Softwareprojekten. Dazu gehört die Definition und Spezifikation der Benutzeranforderungen, der Entwurf einer oder mehrerer technischer Lösungen, die Implementierung einer dieser Lösungen nach geltenden ingenieurmäßigen Grundsätzen damals war es die strukturierte Programmierung, heute ist es objektorientierte oder komponentenbasierte Programmierung und die systematische Verifikation und Validation der implementierten Lösung gegen die Spezifikation. Das damals vorherrschende Wasserfallmodell sah eine sequenzielle Ablauffolge dieser Tätigkeiten vor, d. h. jedes Zwischenergebnis baut auf dem Vorgängerergebnis auf und setzt dieses voraus. Der Systementwurf baut auf der Anwendungsspezifikation auf, die Programmierung auf dem Systementwurf und der Test auf allen drei. Die Aufgabe des Entwicklers besteht darin, eine semantische Ebene in die nächste zu übersetzen. Die Aufgabe des Testers oder Qualitätsbeauftragten besteht darin, die eine semantische Ebene gegen die andere zu testen, z. B. den Code gegen den Systementwurf Integrationstest oder den Code gegen das Fachkonzept Systemtest. Später, als CASE Computer Aided Software Engineering aufkam, ging es darum, die Transformationen möglichst zu automatisieren. James Martin und Carma McClure behaupteten, CASE sei Softwareentwicklungsautomation. Die Programmiersprache soll aus den höher liegenden Spezifikations- und Entwurfssprachen abgeleitet werden. Damit versprach CASE, den anwendungsorientierten Analytiker zu bemächtigen, Lösungen ohne Programmierer zu schaffen. Jenes Transformationsmodell setzte jedoch eine saubere Trennung der Sprachschichten voraus. Die Spezifikationssprache soll das Was, die Entwurfssprache das Wie beschreiben. Die Programmiersprache soll beides vereinigen und die Testsprache soll sie miteinander abgleichen. Auch mit dem Einzug der objektorientierten Programmierung wurde weiterhin zwischen OO-Analyse, OO-Design, OO-Programmierung und OO-Test unterschieden. Die vier Grundphasen bzw. semantischen Ebenen der ingenieurmäßigen Softwareentwicklung blieben unangetastet. Mehrere OO-Autoren, darunter Coad und Yourdon, Odell und Martin, Schlaer und Mellor haben Modelle propagiert, bei denen die Analyse und der Entwurf getrennt blieben. Nicht aber Booch, Rumbaugh und Jacobson. Nur Jacobson mit seinen Use Cases trug etwas zum Requirements Engineering bei.alle anderen Modelle dienen der Beschreibung einer Lösung. UML ist bis auf die Use-Case-Diagramme eine reine Entwurfssprache. Diese Vernachlässigung der Anforderungsspezifikation in UML war der erste Schritt weg von Software-Engineering, denn ohne eine solche separate Aufgabenstellung als Baselinedokument kann es keine ingenieurmäßige Entwicklung geben, geschweige denn eine systematische Verifikation. Der nächste Schlag gegen Software-Engineering folgte mit der Extremprogrammierung. Damit fiel auch noch der Systementwurf dem Zeitgeist zum Opfer.Die Struktur bzw. Architektur der Lösung wird nicht projektiert, sondern erforscht nach dem Motto Probieren geht über Studieren. Die Väter der extrem- Programmierung gehen davon aus, daß der Anwender nicht weiß, was er will, was ja in vielen Fällen zutrifft. Ergo lohnt es sich nicht, eine Lösung zu planen, weil der Endbenutzer a) den Plan nicht versteht, b) auch wenn er ihn verstünde, ihn nicht unterschreiben würde, bis er die Lösung zu sehen bekommt und c) weil er, falls er ihn doch noch verstünde, jeden Tag auf den Kopf stellen würde. Demzufolge ist es ratsamer, die Lösung eben Stück für Stück zu erarbeiten und immer mit dem Benutzer abzustimmen. Somit bleibt zwar eine testgetriebene, aber dennoch experimentelle Vorgehensweise. Keiner kann sagen, wo die Reise hinführt. Eine Dissertation an der Universität Hamburg vergleicht solche Projekte mit Expeditionen ins Ungewisse. Diesen Muddling Through Approach zur Entwicklung von Software hat es schon immer gegeben, vor allem in kleineren Projekten mit ungewissen Zielen. Man hat jedoch peinlichst gemieden, solche Projekte als Software-Engineering zu bezeichnen. Im Gegenteil, diese Vorgehensweise ist den Prinzipien des Software-Engineering diametral entgegengesetzt. Da es keine fest vereinbarten Ziele gibt, ist es nicht möglich, die Einhaltung der Ziele zu kontrollieren. Da es keine zumindest semiformale Spezifikation gibt, ist es nicht möglich, das Fachkonzept zu validieren und da es keinen unabhängigen Systementwurf gibt, ist es nicht möglich, die Lösung zu verifizieren. Am Ende der Extremprogrammierung ist die einzige Beschreibung der Lösung die Lösung selbst nämlich der Code. Software-Engineering hat immer Wert auf eine mehrfache Beschreibung der Lösung gelegt das Fachkonzept ist eine, der Entwurf eine andere, das Testkonzept eine dritte und der Code selbst eine vierte. Schließlich sei Korrektheit nur nachweisbar, wenn mindestens zwei unabhängig voneinander erstellte Beschreibungen abgeglichen werden und Qualität sei nur über einen Soll/Ist-Vergleich zu messen. Dies setzt jedoch voraus, daß Soll und Ist zwei getrennte Sichten sind. Software- Engineering hat als Ziel ein planbares, meßbares und kontrollierbares Verfahren. Ein Verfahren, bei dem es jederzeit möglich ist, den Ist-Zustand anhand seines Abstandes zum Soll- Zustand zu ermitteln. Extremprogrammierung kann diese Kriterien nicht erfüllen. Ergo mag Extremprogrammierung für Expeditionen ins Ungewisse die richtige Lösung sein, mit Software-Engineering hat es nichts zu tun. 2

3 Hier stellt sich die Frage, ob Software-Engineering für alle Softwareentwicklungsprojekte der geeignete Ansatz ist. Sicherlich nicht. Für die Entwicklung sicherheitsrelevanter oder Mission-Critical-Systeme, auch für Embedded Software und die meisten Prozeß-Steuerungs-Systeme wird sie weiterhin eine dominante Rolle spielen. Sie empfiehlt sich ebenfalls für manche wohldefinierten Backoffice-Systeme in der IT-Welt. Für die meisten Neuentwicklungen in der kommerziellen Datenverarbeitung ist sie jedoch ungeeignet, zu teuer und zu zeitaufwändig. Ungeeignet, weil es nicht möglich ist, die Anforderungen exakt zu spezifizieren, zu teuer, weil keiner weiß, wie lange die Lösung bestehen wird und zu zeitaufwendig, weil keiner weiß, wie lange das Projekt dauern wird. Die Entwicklung neuer kommerzieller Anwendungen, vor allem im Internet-Bereich, ist ein experimenteller Prozeß. Dafür ist die extrem-programmierung natürlich besser geeignet. Was aber passiert, wenn die neuen kommerziellen Anwendungen in Produktion gehen? Da beginnt die Software-Evolution bzw. die Wartung und dafür ist die extrem-programmierung gänzlich ungeeignet. Für einen geordneten Evolutionsprozeß braucht man wieder Software-Engineering, und zwar auch für Systeme, die durch extrem-programmierung entstanden sind. Alle Änderungen und Erweiterungen müssen genau spezifiziert werden. Es muß eine Analyse der betroffenen Software und einen Entwurf der notwendigen Anpassungen geben. Schließlich muß die geänderte Software gegen die alte Software getestet werden. Denn jetzt hat man eine Baseline, nämlich den Ist-Zustand. Durch Reverse Engineering wird dieser Zustand nachdokumentiert. Durch Reengineering wird er nachgebessert. Durch Erweiterungen und Anpassungen wird er fortgeschrieben. Alle diese sogenannten Wartungsaktivitäten basieren auf Software-Engineering-Grundsätzen. Es gebe also doch noch einen Bedarf an Software-Engineering, auch in der kommerziellen Datenverarbeitung, wenn nicht in der Entwicklung, dann doch bei der Wartung und Weiterentwicklung. Mag sein, daß der extrem-programmierer eher ein Künstler ist, der Wartungsprogrammierer soll dennoch eine Ingenieur sein. Da Systeme viel länger in der Wartung als in der Entwicklung sind, wird Software-Engineering immer noch eine große Bedeutung behalten. Gerade bei der Entwicklung abstrakter, unsichtbarer Stoffe wie Software müssen die Ergebnisse im Vordergrund bleiben. Das heißt, wir Softwareentwickler sollten uns weniger mit Aktivitäten und deren Reihenfolge und mehr mit unseren Produkten befassen. Viele Wege führen zu einem ähnlichen Ergebnis, wobei nicht der Weg, sondern das Ergebnis ausschlaggebend ist. Da wir heutzutage alle ebenbürtig sind, ist es sogar anmaßend, einem anderen einen bestimmten Weg vorzuschreiben. Das Problem ist, die Verfasser der Prozeßmodelle haben sich von der Projektwirklichkeit seit langem abgesetzt und leben in eine abgehobenen idealisierten Scheinwelt. Nicht umsonst sind die meisten ISO- und CMM-zertifizierten Softwarehäuser in Indien. Denn dort werden die Menschen zur Gehorsamkeit und Authoritätsgläubigkeit erzogen, zumindest noch. Daß dies in Deutschland nicht mehr der Fall ist, hat sogar die Frau des Bundeskanzlers neulich beklagt. Die Deutschen sind freie Menschen geworden, das heißt jeder macht, was er will, solange er die Gesetze und die Rechte anderer nicht verletzt. Da jeder jederzeit den Arbeitsplatz wechseln kann und für fähige Softwareentwickler jede Menge Arbeitsplätze zur Verfügung stehen, ist es unratsam, Softwareentwicklern Arbeitsprozesse vorzuschreiben. Wenn die Prozesse ihren Freiraum zu sehr einschränken, werden gute Entwickler nur schnell den Arbeitgeber austauschen, denn Gelegenheit dazu haben sie genügend, oder schlimmer noch, sie arbeiten nur noch nach Vorschrift und erreichen gar nichts mehr. Deshalb müssen andere Möglichkeiten gefunden werden, die Qualität der Arbeit in einer freien, nicht autoritären Gesellschaft zu sichern. Eine erfolgversprechende Möglichkeit ist die der ergebnisorientierten Entwicklung bzw. Development by Contract. Der Projektleiter schließt Verträge mit den Projektmitarbeitern ab, wonach sie bestimmte Ergebnisse mit einer bestimmten Mindestqualität abliefern. Bei der Erfüllung jedes Ergebnisorientierte Softwareentwicklung Vor lauter Beschäftigung mit Prozeßmodellen CMM, V-Modell und RUP verlieren wir oft das Wichtigste aus dem Auge die Ergebnisse. Was nutzen jedoch die tollsten Prozesse, wenn die Ergebnisse nicht stimmen. Letztendlich zählen nur die Ergebnisse, egal auf welchem Wege sie zustandekommen. Vertrages erwirbt der Mitarbeiter Pluspunkte bzw. Earned Values, die er gegen Geld oder Freizeit eintauschen kann. Durch die Bestimmung der zu erwerbenden Pluspunkte läßt sich der Projektumfang abstecken und durch die Erwerbung jener Punkte läßt sich der Projektfortschritt messen. Denn jedes Projektergebnis ist soundso viele Pluspunkte wert. Ausschlaggebend ist die Definition der Ergebnisse und ihrer Gewichtung- Typische Softwareergebnisse sind Anforderungsdokumente, Fachspezifikationen, Entwurfsdiagramme, Sourcemodule und Testprozeduren. Jedes solches Softwareergebnis hat ein bestimmtes Gewicht in Punkten. Es können Data-Points, Function-Points oder Object-Points benutzt werden, je nachdem, um was für ein Ergebnis es sich handelt. Ein Softwareergebnis hat aber nicht nur eine Quantität bzw. Größe, sondern auch eine Qualität bzw. Güte. Für jede Ergebnisart Fachkonzeptdokument, Entwurfsdiagramm, Sourcemember, Testskript usw. gibt es eine Konvention, wie alle Ergebnisse dieser Art auszusehen haben. Für das Fachkonzept gibt es eine Konzeptrichtlinie, für Entwurfsdiagramme eine Entwurfsrichtlinie, für Programme eine Programmrichtlinie und für Tests eine Testrichtlinie. Diese Richtlinien schreiben nicht nur die Form, sondern auch gewisse Inhalte vor. Damit hat der Entwickler etwas, wonach er sich richten kann. Nur Ergebnisse, die eine Mindestkonformität zur Richtlinie haben, werden abgenommen. Die Qualitätsrichtlinie ist Bestandteil des Vertrages, der mit dem Entwickler abgeschlossen wird. Also, um die Pluspunkte für ein Ergebnis zu erwerben, muß der Projektmitarbeiter auch die Qualitätsnorm erfüllen. Damit wird die Qualität der Software ebenfalls über die Verträge gesichert. In einer Gesellschaft freier, gleicher Bürger ist der Vertrag das geeignete Mittel, um die Zusammenarbeit zu regeln und Ergebnisse zu vereinbaren (siehe Management by Contract ). 3

4 Neue Berufsbilder in der Informationstechnologie Durch den Wandel der betrieblichen Datenverarbeitung von einer Bastelbude in einen informationstechnologischen Dienstleistungsbetrieb bzw. von einer abgeschotteten technischen Festungsanlage in einen offenen Selbstbedienungsladen haben sich die Berufsbilder der IT-Mitarbeiter verschoben. Einige Berufsbilder, wie Datenerfasser und Arbeitsvorbereiter, sind vollends verschwunden. Andere, wie Organisator oder Systemanalytiker, sind ins Schwanken geraten. Weitere Berufsbilder sind in andere aufgegangen, z. B. Programmierer in Entwickler, wobei unter Entwickler mehr der Organisationsprogrammierer verstanden wird. Es sind aber nicht nur Berufsbilder verschwunden oder in andere übergegangen, es sind dafür jede Menge neuer Berufsbilder entstanden. Diese neuen Berufsbilder haben mit der veränderten Rolle der Informationstechnologie zu tun. Da die Hauptaufgabe der zentralen IT-Abteilung darin besteht, einen technologischen Rahmen bzw. Framework samt TP-Monitor, Middleware, Dialograhmen, Application, Programmschnittstellen, Komponentenrahmen und fertige technische Komponenten bereit zu stellen, wird jetzt ein Systemarchitekt gebraucht, der diesen Rahmen konzipiert und durch entsprechende Produkte ausfüllt. Systemarchitekten müssen eine große Erfahrung haben und auf dem neuesten Stand der Technik stehen. Sie sind auch verantwortlich für die technische Integration der diversen Anwendungssysteme. Da immer mehr fremde Komponenten hinzukommen, Komponenten, die nicht von den eigenen Entwicklern stammen und da die eigenen Entwickler mit dem Test von Gesamtsystemen überfordert sind, werden Testingenieure gebraucht. Die Tester begleiten die Entwicklungsprojekte mit Testprojekten, bei denen sie Testpläne erstellen, die Testszenarien konzipieren, die Testfälle spezifizieren, die Testdaten generieren, die Testumgebung aufbauen, die Tests durchführen, die Testergebnisse auswerten und die Probleme dokumentieren. Sie sind natürlich auch für den Test der Standardsysteme und übernommenen Komponenten zuständig. Dieses Berufsbild hat sich in Amerika, England und den skandinavischen Ländern bereits etabliert - überall dort, wo professionelles Software Engineering betrieben wird. Daß es hier zu Lande noch nicht so weit verbreitet ist, spricht weniger für die Qualität made in Germany als viel mehr für die Rückständigkeit der deutschen IT-Technologie. Da immer mehr Altsoftware gewartet und weiterentwickelt wird, Software, die auf einer nicht mehr aktuellen Technologie basiert, werden Wartungsspezialisten gebraucht. Wartungsingenieure kennen sich mit den Altsystemen aus und können sie korrigieren, anpassen, erweitern und nach Bedarf auch sanieren. Ein Großteil der sogenannten Entwickler sind in der Tat Wartungsingenieure. Wartungsingenieure sind alle, die sich mit den Altsystemen beschäftigen. Für ihre Aufgaben benötigen sie eine spezielle Ausbildung. Da es schließlich so viele verschiedene Systemtypen gibt - alte und neue Systeme, Frontend - und Backendsysteme, eigene und fremde Systeme -, werden Systemintegratoren gebraucht, um die diversen Anwendungssysteme miteinander zu integrieren. Man spricht hier von Enterprise Application Integration. Systemintegratoren müssen moderne Wrappingtechniken, CORBA-IDL, XML und Integration-Frameworks beherrschen. Sie haben eine Schlüsselrolle bei der Gesamtleistung der IT-Abteilung. Case Consult ist bemüht, bei ihrem Ausbildungsangebot gerade diesen neuen IT-Berufsbildern gerecht zu werden. Technologietrends Folgen der Internet-Technologie Die Einführung der Internet-Technologie in die deutsche Wirtschaft hat vielleicht nicht zu der Revolution der Geschäftswelt geführt die viele sich davon versprochen haben, aber ganz ohne Folgen ist sie nicht geblieben. Eine der wichtigsten Folgen ist das Knacken der IT-Festung. Bisher galt die IT-Abteilung als ein Staat im Staate. Sie glich einer mittelalterlichen Burg mit hohen Mauern und einem Wassergraben ringsherum. Innen drin wohnten die hohen Priester der Informatik mit ihren Hostrechner, ihren Datenbanken, ihren esoterischen Sprachen und ihren seltsamen Ritualen, die sie Prozesse nannten. Der IT-Leiter hat zwar wenig Einfluß in der Außenwelt gehabt, aber in der Burg war er der unangefochtene König. Wer etwas von der IT-Abteilung haben wollte, mußte mit einem ordnungsmäßigen Projektantrag an dem Burgportal erscheinen und um Audienz mit den hohen Priestern bitten. Wenn er Glück hatte, wurde sein Antrag angenommen und irgendwann zu einem fest vereinbarten Termin ein Ergebnis ausgeliefert. Es war nicht immer das Ergebnis, was man wollte, oft wurden Wünsche der Bittsteller den Ge- 4 setzen der Informatik untergeordnet. Dennoch, am Ende gab es ein funktionierendes Produkt. Der Prozeß, wonach das Produkt entstanden ist, lief unter der Bezeichnung Software- Engineering. Das hohe Mittelalter solcher IT-Burgen waren die 80er Jahre. Damals war die Macht und ihre Kompetenz unumstritten. Dennoch, schon in den 90er Jahren erschienen Risse in den Burgmauern. Die verteilte Datenverarbeitung mit der Client/Server- Technologie zwang die Burgherren, mehrere Portale zu eröffnen und einen Teil ihrer bisher geschützten Entwicklung nachaußen zu verlagern. Die Anwender gewannen mehr Einfluß auf die Projekte, so daß die hohen Priester der Informatik nicht länger nur unter sich waren. Damit verlor der Burgherr seine Herrschaft über die IT-Prozesse.

5 Jetzt, mit der Entstehung der Internet-Technologie, geraten die IT-Burgmauern gänzlich in Verfall. Deren Ruinen stehen zwar noch dort, wo sie immer gestanden haben, aber keiner kümmert sich um sie. Nur noch eine Nachhut von alten, verunsicherten IT-Priestern hat sich in der Burg eingeschanzt. Der Rest ist in die umliegende Anwendungslandschaft hinausgeströmt, um dort vor Ort Lösungen zusammen mit den Anwendern zu schaffen. Die einstigen stolzen Burgherrn die IT-Leiter sind entmachtet. Sie haben kaum noch Einfluß auf die Geschehnisse um sich herum. Die alte IT-Ordnung ist dahingeschmolzen. Jeder geht seinen eigenen Weg. Projekte im herkömmlichen Sinne gibt s nicht mehr. Insofern ist das ganze Gerede um Prozesse nur Worte in den Wind gesprochen. Die Voraussetzungen für ordentliche Prozeßabläufe gibt es nicht mehr, zumindest nicht in der kommerziellen Anwendungsentwicklung. Extremprogrammierung und adaptive Softwareentwicklung sind die neuen Schlagworte zur Beschreibung der heutigen Programmierpraxis. In zunehmendem Maße werden die Projekte in den Fachabteilungen für die Fachabteilungen abgewickelt. Internet-Projekte sind zeitlich und örtlich begrenzte Vorstöße, um eine gewisse Funktionalität im Netz bereitzustellen. Da die Funktionalität im Voraus schwer zu spezifizieren ist, entsteht sie schrittweise durch einen iterativen Versuchsprozeß, bei dem Entwickler und Benutzer eng zusammenarbeiten. Wegen der Verschmelzung von Internet-Technologie mit den Geschäftsprozessen ist es erforderlich, die Anwendungsentwickler in die Fachabteilungen zu integrieren. Die Rolle der zentralen IT-Abteilung beschränkt sich darauf, die technische Infrastruktur bereitzustellen. Sie sorgt dafür, daß die Unternehmensdaten verfügbar und sicher sind, die Verbindungen zwischen den Anwendungssystemen funktionieren, die Belastung des Netzes optimal verteilt ist, die Transaktionen sicher sind und die neuen Internet-Anwendungen Zugriff auf die Backoffice-Funktionen haben. Die Wartung und Weiterentwicklung der Backoffice-Systeme bleibt auch im Zuständigkeitsbereich der zentralen IT. Insofern ist aus der IT-Burg ein Selbstbedienungsladen geworden. Die Konsumenten der IT-Technologie suchen aus, was sie brauchen und setzen es ein, wie sie wollen. Aus den ehemaligen IT-Burgherren sind Kundenberater und Denkmalschützer geworden. So ändern sich die Zeiten. Notizen aus der Softwareprovinz Im deutschen Lande herrscht große Unsicherheit. Kein IT-Manager traut sich eine Entscheidung zu treffen. Was soll man mit den alten Anwendungssystemen machen? Keiner kann in dieser chaotischen, globalisierten Welt in die Zukunft hineinschauen. Nur eines scheint sicher zu sein. Die IT-Technologie wird immer komplexer und immer anspruchsvoller, und was noch bedenklicher ist, es werden immer mehr Menschen von immer wenigeren abhängig. Können sie wirklich mit JAVA neu implementiert werden? Was für eine Infrastruktur wird sich durchsetzen ONE von Sun,.NET von Microsoft oder doch noch Websphere von IBM? Was wird aus der Object-Request-Broker-Architektur der OMG? Wird es durch Enterprise JAVA Beans überflüssig? Welchem Datenbanksystem gehört die Zukunft? Fragen über Fragen. Kein Wunder also, daß die IT-Entscheidungsträger zögern, eine Entscheidung zu treffen. Immerhin laufen die alten Systemen noch und so lange sie laufen, besteht kein akuter Handlungsbedarf sie abzulösen. Es besteht auch die Möglichkeit, einen großen Teil der alten Systeme weiter zu verwenden. Warum soll der alte Code auf dem Altar der Modernisierung geopfert werden, wenn die Funktionalität die gleiche bleibt? Dazu gebe es gar keinen Anlaß. Es soll nur das neu entwickelt werden, was wirklich zur Effektivität der Anwendungssysteme beiträgt, z. B. der Internet-Anschluß und die Client-Oberflächen. Der Rest kann gekapselt werden. Die IT-Abteilungen müssen im ersten Range damit beschäftigt sein, die bestehenden Anwendungssysteme zu entkoppeln und in möglichst unabhängige Komponenten mit sauberen, normierten Schnittstellen zu zerlegen. Gelingt diese Reengineering-Operation, dann ist der Kernteil der betrieblichen Datenverarbeitung für jede künftige Architektur aufnahmebereit. Dies ist auch das, was hinter dem Begriff Evolution En@bling steckt. Es sollen in der bestehenden Software die Weichen für die Zukunft gestellt werden, egal, um welche Zukunft es sich handelt. Evolution En@bling Seminare mit Harry M. Sneed Software-Evolution: August November 2001 Software-Nachdokumentation: August November 2001 Software-Migration: September Dezember 2001 Software-Kapselung: September Dezember 2001 Objektorientierte Testverfahren: Oktober Dezember 2001 OO-Systemtestverfahren: Oktober Dezember 2001 Software-Projektkalkulation: Oktober Oktober 2001 Software-Projektmanagement: Oktober November 2001 Weitere Einzelheiten zu den Seminaren entnehmen Sie bitte der CC-Seminarbroschüre oder unter 5

6 Harry Sneeds Entwicklungslabor Die Anbindung von Legacy-Programmen ans Internet In den letzten 10 Jahren haben wir den Übergang von festen 3270 Masken zu grafischen Oberflächen bis hin zu Webseiten erlebt. Es ist zu erwarten, daß diese Entwicklung in Richtung WAP und Spracheingabe weitergeht. Betriebswirtschaftliche Anwendungssysteme haben in der Regel einen Präsentationsteil, einen Zugriffsteil und einen Verarbeitungsteil. Der Präsentationsteil bedient die Benutzeroberfläche, der Zugriffsteil die Datenbank und der Verarbeitungsteil die Anwendung. Der Verarbeitungsteil ist der stabilste, denn die Anwendungen ändern sich am wenigsten. Auch der Zugriffsteil bleibt relativ konstant und ändert sich nur dann, wenn das Datenbanksystem ausgetauscht wird. Am labilsten ist der Präsentationsteil, weil hier die größten technologischen Änderungen stattfinden. Wer also seine Programme nicht ständig neu schreiben will, um den Anforderungen der letzten Mensch/Maschine- Kommunikationsmode zu genügen, muß zusehen, daß er die Teile seiner Programme sauber voneinander trennt. Vor allem der Präsentationsteil muß von der Verarbeitungs- und Zugriffslogik entkoppelt und in eine eigene Schicht verlagert werden, damit sie unabhängig vom Rest des Programmes fortgeschrieben werden kann. Dies ist die wichtigste Voraussetzung, um alte Programme ans Netz anzubinden. Das Tool SoftWrap ist dafür gedacht, IMS/DC- und CICS- Oberflächen von Hostprogrammen zu entfernen und durch eine Parameterschnittstelle zu ersetzen. Die Ein- und Ausgabedaten, die früher über die Maske ausgetauscht wurden, werden über eine Batchschnittstelle umgeleitet. Statt Masken zu Neue Werkzeuge für die Aufwandsschätzung von Wartungsprojekten Auf der GI-Softwaremanagement-Tagung an der Universität Marburg im Oktober letzten Jahres habe ich einen Beitrag zur Aufwandsschätzung von Wartungsprojekten geliefert. Dabei ging es um eine Hochrechnung der Fehlerbehebungs- und Änderungskosten der nächsten Version auf der Basis der Fehlermeldungen, Änderungsanträge und Wartungsaufwände bisheriger Versionen. Dieser metrikbasierte Ansatz diente zur Prognose der Gesamtkosten eines in der Wartung befindlichen Softwareproduktes. Inzwischen habe ich eine Repository-basierte Lösung für die Schätzung einzelner Wartungsprojekte entwickelt. Voraussetzung für diese Lösung ist das Vorhandensein einer Software- Repository. In Wien bei der SDS habe ich sogar drei Repositories eingerichtet, eine für das Fachkonzept bzw. für die Anforderungsspezifikation, eine für den Sourcecode und eine für die Testware. Zur Schätzung eines Wartungsprojektes kann man entweder über das Fachkonzept oder über den Code einsteigen. Beide Ansätze basieren auf einer Impactanalyse. Impactanalyse ist keine neue Technik. die ersten Ansätze gab es bereits in den 70er Jahren. In den 80er Jahren haben Robert Arnold und Shawn Bohner an der Universität Maryland mit dem Thema promoviert. Arnold hat sogar später ein Buch darüber geschrieben. In dem Journal of Software Maintenance sind seit 1990 zahlreiche Beiträge darüber erschienen. In meinem Buch Softwarewartung, erschienen 1990 im Rudolf Müller Verlag, habe ich der Impactanalyse ein Kapitel gewidmet. senden und zu empfangen, liest und schreibt das Programm XML-Dokumente. Dafür sind gewisse Veränderungen zum ursprünglichen Programm erforderlich. Zum einen müssen die TP-Anweisungen ausgeblendet werden. Zum anderen müssen die SEND- und RECEIVE-Operationen durch Stubaufrufe ersetzt werden. Der Stub XMLIN holt das nächste XML-Dokument aus der Pipeline, extrahiert die Daten daraus und überträgt es in die Schnittstelle des Zielprogrammes. Der Stub XMLOUT überträgt die Ausgabedaten des Programmes in ein neu generiertes XML- Dokument und legt dieses in der Outputqueue ab. Somit wird aus einer MFS- bzw. BMS-Schnittstelle eine XML-Schnittstelle und damit wird das Programm Internet-fähig. Das Wichtigste ist, daß die Programmmutation vollautomatisch geschieht, denn nur so ist es möglich, die Umwandlung jederzeit zu wiederholen. Das heißt, man kann das alte Programm pflegen und die Internet-fähige Version auf Knopfdruck wieder erzeugen. Die beiden Stubs XMLIN und XMLOUT sowie der Treiber XMLCOB sind bereits programmiert und in einer Pilotstudie ausprobiert worden. Die Studie hat bewiesen, daß es durchaus möglich ist, CICS- und IMS/DC-Programme ans Internet anzubinden. Über die Ergebnisse der Studie wird auf dem IEEE- Workshop für Software-Reengineering Anfang Oktober 2001 in Stuttgart berichtet. Bei der Impactanalyse geht es darum, ausgehend von einem Softwareelement bzw. einem Knoten im Systemnetz alle verwandten Knoten zu identifizieren, das heißt Elemente, die betroffen sein könnten, wenn das eine Element geändert wird. Man spricht vom sogenannten Ripple Effect. Wenn z. B. ein Modul geändert wird, sind seine Untermodule und eventuell seine übergeordneten Module betroffen. Falls eine Datenstruktur geändert wird, sind alle Module betroffen, die diese Datenstruktur verwenden. Für die Implementierung einer Impactanalyse müssen zum einen die potenziell betroffenen Elemente und zum anderen die relevanten Beziehungen zwischen den Elementen bekannt sein. Durch die Kapselung in der Objektorientierung sollte die Impactdomain bzw. der Wirkungsbereich von Änderungen eingeschränkt werden. Allerdings wird er durch Vererbung und Polymorphie wieder erweitert. Abhängigkeiten zwischen Codeelementen werden durch eine statische bzw. dynamische Codeanalyse erkannt und festge- 6

7 halten. Idealerweise werden sie in eine grafische Datenbank abgespeichert, in der die Knoten über Zeiger verknüpft sind. Wenn also ein Knoten ausgewählt wird, werden über die Zeiger in einem rekursiven Suchverfahren die verwandten Knoten markiert und gesammelt. Natürlich muß dieser Suchvorgang irgendwo auf eine Grenze stoßen das Problem der Transient Closure. Wenn diese Grenze nicht systembedingt ist, z. B. die Spitze der Vererbungshierarchie oder die Senke einer Funktionssequenz, dann muß sie von dem Initiator der Impactanalyse vorgegeben werden. Was für die Analyse des Codes zutrifft, gilt auch für das Objektmodell und das Fachkonzept insofern, als sie nach einem einheitlichen Strukturschema modelliert sind. UML ist ein normiertes Schema für die Abbildung der Systementwürfe. CMF Concept Management Facility ist ein einheitliches Schema für die Strukturierung von Fachkonzepten im Bereich der kommerziellen Informationstechnologie. CodeScan ist ein Werkzeug für die automatische Impactanalyse der SoftRepo Source-Repository. Ausgehend von einem Basiselement werden alle damit verwandten Zielelemente gesammelt und nach ihrer Entfernung von dem Basiselement gewichtet. Der Benutzer kann ein oder mehrere Basiselemente aus der Repository mit einer grafischen Oberfläche auswählen und eine geschätzte Änderungsrate vorgeben. Anschließend stößt er die Impactanalyse an. Als Ergebnis bekommt er die gewichtete Größe des von der geplanten Änderungen betroffenen Wirkungsbereiches sowohl in Anweisungen als auch in Function-Points und Object-Points. Diese Größe wird über die aktuelle Wartungsproduktivitätstabelle in Personentage umgesetzt. Somit hat der streßgeplagte Produktmanager mit einigen wenigen Mausklicks in wenigen Sekunden eine codeund erfahrungsbasierte Schätzung für den anstehenden Wartungsantrag. Als Alternative bzw. als Ergänzung zur Codeanalyse kann das aktuelle Fachkonzept analysiert werden. Zur Auswahl stehen Entitäten wie Geschäftsprozesse, Geschäftsobjekte, Geschäftsregeln, Benutzeroberflächen, Berichte und Geschäftsfunktionen. Der Benutzer markiert die, die zu ändern sind, und gibt die geschätzte Änderungsrate an. Der Rest erfolgt automatisch durch das Tool SpecScan. Es sucht die betroffenen Spezifikationselemente aus, justiert ihre Größe durch die Änderungsrate und die Entfernung vom Basiselement und zeigt die Größe des Wirkungsbereiches in Anweisungen, Function-Points, Data-Points und Object-Points an; Größen, die auch gleich in Personentage umgesetzt werden können. Der Wartungsplaner hat also die Möglichkeit, Wartungsaufwände auf der Sourcecodeebene oder auf der Fachkonzeptebene oder auf beiden Ebenen zu schätzen, wobei er dann zwei Schätzungen zum Vergleich hat. Beide Werkzeuge CodeScan und SpecScan sind jetzt in der Erprobung. Das Ziel ist es, für die Kunden eines Software- Produktes zuverlässige Aufwandsschätzungen für die Implementierung ihrer Sonderwünsche abzugeben. Dies ist wieder eine Vorbedingung zur Realisierung einer fundierten Versionsplanung in einem ordentlichen Wartungsbetrieb. Ein generisches Software-Repository für alte und neue Softwaresysteme Das SoftRepo Software-Repository dient sowohl zur Abbildung von objektorientierten Anwendungssystemen in C++, Java, SQL, IDL und XML, als auch zur Dokumentation von Legacy-Anwendungssystemen in Assembler, PL/I, COBOL, DLI, MFS und BMS. Möglich wurde dies dadurch, daß es gelungen ist, prozedurale Programme in ein objektorientiertes Schema hineinzubringen. Somit gibt es ein einziges allumfassendes Metamodell. Das Repository besteht aus vier Schichten, entsprechend den vier semantischen Ebenen der Softwarearchitektur. Diese sind die Konzept-, die Entwurfs-, die Code- und die Testschicht. Das zugrundeliegende Basismodell ist das Entity/ Relationship-Modell von Chen. In jeder Schicht gibt es Entitäten mit Attributen und bestimmten vordefinierten Beziehungen. Die Konzeptschicht basiert auf der Sprache CMF Concept Management Facility, die Entwurfsschicht auf UML Unified Modelling Language. Auf den Sprachen Java, C++ und COBOL basiert die Codeschicht und die Testschicht basiert schließlich auf der ANSI-828-Norm für Software-Testdokumentation. Die Entitäten und Beziehungen der Konzeptschicht werden aus der Analyse der CMF-Konzepte entnommen, die der Entwurfsschicht aus der UML-Schnittstelle gewonnen, die der Codeschicht über eine statische Analyse des Sourcecodes erfaßt und die der Testschicht aus den Testbibliotheken übernommen. Drei der vier Schichten sind bereits implementiert. Die Entitäten und Beziehungen können in jeder beliebigen relationalen Datenbank als Texte mit binären Beziehungen abgespeichert werden. Interessante Termine & Veranstaltung Bericht über die 23. Internationale Software-Engineering-Konferenz in Toronto Vor kurzem fand die 23. ICSE International Conference of Software Engineering in Toronto, Canada, statt. Wie zu erwarten war, gab es dieses Mal mehr als 800 Teilnehmer für 22 Tutorien, 18 Workshops und 50 Technical Papers. Die Proceedings werden also immer dicker in dem Maße wie die Disziplin Software-Engineering immer weiter wächst. Es ist mittlerweile unmöglich geworden, das Gebiet voll zu überblicken, geschweige denn zu beherrschen. Dafür gibt es viel zu viele Teilgebiete, auf der Prozeßachse von Requirements Analysis bis zu Configuration Management, auf der Umgebungsachse von Assembler auf alten Hostrechnern bis zu XML in einem BizTalk Netzwerk und auf der Anwendungsachse von embedded Echtzeitsystemen bis zu e-commerce-prototypen. Die Welt des Software-Engineering ist eben fragmentiert worden. Nur einige wenige Bezugspunkte halten die verstreuten Fragmente noch zusammen. 7

8 Interessante Termine & Veranstaltung Deutsche Beiträge zu dem Internationalen Workshop on Program Comprehension Ein Teilgebiet des Software-Engineering ist Software-Evolution und davon gibt es ein Teilgebiet Program Comprehension. Zu diesem Thema gibt es einen jährlichen Workshop und diesmal fand er im Rahmen der ICSE in Toronto statt. In Deutschland wächst das Interesse für dieses Gebiet. Neben meinem Beitrag Extracting Business Logic from existing Legacy Programs as a Basis for Redevelopment gab es einen Beitrag von Carola Lange, Universität Koblenz, Comparing Graph- Based Program Comprehension Tools to Relational Databased Tools und einen Beitrag von Thomas Eisenbarth, TU Stuttgart, zum Thema Feature-Driven Program Understanding Using Concept Analysis of Execution Traces. Außerdem trug Professor Gregor Snelting, Universität Passau, auf dem Main Track zum Thema Design Recovery and Program Understanding vor. Es ist also zu begrüßen, daß die deutschen Universitäten das Gebiet Reverse Engineering entdeckt haben und dabei sind, es zu erforschen. Jetzt ist die deutsche Wirtschaft dran sie mit Aufträgen zu unterstützen. IEEE veranstaltet Workshop on Software Reengineering an der TU Stuttgart In der ersten Oktoberwoche findet die 8. Working Conference on Software Reengineering statt, und zwar in Deutschland an der TU Stuttgart. Präsentiert werden vor einem internationalen Publikum Beiträge über die Methoden, Techniken und Werkzeuge des Software-Reverse- und -Reengineering. Besondere Schwerpunkte sind Sourcecode-Analyse, Data Reverse Engineering und Dekompilierungstechniken. Als Mitglied des Programmausschusses möchte ich an alle, die mit der Sanierung und Migrierung alter Systeme zu tun haben, appellieren, sich diese einmalige Gelegenheit nicht entgehen zu lassen. Sie werden es nicht bereuen. Anwesend wird die Weltelite dieser relativ neuen Teildisziplin sein. Wenn Sie von den Weltexperten lernen wollen, wie es mit Ihren Legacy-Programmen weitergehen soll, wenden Sie sich an den General Chair Dr. Rainer Koschke, Universität Stuttgart, Fax: (0711) , Koschke@informatik.uni-stuttgart.de Impressum Software Engineering Newsletter Herausgeber und Redaktion: Harry M. Sneed Flachstraße 13 D Wiesbaden Telefon O6 11/94 2O 4O Telefax O6 11/94 2O harry.sneed@caseconsult.com Druck: Auflage: WfB, Wiesbaden Stück Aufruf zum Besuch der 17. Internationalen Software-Maintenance-Konferenz in Florenz In der Woche vom 6. bis 10. November 2001 findet die Internationale Konferenz für Software-Maintenance zum 17. Mal statt, diesmal in einem für deutsche Besucher günstigen Ort Florenz, Italien. Die Themen reichen von der Gestaltung von Wartungsprozessen Change Management bis hin zur Code-Refaktorierung. Es verspricht also, eine erstklassige Tagung zu sein. Alle, die mit existierenden Softwaresystemen zu tun haben, sei es sie zu pflegen, zu testen, zu migrieren oder nachzubessern, sind herzlich eingeladen, an der Tagung teilzunehmen. Keynote Speaker sind niemand geringerer als die Professoren David Lorge Parnas und Hans-Dieter Rombach. Der Vater vom Extreme Programming Ken Beck wird auf einer Paneldiskussion seine Thesen verteidigen. Die Software-Ingenieure haben hier die Gelegenheit to sock it to him. Ich werde mir diese Gelegenheit nicht entgehen lassen. Auch ich werde diesmal dabei sein, und zwar in dreifacher Erscheinung zum einen mit einem Tutorial über die Kapselung alter Hostprogramme, zum Zweiten mit einem regulären Beitrag zum Thema Impact Analysis und zum Dritten mit einer Demo der SoftRepo Repository-Werkzeuge. All das sollten Sie nicht verpassen. Sie werden sicherlich davon profitieren. Für mehr Information wenden Sie sich an harry.sneed@caseconsult.com. Beiträge für die 6. Europäische Konferenz 2002 in Budapest gesucht Vom 11. bis 13. März 2002 findet die nächste Europäische Konferenz für Software Maintenance und Reengineering in Budapest, Ungarn, statt. Veranstaltet wird die Konferenz von mir persönlich. Program Chair ist Prof. Tibor Gyimóthy von der Universität Szeged. Wir suchen neben wissenschaftlichen Beiträgen auch Praxisberichte aus der Wirtschaft. Wer Erfahrungen mit Real-life-Reengineering-Projekten oder mit der Wartung und Weiterentwicklung von Legacy-Systemen hat, sollte unbedingt einen Bericht darüber verfassen und ihn an meine private -Adresse Harry.Sneed@t-online.de bis zum einreichen. Diese werden als short papers klassifiziert. Als solche dürfen sie nicht mehr als Wörter enthalten. Die Konferenzsprache ist Englisch. Denken Sie daran, daß Sie auch die Konferenz besuchen und bezahlen müssen, falls Ihr Beitrag angenommen wird. Es gibt nichts um sonst. Nur diesen Newletter. Ich freue mich, CC als einen der ersten Sponsoren begrüßen zu dürfen. Harry Sneed s Gesamtausgabe Die Sonderausgabe aller Software Engineering Newsletter von Harry M. Sneed befindet sich im Endstadium. Wir möchten uns bei allen Lesern bedanken, die mitgeholfen haben, diese Sonderausgabe zu ermöglichen.