Software Engineering – Überblick

Case Consult
The Evolution En@ bling Experts
CC-REPRINT
Software-Engineering – Überblick
Harry M. Sneed
CC GmbH, Wiesbaden
Published in:
PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
CC – branded
Case Consult
The Evolution En@ bling Experts
Copyright
No part of this document may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying and recording,
for any purpose without the written permission of CC GmbH. Information in
this document is subject to change without notice and does not represent a
commitment on the part of CC GmbH.
This document and the referenced software described in this document is
furnished under a license agreement or nondisclosure agreement. The document and the referenced software may be used or copied only in accordance
with the terms of the agreement. It is against the law to copy the document or
the software on any medium except as specifically allowed in the license or
nondisclosure agreement.
®
Copyright © 2002 CC GmbH. All rights reserved
© 2002 CC GmbH®
CC – branded
Case Consult
The Evolution En@ bling Experts
Harry M. Sneed
CC GmbH, Wiesbaden
Software-Engineering – Überblick
Sneed, Harry M., (MPA) Master of Public Administration,
Univ. Maryland; Programmer/Analyst, U.S. Navy Sept.;
Programmierer/Trainer, Hochschul-lnformationssysteme;
Projektleiter/Testmanager,
Siemens
AG;
SoftwareEngineering Trainer & Berater, SES; Produktleiter
SOFTORG-CASE System, Budapest; Autor zahlreicher
Bücher und Fachartikel zum Thema "SoftwareEngineering", Mitglied ACM, IEEE, Gl
Der Begriff "Software-Engineering" wurde genau vor 20 Jahren auf einer NATOWissenschaftstagung in Garmisch von dem Münchener Mathematikprofessor
Fritz Bauer geprägt. Als Antwort auf die damalige Software-Krise forderte Prof.
Bauer "The establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real
machines" [1]
Seitdem hat sich diese junge Disziplin stets weiter entwickelt. Natürlich auch mit
den üblichen Kinderkrankheiten. Die ersten Jahre bis etwa 1975 waren die Gründerjahre. Man suchte einen Platz für Software Engineering unter den herrschenden Computerwissenschaften. Da die Pioniere des Faches aus den damaligen
Programmierkreisen kamen - die Gründer wie Bauer, Dijkstra, Dahl, Hoare, Wirth
waren fast ausschließlich Mathematiker- lag in diesen ersten Jahren der Schwerpunkt auf einer Disziplin der Programmierung.
Unter dem Oberbegriff "Strukturierte Programmierung" wurden einige neue
Techniken der Programmierung eingeführt mit dem Ziel, Programme lesbarer,
wartbarer, testbarer und zuverlässiger zu gestalten. Dazu gehörten Techniken zur
Vereinfachung der Ablaufsteuerung, zur Gliederung der Programme, zur Strukturierung der Daten und zur allgemeinen Beherrschung der Programmkomplexität.
Als Nebeneffekt wurde auch die Programmierproduktivität erhöht, wie in zahlreiReprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 1
CC – branded
Case Consult
The Evolution En@ bling Experts
chen Projektberichten aus der damaligen Zeit bestätigt wurde. Aus dieser Zeit
stammen die Nassi-Schneidermann-Programme, die HIPO-Methode, die MichaelJackson-Programming-Technik, die Sprache PASCAL und zahlreiche Programmentwurfssprachen [2].
Die nächste Phase der Software-Engineering reichte in etwa von 1975 bis 1983. In
diesen Jahren verlagerte sich der Schwerpunkt von der Programmierung selbst
auf die Aktivitäten unmittelbar davor und danach, d.h. auf den Entwurf und den
Test. Bezüglich des Entwurfs sind zahlreiche Methoden in allen Erdteilen wie Pilze
aus dem Boden geschossen. Einige Methoden betonten den Entwurf der Datenstrukturen, andere betonten den Datenfluß, andere betonten die funktionale Gliederung und andere den Verfahrensablauf. Gemeinsam an allen Entwurfsmethoden
war das Ziel, ein besser strukturiertes und modulares Software-System mit einem
höheren Grad an Wartbarkeit, Testbarkeit und Wiederverwendbarkeit zu erreichen. Aus dieser Zeit stammen Structured Design, Jackson System Design,
abstrakte Datentypen und zahlreiche andere nützliche und nicht nützliche Entwurfsansätze [3].
Parallel zu dieser Entwicklung auf der Konstruktionsseite entfaltete sich unter dem
Begriff „Verifikation und Validation Techniken" eine Schule für den Test und die
Qualitätssicherung von Software. Von ablaufbezogener Testdeckung über funktionales Testen bis hin zur projektbegleitenden Qualitätssicherung mittels Review
und Inspektionen reichte das Spektrum an Test- und Prüfmaßnahmen, die in dieser
Zeit entstanden sind. Im Gegensatz zu den Entwurfsmethoden, die bald in die Praxis
überführt wurden, blieben diese Techniken jedoch weitgehendst vor den Toren der
Praxis stehen. Dies liegt einerseits an ihrer anspruchsvollen theoretischen Basis
und zum anderen an den Kosten ihrer Einführung. Diese Kosten und Nutzen der
Software-Qualitätssicherung sind immer noch umstritten [4].
Seit etwa 1983 ist Software-Engineering in eine dritte Phase übergegangen. Diese
Phase ist gekennzeichnet, zum einen durch eine Ausdehnung der Software-Engineering-Disziplin aus Aktivitäten außerhalb der eigentlichen Software-Entwicklungsaktivitäten wie Projektplanung, Anforderungsspezifikation, Konfigurationsmanagement und Datenanalyse, zum zweiten durch den Versuch, die diversen
Software-Engineering-Subdisziplinen zu normieren und integrieren und, zum dritten durch die Automation der Software-Entwicklung, die mit dem Begriff CASE Computer Aided Software Engineering - bezeichnet wird [5].
Heute präsentiert sich Software-Engineering als eine tiefgestaffelte und fast endlos
breite Hierachie von Verfahrensmodellen, Methoden, Techniken und Werkzeugen
für alle Tätigkeiten, die mit der Planung, Durchführung und Kontrolle von Projekten zur
Software-Entwicklung und Wartung zusammenhängen. Diese Tätigkeiten reichen von
der Anforderungsanalyse neuer Software bis zur Sanierung von alter Software und
schließen folgendes ein: (s. Bild 1)
!
Projektmanagement
!
Anforderungsspezifikation
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 2
CC – branded
Case Consult
The Evolution En@ bling Experts
!
System- und Programmentwurf
!
Programmierung
!
Programmtest
!
Integrationstest
!
Systemabnahme
!
Systemverwaltung
!
Systemwartung
!
Systemerneuerung
Für jede dieser Tätigkeiten gibt es eigene Methoden mit eigenen Techniken und eigenen Werkzeugen (Bild 2). Da diese auch stark im Fluß begriffen sind, ist es fast
unmöglich, sie alle zusammenzufassen. Software-Engineering ist eben noch sehr
jung und entsprechend schnell ist ihr Wachstum. Sie wächst sogar schneller als unser
Vermögen, sie zu begreifen. Daher muß jeder Versuch, Software-Engineering zu beschreiben, zeitlich und räumlich abgegrenzt werden. In diesem Aufsatz werden fünf
Schwerpunktthemen, die für den heutigen Stand der Software-Engineering kennzeichnend sind, herausgegriffen und kurz erläutert. Diese fünf Themen sind:
!
Software-Projektmanagement
!
Software Requirements Engineering
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 3
CC – branded
Case Consult
The Evolution En@ bling Experts
!
Software-Entwurf
!
Software-Qualitätssicherung
!
Software-Wartung und -Wiederverwendung
Zum Abschluß wird auf den Versuch der IEEE eingegangen, Software-Engineering zu
normieren, denn sollte Software-Engineering jemals eine echte Ingenieurdisziplin
werden, dann nur auf dem Wege der internationalen Normierung. Erst wenn solche
international verbindliche Normen gelten, werden wir von einer wahren Ingenieurdisziplin reden können. Bis dahin wird sie bleiben was sie ist: ein nebelhaftes, konturloses Luftschloß am Horizont, dessen Gestalt sich je nach Blickwinkel ändert.
Software-Projektmanagement
Software Engineering ist von Anfang an eng mit Software-Projektmanagement verbunden gewesen. Michael Jackson hat einmal behauptet, Software-Engineering sei
ausschließlich ein Instrument des Managements um eine dynamisch chaotische
Technologie in ein statisches Zwangsmuster zwecks der Kontrolle hineinzupressen [6].
Damit wollte Jackson die diversen Lebenszykluskonzepte bzw. Phasenkonzepte in
Zweifel stellen. Er meint mit Recht, wir dürfen Dinge nicht institutionalisieren, die noch
nicht ausgereift sind. Wenn wir aber seine Gedanken weiterverfolgen, dann dürften wir
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 4
CC – branded
Case Consult
The Evolution En@ bling Experts
überhaupt keine Software herstellen, weil wir noch zu wenig davon verstehen. Die Tatsache, daß Software zu einem unentbehrlichen Bestandteil unseres postindustriellen
Zeitalters geworden ist, zwingt uns, deren Herstellungs- und Wartungsprozeß unter
Kontrolle zu bringen. Denn nur mittels Phasen, Prüfungen und Richtlinien können wir
überhaupt hoffen, diesen wahrlich stochastischen Prozeß unter dem Gesichtspunkt der
Wirtschaftlichkeit und Zuverlässigkeit in den Griff zu bekommen.
Demzufolge ist ein Phasenkonzept irgendwelcher Art die Voraussetzung schlechthin
für Software-Engineering. In den 70er Jahren hat sich das konventionelle Wasserfallmodell (Bild 3) verbreitet. Danach hat jede Phase das Teilprodukt der vorhergehenden
Phase erweitert und überarbeitet, um daraus ein neues detailliertes Teilprodukt zu erzeugen, z.B. Programme aus dem Entwurf erzeugen. Pro forma arbeiten die meisten
Anwenderbetriebe immer noch nach diesem veraltetem Konzept, obwohl seine
Schwächen hinlänglich bekannt sind.
Sogar Barry Boehm, der Vater dieses Modells, hat sich davon distanziert [7].
Heute hat man die Wahl zwischen verschiedenen Vorgehensmodellen. Neben dem
konventionellen Wasserfallmodell bieten sich u.a. das zyklische Modell, das
Operationsmodell, das Transformationsmodell und das Prototyping Modell an.
Das zyklische Modell (Bild 4) sieht vor, daß ein größeres Software-System stückweise
in vielen kleinen Inkrementen realisiert wird, d. h. der Lebenszyklus wird mehrfach
durchlaufen bis das gewünschte System endlich fertig und einsatzreif ist. Die Inkremente können gar einzelne Programme oder Transaktionen sein. Auf diese Weise reduziert man das Risiko einer Fehlentwicklung. Boehm propagiert, daß kein SoftwareProjekt länger als zwei Jahre oder mehr als 20 Mannjahre beanspruchen darf. Sonst
ist das Inkrement zu groß. Dies hat zur Folge, daß große Projekte in vielen kleineren
Projekten zu zerschlagen sind, die nebeneinander und/oder hintereinander ablaufen
[8],
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 5
CC – branded
Case Consult
The Evolution En@ bling Experts
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 6
CC – branded
Case Consult
The Evolution En@ bling Experts
Das Operationsmodell (Bild 5) sieht eine lange Spezifikationsphase vor, in der bis zu
75% der manuellen Arbeit hineinfließt, um eine operationale Spezifikation zu erstellen.
Danach erfolgen zwei oder mehr automatisierte Transformationen, z.B. vom Fachkonzept ins technische Konzept und vom technischen Konzept in die Programme, wobei auf jeder semantischen Ebene einiges manuell hinzugefügt wird. Danach beträgt
das Verhältnis der Spezifizierer zu den Entwicklern etwa 3:2. Die Hauptaufgabe der
Entwickler bleibt der Test der generierten Programme gegen die ursprüngliche
Spezifikation [9].
Das Transformationsmodell (Bild 6) geht einen Schritt weiter. Hiernach steckt 100%
der manuellen Arbeit in der Spezifikation, die anschließend mit Hilfe eines Expertensystems vollautomatisch in Zielprogramme transformiert wird. Formale Beweisführung
tritt an die Stelle des Testens, denn insofern als die Transformation korrekt erfolgt, sind
die Programme theoretisch eine exakte Wiedergabe der Spezifikation. Für eine
derartige Transformation ist eine Knowledge-Base der Zielumgebung mit Kenntnis der
Umsetzungs- und Optimierungsregeln sowie der technischen Einschränkungen
erforderlich [10].
Das Prototyping Modell (Bild 7) sieht schließlich die Konstruktion einer lauffähigen Version bzw. einer Simulation der Anwendung in einer provisorischen Form vor, damit
der Benutzer einen Eindruck vom Endprodukt gewinnen kann. Mit diesem Modell
werden die Bedürfnisse des Benutzers erforscht und festgehalten, um sie nachher
mit einer richtigen ingenieursmäßig konstruierten Version zu erfüllen. So gesehen ist
der Prototypbau Bestandteil der Requirements Engineering, ein kleines Vorprojekt.
Hier verbirgt sich die Gefahr, daß aus einem Vorprojekt ein ganzes Projekt und aus
dem Prototyp ein Produkt wird mit allen verheerenden Konsequenzen für die Wartung
[ 11] .
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 7
CC – branded
Case Consult
The Evolution En@ bling Experts
Neben der Bereitstellung eines geeigneten Vorgehensmodells umfaßt Software
Management die Tätigkeiten der Systemdefinition, der Kostenkalkulation, der
Projektorganisation, der Projektplanung und der Systemverwaltung.
Bei der Systemdefinition werden die Anforderung analysiert, verschiedene fachliche
Lösungsalternativen ausgewertet, Ziele gesetzt und der Projektumfang quantitativ und
qualitativ abgesteckt.
Bei der Projektkalkulation werden der Aufwand, die Dauer und die Folgekosten der
Projekte nach irgendeiner Schätzmethode geschätzt. Einige der bekanntesten
Schätzmethoden sind die COCOMO-Methode von Boehm [12], die Function-PointMethode von Albrecht [13], die Komponentenanalyse-Methode von Sneed [14], und
die Analogie-Methode von Putnam [15]. Diese Methoden dienen alle dazu, den Aufwand und die Laufzeit eines Projekts anhand der definierten Qualität und Quantität des
Systems sowie der Produktivität der Mitarbeiter zu berechnen. Die Produktivität läßt dich
in Anweisungen, Lines of Code, Function Points oder Komponente erfassen.
Bei der Projektorganisation wird eine geeignete Organisationsform für die Durchführung des Projekts bestimmt. Software-Projekte können fast beliebig organisiert werden. So gibt es verteilte Projekte unter der Leitung der Entwickler, Chief-Programmer
Teams, kollegiale Teams usw. Jede Organisationsform hat Vor- und Nachteile, abhängig von der jeweiligen Projektumgebung. Gewiß ist nur, daß die Organisation des
Projektes untrennbar von der Architektur des Software-Systems selbst ist. Die
Arbeitsteilung im Projekt zeigt sich unweigerlich in der Komponententeilung des
Produktes.
Bei der Projektplanung werden die Zwischenergebnisse, Teilprodukte, Aufgaben und
Phasen eines Projektes endgültig festgelegt und der Projektablauf auf die Zeitachse
projektiert. Dafür werden Planungstechniken wie z.B. PERT, CPM oder MPM verwendet. Sie dokumentieren die Abhängigkeiten zwischen den Aufgaben und zeigen alternative Möglichkeiten zur Abarbeitung der Aufgaben auf. Wichtig hier ist, daß der
Arbeitsplan - Workbreakdown Plan - möglichst fein gegliedert wird, um alle Aufgaben
zu erfassen.
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 8
CC – branded
Case Consult
The Evolution En@ bling Experts
Bei der Projektsteuerung kommt es darauf an, den Projektablauf zu verfolgen und
notfalls zu korrigieren. Für die Projektverfolgung ist ein Berichtswesen nötig. Verfolgt
werden die Termine, Kosten, Aufwand der Aufgaben sowie der Status und die Qualität
der Ergebnisse. Durch einen Soll/lst-Vergleich werden die Abweichungen vom Soll
protokolliert und festgehalten. Es ist hier, wo wichtige Daten für die Software-Forschung zu gewinnen sind.
Bei der Systemverwaltung werden letztlich der Zustand der Software-Komponenten
überwacht, verschiedene Versionen geführt und die Änderungen verfolgt. Hier setzt
also das Configuration Management ein. Hier schließt sich auch der Kreis der Entwicklung mit der Definition neuer Anforderungen aufgrund der Erfahrung mit dem
Produkt [16].
Software Requirements Engineering
Die eigentliche Implementierung der Software bzw. die Programmierung selbst stand
am Anfang im Mittelpunkt der Software Engineering. Sie ist auch heute wichtig und
leider von vielen sogenannten Praktikern immer noch nicht bewältigt, aber inzwischen sind andere Themen der Software-Technologie in den Vordergrund gerückt.
Ein solches Thema ist „ Requirements Engineering". Es hat sich nämlich gezeigt, daß
alle Bemühungen in der Programmierung umsonst sind, wenn man die Anforderungen nicht richtig erfaßt oder verstanden hat. Es besteht sogar die Gefahr, daß eine
völlig falsche Lösung optimal implementiert wird.
Um dies zu verhindern, sind verschiedene Methoden der Requirements-Analyse und
-Spezifikation ins Leben gerufen worden. Sie teilen sich in manuelle und maschinelle
Methoden, aber das Ziel ist gemeinsam. Sie dienen dazu, ein Modell der Anwendung zu
schaffen, damit dieses mit dem Benutzer vor der eigentlichen Realisierung abgestimmt
werden kann. Dazu müssen sie eine Darstellungsform anbieten, mit deren Hilfe das
Anwendungsmodell erfaßt, dokumentiert und validiert werden kann. Darüberhinaus
wird es oft notwendig sein, vor allem bei interaktiven oder zeitkritischen Systemen, das
Verhalten des geplanten Systems zu simulieren. Diese Simulierung unter der Bezeichnung "Prototyping" ist ein wichtiger Bestandteil der Requirements Engineering
geworden.
Im Mittelpunkt der "Requirements Engineering" steht die Darstellungstechnik. Danach
unterscheiden sich die Spezifikationsansätze in graphische, tabulare und notationelle
Beschreibungen. Zu den graphischen Darstellungstechniken gehören Petrinetze,
Datenflußdiagramme, Datenbäume, Funktionsbäume und Entity/Relationship-Diagramme. Zu den tabularen Darstellungstechniken gehören EVA-Diagramme, Entscheidungstabellen, Präzedenztabellen, Relationentabellen und Zuordnungstabellen.
Zu den notationellen Darstellungsformen gehören strukturierte Prosa, Pseudo Code,
Datenbeschreibungssprachen, algebraische Formeln und sonstige formale Beschreibungssprachen wie z.B. die Vienna Definition Language.
In der Praxis werden die genannten Darstellungsformen oft kombiniert. Die Vielfalt der
Darstellungstechniken führt zu einer noch höheren Anzahl von Kombinationsmöglich-
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 9
CC – branded
Case Consult
The Evolution En@ bling Experts
keiten. Daraus erklärt sich die Explosion von Spezifikationsansätzen, die im Grunde
genommen alle ähnlich sind.
Zu den bekanntesten manuellen Spezifikationsansätzen zählen die HIPO-Methodik,
die SADT-Methodik, die E/R-Methodik und die SAMM (structured analyse) Methodik, wovon es verschiedene Varianten gibt. Diese Methoden sehen alle das Zeichen von
Diagrammen vor, die mit Texten und Tabellen ergänzt werden. Die daraus
resultierenden Dokumente werden auf der einen Seite den Benutzern zwecks der
Abstimmung und auf der anderen Seite den Entwicklern als Arbeitsvorgabe vorgelegt
[17].
Außer diesen informalen Ansätzen gibt es zahlreiche formale Spezifikationssprachen
für die Spezifikation von Software-Systemen wie VDL, SETL, Z und SLAN-4. Diese
Sprachen erlauben es dem Analytiker, die Anforderungen in einer strengen mathematischen Notation zu beschreiben, die sich durch entsprechende Werkzeuge editieren
und analysieren läßt [18].
Computergestützte Spezifikationsansätze bilden den Kern dessen, was heute als
CASE auf dem Markt angeboten wird. Abgesehen von dem Etikett, ist aber wenig neu
an
diesen
Ansätzen.
Eine
der
populärsten
computergestützten
Spezifikationsansätze - das ISDOS-System mit PSL und PSA -wurde schon Anfang
der 70er Jahre entwickelt [19]. In der zweiten Hälfte der 70er Jahre entstand das
SREM-System mit seiner Requirements Spezifikationssprache (RSL). Dieses System
ist nach wie vor das umfangreichste Requirements Engineering System der Welt, mit
einer Mischung aus Graphik, Tabellen und Text. Es enthält übrigens auch schon vom
Anfang an eine Prototyping Kapazität [20].
Inzwischen sind die computergestützten Requirements-Spezifikationssyteme so
zahlreich, daß man sie überhaupt nicht mehr zählen kann. Allein in den USA werden
mehr als 200 auf dem Markt angeboten. Nur mit der Zeit wird es möglich sein, den
Streu vom Weizen zu trennen. Auf jedem Fall hat durch CASE das Thema "Requirements Engineering" einen mächtigen Auftrieb bekommen. Umstritten ist noch, ob die
Spezifikation als getrenntes Teilprodukt neben den Programmen zu erstellen und zu
pflegen ist oder ob daraus die Programme zu generieren sind. Für beide Alternativen
gibt es Vor- und Nachteile.
Software-Entwurf
Ein Kernthema der Software Engineering, das von vielen irrtümlicherweise mit Software Engineering schlechthin verwechselt wird, ist der Entwurf von Software-Systemen. Die Tätigkeit des Entwerfens ist zwar von großer Bedeutung, nicht nur für die Programmierung, sondern auch für das Testen und die Wartung, aber sie bleibt schließlich
nur eine von vielen Tätigkeiten, die ein Software Engineer ausübt.
Im Laufe der 70er Jahre ist eine Vielzahl von Entwurfsansätzen aus der DV-Praxis hervorgegangen. Praktiker wie Mills, Wirth, Myers, Constantine, Yourdon, Jackson,
Warnier, Orr und zahlreiche andere haben ihre Ideen zu diesem Thema dokumentiert.
Es sind Ideen, mit denen jeder Software Engineer vertraut sein müßte. Im großen und
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 10
CC – branded
Case Consult
The Evolution En@ bling Experts
ganzen lassen sich die Entwurfsansätze der 70er Jahre nach ihrem Ausgangspunkt
in drei Kategorien erteilen:
!
funktionsorientierte Ansätze
!
datenflußorientierte Ansätze
!
datenstrukturorientierte Ansätze
Die funktionsorientierten Ansätze gehen von der funktionalen Gliederung einer Anwendung aus. Die Hauptfunktionen werden schrittweise verfeinert bis man auf die Grundfunktionen stoßt. Jede Funktion ist eine "black box" mit Eingaben, Ausgaben und einer
Verarbeitungsregel. Die Daten werden aus der Sicht der Verwendung definiert und
erst zum Schluß in Datengruppen zusammengefaßt. Stellvertretend für diesen Ansatz
sind die HIPO-Methode der IBM [21] sowie die Arbeiten von Wirth - Stepwise Refinement [22] - und Mills -Information System Design [23]. Dieser Ansatz gewann im
Laufe der 70er Jahre den größten Verbreitungsgrad.
Die datenflußorientierten Ansätze gehen von dem Datenfluß durch das System aus. Der
Fluß der Daten von einer Transformation zur anderen wird skizziert und aus den
Transformationen werden die Funktionen abgeleitet. Die Funktionsstruktur wird somit
aus der Zusammenführung zusammenhängender Datenflüße abgeleitet. Die Grundfunktionen sind die verfeinerten Datentransformationen. Eine weitere Variante dieses
Ansatzes ist die Transaktionsanlyse für Online-Anwendungen, bei der einzelne Datenflußpfade aufgrund einer Analyse der Transaktionsart angesteuert werden. Stellvertretend für diesen Ansatz sind die Arbeiten von Myers, Constantine und Yourdon unter
dem gemeinsamen Begriff "Structured Design" [24]. Dieser Ansatz ist auch die Basis
zahlreicher Entwurfswerkzeuge geworden, wahrscheinlich wegen der Eignung der
Datenflußdiagramme für graphische Representationen.
Die datenstrukturorientierten Ansätze gehen von der Struktur der Anwendungsdaten
aus. Die Daten werden hierbei als die Basis der Software-Struktur angesehen. Zuerst
wird ihre Struktur in Anhängigkeit von ihrer Verwendung bestimmt. Daraus ergeben
sich die einzelnen Datengruppen, die sich in Eingabe- und Ausgabestrukturen teilen.
Durch eine Gegenüberstellung bzw. einer Zusammenführung der miteinander
verbündeten Eingabe- und Ausgabe-Strukturen werden die Funktionen und ihre
Struktur abgeleitet. Die Funktionen werden als Operationen auf die einzelnen Daten
bzw. Datengruppen betrachtet. Ausschlaggebend für die Strukturierung der Funktionen
ist die Strukturierung der Daten, die sie verarbeiten. Stellvertretend für diesen Ansatz
sind die Arbeiten von Jackson [25], Warnier [26] und Orr [27], die den Ansatz
inzwischen vom Programmentwurf auch auf den Systementwurf übertragen haben.
Der datenstrukturbezogene Ansatz mit seiner exakten Vorgehensweise bietet die
beste Basis für die automatische Generierung der Software. Er ist jedoch der
anspruchvollste und damit auch am schwierigsten zu lernen.
In den 80er Jahren ist ein neuer Entwurfsansatz in Anlehnung an den datenstrukturbezogenen Ansatz unter dem Begriff objektorientierter Entwurf entstanden [28].
Dieser zukunfsträchtige Ansatz sieht als Ausgangspunkt die Identifikation der Datenobjekte vor. Diese können Masken, Listen, Tabellen, Dateien oder sonstige extreme
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 11
CC – branded
Case Consult
The Evolution En@ bling Experts
Schnittstellen sein. Sie entsprechen den Hauptwörtern in der Anwendungsbeschreibung. Sind sie einmal eindeutig identifiziert, werden die Operationen auf sie
ermittelt. Diese entsprechen den Verben in der Anwendungsbeschreibung. Jedes
Objekt und die dazugehörigen Operationen bilden eine Datenkapsel bzw. einen abstrakten Datentyp. Ein Software-System entsteht bottom-up aus der Zusammenführung seiner Datentypen, die über abstrakte Datenschnittstellen miteinander
kommunizieren. Die abstrakten Datenschnittstellen entsprechen den Views bzw.
Datensichten auf die diversen Datenobjekte. Stellvertretend für diesen Ansatz sind
die Arbeiten von Parnas [29], Denert [30], Booch [31] und Cox [32]. Der objektorientierte Entwurfsansatz fördert die Modularität, die Testbarkeit und die Wiederverwendbarkeit und scheint deshalb am meisten im Einklang mit den Zielen der Software-Qualitätssicherung zu stehen [33],
Die Wahl eines geeigneten Entwurfsansatzes ist heute immer noch eine Glaubenssache. Wegen der Vielfalt der Ziele ist es nicht möglich nachzuweisen, daß ein Ansatz
eindeutig besser ist als die anderen. Wichtig ist, daß nach einer Methode entworfen
wird, die mit den Zielen der Anwendung übereinstimmt. Die Entscheidung für eine
Entwurfsmethode hängt aber nicht nur von der Anwendung, sondern auch von dem
Erfahrungsprofil der Entwickler und der Verfügbarkeit von Werkzeugen ab. Sie ist eine
der wichtigsten Entscheidungen, die ein Software Engineer zu treffen hat [34].
Software-Qualitätssicherung
Ein zentrales Thema der Software Engineering, der viel Aufmerksamkeit gewidmet
wird, ist die "Qualitätssicherung". Software Engineering soll schließlich zwei Zwecken
dienen, zum einen der Steigerung der Produktivität und zum zweiten der Erhöhung
der Qualität. Von diesen beiden Zielen hatte jedoch vom Anfang an die „Qualitätssicherung" die höchste Priorität. Man könnte behaupten, Software Engineering sei ins
Leben gerufen, um die Qualität der Software zu bessern.
Es stellte sich jedoch bald heraus, das der Begriff "Qualität" im Bezug auf Software
äußerst schwammig ist. Es ist zwar sehr viel zu diesem Thema geschrieben worden
und an Definitionen mangelt es nicht. Die Schwierigkeit besteht darin, die Definitionen
zu operationalisieren; der Teufel steckt im Detail. Die üblichen Qualitätsmerkmale
sind:
!
Zuverlässigkeit
!
Benutzerfreundlichkeit
!
Sicherheit
!
Effizienz
!
Wartbarkeit
!
Übertragbarkeit
!
Erweiterbarkeit
!
Wiederverwendbarkeit [35]
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 12
CC – branded
Case Consult
The Evolution En@ bling Experts
Die ersten vier Merkmale ergaben sich aus der Sicht des Konsumenten, die letzten
vier sind mehr aus der Sicht des Produzenten. Hier zeigt sich schon, daß Qualität wie
Schönheit nicht ohne weiteres objektivisierbar ist, sie liegt zum Teil in den Augen des
Betrachters. Qualität ist auch relativ. Sie hängt von der jeweiligen Situation und der
Nutzung ab. D.h. sie muß bei jeder Anwendung neu definiert werden.
Die Variante Natur der Software-Qualität macht es sehr schwer, sie so exakt zu definieren, daß man sie messen könnte. Denn, um sie messen zu können, müßte die
Qualität erst quantifiziert werden. Hierfür bieten sich zahlreiche Software-Metriken
an, z.B. Halsteads Software Science [36], McCabes Metrik für Ablaufkomplexität [37],
Chapins Metrik für Datenkomplexität [38], Huangs Metrik für Datenflußkomplexität [39]
und Henrys Metrik für Systemkomplexität [40]. Somit haben wir auf der einen Seite
einige abstrakte Begriffe und auf der anderen Seite eine Vielzahl an quantitativen
Meßansätzen. Dazwischen ist eine riesige Kluft. Es fehlt also die Verbindung zwischen
diesen beiden Ebenen, d.h. niemand kann sagen, ob McCabes Metrik wirklich einen
Zusammenhang mit Wartbarkeit oder Zuverlässigkeit hat. Solange diese Verbindungen
fehlen, wird die Software-Qualitätssicherung keine fundierte theoretische Basis haben.
Zur Zeit arbeiten einige nahmhafte Forschungsprojekte daraufhin, diese Verbindung
herzustellen, darunter das Software-Engineering-Labor von Prof. Basili; in den USA
[41] und das REQUEST-Projekt in Europa [42]. Da die Verbindungen sich nur
empirisch beweisen lassen, ist die Arbeit äußerst mühselig. Es ist vor allem schwierig,
geeignete Daten aus der DV-Praxis zu erhalten. Daher wird es wahrscheinlich noch
Jahre dauern, bis ein fundiertes theoretisches Modell für Software-Qualitätssicherung
existiert. Bis dahin wird man sich mit pragmatischen Ansätzen abfinden müssen.
Die pragmatischen Ansätze zur Qualitätssicherung orientieren sich an den SoftwareEntwicklungsphasen. Nach der Phase der Anforderungsspezifikation erfolgt die
Spezifikationsabnahme durch formale und sachliche Prüfungen. Die formalen Prüfungen, die auch computergestützt sein können, kontrollieren die Konsistenz, die Vollständigkeit und die Plausibilität bzw. Implementierungsgerechtigkeit des Fachkonzeptes. Hier lassen sich schon sowohl etliche formale Fehler erkennen als auch
fachliche Schwachstellen aufdecken.
Nach der Entwurfsphase folgt die Entwurfsbewertung bzw. der Design Review. Hier
sind vielerlei Prüfungen möglich. Zum einen wird geprüft, ob das technische Konzept
formal korrekt ist. Zum zweiten wird geprüft, ob der Entwurf den Entwurfsrichtlinien
entspricht. Zum dritten wird geprüft, ob der Entwurf die Spezifikation abdeckt. Schließlich läßt sich prüfen, inwieweit der Systementwurf die Spezifikationsmerkmale erfüllt.
Diese Prüfungen lassen sich zum größten Teil automatisch durchführen.
Auf die Programmierung folgt die Programmprüfung, auch Code-Inspektion genannt.
Hier geht es darum, zu prüfen, ob die Programme die Programmierrichtlinien einhalten, ob sie den Entwurf korrekt widerspiegeln und ob sie im Einklang mit spezifizierten Qualitätsmerkmalen sind. Im immer stärkeren Maße werden diese Prüfungen
durch automatische Werkzeuge wie Code-Auditoren und statischen Analysatoren
unterstützt.
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 13
CC – branded
Case Consult
The Evolution En@ bling Experts
Nach dem Test erfolgt eine Testrevision. Hier wird kontrolliert, ob die Software ausreichend getestet wurde. Dazu sind gewisse Testdeckungsgrade wie z.B.
Ablaufdeckung, Datendeckung und Funktionsdeckung erforderlich. Diese
Deckungsmaßstäbe hängen mit den jeweiligen Testansätzen zusammen:
!
der ablaufbezogene Test, wonach die Testfälle aufgrund der Ablaufstruktur der
Programme ermittelt werden
!
der datenbezogene Test, wonach die Testfälle aufgrund der Datenstruktur
ermittelt werden
!
der funktionsbezogene Test, wonach die Testfälle aufgrund der Spezifikation
ermittelt werden
Die genannten Testansätze müssen systematisch angewandt und maschinell unterstützt werden. Dafür werden diverse Testwerkzeuge wie Testmonitoren, dynamische
Analysatoren, Testdatengeneratoren und Testergebnisvalidatoren eingesetzt.
Der Nutzen der Software-Qualitätssicherung zeigt sich meist erst in der Wartungsphase. Je länger diese Phase dauert, je größer der Nutzen. Da dieser Nutzen aber
selten in die ursprüngliche Kosten/Nutzen-Analyse berücksichtigt ist, sehen die
Verantwortlichen der Software-Entwicklung nur die erhöhten Kosten der Qualitätssicherung. Dies erklärt, warum die Qualitätssicherung in der Praxis fast immer zu kurz
kommt. Software-Qualität in den Griff zu bekommen, ist eines der großen offenen
Probleme der heutigen Software Engineering [43].
Software-Wartung und -Wiederverwendung
Wartung und Wiederverwendung sind zwei verwandte Themen, die immer mehr an
Bedeutung gewinnen. Je mehr Software produziert wird, desto mehr wächst das Problem der Pflege und je teurer Software wird im Verhältnis zur Hardware, desto mehr
wächst der Druck, vorhandene Software wiederzuverwenden. Casper Jones hat geschätzt, daß es 1990 weltweit mehr als 25 Milliarden Programmanweisungen geben
wird. In einem durchschnittlichen Programm sind jedoch nur ca. 15% der Anweisungen problemspezifisch, d.h. 85% wäre wiederverwendbar [44]. Es werden in fast jedem Betrieb Millionen an redundanter Software verschwendet, bloß weil es dem
Software Management nicht gelingt, vorhandene Software wiederzuverwenden.
Inzwischen hat Software Engineering auf diese Situation reagiert, nicht nur in der
Theorie, sondern auch in der Praxis. Software-Wiederverwendung ist kein Schlagwort
mehr. Sie wird auf der einen Seite durch neue Entwurfsansätze wie "Object Oriented
Design" explizit bei der Entwicklung angestrebt [45]. Auf der anderen Seite wird sie
nachträglich durch "Reverse Engineering" erarbeitet. Durch die Methodik der Software-Sanierung werden alte Software-Systeme wie alte Städte renoviert und wieder
verwendbar gemacht. Außerdem wird durch den Einsatz von Expertensystemen alte
Software automatisch wiederaufbereitet und in neue Systeme mit den gleichen Funktionen überführt. Diese und ähnliche Ansätze versprechen mögliche Lösungen zur
Bewältigung der Vergangenheit und zur Rettung bisheriger Investitionen [46].
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 14
CC – branded
Case Consult
The Evolution En@ bling Experts
Ebenso wichtig wie die Wiederverwendung der alten Software ist deren Pflege. Die
überwiegende Mehrzahl der heutigen Programmierer - nach Lientz und Swanson
schon mehr als 50% - sind nur noch mit der Instandhaltung vorhandener SoftwareSysteme beschäftigt. Dafür sind dringend erprobte Verfahren und Hilfsmittel erforderlich. Ein solches Verfahren ist das "Configuration Management" für die laufende Verwaltung der Software-Komponenten sowie für einen geregelten Fehlerkorrektor- und
Änderungsdienst. Fehlermeldungen und Änderungsanträge durchlaufen ein exakt
definiertes Vorgehensmodell, in dem die Änderungen, Erweiterungen und Korrekturen
zur vorhandenen Software geplant, spezifiziert, durchgeführt, verifiziert und validiert
werden. Außerdem werden verschiedene Software-Versionen registriert und geführt.
Werkzeuge für die Software-Wartung reichen von Source-Comparatoren und statischen Analysatoren bis zu Data Dictionary und Configuration Management Systeme.
Ihr Einsatz ist für die Verwaltung komplexer Software-Systeme heute unentbehrlich
[47].
Wartung und Wiederverwendung werden in den 90er Jahren mit großer Wahrscheinlichkeit die wichtigsten Themen in Software Engineering werden (Bild 8).
Software Engineering Standards
Seit 1975 bemüht sich das IEEE (Institute of Electrical and Electronics Engineers) um
Standards für Software Engineering. Das Ergebnis dieser Bemühungen ist eine Reihe
Standards für fast alle Gebiete der Software Engineering. Diese Standards werden zur
Zeit von dem American National Standard Institute als Probe-Standards angeboten.
Nachdem genügend Erfahrung mit ihnen gesammelt worden ist, werden sie ausgeReprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 15
CC – branded
Case Consult
The Evolution En@ bling Experts
wertet und notfalls überarbeitet. Noch steht es allen Unternehmen offen, ob sie sich
nach diesen Normen orientieren oder nicht. Im zunehmenden Maße werden jedoch die
lEEE-Normen zum Bestandteil der Software-Entwicklungsaufträge, die die US-Regierung erteilt. Auf diese Weise wird Druck auf die Industrie ausgeübt, die Normen anzuwenden.
Zwar sind die lEEE-Normen nicht überall der Weisheit letzter Schluß, aber sie bieten
doch einen praktikablen Ausgangspunkt und sind die beste Orientierung, die Software
Engineering zur Zeit hat. Wenn Software Engineering in den nächsten Jahren überhaupt feste Konturen gewinnt, dann wird es auf der Basis dieser Normen sein.
Normierung fängt bei den Begriffen an. Dafür hat die IEEE ein "Glossery of Standard
Software Engineering Terminology" ANSI/IEEE Std. 729-1983 herausgegeben. In
dieser Standard befindet sich auch ein musterhaftes Lebenszykluskonzept mit den
Phasen:
!
Concept Exploration
!
Requirements Specifikation
!
Design
!
Implementation
!
Test
!
Installation
!
Operation and Maintenance
Für die allgemeine Software-Qualitätssicherung gibt es zwei Normen, das ANSI/IEEE
Std. 730-1984 - Software Quality Assurance Plans - mit Maßnahmen zur Sicherung der
Qualität im gesamten Lebenszyklus, und ANSI/IEEE Std. 983-1986-Software Quality
Assurance Planning - zur Planung der Qualitätssicherungsmaßnahmen.
Für die Spezifikation der Anforderungen bzw. die Erstellung eines Fachkonzeptes gibt
es das ANSI/IEEE Std. 830-1984-Software Requirements Specifications - mit einem
umfangreichen Fallbeispiel.
Für den Entwurf der Software-Systeme bzw. die Erstellung eines technischen Konzeptes gibt es das ANSI/IEEE Std. 1016-1987 - Software Design Description - mit
genormten Diagrammtechniken zur Entwurfsdokumentation.
Für die Programmierung gibt es das ANSI/IEEE Std. 999-1987 - ADA as a Program
Design Language - mit der Empfehlung, ADA zumindest als Programmentwurfssprache zu benutzen, auch dann, wenn das Programm in einer anderen Zielsprache implementiert wird.
Für den Programmtest gibt es den ANSI/IEEE Std. 1008-1987, Software Unit
Testing, mit einem ausführlichen Modultestverfahren.
Für den Systemtest gibt es den ANSI/IEEE Std. 829-1983, Software Test Documentation, mit einer Beschreibung von Testplänen, Testfallentwürfen, Testprozeduren und
Testberichten.
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 16
CC – branded
Case Consult
The Evolution En@ bling Experts
Für die Systemabnahme gibt es den ANSI/IEEE Std. 1012-1986, Software Verification and Validation Plans, mit einer Liste der wichtigsten Abnahmekriterien.
Für die Systemverwaltung gibt es schließlich den ANSI/ IEEE Std. 828-1983, Software Configuration Management Plans, mit Richtlinien für die Versionsführung, den
Änderungsdienst und die Zustandsverfolgung [48].
Die obengenannten Standards bieten ein brauchbares Gliederungsschema zum
Thema Software Engineering und haben in dem Meer von Literatur zu diesem Thema
die Rolle von Leuchttürmen angenommen. Daher sei es ratsam für jeden, der sich
Software-Ingenieur schimpft, sich danach zu richten. Nur so hat Software Engineering
die Chance, jemals eine echte Ingenieurdisziplin zu werden.
Literatur
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
Naur, P./Randell, B.: „Software Engineering" Report on Conference of NATO Science
Committee, NATO, 1969
Sneed, H.: „Strukturierte Programmierung" GES Training Pakkage nr. 2, Allensbach,
1975
Freeman, P./Wassermann: „Software Design Techniques" IEEE Computer Society
Press, Los Angeles, 1980
Sneed, H.: „Wirtschaftlichkeit der Qualitätssicherung" in Proc. of DEC College
Conference on Software Quality Assurance, München 1988
Manley, J.: „CASE-Foundation for Software Factories" in COMPCON Proceedings,
IEEE, Sept. 1984
Jackson, M.: „Life-Cycle Concept Considered Harmful" in ACM Software Engineering
Notes, Vol. 7, No. 2, April 1982
Boehm, B.: „Improving Software Productivity" Sept. 1987
Boehm, B.: „A Spiral Model of Software Development and Enhancement" in IEEE
Computer, May, 1988
Zave, P.: „The Operational Versus the Conventional Approach to Software Development" in Comm. of ACM, Vol. 27, No. 2, Feb. 1984
Bauer, F.: „From Specifications to Machine Code – Program Construction Through
Formal Reasoning" in Prof, of 6th International Conf. on Software Engineering, IEEE
Computer Society Press, New York 1982
Alavi, M.: „An Assessment of the Prototyping Approach to Information Systems
Development" in Comm. of ACM. Vol. 27, No. 6, June 1984
Boehm, B.: „Software Engineering Economics" in IEEE Trans on Software Engineering,
Vol. SE-10, No. 1, Jan. 1984
Albrecht, A.: „Software Function, Source Lines of Code and Development Effort
Prediction" in IEEE Trans, on S. E., Vol. SE-9, No. 6, 1983
Sneed, H.: „Requirements Analysis of Business Systems" in Proc. of ACM Computing
Symposium, Teubner Verlag, Stuttgart, 1983
Putnam, L: „A General Empirial Solution to the Macro Software Sizing and Estimating
Problem" in IEEE Trans, on S. E., Vol. SE-4, No. 4, July 1978
Sneed, H.: „Software-Management" Rudolf Müller Verlag, Köln, 1987
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 17
CC – branded
Case Consult
The Evolution En@ bling Experts
[17]
Balzert, H,: „Die Entwicklung von Software-Systemen" B. l. Wissenschaftsverlag,
Mannheim, 1982
[18] Rzepka, W./Ohno, Y.: „Requirements Engineering Environments" in IEEE Computer, April
1985
[19] Teichroew, D./Hershey, E.: „PSL/PSA-A Computer Aided Technique for Structured
Documentation and Analysis of Information Processing Systems" in IEEE Trans, on S.
E., Vol. SE-3, No. 1, 1977
[20] Alford, M.: „SREM at the Age of Eight - The Distributed Computing Specification
System" in IEEE Computer, April 1985
[21]Katzan, H.: „Methodischer Systementwurf" Rudolf Müller Verlag, Köln, 1980
[22] Wirth, N.: „Systematisches Programmieren" Teubner Verlag, Stuttgart, 1975
[23] M/7/s, H,/Linger, R.: „Principles of Information Systems Analysis and Design" Academic
Press, London, 1986
[24] Yourdon, E./Constantine, L.: „Structured Design" Yourdon Press, New York, 1978
[25] Jackson, M.: „Principles of Program Design" Academic Press, London, 1975
[26] Warnier, J.-D.: „Logical Construction of Programs" Van Nostrand Reinhold. Pans, 1974
[27] Orr, K.: „Structured Systems Development" Yourdon Press, New York, 1977
[28] Pressman, H,: „Software Engineering - A Practitioner's Approach" McGraw-Hill, New
York, 1987
[29] Parnas, D.: „On Criteria to be Used in Decomposing Systems into Modules" in Comm. of
ACM, Vol. 14, No. 1, April 1972
[30] Denen, E.: „Software-Modularisierung" in Informatik-Spektrum 2, Feb. 1979
[31]
Booch, G.: „Software Engineering with ADA" Benjamin-Commings Pub., Washington,
1983
[32] Cox, B.: „Object Oriented Programming" Addison-Wesley, Reading, 1986
[33] Schumann, J./Gerisch, M.: „Software-Entwurf" Rudolf Müller Verlag, Köln, 1986
[34] Sneed, H.: „Software-Entwicklungsmethodik" Rudolf Müller Verlag, Köln, 1986
[35] Asam, R./Drenkard, N./Maier, H.-H.: „Qualitätsprüfung von Softwareprodukten"
Siemens Fachverlag, München, 1986
[36] Halstead, M.: „Elements of Software Science" Elsevier-North-Holland, New York, 1977
[37] McCabe, T.: „A Complexity Measure" im IEEE Trans, on S. E., Vol. SE-2, No. 4, 1976
[38] Chapin, N.: „A Measure of Software Complexity" in Proc. Of AFIPS NCC, New York,
1979
[39] Huang, J. C.: „Detection of Data Flow Anomaly through Program Instrumentation" in
IEEE Trans, on S. E., Vol. SE-5, No. 3, 1979
[40] Henry, S./Kafura, D.: „The Evaluation of Software Systems Structure Using Quantitative
Software Metrics" in Software Practice and Experience, Vol. 14, No. 6, June 1984
[41] Basili, V./Rombach, H.-D.: „Implementing Quantitative SQA – A Practical Model" in
IEEE Software, Sept. 1987
[42] ESPRIT: REQUEST COQUAMO, Request Report 1, EG-Kommission, Brüssel, 1986
[43] Sneed, H.: „Software-Qualitätssicherung" Rudolf Müller Verlag, Köln, 1988
[44] Jones, T. C.: „Reusability in Programming - A Survey of the State of the Art" in IEEE
Trans, on S. E., Vol. SE-10, No. 5, Sept. 1984
[45] Endres, A.: „Software-Wiederverwendung" in Informatik Spektrum, Nr. 1 1 , 1988
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 18
CC – branded
Case Consult
The Evolution En@ bling Experts
[46]
[47]
[48]
Arnold, R.: „Tutorial on Software Restructuring" IEEE Computer Society Press, Los
Angeles, 1986
Sneed, H.: „Software Renewal - A Case Study" in IEEE Software, Vol. 1, No. 3, July 1984
IEEE: „Software Engineering Standards" IEEE Computer Society Press, New York, 1987
Reprint aus PIK 12 (1989)
Praxis der Informationsverarbeitung und Kommunikation,
Carl Hanser Verlag, München, 1989
© 2002 CC GmbH®
Seite 19
CC – branded