Impressum Inhalt • Sommaire - Pixelpoint Multimedia Werbe GmbH

Impressum
INFORMATIK
Zeitschrift der schweizerischen
Informatikorganisationen
INFORMATIK ist das Verbandssorgan der
Schweizer Informatiker Gesellschaft (SI)
und des Wirtschaftsinformatik-Fachverbands
(WIF).
INFORMATIQUE
Revue des organisations suisses
d’informatique
INFORMATIQUE
est l’organe de la Société
suisse des informaticiens (SI) et du
Wirtschaftsinformatik-Fachverband (WIF).
Herausgeber • Editeur
SVI/FSI Schweizerischer Verband der Informatikorganisationen
• Fédération suisse des
organisations d’informatique
Postfach 71, 8037 Zürich
Projektgruppe Zeitschrift
Helmut Thoma, Walter Wüst, Prof. Dr. Carl
August Zehnder
Beirat • Comité consultatif
Dr. Martin Dürst (Universität Zürich), Martin
Egli (Osys AG, Zürich), Dr. Stefan Klein
(Hochschule St. Gallen), Dr. Rudolf Marty
(Schweiz. Bankgesellschaft, Zürich), Prof.
Dr. Jean-Daniel Nicoud (EPF Lausanne),
Prof. Dr. Jürg Nievergelt (ETH Zürich),
Prof. Dr. Hans-Jörg Schek (ETH Zürich),
Dr. Reinhold Thurner, Rudolf Weber (RWC
Consulting, Binz Zh), Roland Wettstein
(Schweiz. Nationalbank, Zürich)
Redaktion • Rédaction
François Louis Nicolet
Schwandenholzstr. 286, 8046 Zürich
Telefon 01 371 73 42, Telefax 01 371 23 00
e-mail nicolet@clients.switch.ch
English proof-reading: Mary Jo Kostya
Titelblatt • Frontispice: Cedric Barco
Druck, Versand • Impression, expédition
Stulz AG, 8942 Oberrieden
Inseratenverwaltung • Régie des annonces
Geschäftsstelle SVI/FSI
Postfach 71, 8037 Zürich
Telefon 01 - 632 72 81 (Frau Messerli)
Jahrgang • Année de parution
1. Jahr • 1ère année
Erscheinungsweise • Parution
Jährlich 6 mal • 6 fois par an
Auflage • Tirage: 4’000 Exempl.
Die Zeitschrift sowie alle in ihr enthaltenen
Beiträge und Abbildungen sind urheberrechtlich
geschützt. • La revue ainsi que
toutes les contributions et figures qu’elle
contient sont protégées par la loi sur les
droits d’auteur.
Inhalt • Sommaire
Fachbeiträge • Contributions techniques
Software-Qualität • Qualité du logiciel
2 Editorial – Karol Frühauf
3 Software-Qualitätsmanagement, eine Einführung – Karol Frühauf
6 Qualitätsmanagement in der Informationsverarbeitung – Ernest Wallmüller
19 “Wir haben kein Q-System – Wir sind eines!”
– Stefan Brantschen und Stefan Zeder
30 Ein QS-System für objektorientierte Softwareentwicklung – Simon Moser
36 Standortbestimmung und Vorbereitung der ISO 9001-Zertifizierung
– Thomas Frühauf und Ernst Lebsanft
43 Objektorientierte Programmierung verteilter Systeme – Silvano Maffeis
50 Verwaltung heterogener Systeme – Michael Abel
Aktualitäten • Actualités
40 Zum 60. Geburtstag von Prof. Hansjürg Mey – Hanspeter Bieri
41 Tagungsbericht: Mustererkennung 1994 – Bruno T. Messmer
Mitteilungen der Schweizer Informatiker Gesellschaft (SI)
Communications de la Société Suisse des Informaticiens (SI)
42 SI-Generalversammlung 1994: Beschlussprotokoll
43 Assemblée Générale Si 1994: Procès-verbal
43 CHOOSE – Object-Oriented Systems and Environments
46 DBTA – Data Bases – Theory and Application
46 I&G – Informatik und Gesellschaft
48 Security
48 SGAICO – Swiss group for artificial intelligence and cognitive science
49 SIPAR – SI Group on parallel systems
49 SI-SE – Software-Engineering
Mitteilungen des Wirtschaftsinformatik-Fachverbands
50 Verwaltung heterogener Systeme – Michael Abel
52 Tagungsankündigung: Gestaltung von Client/Server-Anwendungen
53 Ankündigung: Betriebsbesichtigung Sihlpost
53 Höhere Prüfung für Wirtschaftsinformatik-Fachleute 1994. Ergebnisse
54 Index 1994
INFORMATIK Nr. 6 (Dezember 1994) 1

Das Besondere dieser Ausgabe von IN-
FORMATIK•INFORMATIQUE besteht
darin, dass die gleichen Fachbeiträge
auch in der Januar-Nummer der neuen
Fachzeitschrift Qualität erscheinen
werden. Qualität wird das SAQ-Bulletin
der Schweizerischen Arbeitsgemeinschaft
für Qualitätsförderung (SAQ) ersetzen.
Sie haben also mit diesem Heft
eine gemeinsame Arbeit der Redaktoren
der schweizerischen Informatikorganisationen
und der Schweizer Arbeitsgemeinschaft
für Qualitätsförderung
(SAQ) vor sich. Es wäre zu wünschen,
dass diese Zusammenarbeit Schule
macht. Informatik und Qualitätssicherung
sind bezüglich ihrer Anwendung
bereichsüberschreitende, universelle
Disziplinen. Es gibt kaum einen
Lebensbereich, in den die Informatik
nicht hineinwirkt und es gibt keinen, in
dem nicht die Qualität eine Rolle spielt.
Also sind auch die Zeitschriften, die
sich mit diesen Themen befassen dazu
prädestiniert, ihre Grenzen zu sprengen
und zusammenzuarbeiten. Zu dieser Tat
möchte ich den beiden Redaktionen
gratulieren und auch in Ihrem Namen,
werte Leserschaft, herzlich danken.
In meiner Funktion als Leiter der SAQ-
Arbeitsgruppe “Qualitätssicherung von
Software” und SAQ-Vorstandsmitglied
möchte ich Ihnen die SAQ vorstellen.
Die SAQ wurde vor mehr als 25 Jahren
gegründet und zählt heute gegen 2’000
Firmenmitglieder und einige Dutzend
Einzelmitglieder. Lange Jahre dominierten
die Maschinen- und die Elektroindustrie
die Mitgliedschaft. Mit der
Diffusion des Qualitätsmanagements in
andere Bereiche kamen immer mehr
Mitgliedsfirmen aus anderen Gebieten
hinzu. Vor allem die Dienstleistungsund
Informatikunternehmen finden in
ihrem Streben nach Qualität zunehmend
den Weg zur SAQ.
2 INFORMATIQUE No 6 (décembre 1994)
Editorial
Software-Qualität
Die Schulung nimmt im Leistungsangebot
der SAQ den wichtigsten Platz ein.
Mit rund 15’000 Teilnehmertagen bietet
die SAQ in der Schweiz das grösste
Schulungsangebot auf dem Gebiet der
Qualitätssicherung und des Qualitätsmanagements.
Es umfasst alle Anwendungsgebiete,
inklusive Software. Erst
kürzlich hat der SAQ-Schulrat den
Grundsatzentscheid gefällt, die Schulung
auf dem Gebiet des Software-Qualitätsmanagements
auszubauen.
Mit ihrer zehnmal jährlich erscheinenden
Zeitschrift und anderen Publikationen,
Tagungen und Seminaren versteht
sich die SAQ als Informations-Drehscheibe
in Sachen Qualität. Durch die
gemeinsame Organisation von Tagungen
und Seminaren mit anderen Verbänden
werden die Ideen des Qualitätsmanagements
neuen Kreisen zugänglich
gemacht. Auf dem Gebiet der Software
veranstaltet die SAQ Workshops, bei
denen Erfahrungsaustausch und Gruppenarbeit
im Vordergrund stehen. Die
erarbeiteten Ergebnisse werden publiziert.
Die erste SAQ-Konferenz zum
Thema Software-Qualitätssicherung hat
1987 rund 450 Teilnehmer aus der ganzen
Schweiz verzeichnen dürfen.
Im vergangenen Oktober ist die SAQ
zusammen mit ihrem europäischen
Dachverband European Organisation
for Quality (EOQ) Veranstalter der
Fourth European Conference on Software
Quality in Basel gewesen. Hier haben
wir leider zu spät an eine Zusammenarbeit
mit der SI und dem WIF
gedacht. Die 250 Teilnehmer aus 30
Ländern haben durchwegs positiv über
die Konferenz berichtet. Die Proceedings
der Konferenz können bei der
SAQ-Geschäftsstelle bezogen werden.
Die nächste grosse Herausforderung für
die SAQ ist der 39th EOQ Annual Congress
im Juni 1995. Gegen 1000 Experten
und solche, die es werden wollen,
werden in Lausanne erwartet. In früheren
Kongressen kamen bis zu 10% der
Teilnehmer aus der Informatik. Die
Konzepte und Hilfsmittel des Qualitätsmanagements
sind universell anwendbar;
es ist für Informatiker also durchaus
lohnenswert, Berichte darüber zu
hören und anschliessend zu versuchen,
diese in der eigenen Umgebung auszuprobieren.
Ich durfte als Gast dieses Editorial
schreiben. Als Gründungsmitglied der
SI bin ich aber kein echter Gast. Als
Mitglied beider Gesellschaften hoffe
ich natürlich, dass die Beschäftigung
mit dem Thema Software-Qualität nicht
einmalig bleibt, sondern auf den Seiten
der
INFORMATIK•INFORMATIQUE
regelmässig wiederkehren wird. Das
Thema hat viele diskussioswürdige
Aspekte: rein technische (z.B. Feststellen
der Qualität), technologische (z.B.
qualitätsfördernde Methoden und Werkzeuge),
juristische (z.B. Urheberrecht),
philosophische (was ist Qualität?), soziale
(z.B. Einfluss auf die Beschäftigung
– durch Automatisierung vernichten
wir Arbeitsplätze anderer, durch
schludrige Arbeit erhalten wir die eigenen)
und ethische (dürfen wir mit dem
gegenwärtigen Stand der Praxis gewisse
Anwendungen überhaupt in Angriff
nehmen?).
Ich weiss, dass die Redaktoren, Herr
Hohl und Herr Nicolet, Beiträge zu diesen
Themen gern entgegen nehmen.
Lassen Sie sich von den folgenden inspirieren.
Karol Frühauf,
Gastredaktor

Vom Kunsthandwerk zum
Ingenieurwesen
Die Entwicklung von Computerprogrammen
ist eine junge Disziplin. Das
Programmieren war in seinen Anfängen
die Domäne von Naturwissenschaftlern,
die ihre Probleme mit Hilfe des Computers
schneller und nachvollziehbar lösen
konnten. Die Zuverlässigkeit der Ergebnisse
hing stark von ihren Programmierfähigkeiten
ab.
Ende der fünfziger Jahre begann man
dann Computer zur Unterstützung der
administrativen Führung der Unternehmen
sowie zur Überwachung und
Steuerung von Maschinen, Anlagen und
Prozessen einzusetzen. Betriebswissen-
Fachbeiträge • Contributions techniques
Software-Qualitätsmanagement, eine Einführung
Karol Frühauf
Die Normenreihe ISO 9000 ermöglicht die Zertifizierung von Unternehmen durch eine unabhängige Partei.
BOOTSTRAP begnügt sich nicht mit der Beurteilung, sondern bietet auch Hilfe für die Verbesserung.
Beim Total Quality Management (TQM) hat die Optimierung des Arbeitsablaufs (Prozess) grosse Bedeutung;
die Organisation muss sich ihr unterordnen. Das Ziel ist die kontinuierliche Verbesserung.
Karol Frühauf,
Dipl. El. Ing. war 12 Jahre
bei BBC Brown Boveri AG in Baden
auf dem Gebiet der Netzleittechnik tätig.
1987 einer der Gründer der INFOGEM
AG, Informatiker Gemeinschaft für Unternehmensberatung
in Baden. Dort in
Beratungsprojekten und Schulung in
den Bereichen Software-Qualitätssicherung
und Projektmanagement tätig.
Mitglied des Vorstands und des Lenkungsausschusses
der Arbeitsgruppen
der Schweizerischen Arbeitsgemeinschaft
für Qualitätsförderung (SAQ); Vizepräsident
der European Organisation
for Quality (EOQ) – Software Committee.
Koautor der Bücher “Software-Projektmanagement
und Qualitätssicherung”
und “Software-Prüfung, eine Fibel”,
beide erschienen im vdf Verlag der Fachvereine
Zürich.
schaftler und Ingenieure gesellten sich
zur elitären Schar der Computer-Beherrscher.
Die Programme waren noch
immer Ausdruck individueller Begabung,
keine Handelsgüter. Mit jedem
Programm nahm die Abhängigkeit der
Wirtschaft vom Computer mehr als proportional
zu. Die Unzufriedenheit mit
dem Stand der Technik in der Programmentwicklung
war 1968 Ausgangspunkt
für die Working Conference
on Software Engineering der NATO, wo
der Begriff “Software Engineering” eingeführt
wurde. Dies war der Schritt vom
kunsthandwerklichen zum ingenieurmässigen
Vorgehen.
Vor allem im militärischen Sektor
entdeckte man die Qualitätssicherung
von Software. Die Anforderungen an
die Rückverfolgbarkeit der Änderungen,
die damit eng verbundene Kennzeichnung
von Software-Einheiten und
-Konfigurationen und ihre Verwaltung
ebneten den Weg für die Qualitätssicherung
in den Software-Werken. Paradoxerweise
wird die Disziplin des Software-Konfigurationsmanagements
erst
in den letzten Jahren ernst genommen;
wohl unter dem Druck der wachsenden
Software-Halden.
Eine weitere Domäne der Software-
Qualitätssicherung war die Prüfung.
Auch bei der Herstellung materieller
Güter hat man sich zunächst auf die Prüfung
der Endprodukte konzentriert. Erst
nach vielen Jahren ging man dazu über,
die zur Herstellung verwendeten Werkzeuge
in Ordnung zu halten und das
verwendete Material einer Eingangsprüfung
zu unterziehen. Die beste Fer-
tigung produziert nur Ausschuss, wenn
die von der Entwicklung bereitgestellten
Fertigungsunterlagen fehlerhaft
sind. Die Entwicklung ist in das Gesichtsfeld
der Qualitätssicherung geraten.
Bei der Software – auch bei den Massengütern,
die wir auf unseren PCs installieren
– ist die Fertigung ein trivialer
Prozess, nämlich eine Reproduktion.
Man kümmerte sich deshalb bei der
Software relativ schnell um den Entwicklungsprozess
und die Fehlerverhü
tung.
Mit einer gewissen Berechtigung
kann man behaupten, dass in diesem
Bereich die Software-Industrie die traditionelle
befruchtet hat.
Immer mehr Kunden verlangten von
den Lieferanten ein wirksames Netz von
Massnahmen zur Verhütung der Produktfehler.
Und immer mehr Kunden
begnügten sich nicht mehr mit der Behauptung
der Lieferanten, dass sie dies
tun; die Abnehmer begannen mit der
Prüfung der Arbeitsabläufe bei ihren
Lieferanten. Die Lieferanten sahen sich
mit einer Vielzahl von Kundenaudits
konfrontiert, und die Abnehmer mit
einer Vielzahl von Qualitätssystemen,
weil es keine international anerkannte
Norm gab. Bei der zunehmenden Globalisierung
der Märkte eine unerfreuliche
Situation.
Ein Wendepunkt in der Geschichte der
Qualitätssicherung war das Erscheinen
der Normen ISO 9000 ff im Jahre 1987.
Die darin formulierten Anforderungen
an das Qualitätssystem eines Unternehmens
sind weltweit akzeptiert. Gleich-
INFORMATIK Nr. 6 (Dezember 1994) 3

zeitig betrat das Qualitätsmanagement
die Bühne. Mit dem früheren Bedeutungsinhalt
des Begriffs Qualitätssicherung
ausgestattet, ist es eine universelle
Management-Disziplin geworden, wie
die Betriebswissenschaften. Universell
im Sinne der Anwendbarkeit auf alle
Gebiete des wirtschaftlichen aber auch
gesellschaftlichen Wirkens (z.B. Schulen,
Verwaltungen). Seit 1991 gibt es
auch die Norm ISO 9000-3, die Anleitungen
für die Anwendung des Qualitätsmanagements
im Software-Bereich
gibt.
Das gegenwärtige Umfeld
Die Normenreihe ISO 9000 ermöglicht
die Beurteilung von Unternehmen
durch eine unabhängige Partei. Mit
einem Zertifikat wird einem Unternehmen
bescheinigt, dass es ein Qualitätsmanagementsystem
gemäss ISO-Norm
unterhält. Für Unternehmen, die selbst
Software herstellen, gilt die Norm ISO
9001. Nach ISO 9000-3 kann man sich
nicht zertifizieren lassen, weil diese
Norm nur ein Leitfaden für die Anwendung
von ISO 9001 ist. Reine Rechenzentren,
die keine neue Dienstleistungen
entwickeln, können sich nach ISO
9002 zertifizieren lassen. Noch weniger
Anforderungen stellt ISO 9003; sie ist
anwendbar auf Unternehmen, die sich
ausschliesslich mit Prüfen von Software
beschäftigen.
Die Zertifikate können von akkreditierten
Zertifizierungsgesellschaften erstellt
werden. In der Schweiz beauftragt das
Gesetz das eidgenössische Amt für
Messwesen (EAM) mit dem Akkreditieren.
Heute sind nach meinem
Wissensstand die Gruppe für Rüstungsdienste
(GRD), die Schweizerische Vereinigung
für Qualitätssicherungs-Zertifikate
(SQS), das Bureau Veritas Quality
International (BVQI) Switzerland, Det
Norske Veritas (DNV), TÜV Schweiz
und SGS International Certification Services
AG (SGS) akkreditiert. Im Rahmen
des Zertifizierungsaudits wird von
den Auditoren geprüft, ob das Qualitätsmanagementsystem,
so wie es dokumentiert
ist, alle Anforderungen der
Norm erfüllt und als Stichprobe, ob im
Unternehmen gemäss der vorliegenden
4 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Dokumentation verfahren wird. Ende
1994 dürften in der Schweiz ca. 1’000
Unternehmen zertifiziert sein.
In Grossbritannien will eine Initiative
unter dem Namen TickIT eine Zertifizierung
nach ISO 9000-3 einrichten.
Mit der Unterstützung des Industrieund
Handelsministeriums hat man erreicht,
dass Unternehmen, die auch
Software in ihren Produkten einsetzen,
nur dann ein Zertifikat erhalten, wenn
sie auch ein TickIT-Audit erfolgreich
bestehen. Die Briten sind sehr emsig
dran, dieses Schema auch in anderen
Europäischen Ländern und in den USA
zu vermarkten.
1987 erschien das Capability Maturity
Model (CMM) des Software Engineering
Institute (SEI) in USA.
Ursprünglich nur für die Beurteilung
der Software-Lieferanten des Verteidigungsministeriums
gedacht, erlangt
CMM mit seinen fünf Reifegraden immer
mehr Popularität. Die europäische
Reaktion heisst BOOTSTRAP.
Es begnügt
sich nicht mit der Beurteilung
sondern bietet auch Hilfe für die Verbesserung.
Andere ähnliche Modelle
entstanden anfangs der neunziger Jahre.
Um dem Wildwuchs vorzubeugen, wurde
1993 das Projekt SPICE gestartet,
mit dem Ziel, eine ISO-Norm für die
Beurteilung der Reife und der Möglichkeiten
zur Verbesserung eines Unternehmens
zu definieren.
Die Zertifizierung und die ISO Normen
sind, vor allem in USA und Japan, Gegenstand
von Kontroversen. Die grosse
Konkurrenz heisst Total Quality Mana-
gement
(TQM). Eine Philosophie aus
USA, die in Japan auf fruchtbaren Boden
gefallen und nun auch in Europa an
Bedeutung gewinnt. Aus den vielen inkohärenten
Ansichten darüber, was
TQM ist, kann man folgendes herausdestillieren:
der Kunde, der Mensch steht
im Mittelpunkt. Wichtig ist die Optimierung
des Arbeitsablaufs (Prozesses)
und die Aufbauorganisation muss sich
ihr unterordnen. Die Gestaltung der Arbeitsabläufe
wird Teams übertragen, deren
Mitglieder aus verschiedenen Bereichen
des Unternehmens stammen. Das
übergeordnete Ziel ist die kontinuierliche
Verbesserung.
Statt Zertifizierung bietet die TQM-Bewegung
Preise als Anreiz an. Der älteste
ist der Deming Award in Japan, der seit
den frühen fünfziger Jahren vergeben
wird. Grosses Prestige geniesst der seit
Mitte der achtziger Jahre in USA vergebene
Baldrige Award.
In Europa wird
seit Anfang der neunziger Jahre der European
Quality Award von der European
Foundation for Quality Management
(EFQM) erteilt. EFQM wird
finanziell von ihren Mitgliedern, die
sich aus der europäischen Industrie rekrutieren,
getragen. Einige Länder in
Europa haben bereits in Anlehnung an
das EFQM-Modell ihre nationalen Qualitäts-Preise
ins Leben gerufen. Bei
allen Awards werden die Preisträger
anhand einer unabhängigen Bewertung
durch Assessoren erkoren. Sie verwenden
einen Fragenkatalog, dem ein
Modell zugrunde liegt. Im Vergleich zur
ISO-Zertifizierung spielen bei den Preisen
die betriebswirtschaftlichen und
führungstechnischen Aspekte eine wesentliche
Rolle.
Die kontinuierliche Verbesserung stösst
dort auf Grenzen, wo Märkte austrocknen
oder Arbeitsabläufe nicht mehr zeitgemäss
sind. Also dort, wo Innovation
oder radikales Umdenken nötig ist. Das
ist das Feld für das Business Process
Reengineering.
Nach vollzogenem Umbau
kann man wieder inkrementell verbessern.
Was heisst Software-
Qualitätsmanagement?
Das Feld des Software-Qualitätsmanagements
abzustecken, ist schwierig.
Je nach Standpunkt kann man es als Teil
der Disziplin Software Engineering ansehen
oder umgekehrt. Offen ist auch
die Frage, ob Konfigurationsmanagement
oder Softwareprüfung ein Teil des
Software-Qualitätsmanagements ist
oder nicht.
Ich neige dazu, Qualitätsmanagement
eng zu sehen. Zu ihrer eigentlichen Domäne
zähle ich folgende Aufgabengebiete
bzw. Verfahren:

Vision, Grundsätze und Ziele schaffen
Ein Unternehmen erfüllt in der Regel
eine Mission, sie strebt einer Vision
nach. In dieser muss auch die Qualität
ihrer Produkte und Dienstleistungen
Platz finden. Mit den Grundsätzen wird
umschrieben, wie sich die Mitarbeiter
im Tagesgeschäft verhalten müssen, damit
sie der Vision nachleben. Mit den
Zielen, die jährlich neu gesetzt werden,
schafft sich das Unternehmen eine
Messlatte für das Beurteilen der Entfernung
zwischen der Realität und der Vision.
Beschreibung der Verfahren
Das Modellieren der Softwareprozesse
und die Methoden zur Verbesserung der
Prozesse bzw. die Schaffung neuer Prozesse
soll den Konsens über die zweckmässige
Arbeitsweise sichtbar machen,
als Anleitung zur Verfügung stehen und
die Möglichkeit haben, sich einen Spiegel
vorhalten zu können.
Messen von Softwareprozessen
Eine unabdingbare Voraussetzung für
Verbesserungen ist die Fähigkeit, das
Potential hierfür objektiv erkennen zu
können und die erfolgte Verbesserung
(oder Verschlechterung) ausweisen zu
können. Dies kann man am besten mit
dem Messen des Softwareprozesses bewerkstelligen.
Beurteilen von Software-Prozessen
Neben dem Messen sind die Audits das
wichtigste Verfahren zur Beurteilung
der Prozesse. In den Audits wird geprüft,
ob die Prozesse gemäss ihrer Definition
angewendet werden und ob sie
in der jeweiligen Situation zweckmässig
sind. Das Assessment-Verfahren hat
zum Ziel, Verbesserungspotentiale aufzuzeigen.
Durchgeführt wird es wie ein
Audit.
Messen von Softwareprodukten
Die Suche nach Kennzahlen, mit denen
die Software-Produkte charakterisiert
werden können, d.h. die Anforderungen
eindeutig spezifiziert und ihre Erfüllung
objektiv belegt werden kann, ist ein
langgehegter Wunsch der Softwerker.
Experimentelle Forschung in diesem
Feld ist eine wichtige Aufgabe der Praxis
des Qualitätsmanagements.
Fachbeiträge • Contributions techniques
Erfahrung schriftlich festhalten
Erfahrungen in einem Unternehmen für
alle greifbar und interpretierbar festhalten
ist eine Voraussetzung für Prävention.
Auch hier gilt es, neue Wege zu
begehen versuchen.
Regelkreise bilden und erhalten
Mechanismen in Gang setzen und halten,
damit Erfahrungen auch wirklich
genutzt werden, damit nicht immer wieder
die gleichen Fehler wiederholt werden
(und mehr Zeit für das Erfinden
neuer Fehler bleibt, aus denen man wieder
lernen kann).
Diese Regelkreise haben unterschiedlichen
Wirkungsbereich. Einerseits wirken
sie auf das in Entwicklung befindliche
Produkt (Quelle der Erkenntnisse
sind die Prüfungen in Form von
Reviews und Tests), andererseits auf das
Projekt zu ihrer Herstellung (anhand
Fortschrittskontrollen und Audits). Erkennt
man Gesetzmässigkeiten über
mehrere Produkte bzw. Projekte hinweg,
dann kann ein Regelkreis auf den
Prozess wirken, der die Rahmenbedingungen
für alle Projekte festlegt.
Ausblick
Im Laufe dieses Jahrzehnts wird die
Zertifizierung selbstverständlich werden.
Das Zertifikat wird ein “Qualitäts-
Führerschein”. Die TQM-Bewegung
wird die Orientierung der Normenreihe
ISO 9000 stark beeinflussen und radikal
ändern. Die den Preisen zugrundeliegenden
Modelle werden grundsätzlich
überarbeitet oder auf eine ganz neue Basis
gestellt werden. Dies ist das pessimistische
Szenario.
Im optimistischen Szenario werden die
Unternehmen mündig. Die Selbstbeurteilung
und das Funktionieren der
Regelkreise wird ernsthaft betrieben.
Anstelle von Zertifikaten und Preisen
tritt die Publikation von allgemein interpretierbaren
Kennzahlen, die eindeutigen
Aufschluss geben über die Güte der
Softwareprodukte und -prozesse der
einzelnen Unternehmen; die Preise vergibt
dann der Markt.
Damit das optimistische Szenario eintreffen
kann, muss sich ein radikaler
Wandel bei den Abnehmern von Software
vollziehen. Die Kunden müssen
einsehen, dass sie mit ihren Vorstellungen
darüber, was in welcher Zeit zu welchem
Preis machbar ist, weit neben dem
heute Möglichen liegen. Niemand würde
bei einem Autohersteller ein massgeschneidertes
Modell mit der Auflage zu
bestellen, dieses innerhalb von einer
Woche zum Preis eines Fahrzeugs aus
der Serienfertigung auszuliefern. Bei
Software ist dies heute der Normalfall.
Wenn die Kunden die Möglichkeiten
der Software-Industrie richtig einschätzen
lernen, erwerben sie auch das
Recht, gleiche Ansprüche an Software
geltend zu machen, wie an alle andere
Gebrauchsgüter. Dann werden auch die
Softwarelieferanten bestrebt sein müssen,
ihre Zusagen an ihre Kunden in allen
Belangen zu erfüllen und, was noch
wichtiger ist, nur Zusagen zu machen,
die sie erfüllen können.
Spezifikation der Anforderungen, Abnahme
von Software-Produkten, Kosten
und Dauer von Software-Entwicklungen
sowie Kosten und Dauer der Einführung
von Informatik-Lösungen sind
Themen, die dermassen an Bedeutung
gewinnen, dass sie in allen Disziplinen
der höheren Ausbildung werden gelehrt
werden müssen, weil alle Abgänger potentielle
Software-Beschaffer sind. Diese
Themen haben im engen Sinne nur
am Rande mit Software-Qualitätsmanagement
zu tun, aber sehr viel mit der
Qualität im weitesten Sinne.
Schlussbemerkung
Die Arbeitsgruppe “Qualitätssicherung
von Software” der Schweizerischen
Arbeitsgemeinschaft für Qualitätsförderung
(SAQ) beschäftigt sich seit 1983
mit allen Aspekten der Software-Qualität.
Etwa die Hälfte der 90 Mitglieder
arbeitet in kleineren Teams, in denen ein
spezifisches Thema bis zur Publikationsreife
bearbeitet wird und Erfahrungen
ausgetauscht werden. Interessenten
sind herzlich willkommen. Information
ist bei der SAQ-Geschäftsstelle, Postfach,
4603 Olten, Fax 062 32 93 30, Telefon
062 32 93 29.
INFORMATIK Nr. 6 (Dezember 1994) 5

Bedeutung der Qualität
im Unternehmen
“Die weltweite Qualitätsrevolution hat
permanent die Art und Weise verändert,
wie wir unsere Geschäfte betreiben.
War Qualität einst nur auf technische
Belange beschränkt, so ist Qualität
heute ein dynamischer Verbesserungsprozess,
der alle Bereiche unserer Geschäftswelt
durchdringt.”
Dieses Zitat von R.C. Stempel [Munro-
Faure 92], dem Vorsitzenden der Gene-
6 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Qualitätsmanagement in der Informationsverarbeitung
Ernest Wallmüller
Unsere Wirtschaft und unser gesellschaftliches Leben wird in einem solchen Masse von rechnergestützten
Informationssystemen beherrscht, dass jeder von uns von diesem fundamentalen Veränderungsprozess
direkt oder indirekt betroffen ist. Nicht nur, dass Information und ihre Verarbeitung neben Kapital und
Arbeit zum bestimmenden Faktor geworden ist, sondern auch der innovative und zugleich verändernde
Einfluss auf alle uns umgebenden Arbeits-, Geschäfts-, ja sogar Lebensprozesse zeigt quantitative, aber
auch qualitative Wirkung. Mit dem vorliegenden Qualitätsmanagementansatz soll auch eine kritische Einstellung
aller Informationsnutzer und -erzeuger zu Information Engineering-Produkten und -Dienstleistungen
geschaffen werden.
Der vorliegende Ansatz trägt mit einem offenen und umfassenden Qualitätskonzept für die Informationsverarbeitung
dem Bedarf und der Notwendigkeit Rechnung, das Erstellen und die Evolution von Informationssystemen
auf einem qualitativ hohem Niveau durchführen zu können.
Ernest Wallmüller,
Dr. sc. techn. ist Prokurist
der Firma ATAG Ernst & Young
Consulting AG, Abteilung Information
Technology, in Zürich. Beratungsschwerpunkte:
Information- und Software
Engineering, insbesondere
Einführung von Prozessmodellen, Qualitätssicherung
und -management, kontinuierliche
Verbesserung im Bereich
Informatik-Prozesse.
Bücher: Software Engineering in der
Anwendungsprogrammierung (Wien
1984), Software-Qualitätssicherung in
der Praxis (München-Wien 1992), Umfassendes
Qualitätsmanagement in Informationsverarbeitung
(erscheint im
Dezember 1994 bei Hanser).
ral Motors Corporation, kennzeichnet
treffend unsere heutige Situation. Qualität
und deren Verbesserung ist zu einer
fundamentalen Geschäftsstrategie der
90er Jahre geworden. Keine Unternehmensfunktion,
auch nicht die Informationsverarbeitung,
kann sich dieser Strategie
entziehen.
Die Globalisierung des Welthandels,
der Abbau der politischen Ost-West-
Polarisierung und das Ende des komplementären
Warenangebots in den drei
grossen Regionen USA, Europa und
Ferner Osten lassen geschützte Märkte
verschwinden. Dies führt in diesen
Regionen zu einer dramatischen Verschärfung
des Wettbewerbs, wobei Qualität,
Lieferzeit, Innovation und
Kundendienst ständig an Bedeutung gewinnen.
Qualitätsmanagement zielt darauf ab,
den Wert des Produkts oder der Dienstleistung
für den Kunden und Benutzer
zu steigern. Im Wettbewerb ist die Produktqualität
oft der zentrale Erfolgsfaktor.
Sie ist ein ausschlaggebendes Kriterium
für den Käufer, erlaubt in der
Regel höhere Preise und ist vielfach mit
strategischen Wettbewerbsvorteilen verbunden,
die durch Konkurrenten nicht
kurzfristig aufzuholen sind (z.B. amerikanische
Autoindustrie).
Durch qualitätsorientierte Gestaltung
der Leistungsprozesse sowie der Leistungspotentiale
lassen sich die Fehlerkosten
vermindern, Entwicklungszeiten
verkürzen und Schäden am Image vermeiden.
Bei der Entwicklung von Betriebssystemen
der Firma Siemens [Freund 89]
wurde festgestellt, dass ein Fehler, der
in der Entwicklung gefunden wird, Kosten
in der Höhe von DM 2.000,– verursacht.
Wird der Fehler erst während des
Systemtests entdeckt, so entstehen pro
Fehler Kosten in der Höhe von DM
6.000,–. Wenn der Fehler erst während
des Feldeinsatzes des Produktes auftritt,
so kostet die Beseitigung des Fehlers bis
zu DM 20.000,–.
Nach einer MIT-Studie [Scott Morton
91] haben die Einflussgrössen auf
Unternehmensziele in bezug auf die
Wettbewerbsposition unterschiedliche
Bedeutung. Die Möglichkeiten eines
traditionellen Kostensenkungsprogramms
(z.B. durch Personaleinsparungen)
sind begrenzt. Die Sicherung und
Steigerung der Qualität, sowie die
Sicherstellung schneller Reaktionszei-

ten auf Kunden- und Marktanforderungen
nehmen an Bedeutung zu. Im Zuge
dieser Schwerpunktverlagerung haben
sich auch die Aktionsfelder des Informationsmanagements
und der Anwendung
von Informations- und Kommunikationstechnologien
verlagert. Von den
ursprünglichen Buchhaltungs- und
Rechnungswesenanwendungen ausgehend
verlagert sich das Interesse über
die Produktion (PPS-System) hin zu
Anwendungen in den Bereichen Marketing,
Logistik, Produktentwicklung und
Kundenservice. Mit dieser Schwerpunktverlagerung
hat auch eine Veränderung
der durch die Informatik unterstützten
Personengruppe stattgefunden.
Waren es anfänglich die ausführenden
Mitarbeiter der operativen Ebenen (Production
Worker), so sind es heute immer
mehr die qualifizierten Planer und Entscheidungsträger
in der dispositiven
Ebene (Knowledge Worker).
Informationsmanagement und der Einsatz
von Informations- und Kommunikationstechnologien
leisten einen wesentlichen
Beitrag zur Schaffung von
Wettbewerbsvorteilen und zur Sicherung
von Marktpositionen.
Informationsmanagement und der Einsatz
von Informations- und Kommunikationstechnologien
können einen
essentiellen Beitrag zur Schaffung von
Wettbewerbsvorteilen und zur Sicherung
der Marktposition leisten, wenn sie
umfassend und dem Unternehmensziel
gerecht eingesetzt werden.
Beispiele von Qualitätsproblemen in
der Informationsverarbeitung
Einige Beispiele aus der internationalen
Softwareszene und aus der Beratungspraxis
des Autors zeigen die Vielfältigkeit
der Qualitätsprobleme und ihre Folgen
für die Unternehmen.
Ein internationaler Softwarehersteller
Der Direktor von Ashton Tate forcierte
die Freigabe einer neuen Version
eines Datenbanksystems, ohne zu
erkennen, dass es stark fehlerbehaftet
Fachbeiträge • Contributions techniques
war. Das Produkt musste vom Markt
zurückgenommen werden. Die
daraus resultierenden finanziellen
Schwierigkeiten führten zur Entlassung
des Direktors und zur Übernahme
des Unternehmens durch Borland.
Eine Schweizer Grossbank
Die Einführung von Wertpapieren an
den Börsen von New York und Tokio
kann nicht direkt über die Konzernfirma
mit Hauptsitz Zürich informationstechnisch
geplant und kontrolliert
werden, da die dazu nötigen
Informationssysteme fehlen. Das
Grossprojekt zur Entwicklung der
Basisapplikationen für das Auslandsgeschäft
der Bank ist innerhalb von
10 Jahren dreimal gescheitert. Der
Verlust beträgt mehrere hundert Millionen
Franken.
Beim kleinen Börsenkrach im Oktober
1987 kam es zu einer Häufung
von Mängeln und Fehlern im Börseninformationssystem,
die bei der
Wochenverarbeitung begannen und
bis zu einer vierstündigen Abschaltung
des Informationssystems vier
Tage später führte. Das Börsengeschäft
musste rein manuell durchgeführt
werden. Die informationstechnische
Aufarbeitung der
Geschäftsfälle dauerte mehrere Wochen.
Ein internationaler Computerhersteller
Die Firma beschäftigt ca. 400 Mitarbeiter
im Softwarebereich, denen
eine Palette von ungefähr 300 Softwareprodukten
gegenübersteht. Ein
Grossteil der Produkte ist veraltet
und muss mit grossem Aufwand
gewartet werden. Durch die rasante
Hardwareentwicklung ist der Bedarf
an Applikationen für neue Hardwareproduktlinien
extrem gross. Eine
Portierung kommt aus technischen
Gründen nicht in Frage. Es besteht
die Gefahr, dass ein Grossteil der Alt-
Kunden die Migration zu den neuen
Produkten nicht mitmacht, da die dafür
notwendigen neu zu entwickeln-
den Softwarelösungen nicht rechtzeitig
zur Verfügung stehen.
Ursachen von Qualitätsproblemen
Die Ursachen von schlechter Softwarequalität
lassen sich nach Rathbone
([Rathbone/Vale 88], [Rathbone 90])
auf drei Einflussgrössen zurückführen:
Management, Technologie und Mitarbeiter.
Alle drei Einflussgrössen wirken
auf der normativen, taktischen und
operativen Unternehmensebene. Im einzelnen
lassen sich folgende Probleme
erkennen:
Management
•Kurzfristiges Reagieren verhindert
eine geplante mittelfristige Umsetzung
von Zielen.
• Es ist keine strategische Planung vorhanden,
oder bei vorhandener strategischer
Planung fehlt die konsequente
Umsetzung (Management der
Umsetzung), oder die Ergebnisse der
Planung werden nicht mit den Mitarbeitern
besprochen (fehlende Kommunikation).
• Die Informationstechnik unterstützt
nur geringfügig die Unternehmensziele.
Die kritischen Erfolgsfaktoren
werden entweder gar nicht oder mit
veralteten Informationssystemen unterstützt.
• Managementprozesse werden nicht
als solche gesehen und ausgeführt.
• Die Führung ist entweder autoritär
oder chaotisch, oder sie fehlt ganz.
• Die Qualifikation der Mitarbeiter
wird weder systematisch gepflegt
noch weiterentwickelt.
• Die Aufgaben der Organisationsentwicklung,
die für Unternehmen in extrem
dynamischen Märkten entscheidend
sind, werden entweder gar nicht
oder nur unzureichend wahrgenommen.
Eine dieser Aufgaben, das Management
von technologiebedingten
Veränderungen, gehört gegenwärtig
zu den grössten Problemen.
• Nichtbeherrschen von Projekten und
Prozessen, insbesondere bei der Erstellung
von Informations- bzw. Softwaresystemen,
ist eine wesentliche
Ursache für die schlechte Qualität der
Ergebnisse.
INFORMATIK Nr. 6 (Dezember 1994) 7

Technologie
• Durch den raschen Wandel in der
Informationstechnologie müssen sich
die Unternehmen verstärkt mit dem
parallelen Umgang unterschiedlicher
Generationen von Technologie beschäftigen.
Applikationsportfolios,
die in Assembler, COBOL, PL/1, C
und C++ geschrieben sind, sind keine
Seltenheit mehr. Das heute in den
Unternehmen praktizierte Technologiemanagement
berücksichtigt dies
nicht oder nur schlecht.
• Die Zeitspanne vom Vorliegen von
Forschungsergebnissen bis zu deren
Einführung und Umsetzung wird immer
kürzer. Technologiebeobachtung
und Technologieerprobung werden
zu einem kritischen Wettbewerbsfaktor.
Unternehmen besitzen gegenwärtig
kaum oder nur schlecht die Fähigkeit,
neue Technologien zu
beobachten, zu erproben, einzuführen
oder zu beherrschen.
• Die qualitative Voraussetzung, um
Geschäftsziele durch Informationssysteme
flexibel unterstützen zu
können, ist eine Informationssystemarchitektur,
die auf den Pfeilern Applikationen,
Daten, Technologie und
Management/Organisation beruht.
Bei vielen Unternehmen ist diese Architektur
einseitig auf Applikationen
ausgerichtet. Die Ergebnisse der strategischenInformationssystemplanung,
die diese Architekturen etablieren
soll, werden – wenn überhaupt
vorhanden – nicht umgesetzt.
• Derzeit wird die Bedeutung guter
rechnergestützter Werkzeuge unterschätzt,
und mit veralteten Hilfsmitteln
werden Ergebnisse mit niedriger
Qualität produziert. Der Anteil an
Überarbeitung und Ausschuss ist
demzufolge hoch (ca. 40% [Boehm
81]). Qualität im Informatikbereich
wird wesentlich von den eingesetzten
Werkzeugen, Fehlerbehebungsmechanismen,
dem Grad der Wiederverwendung
von Bauteilen, den
Programmiersystemen und dem Entwicklungsprozess
mit seiner Methodik
beeinflusst.
Mitarbeiter
• Mangelnde Qualifikation ist ein Problem
mit zunehmender Bedeutung.
8 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Insbesondere wird der Vorbereitung
auf neue Aufgaben zu wenig Aufmerksamkeit
geschenkt.
• Persönliche Qualifikation hat mit
persönlichem Einsatz und Aufwand,
Neigungen und Fähigkeiten, Erziehung
und Ausbildung, Weiterbildung
und Einstellung zu tun. Ein Grossteil
dieser Einflussgrössen wird in einem
Berufsleben nicht bewusst gestaltet,
und somit werden Potentiale nicht genutzt.
• Die Mitarbeiter haben Angst, in einer
Informationsgesellschaft zu leben
und zu arbeiten, in der die Verfallszeit
des Wissens auf fünf Jahre geschrumpft
ist.
• Die Mitarbeiter haben immer grössere
Schwierigkeiten, sich mit der Arbeit
zu identifizieren und somit den Erfolg
des Unternehmens zu sichern.
• Die Stabilität eines qualifizierten Mitarbeiterstabes
wird für Unternehmen
Qualität ist zweifelsohne eine der zentralen
Grössen für den wirtschaftlichen
Erfolg von Unternehmen. Der rasche
Wandel in unserer Gesellschaft, begleitet
oder verursacht von Technologieund
Innovationsschüben, die in immer
kürzeren Zeitabständen auftreten, erfordert
eine umfassende Diskussion des
Themas Qualität, die nicht nur rein technisch
geführt werden darf. Im folgenden
gehen wir auf die Begriffe Qualität, Management
und Qualitätsmanagement
näher ein.
Begriff Qualität
Was verstehen wir unter Qualität? Der
Qualitätsbegriff ist seit dem Altertum
bekannt. In der lateinischen Sprache
wird
qualitas
Grundlagen des Qualitätsmanagements
mit der Beschaffenheit
(eines Gegenstands) übersetzt. So alt
wie der Begriff selbst ist auch die Diskussion
um seine Inhalte, die bis heute
andauert. Alle Standpunkte und Abstufungen
dieser fachlichen Diskussion
sind unmöglich wiederzugeben.
zu einer Überlebensfrage. Durch die
hohe Fluktuationsrate im Informatikbereich
verlieren Unternehmen jährlich
einen wesentlichen Anteil ihres
Know-hows.
Zusammenfassend kann festgestellt
werden, dass die Qualitätskultur und
das Qualitätsbewusstsein im Informatikbereich
mangelhaft sind. Gegenwärtige
Anstrengungen, die zu einer qualitativ
besseren Leistung führen sollten,
sind meist nur lokal und stark an neuen,
noch nicht ausgereiften Technologien
orientiert. Die Einflussgrösse “Mitarbeiter”
wird nur geringfügig strategisch
geplant, schlecht operativ geführt und
erbringt meistens mangelhafte Leistungen.
Die Realität von heutigen Informatikorganisationen
sind in der Folge
schlecht qualifizierte Mitarbeiter, die
den Unternehmen viel Geld und Zeit
kosten.
Nach ISO 8402 (Entwurf 1992) ist Qualität
die Gesamtheit von Merkmalen eines
Produktes oder einer Dienstleistung
bezüglich der Eignung, festgelegte oder
vorausgesetzte Erfordernisse zu erfüllen.
Der Begriff Gesamtheit kann beispielsweise
Service, Güter/Waren, Informationen
oder Interaktionen mit Kunden
umfassen. Der Kunde erlebt primär
Qualität rein subjektiv. Bei Erleben von
negativer Qualität spielen häufig die
vorausgesetzten Bedürfnisse eine Rolle.
Zwar sind Kundenerwartungen und
Kundenbedürfnisse Zielgrössen bei der
Qualitätsgestaltung, doch ist die Beurteilung
der Qualität durch den Kunden
oftmals undurchsichtig und die Auswertung
seiner Aussagen eine schwierige
Aufgabe. Der Kunde misst zwar die
Qualität an seinen Erwartungen, aber
welche Qualität misst er denn wirklich?
Die versprochene Qualität, die gelieferte
Qualität, die in Anspruch genommene
Qualität?

Empfehlungen
Erfahrungen
Nach derzeitigem Erkenntnisstand kann
man davon ausgehen, dass der Kunde
nur einen Teil der in Anspruch genommenen
Qualität wahrnimmt (Abb. 1).
Diese wahrgenommene Qualität ist es,
mit der er seine Qualitätserwartungen
vergleicht und sich aus diesem Vergleich
sein Urteil über die Qualität bildet
[Zeithaml 91]. Ist die Differenz zwischen
wahrgenommener Qualität und
den Erwartungen klein oder gar null
(Abb. 1, ∆1),
so fällt das Urteil günstig
aus. Wird zudem der Preis als fair angesehen
und stimmt der Liefertermin,
wird der Kunde zufrieden sein.
Für den Anbieter kann die Differenz
zwischen in Anspruch genommener und
wahrgenommener Qualität von erheblichem
Nachteil sein (Abb. 1, ∆2).
So
kann beispielsweise ein Kunde nicht erkennen,
dass ein neuer Anbieter wesentliche
Teile seiner Qualitätserwartungen
nicht erfüllt, die der bisherige Lieferant
erfüllte, ohne dass er dies wahrgenommen
hat. In Unkenntnis dieses Sachverhaltes
kann er bei günstigen Preisangeboten
des neuen Anbieters
möglicherweise den Lieferanten wechseln.
Beispiele für nicht wahrgenommene
Teile der in Anspruch genommenen
Qualität sind die Nähe einer Servicestelle
zum Kunden, die Fehlerfreiheit
Fachbeiträge • Contributions techniques
Kunde Anbieter
Wettbewerbsangebote
Erwartungen
∆1
∆10
Spezifizierte
Q-Forderung
Wahrgenommene
∆2 ∆3
Qualität
In Anspruch genommene
Qualität
Gelieferte Qualität
Bedürfnisse
Abb. 1: Qualitätsbeurteilung, Differenzen und Defizite
∆4
∆5
∆9
Vorstellungen
über
Erfordernisse
Versprochene
(zugesicherte)
Qualität
Erstellte
Ausführungsqualität
∆8
∆6
Definierte
Qualitäts-
Anforderungen
bisheriger Interaktionen zwischen dem
Kunden und dem Lieferanten oder der
Umfang der erbrachten Serviceleistung.
Infolge Gewöhnung werden solche Teile
der in Anspruch genommenen Qualität
nicht mehr richtig wahrgenommen.
Ihr Wert wird oftmals erst bewusst,
wenn der Lieferant bereits gewechselt
wurde. Um dies zu verhindern, tut der
Anbieter gut daran, dem Kunden die
Qualität seiner Leistungen in vollem
Umfang ins Bewusstsein zu bringen.
Der Kunde wird normalerweise nur
einen Teil der gelieferten Qualität tatsächlich
in Anspruch nehmen, während
der übrige Teil für ihn unwichtig ist
(Abb. 1, ∆3).
Ganz lässt sich ein solcher
Überschuss an Qualität der Lieferung
nur im Falle von Einzelanfertigungen
und einmaligen Dienstleistungen vermeiden.
Bei allen Serienprodukten, die
auf die Bedürfnisse und Erwartungen
von Kundengruppen und nicht von Einzelkunden
ausgerichtet sein müssen,
kann für den einzelnen Kunden ein
Überschuss zwischen gelieferter und in
Anspruch genommener Qualität auftreten.
∆7
Gestaltete
Entwurfsqualität
Wenn jedoch für alle Kunden ein solcher
Überschuss besteht, liegt Overengineering
vor. Das heisst, das Produkt
kann zuviel, der Entwickler hat weniger
die Kundenbedürfnisse und -erwartun-
gen als seine eigenen Qualitätsvorstellungen
im Auge gehabt und sich am
technisch Machbaren begeistert. Dies
führt in der Regel zu der Situation, dass
die Konkurrenz die Kunden kostengünstiger
beliefern kann, weil ihre Produkte
kein Overengineering aufweisen. Um
dennoch im Geschäft zu bleiben, muss
der Anbieter mit Overengineering auf
Deckungsbeiträge verzichten und niedrigere
Preise einräumen.
Ebensogut kann das Gegenteil eintreten:
nicht Overengineering, sondern
ungenügende Erfüllung der Kundenerwartungen.
Für beide Erscheinungen
kommen mehrere Ursachen in Frage. So
ist es dem Anbieter möglicherweise
nicht gelungen, die Erwartungen der
Kunden richtig zu erfassen, so dass seine
Vorstellungen von den Kundenerwartungen
nicht mit der Wirklichkeit übereinstimmen
(Abb. 1, ∆9).
Als Folge
davon wird die Spezifikation, welche
der Produktentwicklung zugrundegelegt
wird, Lücken aufweisen oder übertriebene
Forderungen enthalten (Abb. 1,
∆8).
Aber auch im Falle eines guten und
vollständigen Pflichtenheftes kann ein
Qualitätsdefizit zustandekommen, weil
die gestaltete Entwurfsqualität des Produktes
ungenügend ist (Abb. 1, ∆7).
Man spricht in diesem Fall von
ungenügender Treffsicherheit der
Entwicklung.
Weitere wohlbekannte Defizite können
bei der Produktion des Produktes entstehen,
wobei man von mangelnder
Ausführungsqualität spricht. Die hergestellten
Produkte sind nicht konform mit
der spezifizierten Entwurfsqualität und
müssen nachbearbeitet werden (Abb. 1,
∆6).
Ein weiterer Fall eines Qualitätsdefizits
liegt vor, wenn die versprochene Qualität
nicht mit der gelieferten Qualität
übereinstimmt (Abb. 1, ∆4).
Dies führt
zu Reklamationen, weil zugesicherte
Qualitätsmerkmale nicht vorliegen
(Nicht-Konformität).
Diese Darstellung der Übererfüllung
und der Defizite betraf primär materielle
Produkte. Ähnliche Abweichungen sind
aber auch bei den Informationen (Soft-
INFORMATIK Nr. 6 (Dezember 1994) 9

ware), bei Service und bei den Interaktionen
zu beobachten. Bei diesen Teilen
des Leistungsangebots wird die Auseinandersetzung
über Qualitätsdefizite
häufig noch schwieriger, weil in der Regel
die Erfordernisse weniger sorgfältig
erfasst und umgesetzt sind als bei Hardware.
Grundlegende Arbeiten zum Verständnis
des Begriffs Qualität hat Garvin von
der Harvard Business School geliefert
[Garvin 88]. Er unterscheidet fünf Ansätze,
um zu einer Qualitätsvorstellung
zu kommen:
Der “transzendente” Ansatz
Danach ist Qualität universell
erkennbar und ein Synonym für kompromisslos
hohe Standards und Ansprüche
an die Funktionsweise eines
Produkts. Die Vertreter dieses Ansatzes
glauben allerdings, dass sich
Qualität in diesem Sinne nicht präzise
definieren oder messen lässt.
Ebenso meinen sie, dass Qualität nur
durch Erfahrung bewertet werden
kann. Der Begriff der Qualität kann
genauso wenig implizit definiert
werden wie jener der “Schönheit”.
Der produktbezogene Ansatz
Die Vertreter dieses Ansatzes glauben,
dass die Qualität präzise
messbar ist. Danach spiegeln Qualitätsdifferenzen
Unterschiede in der
vorhandenen, beobachtbaren Quantität
bestimmter Eigenschaftsausprägungen
wider, die in einem Produkt
festgestellt werden können. Dieser
Ansatz erlaubt es im Prinzip, eine
Rangordnung von verschiedenen
Produkten der gleichen Kategorie anzugeben.
Der anwenderbezogene Ansatz
Hierbei liegt die Auffassung vor, dass
die Qualität durch den Produktbenutzer
festgelegt wird und weniger
durch das Produkt selbst. Danach haben
verschiedene Produktbenutzer
unterschiedliche Wünsche und Bedürfnisse,
und diejenigen Produkte,
die diese Bedürfnisse am besten
befriedigen, werden als qualitativ
hochstehend angesehen.
10 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Der konstruktive Ansatz
Vertreter dieses Ansatzes gehen davon
aus, dass durch Einhaltung von
Spezifikationen und Standards bei
der Produktentwicklung und -fertigung,
sowie durch die geistige Einstellung,
eine Tätigkeit zur Produkterstellung
gleich das erste Mal
richtig auszuführen, die Qualität entsteht.
Diese Vorstellung von Qualität
ist auf die heutige Wirtschaft und Industrie
ausgerichtet. Im Mittelpunkt
steht der Entwicklungs- und Produktionsprozess,
der kontrolliert wird,
um die Ausschuss- und Nachbearbeitungskosten
zu verringern. Dabei
spielt der Automatisierungsgrad eine
grosse Rolle. Durch rechnergestützte
Werkzeuge soll der Produktionsprozess
soweit als möglich mängelfrei
und reibungslos abgewickelt werden.
Auch in der immer stärker werdenden
Diskussion um die Produkthaftpflicht
bietet dieser Ansatz eine gute
Ausgangsbasis, um die Seriosität und
die Verantwortlichkeiten der Prozessausführung
nachzuweisen.
Der wertbezogene Ansatz
Bei diesem Ansatz wird eine Qualitätsvorstellung
durch die Begriffe
Preis und Kosten gebildet. Ein Qualitätsprodukt
ist in dieser Denkweise
ein Erzeugnis, das einen bestimmten
Nutzen zu einem akzeptablen Preis
oder eine Übereinstimmung mit Spezifikationen
zu akzeptablen Kosten
erbringt.
Begriff Management
Der Begriff Management ist in der Literatur
vielfach erörtert worden. In dieser
Arbeit werden nur jene Aspekte des
Managements erläutert, die dem integrativen
Charakter und der Multidimensionalität
des Begriffs Qualität entsprechen.
Bleicher [Bleicher 91, Seite 52–
58] spricht im Zusammenhang mit der
Multidimensionalität von normativem,
strategischem und operativem Management.
Das normative Management beschäftigt
sich mit den generellen Zielen der
Unternehmung, mit Prinzipien, Normen
und Spielregeln, die darauf ausgerichtet
sind, die Lebens- und Entwicklungsfähigkeit
der Unternehmung sicherzustellen.
Entwicklungsfähigkeit umschliesst
auch eine qualifizierte Veränderung in
Richtung eines positiven, sinnvollen
Wandels. Ausgehend von einer unternehmerischen
Vision ist unternehmungspolitisches
Handeln und Verhalten
zentraler Inhalt des normativen
Managements. Ein wesentliches Gestaltungselement
des normativen Managements
ist die Unternehmenspolitik, die
durch die Unternehmenskultur und die
Unternehmensverfassung getragen
wird.
Strategisches Management ist auf den
Aufbau, die Pflege und die Ausbeutung
von Erfolgspotentialen gerichtet, für die
Ressourcen eingesetzt werden müssen.
Erfolgspotentiale sind die Menge aller
jeweils produkt- und marktspezifischen,
erfolgsrelevanten Voraussetzungen, die
spätestens dann bestehen müssen, wenn
es um die Realisierung geht. Bestehende
Erfolgspotentiale drücken die im
Im St. Galler Informationssystemmanagement
wird Management als Regelkreis
gesehen, der die Teilfunktionen
Planen, Verabschieden, Umsetzen und
Kontrolle umfasst.
Zeitablauf gewonnenen Erfahrungen einer
Unternehmung mit Märkten, Technologien
und sozialen Strukturen und
Prozessen aus. Neue Erfolgspotentiale
zielen auf die Entwicklung von zukünftigen
Wettbewerbsvorteilen. Im Mittelpunkt
strategischer Überlegungen
stehen neben Programmen die grundsätzliche
Auslegung von Strukturen und
Systemen des Managements sowie das
Problemlösungsverhalten ihrer Träger.
Normatives und strategisches Management
finden ihre Umsetzung im operativen
Management, das sich durch
Aktivitäten (Prozesse), Strukturen und
Verhalten charakterisieren lässt.
Operatives Management ist aus wirtschaftlicher
Sicht auf leistungs-, finanzund
informationswirtschaftliche Pro-

Qualitätssicherung
zesse ausgerichtet. Aktivitäten (Prozesse)
entstehen durch die Konkretisierung
von Normen über Missionen zu Programmen,
die schliesslich in Aufträge
umgesetzt werden. Strukturen werden
in Form der Unternehmensverfassung
konkretisiert, beispielsweise über Organisations-,
Management- und Dispositionssysteme.
Beide Aspekte, Prozesse
und Strukturen, dienen der Beeinflussung
menschlichen Verhaltens im
Wechselspiel von Wertvorstellungen,
strategischem Denken und Lernen. Für
die Leistungsorientierung ist das Leistungs-
und Kooperationsverhalten im
Arbeitsprozess durch geeignete Führungsmassnahmen
zu fördern.
Unter Management verstehen wir nach
Ulrich [Ulrich 84] das Gestalten, Lenken
und Weiterentwickeln produktiver
sozialer Systeme. Die Funktionen des
Managements sind Entscheiden, Ingangsetzen
und Kontrollieren.
Ein für Wirtschaftsinformatiker wichtiges
Konzept ist das St. Galler Informationssystemmanagement
[Österle et al.
92]. In diesem Konzept wird Management
als Regelkreis gesehen, der die
vier Teilfunktionen Planen (Ziele setzen,
Pläne entwickeln), Verabschieden
(entscheiden), Umsetzen und Kontrolle
(Kontrolle der Zielerreichung) umfasst.
Fachbeiträge • Contributions techniques
Qualitätsplanung
Führung
in
Sachen
Qualität
Qualitätsförderung
(Qualitätsverbesserung)
Abb. 2: Funktionen des Qualitätsmanagements
Qualitätslenkung
(Prozeßmanagement)
Begriff Qualitätsmanagement
Nach dem Entwurf DIN ISO 8402 vom
März 1992 verstehen wir unter Qualitätsmanagement
folgendes:
Alle Tätigkeiten der Gesamtführungsaufgabe,
welche die Qualitätspolitik,
Ziele und Verantwortungen festlegen,
sowie diese durch Mittel der Qualitätsplanung,
Qualitätslenkung, Qualitätssicherung
und Qualitätsverbesserung
im Rahmen des Qualitätsmanagementsystems
verwirklichen.
Qualitätsmanagement gehört in den
Verantwortungsbereich aller Führungskräfte.
Bei der Umsetzung des
Qualitätsmanagements, die unter dem
Gesichtspunkt der Wirtschaftlichkeit
erfolgt, sind alle Mitarbeiter der Organisation
involviert.
Seghezzi [Seghezzi 92] rundet die obige
Definition praxisnahe ab, indem er dem
Qualitätsmanagement vier Fachfunktionen
und eine Führungsfunktion zuordnet
(Abb. 2).
Von den vier Fachfunktionen hat die
Qualitätsplanung die Aufgabe, Bedürfnisse
zu ermitteln und diese in Form von
Produkt- und Prozessmerkmalen umzusetzen.
Im Rahmen der Qualitätslen-
kung (Prozessmanagement) sind sämtliche
Prozesse einer Unternehmung so
durchzuführen und zu beherrschen, dass
die Spezifikationen eingehalten werden
und fehlerfreie Produkte entstehen. Die
Qualitätssicherung nimmt ausschliesslich
die Aufgabe wahr, Qualitätsrisiken
zu ermitteln und Massnahmen zu treffen,
um sie zu vermindern oder zu eliminieren.
Schliesslich werden durch die
Qualitätsförderung (Qualitätsverbesserung)
Anstrengungen unternommen, die
Qualität der Produkte, der Prozesse und
somit des Unternehmens zu steigern,
um damit die Wettbewerbsfähigkeit zu
erhöhen.
Diese vier Fachfunktionen lassen sich
nicht einzelnen Organisationseinheiten
zuordnen, sondern sind als Querschnittsaufgaben
auf eine Vielzahl von
Unternehmenseinheiten verteilt. Damit
tritt auch eine beachtliche Schnittstellenproblematik
auf. Aus diesem Grund
definiert Seghezzi eine fünfte Funktion,
die Führung in Sachen Qualität, die weit
bedeutsamer geworden ist, als dies in
der Vergangenheit der Fall war. Im folgenden
werden einige der bekanntesten
Qualitätskonzepte untersucht und weiterführende
Konzepte diskutiert.
Lösungsansatz
Das hier vorgestellte Lösungskonzept
einer umfassenden Methodik des Qualitätsmanagements
für die Informationsverarbeitung
soll die oben erwähnten
Probleme zufriedenstellend lösen.
Gleichzeitig ist dieser Ansatz in eine
umfassende Qualitätskonzeption für das
gesamte Unternehmen integriert (Bezugnahme
auf ISO 9000, Prozessmanagement,
Total Quality Management).
Das Lösungskonzept beruht auf drei
Ebenen (Abb. 3):
Normative Lösungsebene
Die erste Ebene umfasst die Entwicklung
einer (Qualitäts-)Vision
und einer (Qualitäts-)Politik im Rahmen
der strategischen Informationsplanung.
Vision und Politik sind im
strategischen Planungsprozess mit
den Zielen für die Informationsinfra-
INFORMATIK Nr. 6 (Dezember 1994) 11

1
struktur [Heinrich 92] abzustimmen.
Strategische Lösungsebene
Die zweite Ebene legt die Rahmenbedingungen
für die kritischen Einflussgrössen
Management, Technologie
und Mitarbeiter fest.
Operative Lösungsebene
Die dritte Ebene (“Prozessmanagement”)
zielt auf die Beherrschung
der Prozesse ab, um eine Informationsinfrastruktur
zu entwickeln und
zu pflegen.
Wir stützen unseren Qualitätsmanagementansatz
durch eine Reihe von Thesen
ab, die wir durch Beobachtung von
Unternehmen, durch Literaturstudien
und Expertenbefragung gewonnen haben:
T1) Qualität ist in der Vision des
Unternehmens zu verankern und
durch eine geeignete Politik umzusetzen.
Ausgehend von der (Qualitäts-)Politik
sind qualitative Ziele
1. Unter Informationsinfrastruktur werden
Einrichtungen, Mittel und Massnahmen
verstanden, welche die Voraussetzungen
für die Produktion von Information
und Kommunikation in einer Organisation
schaffen (z.B. Software, Hardware,
Personal, etc.).
Normative
Ebene
Strategische
Ebene
Operative
Ebene
Abb. 3: Qualitätsmanagementkonzept
12 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
(Qualitäts-)
Vision, Politik und Ziele
Rahmenbedingungen
• Management
• Technologie
• Mitarbeiter
Prozeßmanagement
und Subziele mit den Organisationseinheiten
zu entwickeln. Im
Rahmen einer qualitätsorientierten
strategischen Informationssystemplanung
wird eine Informationssystemvision
gemeinsam erarbeitet,
aus der unter anderem auch
qualitative Informationssystemziele
und -grundsätze abgeleitet
werden.
Die Thesen für die strategische
Lösungsebene sind:
T2) Für die Umsetzung der Vision und
der Politik über Ziele und das Führen
von qualitätsorientierten informationsverarbeitenden
Prozessen
sind die Rahmenbedingungen in
den Schlüsselbereichen Management,
Technologie und Mitarbeiter
entscheidende Einflussgrössen.
Diese Rahmenbedingungen sind
bewusst durch das Management zu
gestalten.
T3) Die Verpflichtung des Managements
auf Qualität ist entscheidend
für die Motivation der Mitarbeiter.
Wesentliches Werkzeug
des Qualitätsmanagements ist das
Qualitätsmanagementsystem. Es
ist als aktives Führungssystem zu
gestalten.
T4) Der Umgang mit Innovations- und
Veränderungsprozessen ist eine
Führungsaufgabe und ist insbesondere
zu planen. Für jeden Veränderungsprozess
ist ein Sponsor
verantwortlich. Die Wirksamkeit
eingeführter Innovationen und
neuer Technologien hängt vom
Reifegrad der Projekte, der Prozesse
und der Information Engineering-Organisation
ab.
T5) Die Beteiligung der Mitarbeiter an
den Prozessen und im speziellen
am (Qualitäts-) Verbesserungsprozess
ist eine notwendige Rahmenbedingung,
um effizient Information-
/ Software Engineering-
Prozesse betreiben zu können.
Die Thesen für die operative Lösungsebene
sind:
T6) Die Qualität von Informationssystem-
und Softwareprodukten ist
eng mit deren Erstellungs- und
Führungsprozessen verknüpft.
T7) Die Definition eines Information-/
Software Engineering-Prozesses
ist Voraussetzung, um ihn zu führen.
Die Bewertung (Messung) ist
Voraussetzung, um ihn zu lenken
und zu verbessern.
T8) Die Reife und Qualität von Prozessen
hat auf die effektive Nutzung
der eingesetzten Technologie Einfluss.
Normative Lösungsebene
Ausgangspunkt für den Lösungsansatz
sind die heute bekannten Ansätze des
Qualitätsmanagements im Unternehmen,
beginnend mit den Programmen
von Deming und Juran bis hin zum Total
Quality Management (TQM). Die bekannten
Qualitätsprogramme und der
TQM-Ansatz werden aus der Sicht des
Information Engineering betrachtet und
diskutiert.
Ziel ist ein Qualitätskonzept, das im
Rahmen der strategischen Planung der
Informationsinfrastruktur entsteht und
speziell auf die Belange des Informa-

tion Engineering ausgerichtet ist. Es
müssen dabei Vorstellungen entwickelt
werden, wie die Zukunft der Informationsverarbeitung
in Form von Vision,
Mission, Zweck und Grundsätzen aussehen
soll.
Dieses Qualitätsmanagementkonzept
stellt einen Beitrag im Rahmen des normativen
Managements dar [Bleicher
91]. Es legt damit den Grundstein für
eine Qualitätsvorstellung, die sich primär
am Markt und an den Bedürfnissen,
Wünschen und Erwartungen der Kunden
ausrichtet.
Strategische Lösungsebene
Das Qualitätsmanagementkonzept wird
durch drei Kategorien von Rahmenbedingungen
auf strategischer sowie
taktischer Ebene umgesetzt. Es sind
dies Rahmenbedingungen für
• ein qualitätsorientiertes Management,
das sich als Führungsinstrument
eines Qualitätsmanagementsystems
und als Arbeitstechnik der
Qualitätskostenanalyse bedient,
• einen qualitätsorientierten Umgang
mit Technologien und Innovationen,
sowie für
• einen qualitätsorientierten Umgang
mit den Mitarbeitern.
Die Gestaltung der Rahmenbedingungen
für die Schlüsselgrösse Management
umfasst die Verbesserungen der
Führungsarbeit selbst, den Einsatz eines
Qualitätsmanagementsystems, die Benutzung
von Qualitätskostenanalysen,
sowie die Anwendung von organisationsbezogenemÄnderungsmanagement.
Zuerst diskutieren wir Massnahmen
zur Verbesserung der eigentlichen
Führungsarbeit. Die Begründung für die
Verbesserung der Führungsarbeit besteht
in folgenden Fakten:
• Qualität bedeutet Managementverantwortung
und kann nicht delegiert
werden.
• Vorbildfunktion (leadership) wird
durch sichtbares, persönliches Engagement
für Qualität wahrgenommen.
• Um aktive Führungsarbeit in Sachen
Qualität zu leisten, sind das Verständnis
und die Kenntnisse von Qualitätskonzepten,
-methoden und -werkzeu-
Fachbeiträge • Contributions techniques
gen bei Führungskräften zu fördern
(daher ist die Information, die Ausund
Fortbildung für Führungskräfte
in Sachen Qualität unerlässlich).
Anschliessend fordern wir, dass informationsverarbeitende
Organisationen
ein Qualitätsmanagementsystem nach
ISO 9001 betreiben. Die Begründung
für den Einsatz eines Qualitätsmanage-
Qualität bedeutet Managementverantwortung
und kann nicht delegiert werden.
mentsystems beruht auf folgenden Fakten:
• Verbesserung der Kundenzufriedenheit,
da Produkte und Dienstleistungen
entsprechend ihrer Anforderungen
entwickelt und produziert
werden.
• Die Zertifizierung nach ISO 9001 ist
ein Marketinginstrument.
• Bereits vorliegender und zu erwartender
Druck durch Kunden. Immer
mehr Unternehmen fordern von ihren
Auftragnehmern den Nachweis der
Qualitätsfähigkeit in Form eines ISO-
9001-Zertifikats.
• Die Internationalisierung der Märkte
schreitet unaufhaltsam fort. Immer
mehr Unternehmen in den USA und
in Fernost sind durch den globalisierten
Wettbewerb gezwungen, ein Qualitätsmanagementsystem
auf der Basis
von ISO 9001 zu betreiben.
• Gesteigerte Mitarbeitermotivation,
da die Mitarbeiter effizienter arbeiten
können.
• Vorteile im Bereich der Produkthaftung.
• Reduktion der Qualitätskosten durch
Reduktion der Nonkonformitätskosten
(insbesondere durch Reduktion
der Ursachen von Reklamationen und
des Anteils an Überarbeitung).
• Reduktion der Häufigkeit von Audits
durch den Auftraggeber.
Die Begründungen basieren auf einer
Studie, die von Price Waterhouse durchgeführt
wurde ([Englert/Pfriem 93],
[Friedrich 94]). Darüber hinaus bietet
ein effizient betriebenes Qualitätsmana-
gementsystem eine ideale Basis, um
kontinuierliche Verbesserung zu betreiben.
Die Norm ISO 9001 verlangt, dass
jedes Jahr ein internes Systemaudit auf
Veranlassung der Geschäftsleitung
durchgeführt und alle drei Jahre das
ISO-9001-Zertifikat durch ein externes
Systemaudit erneuert wird. Diese Bedingungen
stellen sicher, dass Qualitätsmanagement
keine einmalige Aktion
bleibt.
Als weiteres Gestaltungsmittel werden
Qualitätskostenanalysen als essentielles
Managementwerkzeug vorgestellt, um
die Umsetzung der Qualitätspolitik und
der daraus abgeleiteten Qualitätsziele in
der Informationsverarbeitung zu fördern.
Die Begründung für die Messung
und Analyse der Qualitätskosten beruht
auf folgenden Fakten:
Idee Produkt
Prozess
Projekt
Abb. 4: Zusammenhang
Produkt – Projekt – Prozess
• Die Grösse der Qualitätskosten kann
benutzt werden, um die Aufmerksamkeit
der Geschäftsleitung zu gewinnen
und ihre Verpflichtung zur
aktiven Umsetzung des Qualitätsmangementansatzes
zu bekommen.
• Die Berichterstattung über qualitätsrelevante
Aktivitäten in Form von
finanziellen Grössen steigert die Bedeutung
von Qualität in der Geschäftsleitung
und stellt sicher, dass
die gleiche Aufmerksamkeit erreicht
wird wie andere Aktivitäten mit grosser
Auswirkung auf die Unternehmensleistung.
• Das Aufzeigen von Bereichen mit hohen
Qualitätskosten liefert eine gute
Ausgangsbasis für Verbesserungsprojekte
und -massnahmen.
INFORMATIK Nr. 6 (Dezember 1994) 13

• Das Wissen um Qualitätskosten und
deren Entstehungsgründe ermöglicht
Entscheidungen, die faktenbasiert
sind. Der Nutzen von jeglichen Entscheidungen
oder Massnahmen kann
entsprechend ihrer Wirkung auf die
Qualitätskosten bewertet werden.
Abschliessend werden die Grundlagen
eines organisationsbezogenen Änderungsmanagements
diskutiert. Die
Begründung für das Änderungsmanagement
besteht darin, dass Qualitätsmanagement
mit folgenden Unternehmensbedingungen
konfrontiert ist:
• grossflächiger Einsatz neuer Technologien,
• Deregulierung und Globalisierung
der Märkte,
• Intensivierung des Wettbewerbs,
• stark erhöhte Innovationsdynamik
und drastisch verkürzte Produktlebenszyklen,
• Diskontinuitäten und Turbulenzen in
Politik und Wirtschaftsleben,
• gestiegene Ansprüche der verschiedensten
Interessensgruppen der Unternehmung,
• verschärfter Kampf um begrenzte
Ressourcen,
• Zerfliessen bisheriger Unternehmensgrenzen
(Fusionen, Allianzen,
Ventures).
Diese Ebene regelt die Voraussetzungen
und Bedingungen, damit die operative
Ebene wirkungsvoll funktionieren
kann, insbesondere wird ein effizienter
Ressourceneinsatz sichergestellt.
Operative Lösungsebene
Auf dieser Ebene stehen die Prozesse
im Zentrum. Durch Managementverantwortung
und mit ingenieurmässigen
Methoden werden die Prozesse zur Entwicklung
und Pflege der Informationsinfrastruktur
gestaltet. Dafür hat sich
der Begriff Prozessmanagement ([Imai
86], [Humphrey 89], [Harrington 91],
[Chroust 92]) durchgesetzt. Die wesentlichen
Aufgaben sind:
• Prozess-Definition
• Prozess-Verantwortung festlegen
• Prozess-Messungen
• Prozess-Kontrolle
• Prozess-Benchmarking
14 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
• Prozess-Verbesserung
• Prozess-Innovation
Durch die Anwendung des Prozessmanagements
wird eine qualitativ hochwertige
Erstellung und Pflege von
Produkten und Dienstleistungen der Informationsverarbeitung
sichergestellt.
Bevor wir auf Prozesse und deren
Management sowie Engineering näher
eingehen, wird der Zusammenhang
zwischen Produkt, Projekt und Prozess
geklärt (siehe Abbildung 4). Zu Beginn
eines Projekts steht die Idee mit der Formulierung
des Projektziels, das in der
Erstellung eines auftraggerechten Produkts
besteht. Hierfür ist in einem geordneten
Projektablauf, dem Prozess,
eine Fülle von Projektaufgaben zu bewältigen.
Produkt
Ein Produkt wird im allgemeinen
Sprachgebrauch als Erzeugnis oder
Ertrag einer Menge von Tätigkeiten
verstanden. Es ist das Resultat von Entwicklungs-
und Projektierungsanstrengungen.
Wichtig für ein Produkt ist,
dass es eine Beschaffenheit hat, die für
den Auftraggeber und den Anwender
nützlich ist – so nützlich nämlich, dass
er es erwerben will.
Input-
Anforderungen
Input
Abb. 5: Erweitertes Prozessmodell
(Aktivität/
Ergebnis)*
Ein Produktmodell beschreibt die
Struktur und die Eigenschaft von Komponenten
eines Software- oder Informationssystems.
Darunter verstehen wir
nicht nur den Code, sondern sämtliche
Artefakte, die bei der Entwicklung oder
Pflege anfallen oder benötigt werden.
Projekt
Ein Projekt ist demgegenüber das zielorientierte
Vorhaben zur Herstellung
dieses Produktes. Ein Projekt ist notwendigerweise
immer in seinem zeitlichen
Ablauf klar umgrenzt, d.h. es hat
einen Anfangs- und Endtermin. Es umfasst
dabei alle Aktivitäten, die für das
Erreichen des gesetzten Projektziels,
d.h. für die Erbringung des Produkts
erforderlich sind.
Prozess
Kunden-Lieferanten-Anforderungsfluss
Prozess
Arbeitspaket
Der Prozess kennzeichnet das eigentliche
Vorgehen im Projekt zur Herstellung
des Produkts. Er beschreibt also
den Planungs- und Realisierungsablauf.
Im Prozess werden die für die Zielerreichung
notwendigen Aktivitäten –
gemeinhin als Arbeitspakete bezeichnet
– in definierte Abläufe eingeordnet, wobei
die jeweils notwendigen Vorgaben,
sowie die zu erreichenden Ergebnisse
bindend festgelegt sind. Innerhalb der
Prozessstruktur sind Entscheidungs-
Output
Output-
Anforderungen
Lieferant Prozeßgrenzen
Kunde
* … n-mal
Lieferanten-Kunden-Leistungsfluss

punkte definiert. An diesen wird der
Prozess durch Soll-Ist-Abfragen gesteuert.
Ein Prozessmodell ist eine Repräsentation
der Aktivitäten (und der damit assoziierten
Input- und Outputbedingungen)
eines Projekts.
Haist und Fromm [Haist/Fromm 89]
verstehen unter einem Prozess das Zusammenwirken
von Menschen, Maschinen
(z.B. Rechnern), Informationen
und/oder Materialien und Verfahren,
das darauf ausgerichtet ist, eine
bestimmte Dienstleistung zu erbringen
oder ein bestimmtes Endprodukt zu
erzeugen.
Rombach [Rombach 90] definiert einen
Prozess im Kontext des Software Engineering
als jede Aktivität, die ein Eingabeprodukt
konsumiert und ein Ausgabeprodukt
erzeugt. Als Beispiele nennt er
den gesamten Lebenszyklus, jede Aktivität
des Lebenszyklus oder die Ausführung
eines Übersetzungsprogramms.
Unter Produkt versteht er jedes Dokument,
das in einem Projekt erzeugt wird,
unbeschadet der Frage, ob es zur direkten
Auslieferung an den Kunden
bestimmt ist.
Wir erweitern diese Aussagen zu einer
Arbeitsdefinition mit dem Fokus Planung,
Kosten und Qualität:
Ein Prozess umfasst jede Aufgabe, die
innerhalb eines geplanten und budgetierten
Arbeitspakets auszuführen ist.
Jedes Arbeitspaket (und somit jeder
Prozess) konsumiert ein Eingabeprodukt
mit bestimmten Anforderungen
und führt zu einem (Ergebnis-)Produkt
oder einer Dienstleistung, welches/welche
definierten Anforderungen genügt.
Ein Prozess erzeugt einen Mehrwert
und ist wiederholbar.
Jeder Prozess kann in eine Folge von
Aktivitäten zerlegt werden, die dadurch
charakterisiert sind, dass sie messbare
Eingaben und Ergebnisse (Ausgaben)
besitzen und seine Werterhöhung gemessen
werden kann.
Fachbeiträge • Contributions techniques
Wir charakterisieren einen Prozess als
Summe von Aktivitäten, die in einem
Arbeitspaket ausgeführt werden und zu
einem Produkt oder einer Dienstleistung
führen. Er hat messbare Eingaben
(Input) und Ergebnisse (Output), an die
Anforderungen gestellt werden, schafft
einen Mehrwert für den Prozesskunden
und ist wiederholbar. Er ist gekennzeichnet
durch einen Kunden-Lieferanten-Anforderungsfluss
und einen Lieferanten-Kunden-Leistungsfluss.
Das
erweiterte Prozessmodell ist in Abbildung
5 dargestellt.
Beispiele für Prozesse und Subprozesse
bei der Erstellung und Pflege von Informationssystemen:
• Strategischer Planungsprozess für
Software-/Informatikprodukte
• Projektmanagementprozess
– Strukturieren
– Planen
– Steuern und Kontrollieren
– Berichten und Kommunizieren
– Änderungen bewerten
– Abschliessen
• Entwicklungsprozess
– Sammeln von Benutzerinformationen
– Ermitteln von Anforderungen
– Design
– Code erzeugen
–Testen
– Abnehmen
– Ausbilden
• Evolutionsprozess
• Qualitätsmagement-/Risikomanagementprozess
• Konfigurationsmanagementprozess
• Pflege der Kunden-/Benutzerbeziehung
• Lieferantenmanagement
• Finanzmanagement
Die Kundenorientierung eines Prozesses
führt dazu, dass der Kunde/Benutzer
als Empfänger der Prozessergebnisse
gesehen und die Zufriedenheit des Benutzers/Kunden
als primärer Faktor zur
Bewertung des Prozesses herangezogen
wird.
Rollen
Der Mensch als Benutzer, Mitarbeiter
oder als Manager ist integraler Bestand-
teil von Prozessen. Es stellt sich die Frage,
wie die Zuordnung der Prozesse zu
den “ausführenden” Menschen geschieht.
Man fasst kleine Mengen von Aktivitäten
zu Aufgaben zusammen. Die zusammengehörigen
Aufgaben einer oder
mehrerer Personen in einem Projekt
werden als Rollen bezeichnet. Eine Rolle
besitzt eine funktionale Verantwortung
zur Erreichung eines gegebenen
Ziels.
Es wird deutlich, dass die Zuordnung
Mensch – Prozess durch die beiden Zuordnungen
Mensch–Rolle und Rolle–
Prozessbeschreibung vorgenommen
wird. Eine Rolle ist also, entsprechend
dieser Sichtweise, eine Abstraktion von
Aktivitäten.
Beispiele für Rollen bei der Erstellung
und Pflege von Informationssystemen
sind:
a) Projektteamrollen
– Applikationsdesigner
– Applikationsentwickler
– Analytiker
– Benutzer
– Informationsarchitekt
– Informationsplaner
– Projektleiter
–Technischer Spezialist
–Tester
–Wissensbasiskoordinator
b) Projektunterstützungsrollen
– Abnahmetester
– Auditor
– Information Engineering-
Manager
– Moderator
– (Prozess-)Qualitätsberater
–Reviewer
– Sponsor
–Trainer
Unter Prozessengineering verstehen
Haist und Fromm [Haist/Fromm 89] die
Anwendung von Ingenieur- und Informationstechniken
auf Prozesse (Geschäftsprozesse,informationsverarbeitende
Prozesse). Insbesondere durch
zunehmende Rechnerunterstützung und
Automatisierung gewinnt das Prozess-
INFORMATIK Nr. 6 (Dezember 1994) 15

Mitarbeiter
Abb. 6: Softwareprozess
engineering als Methode zur Formalisierung
und Systematisierung von Prozessen
an Bedeutung. Ein besonderes
Interesse erlangt die explizite Modellierung
einer Teilklasse von Information
Engineering-Prozessen, die sich mit der
Entwicklung, Lieferung und der Evolution
von Software beschäftigen. Die Relevanz
einer expliziten Repräsentation
und Standardisierung der in einer Projektumgebung
existierenden Tätigkeiten
wird besonders durch die vermehrte
Bewertung von Softwareorganisationen
mittels Capability-Maturity-Modellen
deutlich. Beispiele solcher Modelle
sind:
• SEI-Modell,
• BOOSTRAP-Modell [Maiocchi 92],
• Software Assessment Method (SAM)
von British Telecom,
• Software Development Capability
Assessment Method (SDCAM) von
Bell Canada,
• Software Quality and Productivity
Analysis (SQPA) von Hewlett Packard
und
• ISO-9001-Modell.
Das ISO-Projekt SPICE [Dorling 93]
entwickelt einen internationalen Standard
für Software-Prozessbewertungen
und -Verbesserungen, der die Erkenntnisse
der obigen Modelle und Methoden
berücksichtigt.
Erste Werkzeuge und Hilfsmittel zur
Modellierung von Softwareprozessen
16 INFORMATIQUE No 6 (décembre 1994)
A
Fachbeiträge • Contributions techniques
Management
B
C
PROZESS
D
Technologie
sind Arcadia, HFSP, MVP und Process
Weaver [Rombach et al. 93]. Ein Beispiel
einer rechnergestützten Werkzeugumgebung
für Prozessmodellierung,
aber auch für die Projektabwicklung ist
das Automated Methods Environment
(AME) von Ernst & Young [Ernst&
Young 93].
Zum ingenieurmässigen Vorgehen gehört
unter anderem auch, dass ein Prozess
geplant und entworfen wird, dass
eine vollständige Beschreibung existiert,
Kontrollpunkte zur Einrichtung
von Messungen festgelegt und Auswertungen
der Messungen für die Prozessverbesserung
verwendet werden.
Merkmale von Prozessen
Für die Bewertung von Prozessen sind
die Auswahl und Zuordnung von Merkmalen
von Bedeutung. Nachfolgend
sind einige Merkmale angeführt, die zur
praktischen Bewertung von Prozessen
eingesetzt werden [Haist/Fromm 89].
Der Prozess ist
• effektiv (wirksam), d.h. vorgegebene
Aufgaben und Ziele sind erfüllt,
• effizient (wirtschaftlich), d.h. die
Aufgaben werden durch ein Minimum
an Ressourcen erfüllt,
• kontrollier- und steuerbar, d.h. der
Prozesszustand ist jederzeit erkennbar
und korrektive Massnahmen sind
einleitbar,
• adaptiv (anpassbar), d.h. Veränderungen
der Prozessumgebung, die Änderungen
am Prozess erfordern, sind
einfach durchführbar.
Der Begriff Prozessmanagement umfasst
die Führung, die Kontrolle und
Steuerung, aber auch die Verantwortung
für den Prozess. Prozessengineering
und Prozessmanagement helfen, Prozesse
in einen Zustand der Effektivität,
Kontrollierbarkeit, Steuerbarkeit, Effizienz
und Anpassbarkeit überzuführen
und zu halten.
Humphrey [Humphrey 89] vom Software-Engineering-Institut
(SEI) der
Carnegie Mellon University und seine
Mitarbeiter haben die Charakteristiken
von einem wirklich effizienten Softwareprozess
untersucht und analysiert.
Ein wirklich effektiver Softwareprozess
muss die Beziehungen zwischen allen
notwendigen Aufgaben, Werkzeugen
und Techniken, die benutzt werden, und
die Fähigkeiten der Entwickler, das
Training und die Motivation der Mitarbeiter
berücksichtigen.
Humphrey definiert einen Softwareprozess
wie folgt (Abb. 6). Ein Softwareprozess
ist eine Menge von Aktivitäten,
Methoden, Arbeitstechniken und Transformationen,
die Managern und Softwareingenieuren
hilft, Informationstechnologie
(insbesondere Werkzeuge)
einzusetzen, um Software zu entwikkeln
und zu pflegen, die definierte Qualitätsziele
erfüllt.
Prozessfähigkeit
Die Prozessfähigkeit beschreibt das
Ausmass der erwarteten Ergebnisse, die
durch Prozessausführung erreicht werden
können. Die Prozessfähigkeit einer
Organisation ist eine der Möglichkeiten,
um mit grosser Wahrscheinlichkeit das
Resultat der nächsten Projekte vorauszusagen,
die die Organisation durchführen
will. Die Leistung eines Softwareprozesses
umfasst die aktuellen
Ergebnisse, die durch Befolgen des Prozesses
entstehen.
Um Softwareprozessverbesserung zu
betreiben, ist es notwendig, den Unter-

schied zwischen unreifen und reifen
Softwareorganisationen zu verstehen.
Unreife Softwareorganisationen
In einer unreifen Softwareorganisation
werden die Prozesse innerhalb von Projekten
von Mitarbeitern und ihren
Managern improvisiert. Sogar wenn ein
Softwareprozess spezifiziert wurde,
wird er nicht rigoros befolgt oder verbessert.
Die Softwareorganisation ist reaktionär,
d.h. ihre Manager sind gewöhnlich mit
der Bewältigung von Krisen beschäftigt
(auch als “Feuerwehreinsatz” bekannt).
Zeitpläne und Budgets werden routinemässig
überschritten, weil sie nicht auf
realistischen Bewertungen und Schätzungen
beruhen. Wenn strenge Terminanforderungen
vom Auftraggeber verlangt
werden, werden häufig Abstriche
und Kompromisse bei der Produktfunktionalität
und anderen Qualitätsmerkmale
zugunsten der Termintreue in Kauf
genommen.
Eine unreife Organisation hat kein
nachvollziehbares Verfahren, um Produktqualität
zu bewerten oder die Pro-
Fachbeiträge • Contributions techniques
dukt-/Prozessprobleme zu lösen. Daher
ist auch die Voraussage der Produktqualität
schwierig oder nicht möglich.
Aktivitäten, um die Qualität zu bewerten
und dann zu verbessern, wie z.B.
Reviews und Testen, werden stark reduziert
oder überhaupt eliminiert, wenn
Projekte im Zeitplan zurückliegen.
Reife Softwareorganisationen
Eine reife Softwareorganisation besitzt
eine die ganze Organisation umfassende
Fähigkeit, Entwicklung und Wartung zu
managen. Führungskräfte und Mitarbeiter
sind in der Lage, über Softwareprozesse
zu kommunizieren, und die Projektarbeit
wird entsprechend den
geplanten Prozessen ausgeführt. Diese
definierten Prozesse werden, wenn
nötig, aktualisiert, wobei die Verbesserungen
zuvor durch Pfadfinderprojekte
und Kosten-Nutzen-Analysen entwickelt
wurden. Rollen und Verantwortlichkeiten
sind innerhalb der Projekte
und organisationsweit klar definiert.
In einer reifen Organisation kontrollieren
und überwachen die Führungskräfte
die Produkt-/Prozessqualität. Es gibt
objektive, quantifizierbare Grundlagen,
um die Produktqualität zu bewerten und
Produkt-/Prozessprobleme zu analysieren.
Zeitpläne und Budgets beruhen auf Vergangenheitswerten
und sind realistisch.
Die erwarteten Zielwerte für Planungsgrössen
wie Kosten, Zeit, Funktionalität
und für andere Produktqualitätsmerkmale
werden gewöhnlich erreicht.
Generell wird ein definierter Prozess
konsistent befolgt, da alle Beteiligten
den Wert eines solchen Prozesses verstehen
und eine Infrastruktur besteht,
um den Prozess zu unterstützen.
Prozessreife
Die Reife eines Softwareprozesses ist
das Ausmass, inwieweit ein konkreter
Prozess explizit definiert, geführt, gemessen,
gesteuert, kontrolliert und verbessert
wird und effektiv ist.
Die Reife impliziert ein potentielles
Wachstum in bezug auf die Prozessfähigkeit
und zeigt die Güte eines organisationsbezogenen
Softwareprozesses
auf, sowie dessen Konsistenz, mit der er
Reifestufe Merkmale Verbesserungen Ergebnis
5
optimierend
4
geführt
3
definiert
2
wiederholbar
1
initial
• kontinuierliche Prozeßverbesserung und -evolution
• automatisierte Datensammlung, um
Schwachpunkte zu finden
• rigorose Defekt-Analyse und -Verhütung
(quantitativ)
• gemessener Prozess
• Minimum von Qualitäts- und Produktivitätsmetriken
• Prozeßerfahrungsbasis
(qualitativ)
• Prozess definiert und institutionalisiert
• Prozessgruppe etabliert
(intuitiv)
• Prozess hängt von Einzelpersonen ab
• minimale Prozesskontrolle/-führung
• hohes Risiko bei neuen Herausforderungen
(ad hoc, chaotisch)
• Vorgehen, Schätzungen, Planung nicht formalisiert
• keine wirksamen Führungsmechanismen
• Schlüsselaufgaben nicht verstanden
Abb. 7: Das SEI-Reifegradmodell mit Verbessungsmassnahmen
Prozeßpflege auf
hohem Niveau
• Technologie-Change-
Management
• Problemanalyse
• Problemverhütung
• Prozeßmessungen
• Prozeßanalyse
• Qualitätsplan mit
quantitativen Zielen
• Training
• Reviews/Testen
• Prozeßgruppe/
-standards
• Projektmanagement
• Qualitätssicherung
• Konfigurationskontrolle
Produktivität
&
Qualität
Risiko
INFORMATIK Nr. 6 (Dezember 1994) 17

in Projekten innerhalb der Organisation
angewandt wird.
Je mehr eine Softwareorganisation an
Reife zunimmt, desto stärker institutionalisiert
sie ihren Softwareprozess
durch Regeln, Standards und organisationsbezogene
Strukturen. Institutionalisieren
bedeutet auch den Aufbau einer
geeigneten Infrastruktur und einer Unternehmenskultur,
um den Fortbestand
der Prozesse zu sichern.
Um die Prozessfähigkeit und -reife
einer Softwareorganisation zu verbessern,
empfiehlt Humphrey folgende
Massnahmen:
• Der gegenwärtige Zustand des Entwicklungsprozesses
ist zu analysieren
und zu verstehen.
• Es ist eine Vision des gewünschten
Prozesses zu entwickeln.
• Es ist eine Liste von notwendigen
Massnahmen zur Prozessverbesserung
mit Prioritäten abzuleiten.
• Es ist ein Plan zu erstellen, um diese
Massnahmen umzusetzen.
• Es ist die Zustimmung für den Einsatz
von Ressourcen einzuholen, um
diesen Plan auszuführen.
Dieses Prozess-Reifegradmodell, das
am amerikanischen Software Engineering-Institut
entwickelt worden ist, unterstützt
kontinuierliche Verbesserungen.
Es beruht auf den Prinzipien und
Erfahrungen anerkannter Qualitätsexperten,
wie W. Shewart, E. Deming, J.
Juran und P. Crosby. Die fünf Reifegrade
von Prozessen sind:
• der Initial- oder chaotische Prozess,
• der wiederholbare Prozess,
• der definierte Prozess,
• der geführte Prozess und
• der optimierende Prozess.
Die fünf Grade definieren eine Ordinalskala,
die zur Messung der Prozessreife
und zur Bewertung der Prozessfähigkeit
verwendet wird. Sie helfen einer
Softwareorganisation, für ihre
Verbesserungsaufwände und -anstrengungen
Prioritäten festzulegen. Jeder
Reifegrad umfasst eine Menge von Prozesszielen,
die bei Erfüllung wesentliche
Elemente eines Softwareprozesses
stabilisieren.
18 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Das Erreichen jedes Reifegrades etabliert
unterschiedliche, aufeinander aufbauende
Elemente eines Softwareprozesses.
Dies führt zu einer Zunahme an
Prozessfähigkeit einer Softwareorganisation.
In Abb. 7 sind Merkmale und Verbesserungsmassnahmen
des SEI-CMM dargestellt.
Literatur
[Bleicher 91] Bleicher K.: Das Konzept
Integriertes Management; Das St.
Galler Management Konzept, Band 1,
Campus 1991
[Boehm 81] Boehm B.: Software Engineering
Economics; Prentice-Hall 1981
[Chroust 92] Chroust G.: Modelle der
Software-Entwicklung; Oldenbourg
1992
[Dorling 93] Dorling A.: SPICE: Software
Process Improvement and Capability
Determination; Software Quality Journal
2, 1993, pp. 209–224
[Englert/Pfriem 93] Englert N., Pfriem S.:
Studie über den Nutzen von ISO 9000;
Price Waterhouse, Frankfurt, Report,
1993
[Ernst&Young 93] Ernst&Young: Automated
Methods Environment (AME);
Einführungsbeschreibung, 1993
[Freund 89] Freund B.: Mit Qualität die
Zukunft gestalten; Vortrag bei der
Siemens AG in München/Perlach, 20.
4. 1989
[Friedrich 94] Friedrich J.: Zertifizierung
von Software-Qualitätsmanagementsystemen;
in: Software Process
Maturity, erste deutsche Konferenz zum
Thema Softwareprozessreife, Institute
for International Research, München,
Tagungsunterlagen, 26. – 27. Januar
1994
[Garvin 88] Garvin D.A.: Managing Quality;
Free Press 1988
[Haist/Fromm 89] Haist F., Fromm H.J.:
Qualität im Unternehmen; Hanser 1989
[Harrington 91] Harrington H.J.: Business
Process Improvement; McGraw-Hill
1991
[Heinrich 92] Heinrich L.J.: Informationsmanagement;
4. Aufl., Oldenbourg
1992
[Humphrey 89] Humphrey W.S.: Managing
the Software Process; Addison-Wesley
1989
[Imai 86] Imai M.: Kaizen; Random House
1986
[Maiocchi 92] Maiocchi M.: Esprit Project
BOOTSTRAP: The European Kickoff
of Higher Process Maturity in Software
Development; in: “Lean Software Development”,
Proceedings, H. Woda, W.
Schynoll (Eds.), Stuttgart, 22.–23. 10.
1992
[Munro-Faure 92] Munro-Faure L.: Implementing
Total Quality Management;
Pitman 1992
[Österle et al. 92] Österle H., Brenner W.,
Hilbers K.: Unternehmensführung und
Informationssystem; Teubner 1992
[Rathbone/Vale 88] Rathbone M.P., Vale
J.M.: Software Quality Management;
Quality Assurance, Vol. 14, No. 3, 1988
[Rathbone 90] Rathbone M.P.: The Cost and
Benefits Associated With the Introduction
of a Quality System; Proc. of Sec.
Int. Conf. on Software Quality Assurance,
1990
[Rombach 90] Rombach H.D.: Software
Specifications: A Framework; SEI Curriculum
Module SEI-CM-11-2.1, January
1990
[Rombach et al. 93] Rombach H.D.,
Bröckers A., Lott C., Verlage M.: Entwicklungsumgebungen
zur Unterstützung
von qualitätsorientierten Projektplänen;
Softwaretechnik-Trends, Band
13, Heft 3, August 1993
[Scott Morton 91] Scott Morton M.S.: The
Corporation of the 1990s; Oxford University
Press 1991
[Seghezzi 92] Seghezzi H.D.: Bewirtschaftung
der Qualität – eine betriebswirtschaftliche
Aufgabe; Dokumentation
Betriebswirtschaft 1, 1992
[Ulrich 84] Ulrich H.: Management; Haupt
1984
[Wallmüller 94] Wallmüller E.: Umfassendes
Qualitätsmanagement in der Informationsverarbeitung;
Hanser, Dezember
1994
[Zeithaml 91] Zeithaml V.A., Parasuraman
A., Berry L.L.: Qualitätsservice;
Campus 1991
Dank
Der Autor dankt den Herren Prof. Segezzi,
Prof. Österle, Prof. Pomberger, Prof. Heinrich
und Prof. Rombach für Anregungen zu
dieser Arbeit und den Erfahrungsaustausch.

Risikobasiertes Qualitätsmanagement
Das Dilemma des Q-Leiters
Die Geschäftsleitung einer Firma, die
Softwaresysteme für Kunden oder für
den eigenen Gebrauch entwickelt, hat
sich entschlossen, die Unternehmung
nach ISO 9001 zertifizieren zu lassen.
Der Verantwortliche für Qualitätssicherung
(Q-Leiter) erhält den Auftrag,
unternehmensweit ein normgerechtes
Qualitätssystem (Q-System) einzuführen.
Der Q-Leiter findet sich in einem Spannungsfeld:
Auf der einen Seite steht die
Norm, die es zu verstehen und zu interpretieren
gilt. Der Q-Leiter wird feststellen,
dass er die Norm für die Entwicklung
von Software nicht direkt
umsetzen kann, da der Norm ein anderes
betriebliches Umfeld und andere
Denkmuster zugrunde liegen.
Auf der anderen Seite präsentiert sich
die Firma mit vielfältigen Arbeitskulturen,
die über die Jahre entstanden sind
und sich gefestigt haben. Es gilt nun,
diese Arbeitskulturen den Erfordernissen
der Norm anzupassen. Gerade Veränderungen
der Arbeitskultur stossen
Fachbeiträge • Contributions techniques
«Wir haben kein Q-System – wir sind eines!»
Stefan Brantschen und Stefan Zeder
Das vorgestellte prozessorientierte, umfassende und ISO-zertifizierte Qualitätssystem kann durch die
Umsetzung geeigneter Prinzipien flexibel und wirtschaftlich an die laufend veränderten Anforderungen
und Rahmenbedingungen angepasst werden.
Stefan Brantschen, dipl. Ing. ETH, ist
Geschäftsbereichsleiter Unternehmensentwicklung
und Qualitätssicherung bei
der GfAI Gruppe für Angewandte Informatik
AG, 3037 Herrenschwanden.
Stefan Zeder, dipl. Wirtschaftsinformatiker,
ist Q-Leiter und Senior Consultant
bei der gleichen Unternehmung.
aber bei den Betroffenen auf Widerstand;
sie sind nicht bereit, die vertrauten,
“historisch gewachsenen” Strukturen
und Arbeitsabläufe zu verändern,
und betonen, wie wichtig “pragmatische
Lösungen ohne bürokratischen
Overhead” sind, da die zur Verfügung
stehende Zeit schon für die “normale
Arbeit” kaum reiche.
Der verantwortungsvolle Q-Leiter wird
sich früher oder später die Frage stellen,
ob die Aufwände zur Überwindung
der Schwierigkeiten beim Aufbau eines
Q-Systems alleine aus dem Blickwinkel
der ISO-Zertifizierung gerechtfertigt
werden können.
Die unterschwellige Angst der Mitarbeiter
vor Verlust notwendiger Freiheitsgrade
zur Erledigung der Arbeit ist
verständlich. Sie befürchten, dass die
Festlegung und Beschreibung ihrer
Arbeitsabläufe dazu führt, dass sie nicht
mehr situationsgerecht und flexibel handeln
können. Dazu kommt die Gefahr,
dass eine “Standardisierung” und damit
Vereinheitlichung der Arbeit zur Folge
hat, dass der Einzelne seine persönliche
Arbeitsweise im beschriebenen, standardisierten
Ablauf nicht mehr wiedererkennt
und so die notwendige Identifikation
mit dem Q-System verliert.
Gerade die Betroffenen sind es jedoch,
welche die notwendigen Beschreibungen
erarbeiten und verantwortlich umsetzen
müssen.
Der Q-Leiter muss in diesem Spannungsfeld
Lösungen und Wege finden.
Er muss die Betroffenen motivieren und
sie bei der Umsetzung des Q-Systems
unterstützen. Er muss Möglichkeiten
finden, der Heterogenität der Firma in
ihren verschiedenen Dimensionen gerecht
zu werden. Dabei sind ihm finanzielle
und terminliche Rahmenbedingungen
vorgegeben.
Der verantwortungsbewusste Q-Leiter
wird sich daher früher oder später die
Frage stellen, ob die Aufwände zur
Überwindung dieser Schwierigkeiten
beim Aufbau eines Q-Systems alleine
aus dem Blickwinkel der ISO-Zertifizierung
gerechtfertig werden können.
Erweiterte Ziele
Die Zertifizierung ist ein wichtiger Meilenstein
bei der Erarbeitung eines konsistenten
Q-Systems; sie ist ein erster
Prüfpunkt auf dem Weg zu einem System,
das jedoch umfassendere Ziele im
Bezug auf die gesamte Unternehmung
und die geschäftlichen Tätigkeiten verfolgen
sollte:
• Das Q-System dient dem gezielten
Abbau von Risiken.
• Das Q-System ist die Basis für die
Beherrschung sowie die laufende
Verbesserung und Anpassung aller
Geschäftsprozesse – und damit die
Basis für den Unternehmenserfolg.
• Das Q-System bedeutet nicht zusätzliche,
parallele Arbeitsprozesse, sondern
es ist der Inbegriff tagtäglichen
professionellen Arbeitens. Eine Fir-
INFORMATIK Nr. 6 (Dezember 1994) 19

ma hat kein Q-System, sondern sie ist
eines.
• Das Q-System muss der Heterogenität
der Unternehmung gerecht werden.
Insbesondere die Skalierbarkeit
auf die verschiedenartigen Aufgabenstellungen
muss gewährleistet sein.
Im folgenden wird dargelegt, wie mittels
eines geeignet konzipierten Q-Systems
diese erweiterten Zielsetzungen
erreicht werden können, und wie es darüber
hinaus möglich ist, die Mitarbeiter
laufend direkt in die Weiterentwicklung
zu integrieren, um so die Identifikation
mit den Q-Massnahmen sicherzustellen.
Die Ausführungen sind in die folgenden
Teile gegliedert:
Dimensionen der Heterogenität einer
Unternehmung
Konzipierung und Aufbau eines umfassenden
Q-Systems bedingen die Auseinandersetzung
mit den verschiedenen
Gegebenheiten in einer Unternehmung.
Wichtige Dimensionen dieser hier als
Heterogenität bezeichneten Vielfalt
sind:
• Unterschiedliche Tätigkeitsfelder
und Marktsegmente: Auch Softwarefirmen
entwickeln nicht nur Software,
sondern erbringen zusätzliche
Leistungen wie Beratung, Support
und Ausbildung. Vermehrt gehören
auch Standardprodukte und ihre Integration
in bestehende oder neue
applikatorische Lösungen zum Angebot.
• Verschiedenartige Vorhaben innerhalb
der einzelnen Tätigkeitsfelder:
Verschiedenartige Vorhaben (Dauer,
Umfang, Komplexität, Technologien,
Marktpartner etc.) bedingen eine laufende
Neueinschätzung der vorhandenen
Risiken.
• Unterschiedliche Arbeitskulturen: In
allen Unternehmen gibt es unterschiedliche
lokale Arbeitskulturen,
20 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Erweiterte Zielsetzungen
• Vertiefte Beschreibung der erweiterten
Zielsetzungen.
• Aufzeigen eines Weges zum Aufbau
eines Q-Systems, mit dem diese
erweiterten Ziele erfüllt werden können.
• Vorstellung grundlegender Prinzipien
zur Realisierung des umfassenden Q-
Systems.
• Beschreibung eines in der Praxis realisierten,
ISO 9001-zertifizierten Q-
Systems, welches die Ziele durch
Umsetzung der grundlegenden Prinzipien
erreicht.
• Erfahrungen und Erkenntnisse aus
der Praxis.
die in der Regel über viele Jahre gewachsen
sind und damit nicht einfach
durch Einführung eines Q-Systems
verändert werden können.
• Verschiedenartige Qualitätsmassnahmen:
In den Unternehmen bestehen
bereits verschiedenartig ausgeprägte
lokale Qualitätsmassnahmen
oder gar Teile von Q-Systemen.
• Laufende Projekte: Es gibt laufende
Projekte, die im Sinne der Anforderungen
des zukünftigen Q-Systems
noch nicht genügend definiert sind.
Jedes Q-System muss mit dieser Heterogenität
zurecht kommen. Die Anforderungen
an die Art und Weise, wie dies
geschehen soll, bestimmen den Erstellungsweg,
die dazugehörigen Prinzipien
und letztlich die Ausgestaltung der Lösung.
Ziele für ein umfassendes Q-System
Die in der Einleitung aufgeführten Ziele
eines umfassenden Q-Systems werden
hier noch einmal aufgegriffen, erläutert
und ergänzt.
• Ein Q-System muss der Heterogenität
einer Firma gerecht werden: Ein
wichtiger Aspekt sind hierbei die Kosten
für die Erstellung und Aktuellhaltung
des Q-Systems. Dies bedeutet
beispielsweise, dass bei neuen
oder veränderten Geschäftsprozessen
eine flexible, schnelle und auf die
situativen Bedürfnisse abgestimmte
Anpassung der Festlegungen und Beschreibungen
möglich sein muss.
• Identifikation: Eine Firma hat kein Q-
System, sondern sie ist eines: Die
Verantwortung für die Qualität der
Arbeit liegt immer beim zuständigen
Manager bzw. Mitarbeiter, so dass
dieser die Möglichkeit und die Kompetenz
haben muss, die notwendigen
präventiven und korrigierenden Q-
Massnahmen selbst festzulegen, Beachtung
der Norm vorausgesetzt.
Die Festlegung der Q-Massnahmen
muss laufend und einfach vorgenommen
werden können. Damit ist
sichergestellt, dass die Massnahmen
situationsadäquat sind und daher von
den Betroffenen verstanden, akzeptiert
und umgesetzt werden.
• Vollständigkeit des Q-Systems: Das
Q-System ist die Basis für die Beherrschung
und Verbesserung aller
Geschäftsprozesse: Die Qualität der
Prozesse bestimmt in direkter Weise
die Qualität der resultierenden Produkte
und Dienstleistungen. Nur definierte
Prozesse lassen sich gezielt
verbessern. Die Beherrschung der
Prozessqualität erfordert somit die
Beschreibung der Prozesse, deren
konsequente Befolgung und Überwachung.
Das Schliessen dieses Regelkreises
ist eine notwendige Grundlage
für die laufende Verbesserung der
Prozesse.
Zur Sicherstellung der Gesamtqualität
und des unternehmerischen Erfolges
müssen daher alle geschäftlichen
Aktivitäten solche geregelten Prozesse
sein. Dies bedeutet, dass neben den
“kleinen” Prozessen, beispielsweise
im Rahmen von Projekten, auch
“grosse” Prozesse existieren, welche
die unternehmensweiten Regelkreise
sicherstellen. Beispiele sind Unternehmensplanung
und -steuerung,
Finanz- und Projekt-Controlling. Der
Einbezug dieser Prozesse geht über

die Normforderungen hinaus, ist aber
zwingend notwendig, wenn die Qualität
und damit der Unternehmenserfolg
über den Prozess definiert wird.
• Risikoabbau: Das Q-System dient
dem gezielten Abbau von Risiken:
Qualitätssichernde Massnahmen sollten
auf der Basis von Risikoüberlegungen
festgelegt werden: Q-Massnahmen,
die immer die grössten
vorstellbaren Risiken abfedern sollen,
gehen im Durchschnitt viel zu
weit und sind somit zu teuer – wenn
auch das Ziel der Qualitätssicherstellung
erreicht wird.
Die Erfüllung der Forderungen von ISO
9001 stellt im Rahmen einer Zertifizierung
das absolute Minimum dar. Um
dies zu erreichen, müssen die Anforderungen
der Norm also verstanden und
in den unternehmensspezifischen Festlegungen
konkretisiert werden. Mit anderen
Worten gilt es, zuerst den Grundgehalt
(Essenz 1 ) der Norm zu erkennen,
um diese danach in ein konkretes Q-System
abzubilden (Instanzierung).
Für diese Umsetzung der Norm in ein
Q-System existieren drei prinzipiell
unterschiedliche Wege, die einen entscheidenden
Einfluss auf die Qualität
des entstehenden Q-Systems haben. Im
folgenden werden diese drei Wege beschrieben
und bewertet.
Software-Entwicklung und ISO 9001
– der “structure clash”
ISO 9001 ist eine Norm, welche im Hinblick
auf bestimmte Unternehmungstypen
im Bereich der Produktion und
Montage definiert wurde. Die Strukturen
solcher Firmen prägen denn auch
1. Unter Essenz werden hier – gemäss der
“Essentiellen Systemanalyse” (ESA)
nach McMenamin and Palmer [McMenamin/Palmer
84] – die von der Art und
Weise der (späteren) Implementierung
unabhängigen Eigenschaften eines
Systems verstanden.
Fachbeiträge • Contributions techniques
Von der Norm zum Q-System
Qualität um jeden Preis kann sich
keine Unternehmung leisten. Es gilt
vielmehr, diejenigen qualitätssicherstellenden
Massnahmen zu finden
und anzuordnen, mit denen die in der
Situation bestehenden bzw. voraussehbaren
Risiken kostenoptimal abgesichert
werden. Von einer solchen
Qualitätsphilosophie profitieren sowohl
Kunde als auch Unternehmer.
Diese vier wesentlichen Ziele definieren
zusätzliche, über die Norm hinausgehende
Anforderungen an ein Q-System.
die Gliederung und den Inhalt von ISO
9001, so dass sich diese primär auf eine
bestimmte Unternehmensimplementation
bezieht. In einer Softwareunternehmung
wird diese Ausrichtung der Norm
eklatant sichtbar und führt zu dem, was
Michael Jackson im Rahmen von
Datenstrukturen als “structure clash”
bezeichnet, also einer strukturellen Inkompatibilität,
welche geeignet behandelt
werden muss ([Jackson 75]).
Dieser Sachverhalt ist in der Softwarebranche
bekannt. ISO 9000-3 zeigt, dass
sich auch die Normengremien dieses
“structure clashs” durchaus bewusst
sind. Der Leitfaden ISO 9000-3 gibt
dem verantwortlichen Q-Leiter zwar
einige Hilfestellung für die Strukturierung
des Q-Systems; die postulierten
weitergehenden Zielsetzungen können
jedoch auch mit der Umsetzung von
ISO 9000-3 alleine noch nicht erreicht
werden. Auch ISO 9000-3 stellt letztlich
eine Instanzierung dar, deren essentieller
Gehalt analysiert und vervollständigt
werden muss.
Konventioneller Weg der Umsetzung
der Norm
In der konventionellen Weise der Realisierung
eines Q-Systems ( Abb. 1a) wird
die ISO-Norm direkt auf der “Realisierungsebene”
umgesetzt, ohne die ei-
gentliche Essenz der Norm zuerst systematisch
zu ermitteln, um sodann diese
auf die lokalen Anforderungen und
Bedingungen der Unternehmung anzupassen.
Der “structure clash” wird somit in
einer impliziten Weise direkt während
der Realisierung aufgelöst. Dies ist vergleichbar
mit der Programmierung
eines Systems auf der Basis von Programmiervorgaben
für eine andere
Technologie (Programmierumgebung,
Datenbank etc.) als die effektiv eingesetzte,
so dass der Programmierer diese
Vorgaben laufend implizit in das neue
System umzusetzen hat. Richtig wäre
jedoch, in einem ersten Schritt die
technologiefreien (essentiellen) Anforderungen
zu ermitteln, welche in den
technologiebelasteten Programmiervorgaben
stecken. Erst diese essentiellen
Anforderungen sind dann in neue Programmiervorgaben
für die effektiv zum
Einsatz gelangende Technologie einzuarbeiten;
letztere können dann direkt,
also ohne implizite Umsetzung, programmiert
werden. Dies ist im übrigen
im Rahmen des Re-Engineerings von
Softwaresystemen ein Standardverfahren.
Umsetzung der Norm via Essenz
Abb. 1b zeigt schematisch, wie ein Q-
System in einer Unternehmung via Essenz
definiert und erarbeitet werden
kann. Es können dabei die folgenden
groben Schritte unterschieden werden:
• Befreiung der Normforderungen von
der implizite vorhandenen Abbildung
auf bestimmte Branchen und Organisationsformen.
• Ergänzung dieser essentiellen Normforderungen
um die lokalen, also für
die eigene Unternehmung relevanten
essentiellen Anforderungen.
• Abbildung dieser nun umfassenden,
für die eigene Branche wirklich
essentiellen Anforderungen auf die
eigene Unternehmung.
Essenz von ISO 9001: Zu den wichtigen
essentiellen Anforderungen von ISO
9001 (ISO 9000-3) gehören:
INFORMATIK Nr. 6 (Dezember 1994) 21

• Verankerung des gesamten Q-Systems
auf höchster Managementebene.
• Mitarbeiter mit den richtigen Fähigkeiten
am richtigen Ort.
• Prozesse müssen beschrieben und geplant
sein (Entwicklungs- und Qualitätsprozesse).
• Die Aktualität der Prozessanweisungen
muss sichergestellt sein.
• Arbeitsresultate müssen definiert und
verfolgbar sein.
• Arbeitsresultate müssen nachweisbar
geprüft worden sein.
• Das Q-System muss laufend überprüft
und verbessert werden, die entsprechenden
Massnahmen müssen
belegbar sein.
ISO 9000
Q-System-
Festlegung
ISO 9000
Essentielle
Anforderungen
Abb. 1: Drei prinzipielle Wege der Umsetzung von ISO 9000.
22 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
• Folgende Schnittstellen des Q-Systems
gegen aussen müssen definiert
sein: Vertragsprüfung, Beschaffungen,
Beistellungen, Kundendienst.
Bemerkungen:
• Ein Q-System darf bezüglich seiner
Struktur sehr wohl vom Aufbau der
Norm abweichen, die strikte Beschreibung
entlang der 20 Kapitel
gemäss ISO 9001 oder der drei
Hauptteile von ISO 9000-3 ist nicht
gefordert. Das Vorgehen nach Abb.
1b unterstützt das Finden von Q-Systemstrukturen,
die den Unternehmensstrukturen
und -prozessen besser
angepasst sind.
• Anforderungen, die auf der essentiellen
Ebene zu ergänzen sind, betreffen
beispielsweise Prozesse, die der
ISO 9000
Erkennen der essentiellen Normforderungen
Vervollständigung der essentiellen Normforderungen
Essentielle
Anforderungen
Abbildung der Normforderungen auf die Unternehmensanforderungen
Q-System-
Festlegung
Risiken
Ziele
Nutzung des Q-Systems zur Leistungserbringung
“Essentielle
Firma”
a) b) c)
Lösungsbausteine
Risiko-/zielbasierte, skalierte Instanzierung
“Operative
Firma”
Q-System-Festlegung
unternehmensweiten Planung und
Steuerung dienen.
Bei der Ermittlung und Beurteilung der
Essenz von ISO 9001 stellt man fest,
dass gewisse Anforderungen nicht das
notwendige Gewicht haben, erweitert
oder gar eingefügt werden müssen.
Dazu gehören:
• Das Q-System – und damit die gesamte
Unternehmung – wird nicht
konsequent als System aufgefasst und
modelliert, bei welchem klar zwischen
Innerem (dem “domain of control
and change”) und Äusserem
unterschieden wird, mit allen jeweils
notwendigen, klar definierten
Schnittstellenprozessen, welche die
interne Integrität sicherstellen ([Mc-
Menamin/Palmer 84]).
• Das Denken in Prozessen und vollständigen
Regelkreisen ist nicht
systematische konzeptionelle Grundlage
aller Festlegungen.
• Prüfungen sollten als fester Teil eines
jeden Prozesses gefordert werden,
nicht losgelöst oder nur in bezug auf
Arbeitsresultate.
• Der Einbezug des Risikos als Massstab
zur Festlegung kostenoptimaler
Qualitätsmassnahmen fehlt.
• Es fehlen wichtige geschäftliche Prozesse
wie Unternehmensplanung und
-steuerung, Projekt-Controlling, Finanz-Controlling:
“Die zertifizierten
Prozesse kümmern sich nicht um den
Unternehmenserfolg.”
• Die Prozesse und Aufgaben werden
zu starr auf eine feste Organisation
aufgeteilt.
Die hauptsächliche Leistung von ISO
9001 ist, dass Firmen, die sie umsetzen,
wichtige Prozesse der Entwicklung und
der Produktion beherrschen. Es findet
eine Sicherstellung der Qualität statt, indem
diese Prozesse definiert, befolgt
und kontrolliert werden. Dies ist bereits
ein beachtlicher erster Schritt.

Beurteilung der ersten zwei Wege der
Norm-Umsetzung
Konventioneller Weg der Umsetzung der
Norm (Abb. 1a):
• Die Norm kann auf diesem Weg umgesetzt
werden, so dass die hauptsächliche
Leistung von ISO 9001
effektiv zum Tragen kommt.
• Weitergehende Ziele können auf diesem
Weg jedoch nicht systematisch,
sondern nur dank grossem Geschick
des verantwortlichen Q-Leiters erreicht
werden – wenn überhaupt. Die
Erweiterung und Anpassung der
essentiellen Anforderungen wird
höchstens implizit gemacht und ist
damit nicht nachvollzieh- und prüfbar.
• Die so entstehenden Q-Systeme sind
nicht flexibel und anpassbar. Sie haben
statischen Charakter und werden
in grossen Schritten via wiederholte
Abbildung der Normforderungen
verbessert. Dies bedeutet, dass das Q-
System ganz oder in Teilen immer
wieder neu gebaut werden muss.
Umsetzung der Norm via Essenz (Abb.
1b):
• Alle Errungenschaften des konventionellen
Weges der Umsetzung werden
auch durch die Umsetzung via
Essenz erreicht.
• Weitergehende Ziele können systematisch
verfolgt und erreicht werden:
Die essentiellen Anforderungen werden
ermittelt und können gezielt um
unternehmensspezifische Anforderungen
ergänzt werden.
• Dies ermöglicht prinzipiell die systematische
Erreichung von zwei der
vier postulierten erweiterten Zielsetzungen
für ein Q-System:
–Vollständigkeit des Q-Systems
– Heterogenität der Firma
• Die Zielsetzungen die die Identifikation
mit dem Q-System und die Risikobasierung
der Q-Massnahmen betreffen,
können auch erreicht werden.
Nur wird diese Zielerreichung nicht
systematisch durch die Prinzipien des
Fachbeiträge • Contributions techniques
Vorgehens unterstützt, sondern hängt
– wie bereits beim konventionellen
Weg – vom Geschick des Q-Leiters
ab.
• Auch die auf diesem Weg entstehenden
Q-Systeme sind nicht flexibel
und anpassbar. Der statische Charakter
ist immer noch dominant, die Verbesserung
in grossen Schritten ist
auch hier das Grundprinzip. Es müssen
immer noch ganze Teile des Q-
Systems neu gebaut werden, obschon
es nun möglich ist, auf die essentiellen
Anforderungen zurückzugreifen,
was eine wesentliche Verbesserung
darstellt.
• Die ganze für die Abdeckung der
Heterogenität der Firma notwendige
Typisierung der Prozesse muss
bereits fest im Q-System vorgesehen
werden und ist damit statisch. Eine
neue Ausprägung eines Prozesses
erfordert damit eine Überarbeitung
von Teilen des Q-Systems.
Umsetzung via risikobasierte,
skalierbare Instanzierung
Abb. 1c zeigt, wie das Vorgehen zur Implementierung
eines Q-Systems via Essenz
um das entscheidende Konzept der
risikobasierten, skalierbaren Instanzierung
erweitert werden kann.
Analog der Umsetzung via Essenz
(Abb. 1b) werden die essentiellen
Normforderungen um die unternehmensspezifischen
Anforderungen ergänzt.
Die Erreichung des Zieles der
Vollständigkeit des Q-Systems kann
damit gewährleistet werden. Darüber
hinaus können nun auch den anderen
der vier postulierten Zielsetzungen
systematisch anvisiert werden.
Als entscheidende Neuerung gegenüber
Abb. 1b werden die essentiellen Anforderungen
nicht bereits in ein konkretes
Q-System abgebildet. In einem ersten
Schritt wird eine “essentielle Firma”
beschrieben. Diese besteht aus “generischen
Prozessen”, in denen die einzelnen
Aufgaben und Verantwortlichkeiten
nicht bereits Personen oder Stellen zugewiesen
werden, sondern klar definierten
“Rollen”.
Ein Instanzierungsprozess führt diese
“essentielle Firma” in das konkrete Q-
System über (die “operative Firma”).
Dieser Prozess ist – im Gegensatz zu
den generischen Prozessen – bereits
konkret festgelegt und den einzelnen
Verantwortlichen in der Organisation
(Manager, Abteilungsleiter, Gruppenchefs,
Projektleiter) zugewiesen. Diese
konkretisieren die generischen Prozesse
unter Berücksichtigung der situativen
Risiken und Ziele und benutzen dabei
bestehende Lösungsbausteine, z.B. in
Form von Richtlinien, Checklisten und
Templates. Diese Bausteine sind entweder
bereits vorhanden oder müssen bei
der Instanzierung erarbeitet werden.
Vorteile der risikobasierten,
skalierbaren Instanzierung
Mit Hilfe der risikobasierten, skalierbaren
Instanzierung können die vier Zielsetzungen
erreicht werden:
• Vollständigkeit des Q-Systems: Dieses
Ziel wird durch das Vorgehen
über die essentiellen Anforderungen
und die vollständigen Modellierung
der essentiellen Firma erreicht.
• Identifikation: Der verantwortliche
Mitarbeiter instanziert und konkretisiert
die Prozesse bei Bedarf selbst.
Dies setzt zum einen das Verständnis
für die Grundkonzepte und die Struktur
der essentiellen Firma voraus.
Zum anderen ist die Beschreibung
von Prozessen ein willkommenes Arbeitsinstrument
zur bedarfsgerechten
Konkretisierung und Konfiguration
generischer Vorgaben. Der Mitarbeiter
findet dadurch Lösungen, die seine
spezifischen Bedürfnisse abdekken;
die Identifikation mit den Q-
Massnahmen ist damit gewährleistet.
• Heterogenität: Die verschiedenen
Tätigkeitsfelder der Unternehmung
werden bereits in der “essentiellen
Firma” berücksichtigt. Dadurch, dass
die durch das Q-System vorgesehene
Instanzierung die lokale, situative
Anpassung zum Prinzip erhebt, können
auch die anderen Dimensionen
der Heterogenität abgedeckt werden:
–verschiedenartige Vorhaben innerhalb
eines Geschäftsfeldes (beispiels-
INFORMATIK Nr. 6 (Dezember 1994) 23

weise Projektgrösse)
–verschiedene Arbeitskulturen
– bestehende Q-Massnahmen
– laufende Projekte
• Risikoabbau: Durch die systemimmanente,
bedarfsorientierte Instanzierung
ist gewährleistet, dass Risikoüberlegungen
bei jedem Aufstarten
eines Prozesses mit einbezogen werden.
Die jeweiligen Risiken werden
analysiert und beurteilt und sind das
Mass für die Q-Massnahmen, die gezielt
zum Zweck des Risikoabbaus
festgelegt werden.
Für das Erkennen und Beurteilen von
Risiken können sehr feine Instrumente
zur Verfügung gestellt werden,
welche die Wirksamkeit des Q-Systems
erheblich erhöhen.
• Die auf diesem Weg entstehenden Q-
Systeme sind äusserst flexibel und
Um die Umsetzung nach Abb. 1c realisieren
zu können, müssen einige grundlegende
Prinzipien beachtet werden, die
im folgenden beschrieben werden. Es
handelt sich dabei um:
• Essentielle Firma
• Vollständig geregelte Prozesse (Regelkreise)
• Risiko- und Zielbasierung
• Subsidiarität
Essentielle Firma
Auf der Stufe der Q-Systembeschreibung
werden alle geschäftlichen Aufgaben
und die damit verbundenen
Verantwortlichkeiten in einer von der
konkreten, momentanen Organisationsform
unabhängigen Form beschrieben
durch
• generische Prozesse
• die dazugehörigen Rollen
Generische Prozesse: Festlegung und
Beschreibung aller geschäftlichen Prozesse
in einer von einer momentanen,
24 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Prinzipien
anpassbar. Die Verbesserungen werden
nicht in grossen Schritten durchgeführt,
sondern können nach Bedarf
immer wieder und schnell im Rahmen
der Instanzierung in die jeweilige
Umsetzung einfliessen. Solche Q-
Systeme sind damit in hohem Masse
wartungsfreundlich.
Die Instanzierung ist also nicht ein Prozess,
der bei der Einführung des Q-Systems
gemäss Abb. 1b einmal abläuft,
sondern ist selbst auch ein wichtiges
Element des Q-Systems (Abb. 1c). Die
Ausgestaltung des Instanzierungsprozesses
muss die Erfüllung der Norm
sicherstellen: Lokale Festlegungen dürfen
keine Abschwächungen von Anforderungen
aus den Vorgabedokumenten
bedeuten.
konkreten Aufgabenstellung losgelösten
Implementationsform. Diese Vorgaben
sind im Rahmen der gewählten
Detaillierung für die spätere Konkretisierung
verbindlich.
Rollen: Im Rahmen der generischen
Prozesse können, obschon diese per definitionem
personen- und damit stellenunabhängig
sind, trotzdem einzelne
Aufgaben definiert und Verantwortlichkeiten
zugewiesen werden: Diese werden
den sogenannten Rollen zugeteilt,
eigentlichen “fiktiven Stellen”, die für
jeden der generischen Prozesse bzw.
Subprozesse definiert sind. Beispiele
von Rollen sind Kursreferent, Konfigurationsverantwortlicher,
Gutachter oder
Projektleiter. Diese Beispiele zeigen,
dass die Rollenbeschreibungen die
Grundlage bilden für die konkreten Stellenbeschreibungen
der einzelnen Mitarbeiter.
Vollständig geregelte Prozesse
Planen Durchführen
Analysieren &
Entscheiden
Abb. 2: Geregelter Prozess (Grundprinzip).
Rückkopplung: Kontrollierte Prozesse
müssen über eine geeignete Rückkopplung
verfügen (vgl. Abb. 2). Häufig werden
jedoch nur Ausschnitte aus dem
vollständigen Regelkreis betrachtet.
Dies hat zur Folge, dass die Vorteile eines
Q-Systems gar nicht zum Tragen
kommen, weil die gewonnenen Erkenntnisse
nicht systematisch in den
nächsten Ablauf des Prozesses zurückfliessen.
Eine gezielte laufende Verbesserung
des Prozesses findet nicht statt.
Prozesshierarchien: Das Denken in Regelkreisen,
in Abb. 2 in seiner einfachsten
Form auf nur einer Ebene dargestellt,
kann konsequent erweitert
werden, wenn die Betrachtung auf die
verschiedenen Ebenen der Hierarchie
der Geschäftsprozesse ausgedehnt wird,
die zumindest implizit immer vorhanden
ist:
• Operationelle Ebene: Alle Prozesse,
die direkt oder unterstützend der Erbringung
der Marktleistung dienen.
• Controlling-Ebene: Prozesse, welche
die operationellen Prozesse überwachen.
Controlling-Prozesse greifen
nur im Ausnahmefall direkt in die
Prozesse der operationellen Ebene
ein. Die für die Aufgaben des Controllings
notwendigen Daten und
Informationen werden in der Regel
für übergeordnete Planungs- und
Steuerungsaufgaben verwendet, beispielsweise
auf Unternehmens- oder
Abteilungsebene.
Prüfen
Leistung

• Metaprozess-Ebene: Prozesse, die
die Qualität der Prozesse der beiden
anderen Ebenen beurteilen und wenn
nötig eine Verbesserung bzw. Aktualisierung
des Q-Systems durchführen
oder anstossen. Metaprozesse definieren
also die anderen Prozesse in
grundsätzlicher, nicht planerischer
Weise.
Bemerkungen:
• Im unternehmerischen Sinn ist die
Metaprozess-Ebene der unternehmensweiten
Controlling-Ebene unterstellt.
• Auch innerhalb einer einzelnen Ebene
kann selbstverständlich wieder
eine analoge Hierarchie gebildet werden
(rekursive Struktur). Die hier
vorgestellten Ebenen sind die aus
einer globalen unternehmerischen
Sicht relevanten.
Risiko- und Zielbasierung
Alle Q-Massnahmen werden – im Rahmen
der Forderungen der Norm – durch
Analyse und Beurteilung der Risiken so
festgelegt, dass die Summe der Aufwände
für die Vermeidung von Qualitätsmängeln
(präventive Q-Massnahmen)
und der Aufwände für die
Behebung dieser Mängel (korrigierende
Q-Massnahmen) minimal wird (Abb.
3). Die Beurteilung, ob ein Qualitäts-
Im folgenden werden Teile eines Q-Systems
vorgestellt, welches die risikobasierte,
skalierbare Instanzierung realisiert.
Das Q-System wird aktuell
genutzt und ist erfolgreich nach ISO
9001 zertifiziert worden.
Struktur der Q-Dokumentation
In seiner Dokumentation offenbart sich
ein Q-System: Die gesamte Dokumentationsstruktur
muss so angelegt sein,
dass die Zielsetzungen erreicht werden,
und dass sich die grundlegenden Prinzi-
Fachbeiträge • Contributions techniques
Kosten
Praktische Umsetzung
Aufwand für
korrigierende
Q-Massnahmen
(Behebung von Qualitätsmängeln)
Wenig präventive
Q-Massnahmen
mangel vorliegt, ergibt sich aus den
(Qualitäts-) Zielsetzungen.
Subsidiarität
Innerhalb des Gefüges von Festlegungen
in einer Unternehmung gilt, neben
der Risikobasierung, das Prinzip der
Subsidiarität: Es werden nur dann Aufgaben
an die nächste übergeordnete
organisatorische Einheit abgegeben,
wenn sie durch die untergeordnete nicht
mehr sinnvoll wahrgenommen werden
können, oder wenn dies der ganzen Firma
Vorteile bringt, beispielsweise durch
umfassendere Optimierungsmöglichkeiten
und Entscheide.
pien realisieren lassen. Im vorgestellten
Q-System finden sich folgende drei
Ebenen der Q-Dokumentation (vgl.
Abb. 4):
1. Q-Systemdokumentation: Die Q-Systemdokumentation
ist ihrerseits in
zwei Ebenen gegliedert:
• Qualitätshandbuch (QHB), das den
Bereich der Qualitätssicherung thematisch
absteckt, indem es alle essentiellen
Elemente des Q-Systems definiert
und beschreibt, und damit die
Schnittstelle zwischen den Anforde-
Summe der Aufwände
für präventive und korrigierende
Q-Massnahmen
Bereich des
wirtschaftlichen
Optimums
Abb. 3: Wirtschaftlichkeit von Q-Massnahmen.
Aufwand für präventive
Q-Massnahmen
(Vermeidung von Qualitätsmängeln)
Viele präventive
Q-Massnahmen
rungen von ISO 9001 und deren spezifischen
Umsetzung in der Unternehmung
bildet. Das QHB enthält im
wesentlichen die Beschreibung der
essentiellen Firma und die konkrete
Festlegung des Instanzierungsprozesses.
• Dem Qualitätshandbuch nachgeordnete
Dokumente (QND), also alle das
QHB ergänzenden und konkretisierenden
Vorgabedokumente.
2. Operative Q-Dokumente: Diese sind
das Resultat der Instanzierung und zeigen
auf, wie die generischen Prozesse
aus den Q-Systemdokumenten zu jedem
Zeitpunkt situationsspezifisch umgesetzt
werden. Erst mit diesen operativen
Q-Dokumenten wird das Q-System
konkret und greifbar, da erst hier die
spezifischen, geplanten und angeordneten
Q-Massnahmen für den jeweiligen
Gültigkeitsbereich beschrieben werden.
Die operativen Q-Dokumente sind daher
von zentraler Bedeutung.
3. Q-Nachweisdokumente: Es werden
folgende Kategorien von Nachweisdokumenten
unterschieden:
• prozessbelegende Dokumente zeigen
die korrekte Anwendung des Q-Systems;
• prozess- bzw. produktqualifizierende
Dokumente machen Aussagen über
INFORMATIK Nr. 6 (Dezember 1994) 25

die Qualität der Prozesse bzw. Produkte.
Die Nachweisdokumente dienen der internen
und externen Auditierung sowie
der Verbesserung der geschäftlichen
Prozesse.
Die verschiedenen operativen Q-Dokumente:
Bei den operativen Q-Dokumenten
kann unterschieden werden zwischen
(Abb. 4):
• Unternehmensplan:
– Gilt für die gesamte Firma und bildet
die Grundlage aller geschäftlichen
Aktivitäten eines Jahres.
“Essentielle Firma”
“Operative Firma”
Geschäftsbereich A
Projekt 1
Projekt 2
Ziele
Risiken
Ziele
Aufgaben
Ziele
Aufgaben
Ziele
Aufgaben
Abb. 4: Struktur der Q-Dokumentation.
26 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Geschäftsleitung
Risiken
Risiken
Risiken
–Konzentration auf Strategie, Qualitätsziele,
Marketingziele, Budget und
Entscheidungsfindung auf Unternehmensebene.
– Enthält nur wenige konkrete Festlegungen
von Q-Massnahmen.
• Bereichspläne:
– Es wird ein Bereichplan pro sogenanntem
Geschäftsbereich und pro
Stabsbereich erarbeitet, den organisatorischen
Einheiten der betrachteten
Firma.
– Strategie, Ziele, Risiken und Organisation
auf Bereichsebene.
Qualitätshandbuch (QHB)
Projektplan
1
Nachgeordnete
Vorgabedokumente (QND)
Bereichsplan
A
Subsidiarität
Subsidiarität
Projektplan
2
Unternehmensplan
prozessbelegend prozessqualifizierend produktqualifizierend
Q-Systemdokumente
Operative Q-Dokumente
Q-Nachweisdokumente
– Festlegung erster konkreter Q-
Massnahmen, die für den gesamten
Bereich gelten und primär permanent
organisierte Prozesse betreffen.
Der Unternehmensplan und die Bereichspläne
werden in der Regel einmal
pro Jahr im Rahmen der Strategieaktualisierung
und der Budgetierung überarbeitet
(selbstverständlich ebenfalls Prozesse
des Q-Systems).
• Projektpläne:
– Pro internes oder externes Projekt
wird ein Projektplan erarbeitet und
aktuell gehalten.
– Strategie, Ziele, Risiken, Organisation
etc. auf Projektebene.
– Festlegung aller durch das Q-System
(und ISO 9001) geforderten
Massnahmen, die nicht schon durch
den übergeordneten Bereichsplan abgedeckt
sind.
–Konkrete inhaltliche und terminliche
Projektplanung.
Der Projektplan wird zu Beginn des
Projektes erstellt und dann zu geeigneten
Zeitpunkten aktualisiert, beispielsweise
bei Phasenabschlüssen oder anderen
Meilensteinen.
Inhaltsübersicht Bereichs- und Projektplan:
Der Bereichs- bzw. Projektplan
enthält die notwendigen grundlegenden
Beschreibungen sowie die risikogerechten
Festlegungen und Q-Massnahmen
für den jeweiligen Gültigkeitsbereich:
• Auftrag, inkl. Ziele, Rahmenbedingungen,
Abhängigkeiten
• Leistungen, Lieferobjekte, inkl. Abnahmekriterien
• Vorgehen und Methoden
• Organisation, inkl. Aufgaben und
Verantwortlichkeiten
• Planung und Steuerung, inkl. Risikomanagement
• Externe Reporting- und Controlling-
Schnittstellen
• Aufgaben und Pflichten des Auftraggebers
bzw. Abnehmers

• Fremdprodukte und Fremddienstleistungen,
inkl. Beistellungen und Beschaffung
• Infrastruktur und Support
• Konfigurationsverwaltung und Dokumentenmanagement,
inkl. Problemund
Änderungsverfahren
• Prüfungen, Abnahmen, Fehlerbehandlung
• Qualitätsaufzeichnungen (Nachweisdokumente)
• Kunden-Feedback
Wartung der Q-Systemdokumentation:
Der Aufbau der Q-Systemdokumentation
und die dargelegten Prinzipien der risikogerechten
Instanzierung des Q-Systems
ergeben eine laufende, quasi
natürliche Wartung und Aktualisierung
der Vorgabedokumente:
• Das Q-System wird durch das Prinzip
der bereichs- und projektlokalen
Festlegungen bzw. deren institutionalisierte
Aktualisierung laufend und
als Teil der Routine überprüft und
wenn notwendig angepasst.
• Nachgeordnete Q-Systemdokumente
(QND) wie Richtlinien und Checklisten
entstehen in der Regel durch bereichs-
oder projektlokale Bedürfnisse,
also für konkrete Anforderungen
und im Rahmen der normalen geschäftlichen
Aktivitäten. Bewähren
sich solche bereichs- oder projektspezifischen
Vorgabedokumente, werden
sie verallgemeinert und mit einem
vergrösserten Geltungsbereich in
Kraft gesetzt.
Prüfungen und Freigaben: Alle Q-Systemdokumente
und alle operativen Q-
Dokumente werden selbstverständlich
durch festgelegte Prüfungsgremien geprüft
und durch die vorgesetzte, verantwortliche
Stelle freigegeben. Wichtiger
Aspekt dieser Prüfungen ist die Einhaltung
der firmenweiten Vorgaben des Q-
Systems – festgehalten im für die gesamte
Unternehmung gültigen Q-Handbuch
– und damit der Norm.
Fachbeiträge • Contributions techniques
Prozessgruppierung und -typisierung
Um dem Prinzip der vollständig geregelten
Prozesse über die gesamte Unternehmung
gerecht werden zu können,
muss ein geeignetes Prozessgruppierungs-
und -typisierungskonzept entwickelt
werden, das in der Lage ist, die
unterschiedlichen Prozesshierachien
abzubilden.
Prozessgruppen: Die geschäftlichen
Prozesse werden in die folgenden Prozessgruppen
eingeteilt:
• Operationelle Prozesse: Alle Prozesse,
die direkt der Erbringung der
Marktleistungen nach aussen dienen,
beispielsweise:
– Software-Entwicklung
– Support & Consulting
– Aus- & Weiterbildung
– Standardsoftwareprodukte
– Marketing & Verkauf
• Steuernde Prozesse: Alle Prozesse,
die der Überwachung und Steuerung
auf projekt- und bereichsübergreifender
Ebene dienen:
– Finanz- und Projekt-Controlling
–Validierung und Verbesserung des
Q-Systems
– Strategisch-konzeptionelle Aufgaben
• Unterstützende Prozesse: Alle Prozesse,
die das Funktionieren der operationellen
und der steuernden Prozesse
unterstützen und sicherstellen:
– Mitarbeiterbetreuung
– Methodisch-technischer Support
und Infrastrukturbetreuung
–Pflege von Vorgehen, Methoden
und Werkzeugen
–Konfigurationsverwaltung und Dokumentenmanagement,
inkl. Problem-
und Änderungsverfahren
– Metriken, Mess- und Schätzverfahren
–Formelle Prüfungen
– Fremdprodukte und Fremddienstleistungen
–Kundenfeedback
In dieser Gruppe wird weiter unterschieden
zwischen internen und externen
unterstützenden Prozessen; letztere
bilden wichtige Schnittstellen gegen
aussen: Kunden, Lieferanten, Sub-Akkordanten
und Generalunternehmer.
Bemerkungen:
Auf alle Prozesse auf den Schnittstellen
der Unternehmung gegen aussen muss
grösstes Gewicht gelegt werden: In
einem System wie einer Unternehmung
laufen einerseits die Prozesse im Inneren
ab, beispielsweise die Software-Entwicklung
oder die Konfigurationsverwaltung;
andererseits muss das System
mit der Umwelt kommunizieren.
Das Innere des Systems liegt im “domain
of control and change”, die Prozesse
können dort also vollständig
beeinflusst und gesteuert werden, insbesondere
im Hinblick auf die Prozessund
Produktqualität. Die Umwelt des
Systems kann nur beschränkt beeinflusst
werden, so dass qualitätsgefährdende
Eingaben erfolgen können ([McMenamin/Palmer
84]). Um die Integrität des
Q-Systems zu gewährleisten, müssen
deswegen die Schnittstellenprozesse beherrscht
werden.
Zu den wichtigsten Schnittstellenprozessen
gehören:
• Problem- und Änderungsverfahren,
sowohl bezüglich Prozess (Projekt)
als auch Produkten (Anforderungen,
Spezifikationen).
• Abnahme und Genehmigung von
Arbeitsresultaten durch den Kunden.
• Behandlung von Fremdprodukten
und Fremddienstleistungen, insbesondere
Beschaffung, Beistellung,
Evaluation.
Prozesstypen: Alle geschäftlichen Aufgaben
werden durch folgende Prozesstypen
implementiert:
• Permanent organisierte Prozesse:
Diese Prozesse werden im Prinzip
einmal angestossen und laufen dann
bis auf weiteres oder bis zu einem
geplanten, durch die Zeit gegebenen
Ende weiter.
Beispiele:
– Projekt-Controlling
–Wartung eines Softwaresystems im
INFORMATIK Nr. 6 (Dezember 1994) 27

Rahmen eines Wartungsvertrages
– Marktbeobachtung und -analyse
• Projektartig organisierte Prozesse:
Diese Prozesse werden als einmaliger
Ablauf geplant und durchgeführt.
Beispiele:
– Entwicklungsprojekte
– Erstellung einer Offerte
– Durchführung eines Qualitätsaudits
Bemerkungen:
• Es versteht sich, dass jede geschäftliche
Aufgabe, wenn sie umfassend
betrachtet wird, sowohl aus permanent
als auch projektartig
organisierten Prozessen bestehen
kann. Die Aufgaben des Marketings
umfassen beispielsweise Marktbeobachtung
(permanent) und auch Offerterstellung
(projektartig).
• Sowohl permanente als auch projektartig
organisierte Prozesse können
aus Subprozessen und aus einzelnen
Teilaufgaben und Arbeitsschritten
bestehen, die ihrerseits wiederum jeweils
aus den “Elementarprozessen”
– Planen
– Durchführen (Erbringen der
eigentlichen Leistung)
– Prüfen
– Analysieren und Entscheiden
bestehen (Abb. 2); auf der Ebene der
einzelnen Arbeitsaufträge gibt es
diesbezüglich keinen Unterschied
zwischen den beiden Prozesstypen.
• Permanente Prozesse werden entweder
mit der Einführung des Q-Systems
oder erst bei Bedarf risikogerecht
konfiguriert, geplant,
angestossen und initialisiert.
• Projektartige Prozesse werden immer
bei Bedarf risikogerecht konfiguriert,
geplant, angestossen und initialisiert.
Prozessbeschreibungen
Die Kapiteleinteilung der Q-Systemdokumentation
(QHB) entspricht in ihrem
Hauptteil den bereits vorgestellten Prozessgruppen;
es wurde bewusst auf eine
Strukturierung nach ISO 9001 oder ISO
9000-3 verzichtet.
28 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Jeder generische Prozess ist im Q-
Handbuch nach folgendem einheitlichen
Raster beschrieben:
• Einleitung
– Einführung in Ziel und Zweck des
Prozesses
– Abgrenzung zu anderen Prozessen
– Anwendungsbeispiele
• Festlegungen und Konzepte
–Definition von Begriffen
– Grundlegende Konzepte im Rahmen
des Prozesses
Das Q-System, welches gemäss den
skizzierten Prinzipien konzipiert, aufgebaut
und eingeführt wurde, konnte im
Januar 1994 nach ISO 9001 ohne eine
Schwachstelle zertifiziert werden.
Seit der Zertifizierung wurden bereits
einige interne Q-Audits durchgeführt,
die den Qualitätssystemverantwortlichen
die Gewissheit verschafft haben,
mit ihrem Ansatz auf dem richtigen Weg
zu sein. Im folgenden werden einige
Erfahrungen und Erkenntnisse zusammengefasst,
die sich aus der Einführung,
der bisherigen Praxis und der Weiterentwicklung
ergeben haben.
Grundkonzepte
Die Einführung des Q-Systems umfasste
konzeptkonform die Erarbeitung der
operativen Q-Dokumente in allen Organisationseinheiten,
in allen Projekten
sowie auf Unternehmensebene. Die jeweiligen
verantwortlichen Vorgesetzten
legten also, im Rahmen des durch die
Q-Systemdokumentation definierten
Rahmens, ihr “lokales Q-System” fest.
Mit der notwendigen Ausbildung und
Unterstützung durch die beiden Q-Systemverantwortlichen
konnten diese Arbeiten
zügig erledigt werden. Die Akzeptanz
war kein Problem, wohl gerade
weil keine konkreten Vorschriften erlassen
wurden, sondern weil die jeweils lokalen
Arbeitskulturen und Gegebenheiten
auch unter dem Q-System
Erfahrungen und Erkenntnisse
– Festlegung der Rollen, der “essentiellen
Organisation” im Rahmen des
Prozesses.
• Aufgaben und Verantwortlichkeiten
– Aufbau-, Initialisierungs- und wo
nötig Abbau-Subprozesse
– Eigentliche Kern-Subprozesse
– Überwachungs- und Verbesserungs-Subprozesse
Alle (Sub-) Prozesse sind in resultatorientierter
Weise mit Hilfe eines tabellarischen
Schemas beschrieben.
weiterbestehen durften. Das durch das
Grundkonzept des Q-Systems geförderte
und auch geforderte Verantwortungsbewusstsein
der einzelnen Geschäftsbereichs-
und Projektleiter für die
Belange der Qualitätssicherung innerhalb
ihres Bereichs war – und ist bis
heute – ausserordentlich gross.
Die internen Q-Audits ebenso wie die
unterstützenden Tätigkeiten der Q-Stelle
zeigen, dass die Konzepte sowohl der
Qualitätssicherung als auch des Q-Systems
weitgehend begriffen wurden und
in der Praxis umgesetzt werden. Selbstverständlich
tauchen immer wieder Verbesserungs-
und Optimierungsmöglichkeiten
auf, die im Rahmen des
vorgesehenen Verbesserungsprozesses
realisiert werden.
Reorganisation der Firma
Die Flexibilität des Q-Systems zeigte
sich auch, als die Unternehmung auf
Anfang dieses Jahres, also nur einige
Wochen vor dem Zertifizierungsaudit,
organisatorisch vollkommen neu strukturiert
wurde, nämlich von einer funktionalen
zu einer profit-centerorientierten
Organisation: Die Q-Systemdokumentation
bedurfte nur geringfügiger
Anpassungen, lediglich die
operativen Q-Dokumente mussten naturgemäss
grundlegend überarbeitet
werden. Die notwendigen Anpassungen
innerhalb der Q-Systemdokumentation
konnten darüber hinaus auf “nichtessen-

tielle Verunreinigungen” zurückgeführt
werden, welche sich in der konzeptionellen
Phase des Q-Systemaufbaus eingeschlichen
hatten.
Die “essentielle Firma” musste also lediglich
bezüglich der veränderten Organisation
neu instanziert werden!
Schnittstellenprozesse
Die Schnittstellen gegenüber der Umwelt
erweisen sich nicht nur theoretisch,
sondern auch in der Praxis als sehr heikle
Stellen eines Q-Systems. Wenn den
entsprechenden Schnittstellenprozessen
nicht genügend Bedeutung zugemessen
wird – wozu in der Praxis leider die Tendenz
besteht – können die internen Prozesse
der Leistungserbringung nicht
ungestört ablaufen, mit den entsprechenden
negativen Auswirkungen auf
Kosten und Termine.
Gezielte Zentralisierung
In einer ersten Phase des Aufbaus und
der Nutzung des Q-Systems kamen für
die verschiedenen Problemstellungen
des Qualitätsmanagements vor allem
dezentrale Lösungen zu Einsatz, die lokal
in den Geschäftsbereichen oder gar
Projekten festgelegt wurden. Dies erlaubte
eine Weiterführung der jeweiligen
Arbeitskulturen in einzelnen Teams,
mit den entsprechenden positiven Auswirkungen
auf die Akzeptanz des Q-Systems.
Mit den praktischen Erfahrungen
kommt nun in ganz natürlicher Weise
der Wunsch auf, vermehrt zentrale, also
unternehmensweite Lösungsbausteine
zu erstellen und anzubieten, da dies
offensichtliche Vorteile bezüglich Erstellungs-
und Überwachungsaufwand
sowie Informations- und Erfahrungsaustausch
zwischen den Teams bietet.
Diese Tendenz kann im vorhandenen Q-
System ohne weiteres abgedeckt werden,
da gemeinsame Festlegungen situationsgerecht
zuerst im hierarchisch
Fachbeiträge • Contributions techniques
nächst höheren operativen Q-Dokument
und dann in Form eines Q-Systemdokuments
(Vorgabedokumentes) abgelegt
werden können. Dieser Entwicklungspfad
ist im Q-System genau so vorgesehen.
Wichtig ist, dass die Entscheidung, ob
eine Lösung zentral oder dezentral anzulegen
ist, nicht a priori gefällt werden
muss, sondern sich im Laufe der Q-Systembenutzung
in einer natürlichen
Weise ergeben kann.
Informelle Kontakte
Von grosser Bedeutung sind informelle
Kontakte zwischen den einzelnen Orga-
Qualität wird von Menschen gemacht,
ein Q-System darf daher nie am Menschen
vorbei gestaltet werden. Die Mitarbeiter
sollten die Möglichkeit haben,
die für die Lösung ihrer Probleme relevanten
Q-Massnahmen festzulegen. Die
Mitarbeiter müssen daher einbezogen
werden, aber nicht nur einmal beim
Aufbau eines Q-Systems, sondern laufend,
da sich auch die Anforderungen,
Gegebenheiten und Einflussfaktoren –
insbesondere die Risiken – laufend verändern.
Eine Unternehmung alleine durch genaue
Beschreibungen und Festlegungen
sowie darauf basierender Kontrolle und
Steuerung führen zu wollen, ist unwirtschaftlich.
Es macht schlicht nicht für
alle geschäftlichen Prozesse Sinn, sie
bis zur Perfektion reglementieren zu
wollen, ansonsten das gesamte System
zu unbeweglich und unwartbar wird.
So muss – oder darf – eine Firma gar
nicht zu einem vollständig definierten
und durchorganisierten System werden.
Vielmehr müssen geeignete, durch Risi-
Zusammenfassung
nisationseinheiten und Teams. Gerade
in der eher formalen Welt der normgerechten
Qualitätssicherung, in welcher
Definitionen, Prozessbeschreibungen
und schriftliche Nachweise eine grosses
Gewicht haben, sollte auch der informelle,
aber trotzdem gezielte Erfahrungs-
und Gedankenaustausch seinen
institutionalisierten Platz haben.
Dies wird um so wichtiger, je mehr Eigenverantwortlichkeit
den einzelnen
Mitarbeiter und Vorgesetzten in einem
Q-System übergeben wird.
ko- und Zielsetzungsüberlegungen definierte
und ausgestaltete Regelkreise und
Alarmsysteme der Beurteilungs- und
Reaktionsfähigkeit einzelner Mitarbeiter
überlassen werden. Kreative
Spontaneität und Improvisation müssen
ihren Platz haben oder finden. Dass weniger
detailliert vorgegebene Prozesse
nach mehr fachlicher Kompetenz verlangen,
um qualitativ hochstehende Resultate
zu produzieren, versteht sich von
selbst. Je höher die Fähigkeiten, die
konstruktive Kreativität und die persönlichen
Qualitätsansprüche der Mitarbeiter,
desto flexibler und wirtschaftlicher
können die Prozesse gestaltet
werden, so dass der Einzelne seine Vorstellung
professionellen Arbeitens verwirklichen
kann: “Wir haben kein Q-System
– wir sind eines!”.
Literatur
[McMenamin/Palmer 84] McMenamin,
S.M., Palmer, J.F.: Essential Systems
Analysis. Prentice Hall, 1984.
[Jackson 75] Jackson, M.A.: Principles of
Program Design. Academic Press, London,
1975.
INFORMATIK Nr. 6 (Dezember 1994) 29

Erfahrungsbericht
Der objektorientierte Softwareprozess,
d.h. die Entwicklung und Pflege von
objektorientierten Softwaresystemen,
ist für viele softwareproduzierende Organisationen
(Software Producing Unit,
SPU – Abteilungen, Stabstellen, Einzelkämpfer,
ganze Firmen, Projektorganisationen,
...) terra incognita, ein noch
unentdecktes Gebiet. Viele SPUs suchen
das Neuland noch durch abenteuerliche
Pilotprojekte zu erkunden; nur
wenige haben bereits Erfahrung mit praxisbezogener
Entwicklung und Wartung
produktiver objektorientierter Systeme.
Wir berichten hier über eine SPU, die
vor vier oder fünf Jahren erste Expeditionen
in die neue Technologiewelt ge-
30 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Ein QS-System für objektorientierte Softwareentwicklung
Simon Moser
Die Qualitätssicherung des objektorientierten Softwareprozesses stellt in einigen Bereichen spezifische
neuartige Probleme. Der vorliegende Bericht aus einer seit Herbst 93 nach ISO 9000 ff zertifizierten Organisation,
die seit mehreren Jahren mit Hilfe objektorientierter Technologie Client-Server-Applikationen
implementiert, stellt Lösungsansätze vor, welche sich in der Praxis bewährt haben.
Simon Moser, lic. phil. nat., Diplom-Informatiker
ist verantwortlicher Methodiker
für den mit der objektorientierten
Softwareentwicklung betrauten Bereich
der Bedag Informatik. Er hat in Entwicklungsprojekten
im Umfeld klassischer
strukturierter Methoden (NCR-
CASE, MSA, SA/SD) mitgewirkt. Eines
seiner Spezialgebiete ist die metrikbasierte
Aufwand- und Terminschätzung
grösserer Software-Entwicklungsvorhaben.
Seine Haupterfahrungen hat er
dabei mit der Function Point-Methode
gemacht. Im Rahmen einer Dissertation
an der Universität Bern (Prof. Nierstrasz)
erarbeitet und untersucht er analoge
Schätzmethoden für objektorientierte
Systeme und Prozesse.
Adresse: Bedag Informatik, Engehaldenstr.
18, 3012 Bern. moser@acm.org
wagt hat und heute bereits über Erfahrungen
verfügt. Die Stammtechnologie
(MVS/CICS-basierte COBOL/CSP-
Anwendungen) wird von der Mehrzahl
der ca. 120 Entwickler weiter gepflegt;
eine neue Organisationsabteilung von
10 bis 20 Entwicklern setzt sich ausschliesslich
mit der neuen Technologie
auseinander. In den ersten zwei Jahren
(1990–92) lieferten Pilotprojekte detaillierte
organisatorische und technische
Erfahrungen. Dabei wurde festgestellt,
dass – um bei der Analogie des Neulands
zu bleiben – ein Kontinent extrem
beschleunigter Evolution betreten worden
ist. Aufgrund der gemachten Erfahrungen
wurden nach ca. zwei Jahren die
ersten Systeme im Kundenauftrag nach
mittlerweile erprobten Richtlinien entwickelt.
In dieser Zeit wurde auch mit
der Entwicklung von Standardprodukten
begonnen, die dank dem Einsatz objektorientierter
Techniken innert kürzester
Zeit als Release 1 entwickelt
werden konnten. Diese neuartigen Software-Prozesstypen
werden mit Erfolg
weitergeführt. Einige Individualapplikationen
sind seit mehr als einem Jahr in
Betrieb. Die Standardprodukte haben
alle einen Releasestand 2.x erreicht und
verschiedene Abnehmer gefunden.
Neue Projekte sind bereits in Arbeit.
Technische Plattformen
Die durch die SPU entwickelten Systeme
streben durchwegs eine Client-Server-Architektur
an. Als technische Entwicklungsplattform
wird clientseitig
Enfin von EASEL, eine Implementation
von Smalltalk mit einem Oberflächen-
Entwicklungswerkzeug (Enfin/Designer)
und neuerdings einem Analysewerkzeug
(Synchronicity) eingesetzt.
Auf der Serverseite kommen verschiedene
relationale Datenbanksysteme
(Sybase, Gupta/SQLBase, ORACLE,
etc.) bzw. SQL zum Einsatz. Für serverseitige
Verarbeitungen werden sog.
stored procedures verwendet. Die
Betriebssystemplattformen sind DOS/
Windows, OS/2 und UNIX (Enfin ist
nahezu 100% portabel). Netzwerkseitig
wird mit dem Protokoll TCP/IP auf
Ethernet- oder Tokenring-Verkabelungen
gearbeitet.
Knacknüsse
Im folgenden besprechen wir eine Auswahl
von Problemen im Zusammenhang
mit der Norm ISO 9000 ff, die im
Zuge des Aufbaus und der Anwendung
eines Qualitätssicherungssystems aufgetreten
sind. Diese Auswahl ist nicht
vollständig.
Projektkontrolle: Die Norm fordert geplante
und überprüfbare Prozesse. Für
objektorientierte Softwareprozesse, die
idealerweise zyklisch ablaufen, können
jedoch jederzeit bestehende Resultate in
Frage gestellt werden. Dies macht Projekte
schwer kontrollierbar. Es wird
schwierig, präzise Aussagen über die
bereits erreichten Resultate und über
das weitere Vorgehen zu machen. Demgegenüber
steht das klassische phasenorientierte
Vorgehen, das jederzeit die
Positionierung eines konkreten Projekts

ezüglich eines Phasenschemas ermöglicht.
Prüfplanung: Die Norm fordert eine
Qualitätskontrolle nach einem bestimmten
Plan, der es ermöglicht, weitere
Prozessschritte in Abhängigkeit der
geprüften Resultate zu planen und zu
koordinieren. Wiederum steht die zyklische
Vorgehensweise dazu in einem
scheinbaren Widerspruch.
Anforderungsspezifikationen: Die
Norm fordert, dass die erstellten Produkte
dokumentierten und überprüfbaren
Anforderungsspezifikationen zu genügen
haben. Wieder steht uns das
zyklische Vorgehen, wo schnell mal dies
und jenes geändert wird, im Wege.
Rasanter Technologiewandel: Die
Norm fordert für jeden kritischen
Prozess(schritt) dokumentierte und
identifizierbare Vorgaben (Arbeitsanweisungen,
Richtlinien). Angesichts der
unstabilen Methoden- und Werkzeugsituation
im objektorientierten Umfeld,
der aber aufgrund von Kunden- und
Entwicklerbedürfnissen zumindest teilweise
nachgelebt werden muss, hinkt
die Vorgabenerstellung dem effektiven
Projekt- und Tagesgeschehen oftmals
nach.
Wissenskonzentration: Die Norm fordert
eine risikogerechte Sicherung der
erarbeiteten Resultate. Das Wissen über
die Resultate geht jedoch in der Regel
weit über das hinaus, was formal oder
halbformal dokumentiert ist. Es befindet
sich zu grossen Teilen in den Köpfen.
Gerade in technologisch neuartigen
Prozessen ist die Konzentration des
Wissens in den Köpfen einiger weniger
Entwickler stark ausgeprägt. Dies kann
beim Ausfall oder Abzug einzelner Entwickler
zu erheblichem Resultatverlust
führen.
Integration RDBMS: Die Norm fordert
insbesondere für kritische Prozessschritte
bzw. Produktteile detaillierte
Vorgaben. Eine normierte Umsetzung
der mit objektorientierter Architektur
erstellten Clientteile auf die mit relationaler
Architektur erstellten Serverteile
(und zurück) ist eine auf die Wartbarkeit
Fachbeiträge • Contributions techniques
und Leistungsfähigkeit der erstellten
Applikationen von entscheidender Bedeutung.
Diesbezügliche Vorgaben
müssen unbedingt existieren.
Konfigurationsmanagement: Die Norm
fordert eine jederzeitige Identifikation
der Produkte und Produktteile sowie der
zugehörigen Anforderungsspezifikationen.
Da ein objektorientiertes System
zu wesentlichen Teilen aus Bibliothekskomponenten
(Framework) besteht, die
zum Teil selbst in Entwicklung stehen,
verschärft sich dieses für Softwareentwicklungen
auch im “klassischen” Bereich
omnipräsente Problem.
Testen: Die Norm fordert geplante, dokumentierte
Prüfungen nach identifizierbaren
Vorgaben. Die wechselseitigen
Abhängigkeiten in Klassenhierarchien
(insbesondere unter Smalltalk mit
seinem freien Polymorphismus-Mechanismus)
sind derart, dass zum Teil unveränderte
Programmteile ein neues
Verhalten zeigen, wenn in anderen Bereichen
Änderungen vorgenommen
worden sind. Die Problematik des Wiederholtests
(Regressionstest) von bereits
getesteten Teilen auch nach kleinen
Änderungen verschärft sich, da potentiell
das ganze System davon betroffen
sein kann.
Aufwandschätzungen und Messungen:
Die Norm fordert geplante und messbare
Prozesse, insbesondere auch eine
Schätzung und Messung des Prozessaufwands.
Hier gilt es einerseits wieder
den freien zyklischen Entwicklungsansatz
(unstabile Prozessstruktur), aber
andererseits auch die neuartigen Resultatstrukturen
und die fehlende Erfahrung
mit Korrelationen zwischen
Prozess- und Resultatgrössen zu überbrücken.
Wiederverwendbarkeit: Die Norm fordert
für kritische Prozesse eine Vorgabe.
Die Wiederverwendung von Software-
Komponenten und ihre Vorbereitung im
Rahmen der Erarbeitung der Anforderungsspezifikationen
sind kritische Prozesse,
die in geordnete Bahnen gelenkt
werden müssen.
Durch den Aufbau eines QS-Systems
werden aus betrieblich-ökonomischer
Sicht Fragen aufgeworfen:
1. Die Frage nach präzisen Techniken
für Aufwandschätzungen, die als
Grundlagen für Offerten dienen können.
2. Die Fragen der dokumentierten Anforderungsspezifikationen,
die insbesondere
bei Individualapplikationen die
rechtliche Fortsetzung des Vertrags bilden
und als Referenz für die Bestimmung
von Garantieleistungen dienen.
3. Die Fragen rund um die Wiederverwendbarkeit,
welche die Qualität und
Produktivität des Softwareprozesses erheblich
beeinflussen.
Für eine betrieblich effiziente SPU lassen
sich weitere direkt relevante Themenkreise
aus den obigen ableiten,
doch soll nun auf eine Auswahl von
praktischen Lösungsmöglichkeiten eingegangen
werden.
Projektkontrolle
Zur Erreichung einer brauchbaren Projektkontrolle
haben wir versucht, das
Konzept des zyklischen Vorgehens mit
demjenigen des phasenorientierten zu
verbinden. Dazu unterscheiden wir zwischen
den Phasen im eigentlichen Sinne,
d.h. zeitlich eingrenzbaren Prozessschritten,
und den Phasenresultaten.
Das phasenorientierte Vorgehen ist linear,
insofern innerhalb einer zeitlichen
Phase nur an den zugehörigen Phasenresultaten
gearbeitet wird. Beim zyklische
Vorgehen können in jeder zeitlichen
Phase alle Phasenresultate
bearbeitet werden, was den Begriff der
Phase als Kontrollinstrument unbrauchbar
macht. Unser Ansatz ist es, in jeder
zeitlichen Phase die aktuellen und alle
noch vorausliegenden Phasenresultate
zur Bearbeitung freizugeben. Die Bearbeitung
von zurückliegenden Phasenresultaten
(z.B. die Änderung von konzeptionellen
Resultaten in der
Konstruktionsphase) ist nicht ohne weiteres
vorgesehen. Rückwirkende Änderungen
unterliegen einem formellen
Änderungswesen und daraus resultierende
Anpassungsarbeiten sind nicht im
Standardprozess (und deshalb auch
nicht im Budget) vorgesehen.
INFORMATIK Nr. 6 (Dezember 1994) 31

zeitl.
Phasen
V
K
S
Ko
Fe
E
Phasenresultate
V K S Ko Fe E
V = Vorstudie, K = Konzeption, S = Spezifikation
Ko = Konstruktion, Fe = Fertigung, E = Einführung
Abb. 1a: Zeitliche und resultatmässige
Phasen im Wasserfallmodell.
Für das Vorgehen in einer Phase P bedeutet
das:
• Es kann an relativ vielen Resultaten
gearbeitet werden. Dabei gibt es
Empfehlungen, welche Resultaterarbeitungen
zukünftiger Phasen (z.B.
eine prototyphafte Implementierung
während der Spezifikation) besonders
viele Erkenntnisse für P bringen.
• Es muss an den Resultaten von P selber
gearbeitet werden. Diese Resultate
werden nach Beendigung von P in
dem Sinne “verabschiedet”, dass sie
nach Beendigung von P im Prinzip
nicht mehr angetastet werden.
Durch die Trennung von zeitlicher und
resultatmässiger Phase und die erwähnte
Richtlinie des erlaubten Vorwärtsaber
erschwerten Zurückschauens haben
wir die Voraussetzungen für ein modifiziert
phasenorientiertes (wir nennen
es deshalb resultatorientiertes) Vorgehensmodell
der objektorientierten Softwareentwicklung
geschaffen. Das Vorgehensmodell
nennt sich BI-CASE/
OBJECT und ist primär auf die internen
Bedürfnisse der betroffenen SPU ausgerichtet.
Prüfplanung
Eine Festlegung, wann welche Resultate
einer formalen Prüfung unterzogen
werden, leitet sich aus einem resultatorientierten
Vorgehensmodell wie folgt
ab: In einer zeitlichen Phase P müssen
alle zugehörigen Phasenresultate mit
adäquaten Mitteln (Reviews und Tests)
und Vorgaben (Resultat-Checklisten,
32 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
zeitl.
Phasen
V
K
S
Ko
Fe
E
Phasenresultate
V K S Ko Fe E
Abb. 1b: Zeitliche und resultatmässige
Phasen beim rein zyklischen Vorgehen.
Testszenarien) geprüft werden. Die
vorausschauend erarbeiteten Resultate
zukünftiger Phasen sind nicht notwendigerweise
formal zu prüfen.
Für BI-CASE/OBJECT heisst das, dass
die Standard-Prüflinge einer zeitlichen
Phase genau die Phasenresultate sind.
Mit dem Standard-Prüfplan werden alle
geforderten Resultate “zur rechten Zeit”
formal geprüft. Gleichzeitig dient der
Standard-Prüfplan auch einer Definition,
was wann erarbeitet werden muss
(nicht kann). Der Inhalt von BI-CASE/
OBJECT kann dem Standard-Prüfplan
(Abb. 2) entnommen werden.
Anforderungsspezifikationen
Die Anforderungsspezifikationen an ein
System werden aus den drei Phasenresultaten
der Vorstudie, Konzeption
und Spezifikation gebildet. Diese Phasen
widerspiegeln drei Stabilitäts- und
Detaillierungsgrade der Anforderungsspezifikationen.
Sie wurden derart gewählt,
dass grundlegende Anforderungen
bereits in der Vorstudie und
detaillierte Anforderungen erst in der
Spezifikation, empfohlenerweise nach
mindestens einer Prototypentwicklung,
verabschiedet werden können und müssen.
Die Vorstudienresultate – Ziele und Datenbereiche
– sind grob formuliert und
sollten sehr stabil sein. Erweiterungen
bzw. Änderungen dieser Resultate haben
in der Regeln grosse arbeits- und
damit kostenmässige Auswirkungen.
zeitl.
Phasen
V
K
S
Ko
Fe
E
Phasenresultate
V K S Ko Fe E
= nicht empfohlene Resultatvorauserarbeitung
Abb. 1c: Zeitliche und resultatmässige
Phasen im resultatorientierten Vorgehen
Die konzeptionellen Resultate beschreiben
das System detaillierter und widerspiegeln
insbesondere die betriebliche
Essenz [McMenamin/Palmer 84] bzw.
die zugrunde liegende “Physik” der im
System auftauchenden Objekte und Abläufe.
Ein konzeptionelles bzw. essentielles
Systemelement (z.B. Kunden,
Konti, Moleküle, Magnete) existiert unabhängig
davon, ob es ein Computersystem
gibt oder nicht. Änderungen an
konzeptionellen Resultaten sind wie
diejenigen der Vorstudienresultate in
der Praxis selten. Aufgrund des grösseren
Detaillierungsgrads und damit der
grösseren Komplexität dieser Modellelemente
ist jedoch die inhaltliche Fehler-
bzw. Unvollständigkeitsrate höher
als diejenige der Vorstudienresultate,
was zu einigen Änderungen führen
kann.
Auf dem Niveau der grössten Detaillierung
befinden sich die eigentlichen
Anforderungsspezifikationen an das
EDV-System. Das sind alle Spezifikationen,
die den Systemnutzer betreffen,
beispielsweise Fenster- und Druckgutgestaltung,
Austauschformate mit
Fremdsystemen, Fenster-Ablaufdefinitionen
sowie zur Verfügung stehende
Daten und Funktionen (= Modelle). Auf
diesem Niveau entstehen naturgemäss
die häufigsten Änderungen. Nach dem
Abschluss der zeitlichen Spezifikationsphase
sind jedoch auch Detailänderungen
nur noch formal (d.h. mit Änderungsantrag,
-bewilligung, Kosten- und
Terminschätzung, ...) möglich.

V
K
S
Abb. 3: Die Anforderungsebenen Vorstudie,
Konzeption und Spezifikation mit
ihren Änderungsgeschwindigkeiten.
Rasanter Technologiewandel
Die methodische Festlegung auf Resultate,
d.h. die Definition eines resultatorientierten
Vorgehensmodells, ermöglicht
in einer Welt des permanenten
Wandels und der erdrückenden Vielfalt
von Werkzeugen, Diagramm- und Dokumentationstechniken
eine langlebige
Definition eines Vorgehensmodells.
Ein resultatorientiertes Vorgehensmodell
kann und soll natürlich durch weitere
Komponenten, z.B. Richtlinien für
Konventionen, Dokumentation und
Werkzeugeinsatz unterstützt werden.
Diese können auch relativ rasch angepasst
werden, ohne dass der grundlegende
methodische Gehalt, auf dem die
Standards basieren, geändert wird.
Im praktischen Einsatz ergibt sich durch
die “skelettartige” Definition des Vorgehensmodells
ein Nachteil: Die eher
abstrakten Beschreibungen sind nicht
ohne solides Basiswissen, Schulung,
Unterstützung und ein Minimum an
Phantasie umsetzbar.
Wissenskonzentration
In konkreten Projekten, die in der Vorstudie
mit dem Einsatz von zwei oder
drei Personen beginnen, um dann ab der
Spezifikation ein Team von ca. 5–7 Leuten
zu umfassen, ist immer ein Kern von
zwei–drei zentralen Wissensträgern
auszumachen. Trotz aller Standards bezüglich
der erarbeiteten Resultate, der
Konventionen und der Dokumentation
bleibt viel applikationsbezogenes Wissen
in den Köpfen dieses Kernteams. In
Fachbeiträge • Contributions techniques
der objektorientierten Technologie, wo
die Konzepte der realen Welt viel direkter
Einzug in die technische Lösungsarchitektur
finden, verschärft sich dieses
Problem noch. Die Idee, im Software-
Realisierungsprozess verstärkt die Systembenutzer
als Wissensträger einzusetzen,
scheitert in der Praxis häufig an
folgenden Faktoren: (1) es stehen keine
Benutzer zur Verfügung, (2) die Benutzer
kennen ihre Tätigkeiten zwar aus der
Praxis, können diese Erfahrung aber
nicht in Anforderungen an ein zukünftiges
System umsetzen, (3) die Benutzer
sind nicht in der Lage, die Anforderungen
formal, d.h. in einer Spezifikationsoder
Implementationssprache auszudrücken.
Damit bleibt in vielen Entwicklungsprozessen
die Hauptlast auf
einer kleinen Gruppe von Informatikern
konzentriert.
In unseren Vorgaben versuchen wir, diese
Tatsache zu berücksichtigen, und die
sich daraus ergebende Informatiker-
Rolle explizit zu definieren und mit spezifischen
Vorgaben zu belegen: (1) Er
hat einen 100%-Stellvertreter, (2) er
bleibt physisch zu 100% beim Projekt
über alle Phasen, (3) er hat mit unserem
Vorgehensmodell mindestens einmalige
Projekterfahrung über alle Phasen.
Integration RDBMS
Eine Problematik technischer Art ist die
Integration von objektorientierten Architekturen
(insbesondere Klassenbildung
und Vererbung) in relationale Datenbanksysteme,
die in vielen Kunden-
Infrastrukturen als Datenserver in Client-Server-Architekturen
vorgegeben
sind. Hier haben wir zu das Model-
View-Controller-Prinzip (MVC) [Goldberg
85] erweitert. Das MVC-Prinzip
teilt eine Applikation in drei Klassenschichten
auf, wovon eine (Model) die
betrieblichen Verfahren und Daten
widerspiegelt, die zweite (View) deren
statische Präsentation in Fenstern und
Druckerzeugnissen, und die dritte (Controller)
die Reaktionen des Systems auf
Benutzereingaben. Die objektorientiert
konzipierte Modellschicht haben wir
um eine zusätzliche flach strukturierte,
dem relationalen Schema entsprechende
Zugriffsschicht erweitert. Die Zu-
griffsschicht setzt Methodenaufrufe aus
dem Bereich von Persistenzleistungen
(CRUD = Create, Read, Update, Delete
von Objekten) in die relationale Sprache
SQL um und gibt sie via Kommunikationsleitung
dem RDBM-Server weiter.
Das Ergebnis (eine Tabelle von Werten)
wird in flache Objekte umgesetzt und
von den Modellklassen in strukturierte
Instanzen abgefüllt.
Diese Zugriffsschicht zusammen mit
den “primitiven” Teilen der Modellschicht
und das relationale Schema sind
aus dem sogenannten technischen Klassenmodell
(siehe Kasten) mechanisch
ableitbar. Deshalb setzen wir einen Generator
(POLAR, Persistent Object
LAyeR generator) ein.
Konfigurationsmanagement
Für das Konfigurationsmanagement, einem
“traditionellen” Problem der Informatik,
wo Resultate praktisch ohne
Klassenmodell
Das Klassenmodell in BI-CASE/OB-
JECT (in anderen Methoden, z.B. Rumbaugh/OMT,
Objektmodell genannt) ist
in drei Schichten gegliedert und wird
auch in dieser Reihenfolge entwickelt.
In der Konzeption wird ein sog. essentielles
Klassenmodell (EKM) bzw. ER-
Modell erarbeitet, das nur absolut technologiefreie
Konzepte enthält. In der
Spezifikation wird dieses EKM zum betrieblichen
Klassenmodell (BKM) erweitert,
das alle Datenstrukturen und
funktionale Elemente der Applikation
aus Benutzersicht enthält. Das BKM
wird schliesslich zum technischen Klassenmodell
(TKM) weiterentwickelt, das
auch rein implementatorische Informationen
(Surrogatschlüssel, Datenredundanz,
Indexlegungen, Einbettung ins
Framework, ...) enthält. Alle drei Klassenmodelle,
EKM, BKM und TKM werden
dynamisch geführt (physisch in einem
Dokument). Klassen aus dem
Bereich “Benutzeroberfläche” (Windows,
Forms, Controls, ...) und “Dialogsteuerung”
(Controller, ...) sind auf keiner
dieser drei Schichten. Diese Klassen
werden mit anderen Hilfsmitteln (Layoutdefinitionen,
Ablauf- und Präsentationsdiagramme)
beschrieben.
INFORMATIK Nr. 6 (Dezember 1994) 33

Aufwand kopiert und verschoben werden
können, haben wir traditionelle
Lösungen gefunden. Obwohl mit feinerer
Granularität denkbar (z.B. auf der
Basis einzelner Methoden), haben wir
als kleinstmögliche Konfigurationseinheit
die projektlokalen Arbeiten an einer
Klasse definiert. Für projektspezifische
Klassen umfasst dies folglich die ganze
Klasse, für Erweiterungen bestehender
Klassen nur die neuen Methoden. Diese
Konfigurationselemente werden nicht
im eigentlichen Sinne geplant, sondern
sie entstehen und verschwinden ad hoc.
Als formale Konfigurationselemente
werden auch die entstehenden Dokumente
oder einzelne Kapitel daraus betrachtet.
Neue Konfigurationselemente
werden mit einer Operation first in eine
Konfiguration eingefügt, mit get zum
Bearbeiten bezogen und mit put wieder
zurückgestellt. Alle Änderungen können
rückgängig gemacht werden. Diese
Operationen wurden mit dem UNIX-
Befehl sccs sowie einigen Shell-Scripts
(z.B. Umwandlung von Winword-Dokumenten
in sccs-konforme Dateien)
realisiert. Die zusammengesetzten Konfigurationen
werden auf Releasebasis
geplant. Jeder Entwicklungsrelease,
d.h. jede Konfiguration, erhält eine eigene
Verzeichnisstruktur. Während der
Entwicklung wird die aktuellste Version
des Framework verwendet. Bei der Auslieferung
eines Release wird eine volle
Kopie der Framework-Konfiguration
und der Entwicklungskonfiguration in
eine eigene Wartungskonfiguration
View
Controller
Model
Präsentation der Daten
Interaktion mit dem Benutzer
Maskenfolge
Zugriff Datenbankzugriff
SQL
relationale Datenbank
Applikationskern
Anwendung
34 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
kopiert. Während die Entwicklung der
Folgereleases auf der Entwicklungskonfiguration
weiterläuft, werden Korrekturen
in den Wartungskonfigurationen
vorgenommen. Bei jeder
Korrektur wird entschieden, ob sie auch
in der Entwicklungskonfiguration vorgenommen
wird.
Testen
Abb. 4: Technischer Systemaufbau nach BI-CASE/OBJECT.
Der Testfallentwurf von objektorientierten
Applikationen kann analog zu traditionellen
Applikationen in White Boxund
Black Box-Techniken unterteilt
werden. Die Black Box-Techniken
unterscheiden sich nicht von denjenigen
im traditionellen Umfeld. Nicht so die
White Box-Techniken: Durch den
freien Polymorphismus in Smalltalk
können neue Codesequenzen bei Änderungen
und Erweiterungen via Subclassing
in alte Sequenzen fast beliebig
eingemischt werden. Dies und der geringe
Abdeckungsgrad einzelner formal
nach White Box-Kriterien entworfener
Testfälle haben uns dazu bewogen, auf
formale White Box-Tests ganz zu verzichten
und statt dessen eine organisatorische
Einzeltestphase einzuführen, in
welcher der Programmierer selber die
Korrektheit der Programme heuristisch
verifiziert. Die Black Box-Tests werden
in den zwei Stufen Integrations- und Systemtests
durchgeführt, die sich durch
ihren jeweiligen Fokus, Funktionalität
im Integrationstest und Robustheit und
Performance im Systemtest, unterschei-
Framework
message flow
den. Die Black Box-Tests werden nicht
durch die Codeersteller selber vorgenommen.
Für die Bereitstellung der
Testdaten steht eine adäquate werkzeugmässige
Unterstützung zur Verfügung,
für Testszenarien fehlt uns hingegen
eine entsprechende Unterstützung.
Auch der Regressionstest ist leider noch
zeitraubende “Handarbeit”.
Aufwandschätzung und -messung
An Aufwandschätzungen für den gesamten
Projektaufwand ist man schon in
sehr frühen Prozessphasen interessiert.
Andererseits interessieren nach dem
Ende des Entwicklungsprozesses gewisse
Kennzahlen und Messungen zur
Erfahrungssicherung und Nachbeurteilung
von Prozess und System. In BI-
CASE/OBJECT sind vier Schätzverfahren
integriert. Das erste, die KSM (Konzeptions-
und Spezifikations-Modell)
liefert Schätzungen für die Phasen Konzeption
und Spezifikation aufgrund der
ersten Resultate einer Vorstudie. Die anschliessende
FPM (Function Point Methode)
ist eine sinngemässe Anpassung
der originalen Ideen und Definitionen
von Albrecht [Albrecht/Gaffney 83] an
die Begriffs- und Objektwelt der Konzeptionsphase.
Dies bedeutet, dass z.B.
die Rolle der “Files” von “essentiellen
Klassen” bzw. “essentiellen Entitätstypen”
übernommen werden [Moser 91].
Für diese Schätzmodelle gibt es eine
empirische Datenbasis, in der abteilungsspezifische
Erfahrungsdaten aus
4GL- und OO-Projekten gesammelt und
zu den aktuellen Schätzparametern umgerechnet
werden. Nach einem anfänglichen
(nicht massiven) Produktivitätsrückgang
beim Ersteinsatz der
objektorientierten Technologie wurde
mittlerweile eine 4GL-Produktivität erreicht
und teilweise überholt. Die Produktivität
ist als Anzahl Function Points
pro Personentag des Entwicklungsprozesses
definiert. Jeder konkrete Entwicklungsprozess
wird immer bezüglich
des durch BI-CASE/OBJECT
definierten Referenzprozesstyp über
alle Phasen normiert. Dies bedeutet,
dass in der empirischen Datenbasis immer
Äpfel mit Äpfeln verglichen werden
und nicht Äpfel mit Birnen. Es ist
beispielweise nicht dasselbe, ob man in

der Konzeption die essentielle Objektmodellierung
bis auf Attributebene oder
nur bis auf Klassen- und Assoziationsebene
getrieben hat. Die zur Normierung
verwendeten prozentualen
Verteilschlüssel der einzelnen Referenzprozessschritte
(z.B. die Phasenverteilschlüssel)
werden mit dem dritten
Schätzmodell, der PAK (Projektaufwand-Kalkulation)
geschätzt und in
einer anderen empirischen Datenbasis
nachkalkuliert. Das vierte Schätzmodell
schliesslich beschäftigt sich mit der
Prozessdynamik, d.h. mit der “erzwungenen”
Beschleunigung oder Verlangsamung
der Entwicklungsprozesse. Die
Dynamik, insbesondere die Beschleunigung
des Prozesses, kann nicht beliebig
weit getrieben werden (Stichwort: The
Mythical Man-Month). Ein beschleunigter
(aber auch ein extrem verlangsamter)
Prozess ist weniger produktiv.
Leider fehlt uns noch ein äquivalentes
Modell zur Schätzung von Aufwänden,
die durch nicht essentielle Anforderungsänderungen,
d.h. bloss anwendungsbezogene
oder technische Anforderungen
in der objektorientierten
Systemarchitektur entstehen.
Die bisherigen Erfahrungen zeigen nach
dem erwähnten ersten Rückschritt, der
auf Lernaufwand und Frameworkaufbau
im neuen technologischen Umfeld
zurückzuführen ist, stetige jährliche
Produktivitätsverbesserungen von 5–
10%. Die immer bei Projektende und
abteilungsweit jährlich bestimmte Produktivitätsrate
ist im Rahmen des QS-
Systems die zentrale Grösse, bezüglich
derer jährliche und projektlokale Ziele
gesetzt werden. Die Produktivitätsrate
steigt nicht so rasant an, wie sich der Leser
vielleicht (evtl. beeinflusst durch
marktschreierisches Inserate) vorstellt.
Der Grund dafür ist primär darin zu suchen,
dass wir die Softwareentwicklung
immer im Gesamtzyklus – von Vorstudie
bis Einführung inklusive Projektmanagement
und Qualitätssicherung – betrachten.
Die von der objektorientierten
Technologie betroffenen Teile machen
dabei nur ca. 25–35% des Gesamtprozesses
aus. Eine weitere Tendenz ist
Fachbeiträge • Contributions techniques
die Verschiebung der Phasenanteile zugunsten
der nichttechnischen Phasen,
insbesondere zugunsten der Spezifikation,
innerhalb der oft ein Prototyp entwickelt
wird.
Wiederverwendbarkeit
Die Vorteile von Wiederverwendungstechniken
sind bekannt. Viele Vordenker
der objektorientierten Technologie
[Booch 91] [Rumbaugh 91] legen die
Wiederverwendbarkeit in die technischen
Entwurfsaktivitäten, wo man sich
zu überlegen hat, wie man eine Spezifikation
am besten durch ein gegebenes
wiederzuverwendendes Framework
(Applikationsgerüst) umzusetzen hat.
Wir versuchen, bereits in der Spezifikation
vorzuspuren, indem wir uns zu jedem
spezifizierten Element (ein einzelnes
Feld, ein Fenster, ein Dialogablauf,
..) überlegen, ob es sich dabei um eine
Ausprägung eines Spezifikationstyps
handeln könnte. So ist beispielsweise
das Fenster zum Verwalten von Kunden
eine Instanz eines abstrakten Stammdatenverwaltungsfensters,
das in seinen
Grundzügen immer gleich aussieht, und
von dem sich auch gleiche Funktionen
auslösen lassen. Eine Spezifikation
nach BI-CASE/OBJECT führt also immer
zu Spezifikationstypen. Falls man
es erreicht, in einem konkreten Projekt
viele bestehende Spezifikationstypen zu
verwenden, d.h. solche, die im Framework
mit konstruierten und implementierten
Klassen umgesetzt sind, dann hat
man die entscheidende Grundlage für
eine effiziente technische Wiederverwendung
gelegt. Wiederverwendung
beginnt also bereits in der Spezifikation!
Zusammenfassung und Ausblick
Das in diesem Bericht beleuchtete Vorgehensmodell
BI-CASE/OBJECT zur
Entwicklung von objektorientierten Client-Server-Applikationen
bietet für die
Normelemente eines QS-Systems praxisgerechte
Lösungen. BI-CASE/OB-
JECT ist im Oktober 1993 im Rahmen
eines firmenweiten externen Audit
durch die Firma SQS zertifiziert worden.
Trotz dieser Erfolge bleibt dieses
Vorgehensmodell nicht stehen. Die Praxis
fordert die Integration eines repository-gestützten
CASE-Werkzeugs für
die frühen Phasen. Der bevorstehende
praktische Einsatz von Synchronicity
(EASEL) wird zu Ergänzungen von BI-
CASE/OBJECT führen. Dabei ist es ein
dringliches Bedürfnis, mit diesem Upper-CASE-Werkzeug
die bestehenden
Werkzeuge zu integrieren. Ein weiterer
sehr dringlicher und produktivitäts- und
qualitätsverbessernder Fortschritt wird
der Einsatz von Tools für Regressionstests
sein. Der Entscheid für einen
brauchbaren Werkzeugkanditaten steht
jedoch noch aus.
Für Aufwandschätzungen und -messungen
wird ferner versucht, das bestehende
Instrumentarium durch eine einheitliche
Methode abzulösen, die auch rein
technische Aufgaben und Aspekte der
Objektorientierung (z.B. Wiederverwendung
von Frameworks) berücksichtigen
kann. Dies bedeutet eine Ablösung
der Schätzmodelle KSM und FPM während
die Konzepte der PAK und DKM
aufgrund ihrer Generizität nicht in Frage
gestellt werden.
Literatur
[Albrecht/Gaffney 83] Albrecht,A.J., Gaffney,
J.E. Jr.: Software Function etc.,
IEEE TA on SW Engineering, Vol. 9,
No. 6, pp. 639-648, November 1983
[Booch 91] Booch, G.: Object-Oriented Design,
Benjamin Cummings, Redwood
City, CA, 1991
[Goldberg 85] Goldberg,A.: Smalltalk-80,
Addison-Wesley, Reading, MA, 1985
[McMenamin/Palmer 84] McMenamin,
S.M., Palmer,J.F.: Essential Systems
Analysis, Yourdon Press, N. Y., 1984
[Moser 91] Moser,S.: Metrics Manual, GfAI
AG, Berne, 1991
[Rumbaugh et al. 91] Rumbaugh,J., Blaha,M.,
Premerlani,W., Eddy,F., Lorensen,W.:
Object-Oriented Modelling
and Design, Prentice-Hall, Englewood
Cliffs, N. J., 1991
INFORMATIK Nr. 6 (Dezember 1994) 35

Die Bootstrap-Methode:
In der Softwarebranche waren Qualität
und Qualitätssicherung lange Zeit ein
Thema, das zwar in den Grossprojekten
der Militärs und Raumfahrtbehörden
seine praktische Relevanz hatte, jedoch
ausserhalb dieser Welten lediglich in
akademischen Diskussionsrunden und
diversen Fachbüchern und Fachartikeln
behandelt wurde. Inwieweit sich diese
Situation mit der wachsenden Popularität
der ISO 9000-Standards grundle-
36 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Standortbestimmung und Vorbereitung der
ISO 9001-Zertifizierung bei Softwareentwicklern
Thomas Frühauf und Ernst Lebsanft
Der Aufbau eines ISO 9001-konformen QS-Systems sollte mit einer Bestandsaufnahme beginnen. Die
methodischen Grundlagen hierfür liefert das Reifegradmodell des amerikanischen Software Engineering
Institute. Mit einer europäischen Weiterentwicklung dieses Modells kann man heute nicht nur die Prozessreife
messen, sondern auch präzise Massnahmen ableiten, die eine ISO 9001-Zertifizierung und weitergehende
Prozessverbesserungen ermöglichen.
Thomas Frühauf, Dipl. Informatiker;
Studium der Physik und Informatik in
Saarbrücken und Erlangen. In der deutschen
Computerindustrie tätig. Einführung
von Entwicklungs- und Projektmanagementmethoden,
Erprobung von
CASE-Tools sowie Konzeption und Einführung
eines IT-Controllingsystems in
Handels- und Industrieunternehmungen
in Basel. Seit 1992 selbständiger Unternehmensberater
mit Schwerpunkt Software-Qualitätsmanagement.
Dr. rer. nat. Ernst Lebsanft ist Gründer
und Geschäftsleiter der SYNLOGIC
AG, Mitbegründer und Mitglied der Geschäftsleitung
der SynSpace AG, beide
in Binningen/BL. Studium der Physik,
Mathematik und Rechtswissenschaften
und Promotion bei einem internationalen
Konsumgüterhersteller. Seit 1983
widmet er sich der betrieblichen Nutzung
avancierter Softwaretechnologien
und den Fragen des Software-Engineerings,
vor allem Software-Qualitätssicherung.
gend ändern wird, bleibt zunächst abzuwarten.
Die weite Verbreitung der ISO-
Zertifikate, die man heute in einigen anderen
Industriezweigen schon vorfindet,
zeichnet sich andererseits für die Zukunft
der Softwareindustrie ebenfalls
ab. Allerdings berichten verschiedene
Softwareunternehmen, die bereits ein
ISO 9001-Zertifikat erworben haben,
von hohen Kosten und einem langwierigen
Verfahren. Die Skepsis, die dem
Thema vielerorts noch entgegenschlägt,
ist vor diesem Hintergrund nicht verwunderlich
[Griese 93]. Eine fundierte
Auseinandersetzung mit dieser Problematik
dürfte aber je länger je mehr unerlässlich
sein; gibt es doch schon Kunden
der Softwarebranche, die ein ISO
9001-Zertifikat zur Bedingung eines
Auftrags machen.
Der Aufbau eines ISO 9001-konformen
Qualitätssicherungs-(QS-)Systems wird
zwangsläufig zu einem teuren Kraftakt,
wenn man damit sozusagen auf der grünen
Wiese beginnt und existierende Ansätze
– die in jeder Organisation in irgendwelcher
Form zu finden sind –
ausser Betracht lässt. In der Praxis bietet
sich hier eine differenzierte Vorgehensweise
an, an deren Anfang eine Standortbestimmung
steht und bei der die
bestehenden Verfahren daraufhin analysiert
werden, wie weit die Organisation
in den jeweiligen Normelementen noch
vom Ziel entfernt ist. Hierzu wurde bereits
in mehreren Fällen mit Erfolg die
Bootstrap-Methode eingesetzt. Das hier
beschriebene Verfahren ist auch dann
anwendbar, wenn der Software-Entwicklungsbereich
eines Unternehmens
nachträglich in ein bereits bestehendes
QS-System nach ISO 9001 einbezogen
werden soll.
Bootstrap und seine Herkunft
Die Bootstrap-Methode basiert auf einem
Ende der 80er-Jahre vom amerikanischen
Software Engineering Institute
(SEI) veröffentlichten Reifegradkonzept,
nach dem sich eine Software-Entwicklungsorganisation
anfänglich in einem
“unreifen” Zustand befindet und
sich sukzessive über fünf Stufen bis zu
einem Grad der Prozessbeherrschung
entwickeln kann, der etwa mit der Serienproduktion
in der Automobilindustrie
vergleichbar wäre. Jede Stufe ist gekennzeichnet
durch bestimmte Eigenschaften
der Abläufe – von “ad hoc”
über “standardisiert” bis zu “professionell”
– sowie durch typische Praktiken,
die beherrscht werden müssen, um die
nächst höhere Stufe zu erreichen [Humphrey
89].
Um für eine Organisation diesen Reifegrad
zu ermitteln, werden sogenannte
Assessments (Bewertungen auf der Basis
von Befragungen) durchgeführt, deren
Ziel aber nicht nur eine Standortbestimmung
ist, sondern auch die
Ableitung von Verbesserungsmassnah-

men für die Weiterentwicklung auf der
erwähnten Stufenleiter.
Die Bootstrap-Methode verwendet –
wie das ältere SEI-Verfahren – in den
Assessments standardisierte Fragebögen,
in denen jede Frage einem Reifegrad
zugeordnet ist. Der zur Methode
gehörende Algorithmus berechnet aus
den Wertungen der einzelnen Fragen
den Reifegrad der Organisation. Ein
weiteres Resultat ist – im Unterschied
zur SEI-Methode – ein Stärken-Schwächen-Profil,
aus dem für 17 Attribute der
Softwarequalität hervorgeht, auf welchem
Entwicklungsstand sich die Organisation
im Hinblick auf dieses Attribut
befindet [Lebsanft/Stienen 94].
Mit dem Modell der Qualitätsnorm ISO
9001 ist eine verwandte, in einigen
Punkten jedoch grundlegend unterschiedliche
Betrachtungsweise verbunden.
Während Bootstrap verschiedene
differenzierte Resultate liefert, ist das
Ergebnis eines Zertfizierungsaudits binär:
eine Organisation besitzt das geforderte
Qualitätsniveau oder sie besitzt es
nicht.
Das Ergebnis eines ISO 9001-Zertifizierungsaudits
ist binär: eine Organisation
besitzt das geforderte Qualitätsniveau
oder sie besitzt es nicht.
Bootstrap liefert differenzierte Resultate.
Die Norm ISO 9001 geht von dem Begriff
des Qualitätssystems aus, das
durch ein Qualitätshandbuch und Verfahrensanweisungen
dokumentiert ist
und sich in der täglichen Praxis des
Unternehmens widerspiegeln muss. Die
Norm ist in 20 Einzelelemente gegliedert.
Einem Normelement entspricht
üblicherweise ein Kapitel im Qualitätshandbuch.
Um die Konformität mit der
Norm zu verifizieren, wird im Zertifizierungsaudit
für jedes Normelement
geprüft, ob es angemessen dokumentiert
ist und ob in der Praxis entsprechend
vorgegangen wird. Abweichungen
werden als Schwachstellen
festgehalten. Je nach ihrer Ausprägung
Fachbeiträge • Contributions techniques
ESA PSS-05 SEI CMM ISO 9000-3 . . .
derzeit
mögliche
Auswertungen
BOOTSTRAP
Reifegrad
Beiträge
zur Methode
BOOTSTRAP
Stärken-
Schwächen-
Profil
Abb. 1: BOOTSTRAP: Herkunft und mögliche Auswertungen
kann eine Schwachstelle die Erteilung
des Zertifikats vereiteln.
Es gibt auch historische Unterschiede
zwischen ISO 9001 und Bootstrap.
Während Bootstrap ganz spezifisch auf
die Verhältnisse von Software-Entwicklungsorganisationen
ausgerichtet ist,
zielte ISO 9001 eher auf die Serienproduktion
materieller Güter, was teilweise
auch die in der Norm gebrauchten Formulierungen
beeinflusst hat. Um die
Anwendung der Norm auf andere Branchen
zu unterstützen, hat die ISO später
normergänzende Dokumente, z.B. für
QS-Systeme in Dienstleistungsunter-
ISO 9001 zielt auf die Serienproduktion
materieller Güter – Bootstrap ist ganz
spezifisch auf die Verhältnisse der Softwareentwicklung
ausgerichtet.
nehmen und in der Softwareindustrie
veröffentlicht. So gibt es seit 1991 den
Leitfaden ISO 9000-3 “Anwendung von
ISO 9001 auf die Entwicklung, Lieferung
und Wartung von Software”.
Die in diesem Leitfaden vorgeschlagene
Strukturierung des Softwareprozesses
in Lebenszyklustätigkeiten und unterstützende
oder phasenunabhängige Tätigkeiten
wurde bei der Entwicklung der
BOOTSTRAP
BOOTSTRAP
Massnahmenplan
SEI
Reifegrad
ISO 9001
Gap-
Analyse
Bootstrap-Methode ebenso berücksichtigt
wie die Phasenaufteilung des weit
verbreiteten generischen Prozessmodells
der European Space Agency
(ESA-Standard PSS-05) [ES A91].
Die Abbildung 1 zeigt die Wurzeln der
Bootstrap-Methode zusammen mit den
heute möglichen Auswertungen.
Gemeinsames Merkmal der Bootstrap-
Methode und der ISO 9001-Norm ist
die prozessorientierte Betrachtungsweise,
der die Erkenntnis zugrunde liegt,
dass eine auf die Produktion von Qualität
hin orientierte Gestaltung der Abläufe
wirtschaftlicher ist als nachträgliche
Qualitätsprüfungen an den Produkten.
Es ist klar, dass in einem Bootstrap-
Assessment gleichzeitig auch Informationen
im Hinblick auf eine mögliche
ISO-Zertifizierung anfallen. Wie aus
Abbildung 1 hervorgeht, lässt sich das
Bootstrap-Verfahren nicht nur zur gesamthaften
Beurteilung einer Software-
Entwicklungsorganisation verwenden,
sondern auch gezielt zur Erstellung
einer sog. ISO 9001-Gap-Analyse einsetzen.
Diese Gap-Analyse liefert Aussagen
zu jedem einzelnen der 20 Normelemente
sowie speziell auf das
Zertifizierungsaudit zugeschnittene
Massnahmenempfehlungen. Gleichzeitig
ist der erzielte Bootstrap-Reifegrad
INFORMATIK Nr. 6 (Dezember 1994) 37

ein Indikator für die Erfolgschance der
Zertifizierung. Liegt dieser in der Nähe
oder oberhalb der Ebene 3, so ist davon
auszugehen, dass das ISO-Zertifikat
ohne allzu grossen Zusatzaufwand erreichbar
ist.
Die Schlüsselattribute
Bootstrap kennt 17 sogenannte Schlüsselattribute,
in denen sich die für die Gestaltung
des Softwareprozesses wichtigen
Aspekte widerspiegeln. Der
Bootstrap-Algorithmus berechnet zu jedem
dieser Attribute einen Erfüllungsgrad
zwischen 0 und 100 %, indem er
die in den einzelnen Interview-Fragen
erzielten Resultate jeweils dem der Frage
zugeordneten Attribut zurechnet.
Hieraus resultiert das in Abbildung 2
dargestellte Stärken-Schwächen-Profil,
das auch die Basis für den Bootstrap-
Massnahmenplan bildet. Dieser Plan
soll der softwareentwickelnden Organisation
dazu verhelfen, den nächsten
Schritt auf der Reifeskala zu vollziehen.
Entsprechend dem zugrunde liegenden
Modell einer kontinuierlichen Weiterentwicklung
der Fähigkeiten ist dabei
vor allem auch Reihenfolge wesentlich,
d.h. es sollten die Massnahmen zuerst
100%
75%
50%
25%
0%
nur im Projektfragebogen enthalten
Einbettung
und Struktur
Qualitätssystem
Ressourcenmanagement
Prozessfunktionen
38 INFORMATIQUE No 6 (décembre 1994)
Fachbeiträge • Contributions techniques
Lebenszyklusunterstützende
durchgeführt werden, die als nächste an
der Reihe sind. Hinter diesem Prinzip
verbirgt sich die wichtige Tatsache, dass
die verschiedenen Verbesserungsmassnahmen
in der Regel aufeinander aufbauen
und es somit bestimmte Massnahmen
gibt, die auf das jeweilige
Entwicklungsstadium bezogen den
grössten Nutzen versprechen [Kuvaja et
al. 94]. Die Nichteinhaltung einer solchen
Reihenfolge verursacht hohe Kosten,
zeigt aber nicht den erwarteten
Nutzen, wie viele weniger erfolgreiche
CASE-Projekte bewiesen haben.
Der Bootstrap-Massnahmenplan verhilft
der softwareentwickelnden Organisation
zum nächsten Schritt auf der
Reifeskala.
Den beschriebenen Algorithmus zur Ermittlung
des Stärken-Schwächen-Profils
kann man so modifizieren, dass er
Informationen darüber liefert, wie weit
die untersuchte Organisation von den
Forderungen der ISO 9001-Norm entfernt
ist. Man muss dazu den Fragen des
Bootstrap-Fragebogens statt der 17
Schlüsselattribute die 20 ISO 9001-
BOOTSTRAP-Attribute: Globales Assessment
Abb. 2: Beispiel für ein Stärken-Schwächen-Profil nach Bootstrap
Funktionen
Benutzeranforderungen
Softwareanforderungen
Architektur und
Grobentwurf
Feinentwurf und
Implementierung
Modultest
Integration
Abnahme und
Übergabe
Normelemente zuordnen. Es ergibt sich
dann eine Darstellung, deren Struktur
dem Stärken-Schwächen-Profil nach
Abb. 2 entspricht, wobei die einzelnen
Balken des Diagramms grob als Erfüllungsgrade
der verschiedenen Normelemente
interpretiert werden können.
Der “zertifizierungsfähige”
Reifegrad
Natürlich ist es nicht möglich, auf der
Reifeskala einen Punkt anzugeben, der
eine Garantie für die erfolgreiche Zertifizierung
bietet. Der oben genannte Reifegrad
3 ist in diesem Sinne nur als grober
Richtwert für das Qualitätsniveau zu
verstehen, das die Norm ISO 9001 von
einem Qualitätssystem verlangt.
Es kann durchaus sein, dass das untersuchte
Qualitätssystem in gewissen
Aspekten weit über den Normforderungen
liegt, auf der anderen Seite aber wesentliche
Schwachstellen enthält, die
der Erteilung des Zertifikats im Wege
stehen. Die Ursache hierfür liegt einerseits
darin, dass die Bestandteile der
Prozessqualität aus der Bootstrap-Perspektive
nicht deckungsgleich mit den
ISO 9001-Normelementen sind. Auf der
Betrieb und Wartung
Technologiemanagement
Werkzeuge für
Prozessfunktionen
Werkzeuge für
Lebenszyklus-unabh.
Funktionen
Werkzeuge für
Lebenszyklusfunkt.

Normelement ISO 9001
1 Verantwortung der obersten Leitung
2 Qualitätssicherungssystem
3
4
5
6 Beschaffung
7 Vom Auftraggeber beigestellte Produkte
8
Identifikation und Rückverfolgbarkeit
von Produkten
9 Prozesslenkung
10
11
12
13
14 Korrekturmassnahmen
15
Handhabung, Lagerung,
Verpackung und Versand
16 Qualitätsaufzeichnungen
17
18
19
20
Vertagsüberprüfung
Designlenkung
Lenkung der Dokumente
Prüfungen
Prüfmittel
Prüfstatus
Lenkung fehlerhafter Produkte
Interne Qualitätsaudits
Schulung
Kundendienst
Statistische Methoden
normkonform + Bootstrap
normkonform
normkonform nach Modifikationen
nicht normkonform
noch nicht von Bootstrap abgedeckt
Status
Abb. 3: Beispiel: ISO 9001-Gap einer
Organisation mit Reifegrad 3,5
anderen Seite gibt es auch Organisationen,
für die sich nach Bootstrap zwar
ein Reifegrad 3, jedoch ein sehr unausgewogenes
Stärken-Schwächen-Profil
ergibt. Dies kann z.B. dann der Fall
sein, wenn die Methoden der Anforderungsanalyse,
des Systementwurfs und
der Programmierung zwar sehr gut beherrscht
sind, jedoch phasenübergrei-
Fachbeiträge • Contributions techniques
fende Tätigkeiten wie Projektmanagement
und Konfigurationsmanagement
vernachlässigt wurden. In dieser Situation
sind die Normelemente 4, 5, 8 oder
12 Kandidaten für eine Schwachstelle.
Die gleichen Verbesserungsmassnahmen,
die nach Bootstrap schon zu einem
Reifegrad von weit über 3 führten, würden
hier die ISO 9001-Zertifizierung
überhaupt erst ermöglichen.
Das Vorgehen bei der Gap-Analyse
Bei der Ermittlung des Unterschiedes
(Gap) zwischen dem Ist-Zustand und
der ISO 9001-Norm wird daher eine
Kombination aus formalem und informellem
Vorgehen angewandt. Der formale
Teil besteht aus dem ISO 9001-bezogenen
Stärken-Schwächen-Profil, das
vom modifizierten Bootstrap-Algorithmus
geliefert wird. In diesem Profil
werden alle Wertungen von weniger als
50 % der möglichen Punkte als potentielle
Schwachstellen betrachtet und daher
gesondert untersucht. Dabei gibt es
folgende Möglichkeiten:
a) Die niedrige Wertung ist darauf
zurückzuführen, dass Bootstrap in dem
entsprechenden Aspekt wesentlich
mehr verlangt als die Norm (was z.B. im
Risikomanagement der Fall ist). In einer
solchen Situation werden die auf die
entsprechenden Fragen gegebenen Antworten
noch einmal durchgegangen, um
sicherzustellen, ob sich hier nicht trotzdem
eine Schwachstelle verbirgt, die im
Hinblick auf die Zertifizierung nach einer
Verbesserungsmassnahme verlangt.
b) Die BOOTSTRAP-Anforderungen
liegen etwa auf dem Niveau der ISO-
Norm. In diesem Fall ist es wahrscheinlich,
dass die Normforderungen nicht
erfüllt sind. Das entsprechende Normelement
muss gesondert untersucht werden,
damit entsprechende Verbesserungsmassnahmen
ausgelöst werden
können.
Das Resultat dieses Verfahrens ist eine
Darstellung, die nicht nur die Erfüllungsgrade
der ISO-Normelemente an-
gibt, sondern auch Informationen darüber
liefert, ob das untersuchte QS-
System zusätzliche Bootstrap-Forderungen
erfüllt (Abb. 3). Praktische
Erfahrungen wurden damit im Rahmen
verschiedener Einsätze der Bootstrap-
Methode gesammelt, sowohl in reinen
Software-Organisationen, wo das Ziel
die Vorbereitung der ISO 9001-Zertifizierung
war, als auch in Unternehmungen
mit einem bestehenden, übergreifenden
QS-System, wo die
Softwareentwicklung verstärkt in die
Gesamtprozesse eingebunden werden
sollte.
Es hat sich gezeigt, dass sich mit dem
beschriebenen Verfahren auf effiziente
Art eine Bestimmung der Ausgangslage
für eine Zertifizierung vornehmen lässt.
Darüber hinaus weist Bootstrap aber
auch einen Weg für solche Organisationen,
die das ISO 9001-Zertifizikat nicht
als Ziel, sondern allenfalls als einen
Meilenstein am Anfang einer längerfristigen
Entwicklung des Softwareprozesses
sehen. So haben beispielsweise
bereits nach ISO zertifizierte Firmen
Bootstrap verwendet, um sich weiter zu
verbessern und die dazu adäquaten
Massnahmen präzise zu identifizieren.
Literatur
[Griese 93] J. Griese: Der Beitrag von ISO
9000 zur Software-Qualitätssicherung.
Wirtschaftsinformatik 35 (1993) 6, S.
575-585.
[Lebsanft/Stienen 94] E. Lebsanft, H. Stienen:
Effizienz- und Qualitätsverbesserung
in Softwareschmieden, Bulletin
SEV/VSE 9/1994, S. 39-44.
[Humphrey 89] W. S. Humphrey: Managing
the Software Process, Addison-Wesley,
Reading, Mass., 1989.
[ESA 91] ESA Board for Software Standardisation
and Control: ESA Software
Engineering Standards (ESA PSS 05),
Noordwijk, NL, 1991.
[Kuvaja et al. 94] Kuvaja et al.: Software
Process Assessment and Improvement -
The Bootstrap Approach, Blackwell,
Oxford, 1994.
INFORMATIK Nr. 6 (Dezember 1994) 39

Am 19. September feierte Professor
Hansjürg Mey von der
Firma Ascom AG und vom Institut
für Informatik und angewandte
Mathematik der Universität
Bern seinen 60. Geburtstag.
Am 20. Oktober fand zu seinen
Ehren ein vom Institut und von
der Firma GfAI Gruppe für
Angewandte Informatik AG
gemeinsam durchgeführtes
hochkarätiges Geburtstagskolloquium
statt, mit Beiträgen von
den Professoren Kurt Bauknecht
(Universität Zürich), Heinrich
Meyr (Technische Hochschule
Aachen), Jean-Daniel Nicoud
(EPFL) und Niklaus Wirth
(ETHZ).
Hansjürg Mey hat den grösseren
Teil seines Berufslebens ausserhalb
der Hochschule verbracht.
Über seine sehr erfolgreiche
Karriere in der Schweizer Industrie
soll an dieser Stelle nicht
berichtet werden. Ich kenne und
schätze Hansjürg Mey aufgrund
seines Wirkens an der Universität
Bern und will mich im
wesentlichen darauf beschränken,
seine ebenso erfolgreiche
Universitätskarriere und deren
Vorgeschichte kurz darzustellen
und zu kommentieren.
Ich habe von meinem Kollegen
Hansjürg Mey vieles gelernt und
wohl am meisten bei unseren
häufigen Gesprächen. Wer nach
einem Gedankenaustausch mit
ihm von dannen geht und nicht
gerade einen ganz schlechten
Tag erwischt hat, ist beeindruckt
von der Lebensfreude, der Begeisterungsfähigkeit
und dem
intellektuellen Feuerwerk, mit
denen Hansjürg Mey seine Gesprächspartner
zu faszinieren
weiss. Kontakte mit ihm, bei denen
nicht irgendwelche ganz
neue Gesichtspunkte oder unerwartete
Zusammenhänge zum
Vorschein kommen, bilden die
Ausnahme.
Zum 60. Geburtstag von
Professor Hansjürg Mey
Hansjürg Mey hat an der ETH
Zürich Elektroingenieur studiert,
mit Begeisterung und neugierigen
Kontakten zu ERME-
TH, dem ersten in der Schweiz
entwickelten Computer. Seine
Liebe zum Computer hat ihn
seither nie verlassen und auch
nicht sein Engagement für
schweizerische Wertschöpfung.
Als Hansjürg Mey seine Doktorarbeit
“Linear algebraische Behandlung
digitaler Signale und
Systeme” schrieb, arbeitete er
bereits auf einer vollen Stelle in
der Industrie. Seine Dissertation
ist somit grösstenteils in Nachtund
Wochenendarbeit entstanden.
Sie stellt eine der ersten
Anwendungen der damals neu
aufgekommenen Operatorenmethode
dar und wurde unter
anderem mit der Silbermedaille
der ETHZ ausgezeichnet.
1978 beschloss die Philosophisch-naturwissenschaftliche
Fakultät der Universität Bern,
ein Ordinariat für Informatik
einzurichten und auszuschreiben.
An die Bewerber wurden
ausserordentlich hohe Anforderungen
gestellt, denn was man
suchte war eine seltene Mischung
von Professor und Manager.
Es ging ja nicht nur um
Lehre und Forschung in Informatik,
sondern um den Aufbau
eines neuen Fachs: Informatik
sollte als Neben- und Ergänzungsfach
eingeführt werden.
Hansjürg Mey war damals als
dynamischer und erfolgreicher
Direktor bei der Hasler AG und
auch als Lehrbeauftragter an der
ETHZ schon gut bekannt, und es
war somit naheliegend, bei dieser
Stellenbesetzung an ihn zu
denken und zu versuchen, ihn zu
berufen. Aber ob er käme? Sein
damaliger Vorgesetzter bei der
Hasler AG machte sich keine
Sorgen; er war sicher, dass
Hansjürg Mey bei seiner Firma
bleiben würde. Ihm war offenbar
ein wichtiger Grundsatz in Meys
Lebensphilosophie nicht be-
40 INFORMATIQUE No 6 (décembre 1994)
Aktualitäten • Actualités
kannt: nie länger als 10 Jahre am
gleichen Ort tätig zu sein ...
Anfangs Oktober 1979 begann
Hansjürg Mey als frischgebakkener
Ordinarius und auch gerade
Direktor des Instituts für angewandte
Mathematik mit dem
Aufbau des neuen Fachs. Für ihn
war es keine Frage, dass Informatik
auch möglichst bald
Hauptfach werden sollte, und
schon nach wenigen Wochen am
neuen Ort stellte er einen entsprechenden
Antrag. Seine Dynamik
und Kreativität erfreute
die Mehrheit der Fakultätsmitglieder
und gab ihnen die Bestätigung,
richtig ausgewählt zu haben.
Ein paar anderen war er
allerdings nicht ganz geheuer, zu
wenig akademisch in ihrem
“klassischen” Sinn, möglicherweise
auch eine lästige Konkurrenz.
Mey musste nicht nur um
seine persönliche Anerkennung
kämpfen, sondern mehr noch
um die Anerkennung seines
neuen Faches. Zum Teil naiv,
zum Teil berechnend wurde die
Informatik am Anfang oft gern
als reine Hilfswissenschaft aufgefasst,
und der Computer entsprechend
als etwas betrachtet,
das man “braucht” und nicht erforscht.
Ein Professor allein
kann kein vernünftiges Nebenfach
Informatik anbieten, geschweige
denn ein Hauptfach.
Und so bestand eine Hauptherausforderung
für Mey darin, zu
zusätzlichen Professorenstellen
zu kommen. Es kann hier nicht
im Detail berichtet werden, wie
ihm dies gelungen ist, auf jeden
Fall hat er heute fünf Kollegen.
Es soll aber doch dankend erwähnt
werden, dass sich der Regierungsrat
des Kantons Bern
selbst sehr für die Einrichtung
des neuen Fachs Informatik eingesetzt
hat. 1983 wurde Informatik
Hauptfach. 1985 wurde
das Institut für angewandte Mathematik
nun zutreffender in
“Institut für Informatik und angewandte
Mathematik” umgetauft,
und im gleichen Jahr fand
der Umzug in den Verwaltungstrakt
der alten Toblerfabrik statt,
wo wesentlich grosszügigere
Raumverhältnisse zur Verfü-
gung standen. 1984 kamen auf
die Initiative von Hansjürg Mey
hin die ersten Personal Computer
an die Universität Bern und
wurden von Anfang an durch ein
Computernetz verbunden. Heute
kann man sich kaum noch vorstellen,
dass die Universität Bern
vor 10 Jahren noch weitgehend
mit Lochkarten lebte...
Hansjürg Mey ist ein höchst anregender
Dozent, sowohl in den
Vorlesungen als auch bei seinen
vielen Vorträgen. Besonders am
Herzen liegt ihm, das “Wesen”
der Informatik und ihre grundlegenden
Konzepte den Hörern
nahezubringen. Das wichtige
Thema “Computer und Gesellschaft”
geht er immer wieder
unter neuen Gesichtspunkten an,
und wenn er über die grossen
Chancen aufgrund des technischen
Fortschritts philosophiert,
nimmt er auch stets Stellung zu
den möglichen Nachteilen und
Gefahren. Den Forscher Hansjürg
Mey hat spätestens seit Beginn
seiner Universitätskarriere
vor allem das “Parallele Rechnen”
in all seinen Formen interessiert.
Er hatte sich schon bald
eine kleine, aber hoch motivierte
Forschungsgruppe aufgebaut
und mit ihr Projekte in den
Bereichen “Supercomputing”,
“massiv parallele Systeme” und
“Neuro-Informatik” erfolgreich
in Angriff genommen. Besonders
im letztgenannten Gebiet
arbeitet er auch nach seinem
1991 erfolgten Teilrücktritt von
seiner Professur und zwar immer
mehr in Zusammenarbeit
mit dem Physiologischen Institut
an der Medizinischen Fakultät.
Auch wenn hier in erster Linie
von der Hochschultätigkeit von
Hansjürg Mey die Rede ist, dürfen
seine vielen weiteren Engagements
– die nur scheinbar
“ausseruniversitär” sind – nicht
ausser Acht gelassen werden.
Als gesamtschweizerische Beispiele
sollen hier seine Mitgliedschaft
im Schweizerischen Wissenschaftsrat
sowie seine
Hauptrollen beim Aufbau der
Softwareschule Schweiz und

des Nachdiplomstudiums NDIT
angesprochen werden. Mey ist
auch Gründungsmitglied der SI.
Als kantonalbernische Beispiele
seien seine wichtigen Funktionen
beim Aufbau der Informatik
an den höheren Mittelschulen,
beim Erstellen des 3. KantonalbernischenWirtschaftsförderungsprogramms
und, in dessen
Folge, beim Aufbau des Be-
Techs und des Berner Technoparks
genannt. Hansjürg Mey
hat seine Universitätstätigkeit
und das Hochschulfach Informatik
immer als etwas verstanden,
das in ein Grösseres,
Umfassenderes eingebettet ist.
Lehre und Forschung waren für
ihn nie Selbstzweck. Und gerade
damit hat er dem neuen Fach in
einem schwierigen Umfeld viele
Wege geebnet.
Wie bereits gesagt, gehört der
Grundsatz “nicht länger als 10
Jahre am gleichen Ort” zur Lebensphilosophie
von Hansjürg
Mey. Da er aber auch sehr flexibel
ist, waren für ihn Ausnahmen
stets möglich, und für die
Informatik an der Universität
Bern hat er eine gemacht: Er ist
immerhin ganze 12 Jahre als Ordinarius
und Institutsdirektor bei
uns geblieben, und zu 20% ist er
uns immer noch treu. Nach wie
vor ist er an Lehre und Forschung
beteiligt und leitet seine
Gruppe “Paralleles Rechnen”,
die er wohl bald in “Neuro-
Informatik” umtaufen wird. Er
erwähnt zwar ganz gern 1999 als
das Jahr seines Rücktritts, aber
hoffentlich wohl deshalb, weil er
eine Schwäche für interessante
Zahlen hat. Ob Hansjürg Mey
ein “waschechter” Informatiker
sei oder nicht, darüber haben
sich schon viele Leute unterhalten.
Unbestritten ist aber, dass er
für die Informatik ausserordentlich
viel geleistet hat. Dafür dürfen
wir ihm sehr dankbar sein.
So wie ich ihn kenne, wird
Hansjürg Mey auch in Zukunft
noch viel für die Informatik tun,
und auch dafür gilt ihm schon
jetzt mein Dank. Ich wünsche
ihm dazu auch alles Gute.
Hanspeter Bieri
Tagungsbericht
Aktualitäten • Actualités
Mustererkennung 1994
Workshop der DAGM und ÖAGM in Wien
Die alljährlich stattfindenden
Tagungen der deutschen und
österreichischen Gesellschaften
für Mustererkennung DAGM
und ÖAGM sind in diesem Jahr,
wie vor 10 Jahren bereits einmal,
gemeinsam in Wien abgehalten
worden.
Zahlreiche Forscher aus dem
deutschen Sprachraum aber
auch aus der Tschechei, Frankreich
und den USA haben vom
21.–23. September in den Räumen
der Technischen Universität
Wien Erfahrungen ausgetauscht.
Die Beiträge, die
vorgetragen wurden, waren aufgeteilt
in die Themenkreise
Bildverstehen, räumliches Sehen,
Bewegung, Anwendungen
und Sprache, Neuronale Netzwerke,
Theorie und Lernen. Alle
Arbeiten erwiesen jedoch dem
übergeordneten Thema der Tagung
Erkennen und Lernen auf
die eine oder andere Art ihre Reverenz.
Die zu Beginn jedes Tages angesetzten
geladenen Vorträge setzten
mit visionärem Denken die
Ziele für die nachfolgenden Arbeiten,
die sich vor allem mit
kleinen Schritten und schwierigen
Detailfragen beschäftigten.
Der Vortrag von Y. Aloimonos
(University of Maryland) stellte
gleich zu Beginn die wichtigste
aller Fragen für die Muster-
Bruno T. Messmer
erkennungsgemeinschaft: Wie
macht es die Natur? Komplizierte
Kalkulationen und Optimierungen
von optischen Flussfeldern
sind nicht die Spezialität
von Fliegen und Bienen oder
auch höheren Geschöpfen, führte
Aloimonos aus. Die Zukunft
der Computer Vision liegt seiner
Meinung nach vor allem in der
Erarbeitung neuer qualitativer
Geometrie und weniger der
exakten metrischen Erfassung
der Umwelt durch das elektronische
Auge. In den nachfolgenden
Beiträgen wurden verschiedene
interessante und
kostengünstige Techniken zur
Bewegungsdetektion in Bildern
und zur Steuerung von Robotern
vorgeschlagen. Der nächste
Schritt in Richtung eines ganzheitlichen
Sehens stellt die
Klassifikation von Objekten in
Bildern und Bildfolgen dar. A.
Ueltschi (Universität Bern) dokumentierte
ein System, das Objekte,
die als CAD-Modelle vorliegen,
in Tiefenbildern effizient
detektiert. Eine auf Farbanalyse
basierende Detektion von
Körperteilen (Hände, Gesicht)
wurde von R. Schuster (Universität
München) beschrieben und
die Arbeit von Trobina, Leonardis
und Ade (ETH Zürich), die
sich mit der Steuerung eines
Roboterarms und der Erkennung
von greifbaren Flächen beliebiger
Objekte beschäftigt, fand
aufgrund der gelungenen Verbindung
von Theorie und Praxis
grossen Anklang und wurde mit
einem von sieben Preisen ausgezeichnet.
Ein Gebiet, mit dem sich die
Mustererkennungsgemeinschaft
in den letzten Jahren vermehrt
beschäftigt hat, ist die Erkennung
von gesprochener
Sprache. Das Projekt von H.
Aust und M. Oerder (Philips,
Aachen) beschreibt die automatische
Bearbeitung von telefonischen
Fahrplanabfragen mit
stochastischen attributierten
Grammatiken und Hidden Markov
Models. Dabei zeigte sich
vor allem, dass Menschen selten
grammatikalisch korrekte Sätze
machen und nur eine geringe
Geduldspanne für die Maschine
am anderen Ende des Telefons
aufbringen können. Eine grundsätzliche
Beobachtung, die man
an dieser Tagung machen konnte
und auf die auch Prof. Leberl
(Universität Graz) im letzten
geladenen Vortrag ausdrücklich
aufmerksam machte, ist, dass
nur die Kombination von
verschiedenen fundamentalen
Techniken letztlich zum Erfolg
führen wird. Unter anderem
wurde ein interessantes hybrides
System präsentiert, das modulare
neuronale Netzwerke über ein
semantisches Netz miteinander
verknüpft (R. Moratz, S. Posch,
G. Sagerer, Universität Bielefeld).
Alle Beiträge sind nachzulesen
im Tagungsband “Mustererkennung
1994”, erschienen im Informatik
Xpress Verlag.
INFORMATIK Nr. 6 (Dezember 1994) 41

1. Protokoll der
Generalversammlung 1993
Das Protokoll der Generalversammlung
1993 wurde in SI-Information
Nr. 41 (Dez. 1993)
veröffentlicht. Es wird durch die
Generalversammlung ohne Gegenstimme
genehmigt.
2. Jahresbericht des
Präsidenten
Der Präsident Helmut Thoma
trägt den Jahresbericht 1993/94
vor.
3. Jahresrechnung 1993
Der Kassier Roland Wettstein
legt die Jahresrechnung für das
Geschäftsjahr 1993 vor. Bilanz
und Erfolgsrechnung sowie Revisorenbericht
sind in INFOR-
MATIK•INFORMATIQUE Nr. 5
(Okt. 1994) veröffentlicht worden.
Die Rechnung schliesst mit
einem Erfolg von Fr. 7423.54 ab.
Die Jahresrechnung wird ohne
Gegenstimme genehmigt.
4. Budget 1995
Der Kassier Roland Wettstein
legt das Budget für das Geschäftsjahr
1995 vor. Im Budget
ist eine Zunahme der Mitglie-
Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
Schweizer Informatiker Gesellschaft
Société Suisse des Informaticiens
Società Svizzera degli Informatici
Swiss Informaticians Society
SI-Generalversammlung
21. Oktober 1994, Hochschule St. Gallen
Beschlussprotokoll
derzahl um 5% vorgesehen. Zusammen
mit dem ausserordentlichen
Aufwand von Fr. 11’000
für Mitgliederwerbung, Durchführung
des CEPIS Council
Meetings in Zürich und einen
Mehrwertsteuerkurs wurde ein
Defizit von ca. Fr. 15’000 budgetiert.
Das Budget wird von der
Generalversammlung ohne Gegenstimme
genehmigt.
5. Gründung neuer
Fachgruppen
Die Gründungsversammlung
der Fachgruppe Software Engineering
(SI-SE) hat am 17. Juni
1994 mit der Fachtagung “Software
Engineering beim Einsatz
von Standardsoftware” stattgefunden.
Der Vorstand der Fachgruppe:
Dr. Walter Bischofberger
(Präsident), Dorothea
Beringer, Prof. Martin Glinz, Dr.
Hans-Peter Hoidn, Dr. Horst
Lichter, François Louis Nicolet.
Die Fachgruppe wird von der
Generalversammlung einstimmig
bestätigt.
6. Décharge des Vorstands
Dem Vorstand wird von der Generalversammlung
einstimmig
Décharge erteilt.
42 INFORMATIQUE No 6 (décembre 1994)
Präsident • Président: Helmut Thoma
Sekretariat • Secrétariat: Tel. 01 371 73 42
Schwandenholzstr. 286 Fax 01 371 23 00
8046 Zürich E-mail: si@ifi.unizh.ch
7. Wahlen
Helmut Thoma wird als Präsident
mit Applaus wiedergewählt.
Dr. Georg Maier ist aus dem
Vorstand ausgetreten. An seiner
Stelle wird Frau Prof. Andrea
Back-Hock (Hochschule St.
Gallen) zur Wahl vorgeschlagen.
Der Vorstand wird in globo mit
Applaus gewählt.
Der Vorstand ab Oktober 1994:
Helmut Thoma (Präsident),
Prof. Andrea Back-Hock, Prof.
Pierre-André Bobillier (Vertreter
SISR), Prof. Isabelle Petoud,
Prof. André R. Probst, Dr. Ernst
Rothauser, Prof. Helmut Schauer,
Prof. Hans-Jörg Schek, Roland
Wettstein, Ronald Zürcher.
8. Varia
Der SI-Bildungsfonds soll in einen
SI-Förderungsfonds mit erweiterten
Zielsetzungen umgewandelt
werden. H. Thoma legt
ein Statut für den SI-Förderungsfonds
vor. Die Generalversammlung
stimmt dem neuen
Statut ohne Gegenstimme zu.
Prof. C.A. Zehnder, Präsident
des SVI/FSI und der “Projektgruppe
Zeitschrift”, dankt und
gratuliert den Präsidenten und
den Mitgliedern der Verbände SI
und WIF dafür, dass sie in ihren
Generalversammlungen 1993
die Voraussetzung geschaffen
haben für die Herausgabe der
neuen Fachzeitschrift des SVI/
FSI INFORMATIK•INFORMA-
TIQUE.
Prof. C.A. Zehnder weist auf die
gemeinsame GI-SI-Jahrestagung
vom 18. - 20. September
1995 hin. Er erklärt, dass Werbung
für diese Tagung dringend
nötig sei und bittet alle Anwesenden,
sich daran zu beteiligen.
An die Mitglieder aus der französischen
Schweiz wendet er
sich mit der Aufforderung, mit
Tagungsbeiträgen aktiv mitzuwirken.
Elektronische Medien
EZ-Info mit dem Veranstaltungskalender
des SVI/FSI ist
auch auf World Wide Web abrufbar.
Als nächster Schritt soll der
Kalender auch auf Videotex verfügbar
sein. Die Mitglieder der
Programmkomitees der Fachgruppen
werden dringend gebeten,
ihre Veranstaltungen dem
SI-Sekretariat zu melden, sobald
Titel, Datum und Ort der Veranstaltung
bekannt sind.
Annemarie Nicolet
Die SI zählt gegenwärtig 1652
Einzelmitglieder (wovon 265
Studenten) und 156 Kollektivmitglieder.
La SI compte actuellement 1652
membres individuels (dont 265
étudiants) et 156 membres collectifs.

Assemblée Générale SI
21 octobre 1994, Hochschule St. Gallen
1. Procès-verbal de
l’Assemblée générale 1993
Le Procès-verbal de l’assemblée
générale 1993, tel qu’il a été
publié dans SI-Information n o 41
(décembre 1993), est approuvé
sans opposition.
2. Rapport annuel du
Président
Le président Helmut Thoma
présente son rapport annuel
1993/94.
3. Comptes 1993
Le trésorier Roland Wettstein
présente les comptes de l’exercice
1993. Le bilan des pertes et
profits et le rapport des réviseurs
ont été publiés dans INFORMA-
TIK•INFORMATIQUE n o 5 (oct.
1994). L’exercice s’arrête avec
un bénéfice de 7423.54 francs.
Les comptes sont acceptés sans
opposition.
4. Budget 1995
Le trésorier Roland Wettstein
présente le budget pour l’exercice
1995. Le budget prévoit un
accroissement de 5% de l’effectif.
Un déficit de 15’000 francs
est budgétisé comprennant les
dépenses extraordinaires de
11’000 francs pour le recrutement,
l’organisation de la séance
du CEPIS council à Zurich et un
cours sur la TVA. Le budget est
accepté sans opposition.
5. Constitution de nouveaux
groupes spécialisés
L’assemblée constitutive du
groupe Software Engineering
(SI-SE) a eu lieu avec la conférence
“Génie logiciel dans la
mise en œuvre de logiciel standard”
le 17 juin 1994. Le comité
du groupe spécialisé se compose
ainsi: Dr. Walter Bischofberger
(président), Dorothea Beringer,
Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
Procès-verbal
Prof. Martin Glinz, Dr. Hans-
Peter Hoidn, Dr. Horst Lichter,
François Louis Nicolet. L’assemblée
générale confirme la
constitution du groupe.
6. Décharge du comité exécutif
L’assemblée générale décharge
le comité exécutif.
7. Elections
M. Georg Maier démissionne du
comité exécutif. Mme Andrea
Back-Hock, professeur à l’Ecole
des Hautes Etudes de St. Gall est
proposée comme successeur.
Les membres du comité sont
élus in globo par acclamation.
Dés octobre 1994, le nouveau
comité exécutif se compose
comme suit: Helmut Thoma
(président), Andrea Back-Hock,
Pierre-André Bobillier (délégué
SISR), Isabelle Petoud, André
R. Probst, Ernst Rothauser, Helmut
Schauer, Hans-Jörg Schek,
Roland Wettstein, Ronald Zürcher.
8. Varia
Le Fonds de formation SI est
transformé en un fonds d’encouragement
visant des buts plus
étendus. H. Thoma présente les
nouveaux statuts du Fonds d’encouragement
SI. L’assemblée
générale approuve les nouveaux
statuts sans opposition.
Le professeur C.A. Zehnder attire
l’attention à la Journée annuelle
du 18 au 20 septembre organisée
conjointement par la SI
et la GI (Gesellschaft für Informatik).
Il faut absolumentfaire
de la publicité pour cette journée.
S’adressant tout particulièrement
aux membres de la Suisse
romande il les encourage à y
participer activement avec des
exposés.
Médias électroniques
On peut maintenant consulter
l’agenda des manifestations
SVI/FSI EZ-Info aussi sur
World Wide Web. Les membres
du comité du programme des
groupes spécialisés sont priés
CHOOSE
Chairman: Prof. Oscar Nierstrasz
Correspondent: Hermann Hüni
Rechnernetze und verteilte Systeme
bieten für diverse Anwendungen
mehr Flexibilität und ein
besseres Preis-Leistungs-Verhältnis
als teure Mainframes.
Schlagwörter wie Downsizing,
Open Systems und Client-Server
sind folglich in aller Munde.
Die objektorientierte Programmierung
(OOP) nimmt für sich
in Anspruch, die Entwicklung
von wohlstrukturierter, wartbarer
Software zu erleichtern. Aus
dem Blickwinkel verteilter Systeme
ist OOP besonders interessant,
weil diese eine Verallgemeinerung
des Client-Server
Modells darstellt: Da das Innenleben
eines Objekts sauber eingekapselt
und nur durch eine
wohldefinierte Schnittstelle zugänglich
ist, sind Objekte gut
dazu geeignet, in einem verteilten
System die Einheit der Verteilung
zu bilden und Server-
d’annoncer leurs manifestations
au secrétariat de la SI dés qu’ils
en connaissent le sujet, la date et
le lieu.
Annemarie Nicolet
Special Interest Group on
Object-Oriented Systems
and Environments
Objektorientierte Programmierung
verteilter Systeme
Silvano Maffeis
Rechnernetze und verteilte Systeme bieten mehr Flexibilität und ein
besseres Preis-Leistungs-Verhältnis als teure Mainframes. Aus dem
Blickwinkel verteilter Systeme ist objektorientierte Programmierung
besonders interessant, weil diese eine Verallgemeinerung des Client-
Server Modells darstellt. Die in verteilten Anwendungen benötigte
Interprozess-Kommunikation kann in die Methodenaufrufe integriert
werden. Man spricht in diesem Zusammenhang von Object-Oriented
Distributed Programming.
Funktionen wahrzunehmen. Die
in verteilten Anwendungen benötigteInterprozess-Kommunikation
kann in die Methodenaufrufe
integriert werden. Man
spricht in diesem Zusammenhang
von Object-Oriented Distributed
Programming (OODP)
[Herbert 94, Nicol et al. 93].
CORBA
Der CORBA (Common Object
Request Broker Architecture)
Standard von OMG (Object
Management Group) [Beyer 93,
CORBA 92] verleiht OODP zur
Zeit einen starken Aufschwung.
Dieser Standard ist die verbindliche
Festlegung eines OMGkonformen
Object Request Broker
(ORB), die tragende Komponente
der Object Management
Architecture (OMA) [Soley 92].
Das Ziel der Object Manage-
INFORMATIK Nr. 6 (Dezember 1994) 43

Abb. 1: Die Objekt Management Architecture
Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
Application Objects Common Facilities
Name
Events
Life Cycle
Persistence
ment Architecture ist, die Entwicklung
von händlerunabhängigen,
offenen verteilten
Systemen mittels heute verfügbarer
Objekt-Technologie zu
ermöglichen.
Das OMA Modell besteht aus
vier Komponenten (Abb. 1): Die
Common Object Services (erste
Komponente) [COSS94] bieten
Dienstleistungen wie Nameserving,
Persistenz, Transaktionen,
Licensing und Sicherheit an. Die
Common Facilities (zweite
Komponente) sehen allgemein
einsetzbare Klassenbibliotheken
und Dienste wie E-mail, Printing,
und Compound Documents
vor. Die Anwendungs-Objekte
(dritte Komponente) und die
eben erwähnten Dienste kommunizieren
über einen RPCähnlichen
Mechanismus, der
vom ORB (vierte Komponente)
realisiert wird. Der ORB ist zudem
auch für das Auffinden und
Aktivieren von Objekten zuständig.
Der in CORBA spezifizierte
Object Request Broker kann
folglich als Laufzeitsystem der
Relationships
Externalization
Transactions
Concurrency
Compound
Documents
Object Request Broker
44 INFORMATIQUE No 6 (décembre 1994)
Security
Time
Licensing
Properties
Query
Common Object Services
Object Management Architecture
verstanden werden.
Der CORBA-Standard in seiner
jetzigen Version 1.2 ist seit Anfang
1992 verfügbar, Version 2.0
wurde auf Ende 1994 angekündigt.
Erst ein kleiner Teil der
Common Object Services wurden
bereits spezifiziert [COSS
94], die Arbeiten daran sollen
sich noch bis Ende 1996 erstrekken.
Die Standardisierung der
Common Facilities hat erst begonnen.
Ein Beispiel
CORBA Objekte werden mittels
der OMG Interface Definition
Language (IDL) spezifiziert. Ein
Dienst eines verteilten Systems,
der ein Verzeichnis von Name-
Wert-Tupeln verwaltet, könnten
wir in IDL wie in Abb. 2a gezeigt,
deklarieren.
Argumente, die vom Client zum
Server übermittelt werden, erhalten
das Attribut in. Argumente,
die vom Server zum Cli-
interface Verzeichnis {
void registriere(in string name, in string wert);
void suche(in string name, out string wert);
void lösche(in string name, out string wert);
};
Abb. 2a
E-mail Printing
Tr ading
Change
Management
Data
Interchange
ent gelangen, bekommen das
Attribut out. Das Attribut
inout kombiniert in und out.
Ein OMG-IDL-Compiler übersetzt
die obige Deklaration in
zwei Programmodule. Die Zielsprache
kann dabei C++, Smalltalk,
Lisp, C, Fortran usw. sein.
Das eine Programmodul wird
vom Client benötigt, um Operationen
auf ein Verzeichnis-Objekt
auszuüben; das andere dient
als Programmskelett, um das
Verhalten des Verzeichnis-
Dienstes zu implementieren.
Das C++ Programmfragment in
Abb. 2b demonstriert, wie ein
Verzeichnis-Objekt von einer
Client-Anwendung in Anspruch
genommen werden kann.
Fazit
OODP im Sinne von CORBA
kann dazu verhelfen, offene Anwendungen
zu realisieren und
Entwicklungszeiten zu verkürzen.
Da Schnittstelle und Implementierung
eines Objekts sauber
voneinander getrennt sind,
können Objekte selbst dann kooperieren,
wenn diese in unterschiedlichenProgrammiersprachen
implementiert und auf
unterschiedlichen Betriebssystemen
instanziert wurden. Unternehmungen
können existierende,
strategisch wichtige Systeme
in eine CORBA-Anwendung integrieren,
indem IDL-Schnittstellen
zu diesen Systemen geschaffen
werden (wrapping) und
über CORBA-Objekt-Referenzen
auf die Systeme zugegriffen
wird. Die Migration bestehender
Informationssysteme kann infolgedessen
schrittweise erfolgen
[Brodie 92].
Zur Zeit sind bereits über 440
Firmen Mitglied der OMG und
alle grösseren Software-Hersteller
haben erklärt, mit ihren Produkten
demnächst CORBAkonform
sein zu wollen. Es sind
bereits über zwei Dutzend COR-
BA-Produkte erhältlich, die aber
meist zueinander inkompatibel
sind und nicht kooperieren können.
Der CORBA-Standard an
sich weist noch einige Lücken
auf, z.B. ist die Abbildung von
CORBA-IDL auf C++ seit über
einem Jahr fällig, jedoch noch
nicht im Standard enthalten.
// Objektreferenz v an ein bestimmtes Objekt binden:
Verzeichnis *v;
v = Verzeichnis::bind(“Telefonbuch Uni Zürich”);
string nummer;
v->suche(“Silvano Maffeis”, nummer);
// falls Eintrag gefunden, dann:
cout

OODP in der Schweiz
Aus unserer Sicht besteht ein
Hauptproblem von CORBA darin,
dass das Verhalten einer Anwendung
in Bezug auf Ausfälle
nicht definiert ist. Folglich sind
die meisten der heute erhältlichen
CORBA-Produkte nicht
dazu geeignet, robuste Anwendungen
zu realisieren. Im
Rahmen eines Forschungsprojekts
der Universität Zürich wird
die CORBA-Programmierumgebung
“Electra” entwickelt, die
robuste und ausfalltolerante Anwendungen
ermöglicht [Maffeis
94]. Die Replikation von COR-
BA-Objekten, die konsistente
Behandlung von Ausfällen und
die Mehrfachkommunikation
(reliable multicast) bilden den
Kern des Projekts.
OODP-Projekte werden aber
auch an anderen Forschungsanstalten
in der Schweiz verfolgt.
Beispielsweise wird am
UBILAB der SBG im Rahmen
des Beyond-Sniff-Projekts ein
Framework für die weiträumige
Verteilung von C++-Objekten
erarbeitet, das für das kooperative
Software Engineering eingesetzt
werden soll [Bischofberger
et al. 94]. Ein Team des Bankvereins
wendet CORBA erfolgreich
an, um bestehende
Mainframe-Anwendungen mit
modernen Unix- und Windows/
NT-Applikationen zu vernetzen
[Grotehen 94]. Ein Team der
ETH Lausanne arbeitet an
GARF (Génération Automatique
d'Applications Résistantes
aux Fautes) [Garbinato et al.
94], einer Smalltalk-basierten
Programmierumgebung für ausfalltolerante
verteilte Systeme.
Mit verteilten Objekten wird
auch im Rahmen des Oberon-
Projekts experimentiert [Borchert
94]. Das “Composing Active
Objects”-Projekt der Universität
Bern [CAO 94] befasst
sich mit einem neuartigen Objektmodell,
das die Entwicklung
offener Systeme unterstützen
soll. Das Geographische Institut
der Universität Zürich arbeitet
an einem System von verteilten
Objekten zur dezentralen Ver-
Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
waltung heterogener, geographischer
Datensätze [Stephan et al.
93].
Literatur
[Beyer 93] Torsten Beyer: Objektbörse.
IX Multiuser Multitasking
Magazin, Februar 1993.
[Borchert 94] Andreas Borchert: Zur
Erweiterung von Programmiersprachen
mit Bibliotheken. Dissertation
Universität Ulm, 1994.
[Brodie 92] Michael L. Brodie: The
Promise of Distributed Computing
and the Challenges of Legacy
Information Systems, in: Proceedings
of the 10th British National
Conference on Databases.
Springer-Verlag, 1992.
[Bischofberger et al. 94] Walter Bischofberger,
Thomas Kofler,
Kai-Uwe Mätzel, Bruno Schäffer:
Computer Supported Cooperative
Software Engineering
with Beyond-Sniff. UBILAB
Technical Report 94.9.1.
http://www.ubilab.ubs.ch
[CAO 94] http://iamwww.unibe.ch/
~scg/Research/cao.html
[CORBA 92] Object Management
Group: The Common Object Request
Broker: Architecture and
Specification, Revision 1.2,
1992.
[COSS 94] Object Management
Group: Common Object Services
Specification Volume I, OMG
Document 94-1-1, 1994.
[Maffeis 94] Silvano Maffeis: A
Flexible System Design to Support
Object-Groups and Object-
Oriented Distributed Programming.
Lecture Notes in Computer
Science 791, Springer-Verlag,
1994. ftp://ftp.ifi.unizh.ch/pub/
projects/electra
[Garbinato et al. 94] Benoît Garbinato,
Rachid Guerraoui, Karim
R. Mazouni: Distributed Programming
in GARF. Lecture
Notes in Computer Science 791,
Springer-Verlag, 1994.
[Grotehen 94] Thomas Grotehen:
Evaluation: CORBA-Architektur.
Schweizerischer Bankverein,
interner Bericht, August 1994.
[Herbert 94] Andrew Herbert: Distributing
Objects, in: Distributed
Open Systems, Frances Brazier
and Dag Johansen (Eds.), IEEE
Computer Society Press, 1994.
[Nicol et al. 93] John R. Nicol, C.
Thomas Wilkes, Frank A. Manola:
Object Orientation in Heterogeneous
Distributed Computing
Systems. IEEE Computer, 26(6),
June 1993.
[Soley 92] Richard Mark Soley
(Ed.): Object Management Architecture
Guide, second edition.
OMG Document 92-11-1, 1992.
[Stephan et al. 93] Eva-Maria
Stephan, Andrej Vckovski, Felix
Bucher: Virtual Data Set – An
Approach for the Integration of
Incompatible Data. Proceedings
of the AUTOCARTO 11 Conference,
Minneapolis, 1993. ftp://
geosun.unizh.ch/pub/mint/autocarto.ps
Silvano Maffeis, lic. oec. publ., Wirtschaftsinformatiker,
ist Doktorand
am Institut für Informatik der
Universität Zürich. Seine Forschungsgebiete:
Objektorientierte
Programmierung verteilter Systeme,
Ausfalltoleranz, Gruppenkommunikation,
CORBA, Isis. Thema seiner
Dissertation: “Run-Time Support for
Object-Oriented Distributed Programming”.
Adresse : maffeis@ifi.unizh.ch, Tel.
01/ 257 43 27
Report on CHOOSE activities 93-94
CHOOSE has organised several
educational activities including
a workshop on an Esprit project:
Ithaca, held in Zürich on June
16; a summer school on Object
Oriented Software Development
in Wildegg on Sept. 19-23; and a
joint conference with DBTA on
Object Technology at Work held
in Zürich on Sept. 29-30. The
joint conference included tutorials
by internationally known experts
(Kenny Rubin, Ralph
Johnson, Klaus Dittrich, and
Werner Kuhn), a keynote speech
by Mike Brodie, experience
talks from industry, industrial
and academic poster presentations,
and a panel.
The CHOOSE General Assembly
(held during the joint conference,
on Sept. 29) elected a new
Executive Board: Prof. Oscar
Nierstrasz (chair, oscar@iam.
unibe.ch), Igor Metz (vice-chair,
metz@glue.ch), Dr. Laurent
Dami (secretary, dami@cui.
unige.ch), Dr. Bruno Schäffer
(treasurer, bsch@ubilab.ubs.ch),
Patrick Grässle (100024.2072@
CompuServe.com), Dr. Rachid
Guerraoui (guerraoui@di.epfl.
ch), and Hermann Hüni (hueni
@glue.ch).
CHOOSE has also sponsored a
number of informal gatherings
(known as “SIG Beers”) in
Berne and Zürich on Smalltalkrelated
subjects. These gather-
ings are evolving into more formal
subgroups of CHOOSE.
The next meetings of the Smalltalk
SIG Beers will be held in
Zürich on Oct. 6 at the UBILAB
(contact Marco Abderhalden,
tel. 01 334 22 05, marco. abderhalden@ska.com),
and in Berne
on Dec. 7 at Berne Technopark
(contact René Bach, tel. 031 49
51 11, bach@isbe.ch) If you
wish to start a new SIG-BEER in
your area, contact Igor Metz, tel.
031 305 03 11, metz@glue. ch.
The main upcoming events supported
by CHOOSE are:
– A conference on Open Distributed
Processing and Industry
Standards, on Monday January
30th 1995, in Berne, PTT (contact
Guy Genilloud, tel. 021 693
4657, genillou@litsun.epfl. ch).
– A 3 day seminar in February
1995 in Berne, about “Object
Technology Management, Analysis
and Library Design”, by
Bertrand Meyer, organised by
Formitt. For more information
contact René Bach, bach@isbe.
ch.
– The next CHOOSE Forum
(date and locale not yet fixed).
Last year, CHOOSE members
have published interesting contributions
in INFORMATIK. The
CHOOSE Column in INFOR-
MATIK seeks additional technical
articles about research and experience
with Object Oriented
INFORMATIK Nr. 6 (Dezember 1994) 45

Techniques. Please, contact Hermann
Hüni (hueni@glue.ch).
CHOOSE offers videos to its
members. A list figures in IN-
FORMATIK of Feb. 94. For more
information contact Patrick
Graessle, tel. 01 946 19 54,
100024.2072@CompuServe. com
1. Minutes of the 1993 General
Asembly
Accepted with no objections.
2. Annual Report
Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
Schweizer Informatiker Gesellschaft
Société Suisse des Informaticiens
Società Svizzera degli Informatici
Swiss Informaticians Society
Data Bases – Theory and Application
Vorsitzender: Prof. Klaus Dittrich
Korrespondentin: Dr. Moira Norrie
A gateway from the new group
ch.si.choose to an electronic distribution
list should be functional
in the Fall of 1994. To be added
to the list, please send e-mail
to: si-request@iam.unibe.ch.
CHOOSE now has a new home
page on the World Wide Web at:
Minutes of the General Assembly 1994
30 September 1994, 13.30-14.00, University of Zurich
In 1993/94, we had three major
events:
•Workshop on Interoperability
of DBS and DB Applications,
Fribourg, October 1993.
•Workshop on Facility Management
and OODBMS, Basel,
June 1994.
• CHOOSE/DBTA Conference
Object-Oriented Technology
at Work, University of Zurich,
September 1994.
The Workshop on Facility Management
and OODBMS was a
particular success. With more
than 50 participants, the workshop
was larger than anticipated
and we were especially pleased
that, through this workshop,
DBTA activities reached many
new people.
3. Financial Report and
Budget
The financial report and budget
(see inset) were accepted with
no objections.
4. Ratification (Décharge)
The executive committee for 93/
94 was given décharge without
objection.
5. Elections
The following persons were
elected to the executive committee:
Prof. Klaus Dittrich, University
of Zürich (President); Dr.
José Andany, UNICIBLE, Genève;
Dr. Richard Brägger, Metro,
Baar; Andreas Duppenthaler,
Byron Informatik, Basel; Dr.
Paul Eisner, ICME, Zürich; Dr.
Hanspeter Giger, SKA, Zürich;
Michel Glaubauf, Fides Informatik,
Basel; Dr. Marc Junet,
Services Industriels de Genève;
Dr. Moira Norrie, ETH Zürich;
Prof. Stefano Spaccapietra, EPF
Lausanne.
Prof Klaus Dittrich thanked
Prof. Gerhard Weikum for his
46 INFORMATIQUE No 6 (décembre 1994)
http://iamwww.unibe.ch/
CHOOSE/ It contains addresses
of the executive board, information
about object-oriented projects
and events in Switzerland,
a repository of articles published
in the CHOOSE column of IN-
FORMATIK, information about
the CHOOSE Video library, and
previous service as a member of
the executive committee.
6. Future Activities
The following DBTA supported
activities are planned for 1994/
95:
• FORMITT-Course “Conceptual
Modelling, Databases and
CASE”, Lausanne, October
17-21, 1994.
•Workshop on Groupware, Geneva,
Spring 1995.
Unter diesem Motto stand die
zehnte Jahrestagung des Forums
InformatikerInnen für Frieden
und gesellschaftliche Verantwortung,
die vom 7. bis 9 Oktober
1994 an der Universität Bremen
stattfand. Das FiFF
entstand vor zehn Jahren aus der
Sorge über die zunehmende Verflechtung
von Informationstechnik
und Rüstung und die damit
einhergehende Militarisierung
des Fachgebietes Informatik,
und mit dieser Jubiläumstagung
wollte die Vereinigung darauf
hinweisen, dass sie nun schon
zehn Jahre lang Realität und
pointers to object-oriented information
sources on the WWW.
Oscar Nierstrasz and
Hermann Hüni
• VLDB, Zurich, September 11-
15, 1995.
• GI/SI Joint Annual Conference,
Zurich, September 18-
10, 1995: Workshop “Entwurf
und Entwicklung verteilter Informationssysteme”
(jointly
with two GI-groups).
•Workshop on Building Management,
Romandie, Autumn,
1995.
I & G
Moira C. Norrie
Fachgruppe Informatik und Gesellschaf
Vorsitz: Dr. Henk Goorhuis
1984 plus 10
Realität und Utopien der Informatik
Utopien der Informatik kritisch
und konstruktiv begleitet, und
versucht, eigene Utopien zu entwickeln.
Beabsichtigt war aber
auch die Assoziation zu Orwells
Roman 1984, in dem der Autor
eine düstere Vision von einem
staatlichen Unterdrückungsapparat
auf technischer Grundlage
als utopische Warnung entwikkelt.
Über 200 TeilnehmerInnen aus
Deutschland, Österreich und der
Schweiz kamen, um sich in
Vorträgen, Arbeitsgruppen und

einer Podiumsdiskussion auseinanderzusetzen.
Fachlich bestand die Tagung aus
drei Blöcken: der Eröffnung am
Freitag Nachmittag und Abend
mit mehreren Vorträgen, den
ganztägigen Arbeitsgruppen zu
einem Dutzend verschiedener
Teilaspekten des Tagungsthemas
am Samstag, sowie der Podiumsdiskussion
und den beiden
Schlussvorträgen am Sonntag.
Daneben waren im Foyer des
Hörsaalgebäudes noch mehrere
kleine Ausstellungen und Vorführungen
aufgebaut.
Eröffnet wurde die Tagung mit
drei Kurzreferaten von Henning
Scherf (Senator für Bildung und
Wissenschaft der Stadt Bremen),
Jeff Johnson (Vertreter der
Computer Professionals for Social
Responsability CPSR, der
amerikanischen Schwesterorganistion
des FiFF) und Reinhard
Keil-Slawik (Vorsitzender
des FiFF).
Nach dem Begrüssungsreferat
von Scherf (“Wir wollen nicht
eine fertige, durchstrukturierte
neue Technologie angeboten bekommen,
sondern wir wollen sie
bei der Einführung mitbestimmen”)
stellte Johnson kurz die
Organisation und Arbeitsweise
des CPSR vor, der 1981 gegründet
wurde und heute einerseits
die öffentliche Diskussion über
gesellschaftsrelevante Belange
in der Informatik fördert, andererseits
vom Kongress als unabhängige
Fachberatung bei Informatik-Vorhaben
der Regierung
angefragt wird. Keil-Slawik
stellte anschliessend das FiFF in
Relation zum amerikanischen
Vorbild und betonte, dass man
sich nicht als Vertreter einer Extremposition
verstehe, sondern
vielmehr als Lieferant von Visionen
für die Alltagswelt.
Nach einer kurzen Pause folgte
schon der erste Höhepunkt der
Tagung: der Vortrag von Dr. Bettina
Heintz (Uni Bern) zum Thema
“Die Gesellschaft in der
Maschine”. Sie vertrat die Ansicht,
dass technische Artefakte
Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
immer auch Ausdruck sind
sozialer Strukturen, und belegte
dies anhand zweier typischer
Beispiele:
Alle Brücken zwischen New
York und Long Island hatten
eine baulich begrenzte Durchfahrtshöhe
von 2,30 Metern.
Dies war nicht etwa eine Konstruktionseigenart,
sondern das
in Stahl und Beton gegossene
Verbot für die (schwarze) Unterschicht,
Long Island zu betreten,
da sich diese Gruppe nur der
öffentlichen Busse bedienen,
und deshalb nicht auf die Insel
fahren konnte.
Das zweite Beispiel war der sogenannte
“Berliner Schlüssel”,
dessen Konstruktion den Benutzer
zwingt, die entsprechende
Türe immer wieder zu verschliessen,
wenn er durch sie
hindurchgegangen ist.
So erreicht man mit technischen
Mitteln, dass soziale Verhaltensnormen
immer und unbedingt
eingehalten werden.
Mit Helga Genrich kam anschliessend
noch ein FiFFerling
der allerersten Stunde zu Wort.
Ihr sehr persönlicher Rückblick
auf Zehn Jahre FiFF: Was haben
wir bewegt? war ein starkes Plädoyer
für das ursprüngliche Ziel
der Organisation, die Entflechtung
von Informatik und Militärisch-Industriellem
Komplex.
“Ich frage mich, ob wir als Informatiker
wirklich auf dem
Weg sind von Konstrukteuren
der Waffe Computer zu harmlosen,
fachkundigen Reisebegleitern
auf dem Computer-Superhighway”.
Beim abschliessenden Buffet
gab es dann noch viel Gelegenheit,
persönliche Kontakte und
Gespräche zu pflegen.
Der Samstag stand dann ganz im
Zeichen der zwölf Arbeitsgruppen,
von denen man sich leider
nur an einer beteiligen konnte.
Die Themen waren so vielseitig,
wie man es sich von einer Tagung
nur wünschen kann: Com-
puter und Krieg; (Un-)sicherheit
durch Informationstechnologie;
Ökologische Orientierung in der
Informatik; Neue Bundesländer
– Neue Informatik?; Risikofaktor
Mensch – Leitbild der
Medizinischen Informatik; Informatik
und Verantwortung –
Die ethischen Leitlinien der GI;
Frauenperspektiven in der Informatik
(Gibt es eine feministische
Utopie); Männer in der
Informatik; Arbeit und Technik;
Verdatung und Datenschutz in
Europa; Informationstechnische
Grundbildung; “Civic Networking”
in den USA (Community
Memory).
Die Podiumsdiskussion am
Sonntag Vormittag zum Thema
“Die berufliche Situation von InformatikerInnen
– InformatikerInnen
im Arbeitskampf”
war ein weiterer Höhepunkt dieser
Veranstaltung. Mit Elisabeth
Becker-Töpfer (Diplom-Pädagogin
bei der Gewerkschaft
Handel, Banken, Versicherungen),
Wiegand Cramer (Betriebsrat
bei DEC, Köln),
Gudrun Trautwein-Kalms (Diplom-Politologin
beim Deutschen
Gewerkschaftsbund,
Düsseldorf) und Hans-Joachim
Fuss (Kundenberater bei der
Software GmbH, Frankfurt) war
das Podium kompetent besetzt,
und unter der Moderation von
Jürgen Friedrich entstand eine
lebhafte Diskussion zwischen
dem Publikum und den Referenten.
So tauchte die Frage auf,
ob die zunehmenden Schwierigkeiten
für InformatikerInnen bei
der Jobsuche nur ein konjunkturelles
oder aber ein strukturelles
Problem seien. Flexiblere Arbeitszeitmodelle
wurden ebenso
gefordert wie die vermehrte Einbindung
kommunikativer und
sozialer Kompetenz in die Informatik-Ausbildung.
Den Abschluss der Tagung bildeten
wiederum zwei Vorträge
der Extraklasse. Prof. Dr. Alexander
Rossnagel (Uni Kassel)
sprach zum Thema “Verletzlichkeit
der Informationsgesellschaft
und rechtlicher Handlungsbedarf”
und Dr. Peter
Brödner (Institut Arbeit & Technik,
Gelsenkirchen) machte die
“Krisenreiche Beziehungskiste”
zwischen Computer und Arbeit
zum Thema.
Prof. Rossnagel stellte zuerst
fest, dass die Nutzung der Informationstechnik
die Verletzlichkeit
der Gesellschaft bisher steigert,
und das Schadenpotential
in vielen Fällen erhöht. Anschliessend
führte er aus, dass es
auch Möglichkeiten gibt, die
Verletzlichkeit zu reduzieren.
Dies bedinge aber eine stärkere
gesellschaftliche Steuerung der
Entwicklung. Schliesslich zeigte
er noch Möglichkeiten technischer,
organisatorischer und
rechtlicher Art auf, die Verletzlichkeit
zu reduzieren und entwickelte
daraus rechtspolitische
Anforderungen.
Dr. Bröder schliesslich, als letzter
Vortragender der Tagung,
ging auf die Krisenerscheinungen
bei der Gestaltung von DV-
Systemen als Arbeitsmittel ein.
Er forderte, dass die sozialen
Ursachen kritisch reflektiert
werden, wenn Systeme auf
Schwierigkeiten stossen. Diese
Methode gibt Hinweise darauf,
was zu tun ist und wie es besser
gemacht werden kann.
Die Tagung hat gezeigt, wie
wichtig das Thema Informatik
und Gesellschaft ist, und dass es
Organisationen wie das FiFF
braucht, um die öffentliche Diskussion
anzuregen und begleitend
mit Fachkenntnissen zu unterstützen.
Um die Ergebnisse der Tagung
festzuhalten und allen Interessierten
zugänglich zu machen,
erscheint im Frühjahr 1995 ein
Tagungsband (H.-J. Kreowski,
T. Risse, A. Spillner, R.E. Streibl,
K. Vosseberg (Hrsg.): Realität
und Utopien der Informatik,
agenda-Verlag Münster, 250
Seiten, ca. DM 28.-).
INFORMATIK Nr. 6 (Dezember 1994) 47

Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
Security
Präsident: Adolf Dörig
Korrespondent: Prof. Ueli Maurer
Bericht zur GV der Fachgruppe Security
10. Oktober 1994
In seinem Bericht legte der
Präsident Adolf Dörig Rechenschaft
über das erste Jahr seit der
Gründung der Fachgruppe ab
und erklärte sich mit den
erreichten Zielen zufrieden. Verschiedene
Aktivitäten und Zusammenarbeiten
mit anderen
Verbänden sind im Gang oder
für das kommende Jahr geplant.
Die einzelnen Arbeitsgruppen
berichteten über ihre Arbeit auf
verschiedenen Gebieten der Informationssicherheit.
Auch der
Arbeitsgruppenkoordinator Dr.
Bernhard Hämmerli konnte auf
ein zufriedenstellendes Jahr
zurückblicken. Wahlen standen
keine an, da der Vorstand bei der
letztjährigen Gründung für zwei
Jahre gewählt wurde.
Im Anschluss an die GV der
Fachgruppe Security fand eine
gut besuchte Fachtagung (“Lotus
Notes und Firewalls”) mit
zwei Vorträgen statt, die im folgenden
kurz zusammengefasst
sind.
Peter Hochstrasser, ein Lotus-
Notes Experte, der vor kurzem
von der SBG zur Firma INTER-
IBEX AG in Dübendorf wechselte,
hielt einen sehr kompetenten
Vortrag zum Thema Sicherheit
in Lotus Notes, in dem er
zuerst das Groupware-Produkt
und seine Einsatzmöglichkeiten
darstellte und dann auf sicherheitsspezifische
Aspekte einging.
Das fundierte Sicherheitskonzept
wurde erklärt, und die
bestehenden Mängel wurden
aufgezeigt. Letztere liegen vor
allem in der sehr komplexen Administration
und in der Tatsache,
dass die ausserhalb den USA
verfügbare Exportversion mit 40
Bit einen zu kurzen Schlüssel
für die Verschlüsselung verwendet,
der relativ einfach gebrochen
werden kann.
Das zweite Referat von Dr. Hannes
Lubich (Leiter Ausbildung
und Sicherheitsbeauftragter bei
Switch) trug den Titel Firewalls:
Eine mittelfristige Lösung zum
Anschluss firmeninterner Netze
an das Internet. Dr. Lubich
zeigte auf, dass das Internet völlig
unsicher ist, weil es gar nicht
als sicheres Netz entworfen
wurde. Während sichere Kommunikation
zwischen sich vertrauenden
Entitäten durch Anwendung
der Kryptographie
möglich ist, erfordert der ”asymmetrische”
Anschluss eines Firmennetzes
an das Internet einen
völlig neuen Lösungsansatz, um
Hackerangriffe und andere ungewollte
Ereignisse zu verhindern.
Firewall-Rechner, die auf
verschiedenen Schichten des
OSI-Modells angesiedelt sein
können, können unerlaubte von
erlaubter Kommunikation trennen.
Solche Firewalls, insbesondere
auf der Applikationsschicht,
sind aufwendig zu
realisieren und können (noch)
nicht als Produkt gekauft werden.
48 INFORMATIQUE No 6 (décembre 1994)
Ueli Maurer
swiss group for artificial intelligence and cognitive science
Chairman: Dr. Michael Wolf
Correspondent: Holger Rietmann
Rechnung vom 1. 1. 1993 - 31. 12. 1993
Aktiven
Bilanz
Passiven
Bank UBS Bern 6'566.65 Kreditor SI 6'153.28
c/o SI 7'367.05 Kapital 118'862.40
Festgeld 100'670.30 Aufwandüberschuss -4'291.53
Verrechnungssteuer 6'120.15
Bilanzsumme 120'724.15 120'724.15
Aufwand
Erfolgsrechnung
Ertrag
Allg. Vereinsaufwand 1'993.55 Mitgliederbeiträge 9'531.60
Steuern 2'611.25 Kapital-Wertschriftenertrag 4'885.75
Swiss Vision 2'335.05
Erika-Meeting 646.60
Instandhaltungssem. 4'571.53
Sem. Neuchâtel 3'000.00
Sum. School Lugano 2'000.00
Total Aufwand
15% Abgabe von
17'157.98 Total Ertrag 14'417.35
Ertragsüberschuss 92 1'550.90 Aufwandüberschuss 4'291.53
18'708.88 18'708.88
SGAICO Budget Proposal 1995
Budget Actual Budget Expected Budget
Revenues 1993[1] 1993[2] 1994[3] 1994[4] 1995
Membership Fees 12’000 9’531.60 11’000 9’000 8’500
Commercial Activities 10’000 --- 10’000 --- ---
Capital Yield 5’000 4’885.75 4’000 3’700 3’500
Total Revenues 27’000 14’417.35 25’000 12’700 12’000
Expenses
General
Taxes
8’300
---
1’993.55
2’611.25
8’100
---
2’200
500
2’500
500
Activities, Events 20’000 12’553.18 20’000 15’000[5] 15’000[6]
SGAICO 9x, Gen. Ass. 5’000 --- 5’000 --- 5’000[7]
SI Contribution[8] --- 1'550.90 --- --- ---
Total Expenses 33’300 18’708.88 33’100 17’700 23’000
Profit/Loss –6’300 –4’291.53 –8’100 –5’500 –11’000
[1] acc. to General Assembly 1992
[2] acc. to the published Profit & Loss Statement 1993
[3] acc. to General Assembly 1993
[4] Only rough estimate
[5] Deficit guaranties for AID '94, PerAc '94, NDIT seminar on neural networks
[6] Deficit guaranties for Events planned by R. Pfeifer/Univ. Zürich, R. Bach/
NDIT, T. Bernold, miscellaneous
[7] Expected net loss
[8] 15 % of profit of the preceding year

Schweizer Informatiker Gesellschaft • Société Suisse des Informaticiens
SIPAR
SI Group for
Parallel Systems
Chairman: Dr. Peter Kropf
Correspondent: Dr. Marc Aguilar
A new SIPAR WWW site for
Parallel and Distributed Computing
In an effort to promote the information
exchange and the collaboration
of Swiss research institutions
in the field of parallel and
distributed computing, the University
of Fribourg and SIPAR
recently developed a new World
Wide Web Site which is devoted
to parallel and distributed computing.
Services
This new site provides services
and opportunities to:
• present the most recent research
and development findings
on parallel and distributed
computing;
• announce upcoming events
such as conferences, workshops
and seminars;
• use a mailing list and mail-box
service (mosaic.sipar@unifr.ch)
as a discussion forum.
In order to provide an exhaustive
data base which covers the ongoing
Swiss research work in
the field of parallel and distributed
computing, individuals and
research groups are encouraged
to submit short abstracts (100
words) of internal papers or recently
published articles.
Topics
Publications can cover the following
(not exhaustive) list of
topics.
Parallel Architectures: Massive
parallel systems; real-time
systems; neural networks;
data-flow machines; cellular
automata; parallel supercomputers.
Parallel and Distributed Programming:
Parallel languages;
models; development and system
tools for parallel and distributed
systems.
Parallel Algorithms and Specification
(practical applications
of parallel systems): Process
control; data processing; distributed
data bases; image
processing.
The success of the new SIPAR
server depends naturally on the
support, the promotion and the
active use of such a system by
the Swiss community of parallel
and distributed systems. To have
a closer look at the SIPAR server
and to send us your contributions
please connect to the University
of Fribourg home page at
the URL:http://www.unifr.ch/
and select SIPAR.
Information
For further questions, suggestions
and feedback on the server
and the mail-box service please
contact {Oliver.Krone, Christian.Renevey,
Laurent.Schmutz}
@unifr.ch. For more information
about the SIPAR society,
fell free to send an e-mail to
Marc.Aguilar@unifr.ch.
Marc Aguilar
SI-
SE
Software-Engineering
Sprecher: Dr. Martin Bischofberger
Korrespondent: François Louis Nicolet
Aufruf zum Einreichen von Beiträgen
Konzepte und Architekturen für die Integration
kooperierender Anwendungen
Anlässlich der gemeinsamen Jahrestagung von GI und SI
18.-20. September 1995 in Zürich
Die Anforderungen an Softwareprodukte
werden aufgrund
zunehmender Vernetzung und
den sich daraus ergebenden
Wünschen nach Unterstützung
von kooperativem Arbeiten
immer komplexer und vielschichtiger.
Monolithische Softwaresysteme
werden diesen Anforderungen
nur schwer gerecht,
unabhängig wie hochentwickelt
die verwendete Softwarearchitektur
ist.
Deshalb baut man heute verteilte
Systeme, die aus kooperierenden
Diensten und Anwendungen
bestehen. Solche verteilten Architekturen
bieten inhärent Vorteile
in Bereichen wie dynamischer
Austauschbarkeit,
Rekonfigurierbarkeit, Skalierbarkeit
und Wiederverwendbarkeit.
Ihre Entwicklung stellt aber
hohe Anforderungen an Konzepte,
Architekturen und Infrastruktur
für Daten-, Kontrollund
Benutzungsschnittstellen-
Integration.
Anlässlich der gemeinsamen
Jahrestagung von SI und GI
1995 planen wir die Durchführung
eines halbtägigen
Fachgesprächs zum Thema
“Konzepte und Architekturen für
die Integration kooperierender
Werkzeuge”. Es sollen Ansätze
und Architekturen für verteilte
kooperative Softwaresysteme
mit Schwerpunkt auf Daten-,
Kontroll- und Benutzungsschnittstellen-Integrationdiskutiert
werden, diese kategorisiert
und deren praktische Relevanz
und Durchführbarkeit aufgezeigt
werden.
Gesucht werden konzeptionelle
Beiträge und Erfahrungsberichte.
“Extended Abstracts” oder
vollständige Versionen sollten
bis zum 13. Januar 1995 beim
Fachgesprächsleiter auf Papier
oder elektronisch (PostScript
oder RTF) eingereicht werden.
Ein “Extended Abstract” für
einen Erfahrungsbericht umfasst
2–5 Seiten. Das Einreichen
eines endgültigen Papiers ist bei
einem Erfahrungsbericht freiwillig.
Termine:
13. Januar 1995: Schlusstermin für
die Einreichung von Beiträgen
15. März 1995: Mitteilung über
Annahme oder Ablehnung
15. Mai 1995: Endgültige Fassung
des Beitrags
Fachgesprächsleiter:
Dr. Walter Bischofberger
Union Bank of Switzerland,
UBILAB, Bahnhofstrasse 45,
8021 Zürich
bischofberger@ubilab.ubs.ch
Programmkomitee:
Walter Bischofberger, SBG/UBI-
LAB, Zürich; Lutz Richter, Uni
Zürich, Zürich;Rainer Weinreich,
Uni Linz, Linz; Jürgen F.H. Winkler,
FSU Jena, Jena
Mitveranstalter:
GI Fachgruppe 2.1.1 für Software-
Engineering und SI Fachgruppe für
Software-Engineering
INFORMATIK Nr. 6 (Dezember 1994) 49

Verwaltung heterogener Systeme
Wer teilt, muss zusammenfügen
Michael Abel, Chairman der IAUG (International AIX User Group)
Der Umstieg vom Mainframe auf eine Client/Server-Architektur wird
sehr schnell zum Alptraum für den Systemadministrator. Wo bisher
eine Maschine zu verwalten war, gilt es nun eine Vielzahl von zum Teil
sogar mit unterschiedlichen Betriebssystemen ausgestatteten Computern
zu betreuen.
Beim Begriff Client/Server-
Computing (C/S) denkt man
meist an moderne Anwendungen,
verteilte Datenbanken oder
beispielsweise an die Arbeitsteilung
zwischen PC und Grossrechner.
Dass in derart komplexen
Systemumgebungen auch
Verwaltungs- und Ueberwachungsaufgaben
im “C/S-Look”
durchgeführt werden müssen,
wird oft vergessen. Vor allem für
Unix-Anwender ist der Begriff
des Client/Server-Konzeptes
mehr als ein Schlagwort der
Marketingabteilungen von DV-
Firmen. Unix besass “von Beginn
an” eingebaute C/S-Mechanismen.
So bieten beispielsweise
Daemons als Server
anderen Prozessen Dienstleistungen
an. Protokolle wie NFS
(Network File System) oder
RPC (Remote Procedure Call)
ermöglichen es, Hardware-Ressourcen
anderen Maschinen zur
Verfügung zu stellen.
Im Gegensatz zu anderen Plattformen,
die sich als Partner bei
C/S-Konzepten anbieten, sind
im Unix-Umfeld bereits seit langer
Zeit verteilte Systeme und
die sich daraus ergebenden
50 INFORMATIQUE No 6 (décembre 1994)
WIF Wirtschaftsinformatik-Fachverband
Managementprobleme bekannt.
Vergleicht man den Aufwand
des System-Managements auf
verschiedenen Plattformen,
kommt man schnell zu dem
Schluss, dass ein einzelnes System,
sei es ein Personal Computer
oder auch ein Grossrechner,
deutlich einfacher zu
betreiben ist als ein komplexes
Netz, das aus einer Vielzahl
miteinander verbundener Rechner
besteht.
Im einfachsten Fall löst man das
Problem dadurch, dass man das
klassische Host-Konzept der
Zentralisierung auf kleinere Einheiten
herunterbricht. Wo bislang
ein Mainframe mehrere 100
oder 1000 Benutzer “versorgt”
hat, wird jetzt pro Fachbereich
ein Mehrplatzsystem eingeführt,
das seinerseits einigen Benutzern
zur Verfügung steht. Funktionen
oder Systemmanagement
oder Endbenutzer-Support werden
im gleichen Masse von Gesamtunternehmen
auf einzelne
Abteilungen oder Teilbetriebe
heruntergebrochen. Konkret
bedeutet dies, dass für jedes zu
betreuende System vor Ort ein
Präsident Walter Wüst
Korrespondent: Roland Wettstein
Geschäftsstelle:
Hans-Huber-Strasse 4
Postfach 687 Telefon 01 283 45 30
8027 Zürich Telefax 01 283 45 50
System-Manager zur Verfügung
stehen muss.
In vielen Unternehmen wird
man jedoch eine komplexere
Umgebung antreffen. Neben
dem klassischen Mehrbenutzer-
Unix-System wird es auch reine
Server geben, die Ihre Dienste
im Netz Workstations, PCs oder
anderen Servern anbieten, ohne
dass der Benutzer explizit ein
Login an diesem System durchführt.
Besonders anspruchsvolle
Benutzer werden zudem mit
eigenen Workstations ausgestattet
bzw. an PCs arbeiten, die auf
Basis von TCP/IP mit dem
Unix-System verbunden sind. In
einem solchen Fall ist statt eines
einzigen Systems eine Vielzahl
zumeist unterschiedlicher Systeme
zu verwalten.
Hier macht es keinen Sinn mehr,
jedes System mit einem eigenen
Systemverwalter auszustatten.
Andererseits sollte der Benutzer
eines einzelnen Systems mit der
Verwaltung möglichst wenig zu
tun haben, sondern ausschliesslich
die angebotenen Leistungen
für seine Arbeit sinnvoll nutzen.
Aus diesen Randbedingungen
ergibt sich das Problem, dass in
der Praxis eine relativ kleine
Zahl von Spezialisten ein umfangreiches
Netzwerk aus einzelnen
Systemen betreuen muss.
Dies ist der Punkt, an dem die
Forderung formuliert wird, dass
parallel zur Einführung von
Client/Server-Strukturen für
Anwendungen auch eine entsprechende
Architektur für den
Aufgabenbereich des System-
Managements eingeführt wird.
Damit meint man in der Regel
nicht, dass zukünftig Systemverwaltungsaufgaben
als Request
eines Clients an einen Server
gesendet und dann bearbeitet
werden. Ziel ist es vielmehr, ein
Verwaltungskonzept aufzubauen,
das der verteilten Umgebung
Rechnung trägt: So wie ein zentraler
Datenbankserver den Clients
seine Dienste anbietet, soll
ein zentraler Administrator-Arbeitsplatz
alle übrigen Systeme
im Netz verwalten.
Die technische Implementierung
eines solchen Konzeptes ist
in der Praxis sehr aufwendig.
Die Probleme beginnen bereits
bei der einfachen “Übersetzung”
der meist lokalen, betriebssystemspezifischen
Befehle z.B.
zur Geräte- oder Benutzerverwaltung,
in ein netzwerkfähiges
Kommando. Dieses soll dieselbe
Aufgabe auf mehreren Systemen
durchführen, auch wenn
dort unterschiedliche Betriebssysteme
installiert sind.
Arbeitet man im Netzwerk nur
mit Unix-Systemen, ist es mit
Hilfe von Shell-Scripts möglich,
Kommandos netzwerkfähig zu
machen bzw. auch die Unterschiede
zwischen den einzelnen
Unix-Derivaten in einem gewissen
Rahmen auszugleichen. Beispielsweise
könnte ein netzwerkweites
“mache_benutzer”-
Script auf der einen Plattform
ein “useradd” (Solaris 2.x)
Kommando, auf der anderen
einen “mkuser” (AIX) Befehl
aktivieren (Abb. 1).

mkuser
Damit hat man jedoch immer
noch keine wirkliche Vereinheitlichung
geschaffen, da sich der
Administrator immer noch mit
der unterschiedlichen Benutzerführung
der verschiedenen Programme
abfinden muss.
Der Trick mit den Shell-Scripts
endet jedoch meistens an der
Stelle, wo andere Betriebssysteme
als Unix Verwendung finden.
Davon abgesehen, dass einige
Betriebssysteme keine Benutzerverwaltung
haben, gestaltet
es sich oftmals schwierig, komplexe
Kommandoprozeduren zu
definieren und diese remote zu
aktivieren.
Allerdings kann Unix, präzise
gesagt: die ursprünglich auf
Unix-Systemen implementierten
Netzwerk-Mechanismen,
auch hier als “Retter in der Not”
fungieren. Dass auf beinahe jedem
Betriebssystem eine Implementierung
des Netzwerkprotokolles
TCP/IP zur Verfügung
steht, ist heute selbstverständlich.
In den meisten Fällen erhält
man jedoch auch die auf TCP/IP
aufbauenden “Zusatzprodukte”
wie NFS, NIS oder DNS.
Mit Hilfe dieser Produkte führen
Unix-Systemmanager schon
seit Jahren erfolgreich eine zentrale
Verwaltung ihrer Netze
durch. So wird in umfangreichen
Installationen die
adduser useradd
create user
zentraler
Admin-Befehl
'mache_user'
WIF Wirtschaftsinformatik-Fachverband
net user
/ add
.....
Abb.1: Mit Hilfe von “selbstgestrickten” Prozeduren, die Verwaltungsaufgaben
in systemspezifische Befehle “übersetzen”,
kann ein Teil der Administration in C/S-Umgebungen verein-
Datei /etc/hosts, die Rechnernamen
in IP übersetzt, nicht auf
allen Systemen “von Hand” gepflegt:
Mit Hilfe von DNS (Domain
Name Service) wird ein
Rechner zum Name-Server – er
stellt anderen auf Anfrage die
Dienstleistung der Umsetzung
zwischen Name und IP-Adresse
zur Verfügung. Auf Basis der
weit verbreiteten Implementierungen
ist es heute natürlich
auch möglich, DNS und andere
zentrale Verwaltungsinformationen
in gemischten Netzen zu
realisieren – der MVS-Host als
Name-Server für ein PC-Netz ist
keine Utopie.
So bringt die Dezentralisierung,
wie sie ein ausgefeiltes C/S-
Konzept nach sich zieht, automatisch
das Problem einer netzwerkweiten
Datensicherung mit
sich. Selbst wenn in erster Linie
zentrale Server (File-Server oder
Datenbank-Server) die Speicherung
der Daten vornehmen,
wird es auf jedem System “private”
Daten irgendwelcher Art
geben. Dabei kann es sich um
einfache Texte handeln, die ein
Benutzer auf der lokalen Festplatte
seines PCs speichert oder
um die sich häufig ändernden
Konfigurationsdateien einer
UNIX-Workstation.
Implementiert man beispielsweise
eine Datensicherung nach
dem C/S-Prinzip, so ist die Auf-
gabenverteilung zwischen den
Partnern einfach zu definieren:
Der Client verfügt in erster Linie
über eine Funktion, welche die
zu sichernden Daten über das
Netzwerk an den “Backup-Server”
sendet (Abb. 2). Ergänzend
stehen Routinen zur Verfügung,
Daten auf demselben Weg zurückzuladen.
Der Server seinerseits
stellt die entsprechenden
Partnerfunktionen zur Verfügung,
bei denen die Clients ihre
Daten abliefern bzw. abholen.
Das “Back-End” des Servers ist
dann für die Verwaltung der
Datenmengen und deren Ablage
auf den zur Verfügung stehenden
Medien zuständig.
Ergänzend sollte man erwähnen,
dass die C/S-Architektur neben
der Übertragung der Daten auch
noch die Synchronisierung von
Client und Server umfassen sollte.
Im Beispiel der Datensicherung
bedeutet dies, dass sowohl
der Client als aktiver Part eine
Sicherung beginnen kann, als
auch der zentrale Server durch
eine “pull”-Operation die neuesten
Daten anfordern darf.
Wie bei jeder Form der Zentralisierung
ergeben sich die Vorteile
aus einer zentralen, netzwerkweiten
Datensicherung in erster
Linie durch eine Konzentration
der notwendigen (teuren) Hardware
an wenigen Systemen. Die
durchaus immer noch zum Aufgabenbereich
mancher Systemverwalter
gehörende Tätigkeit,
mit einem externen Bandlaufwerk
von System zu System zu
Backup-
Server
wandern oder gar vor Ort auf
Disketten zu sichern, erscheint
dagegen als reine Arbeitsbeschaffungsmassnahme.
Auch beim Beispiel der Systemüberwachung
lässt sich ein C/S-
Prinzip umsetzen. Überwacht
ein Systemverwalter ein Netz
mit verschiedenen Servern und
Workstations, wird er auf den
“interessantesten” Systemen
einen Client installieren, der
ausgewählte Parameter in bestimmten
Intervallen an einen
Server-Prozess auf dem Administrator-System
übermittelt. Dort
werden die Daten entgegengenommen,
gespeichert und ausgewertet
und stehen dem Verwalter
dann in aufbereiteter
Form und systemübergreifend
zu Verfügung.
Man kann sich den Vorteil
gegenüber der “klassischen”
Vorgehensweise, d.h. der Anmeldung
auf jedem einzelnen
Client per telnet oder rlogin und
dem Start einer lokalen Routine
deutlich vorstellen . Abgesehen
davon sind die Lizenzkosten für
die Client-Programme in der
Regel wesentlich geringer als
für Server-Module.
Wie werden nun diese C/S-Anwendungen
aus dem Bereich der
Systemadministration in der
Praxis implementiert? Wie weiter
oben beschrieben, stellen die
auf TCP/IP aufbauenden Netzwerkprodukte
bereits eine
Vielzahl von Funktionen zur
Synchronisierung und zum Da-
Daten- und
Steuerinformationen
Abb. 2: Bei einer verteilten Datensicherung werden neben den
zu sichernden Daten auch die notwendigen Steuerinformationen,
die Client und Server synchronisieren im Netzwerk übertragen.
INFORMATIK Nr. 6 (Dezember 1994) 51

Tool für
DME
Tool für
DME
DME
DCE
tentransport zur Verfügung. In
reinen Unix-Umgebungen kann
man zudem auf netzwerkfähige
Unix Kommandos wie rdump
(remote dump) für die Datensicherung,
rcp (remote copy) zum
Transfer von Dateien oder rdist
(remote distribution) für
Zwecke der Softwareverteilung
zurückgreifen.
Vor allem in heterogenen Umgebungen
wird man aber nicht darum
herumkommen, sich näher
mit den auf dem Markt befindlichen
Systemwerkzeugen zu beschäftigen,
die auch in gemischten
Umgebungen ein zentrales
Backup oder eine Softwareverteilung
ermöglichen. Es gibt bereits
heute eine Vielzahl solcher
Tools – neben Anbietern, die aus
dem Unix-Bereich stammen,
sollte man dabei vor allem die
Softwarehäuser näher ins Auge
fassen, die in den letzten Jahren
Werkzeuge für das System-
Management auf Grossrechnern
entwickelt haben und jetzt ihre
Erfahrungen mit der zentralisierten
Verwaltung auf “verteilte”,
beispielsweise Unixbasierende
Systemumgebungen
übertragen.
Auch zu erwähnen ist die OSF
(Open Software Foundation),
deren Ankündigung des auf
DCE (Distributed Computing
Environment) basierenden
52 INFORMATIQUE No 6 (décembre 1994)
WIF Wirtschaftsinformatik-Fachverband
Tool für
DME
AIX OS/2 HP-UX MVS
Abb. 3: Mit DME soll die einheitliche zentrale Verwaltung stark
heterogener Umgebungen möglich sein.
DME (Distributed Management
Environment) die Herzen aller
Administratoren hat schneller
schlagen lassen. Aufbauend auf
der plattformunabhängigen
Middleware DCE, die für viele
Umgebungen (z.B. OS/2, verschiedenen
Unix-Varianten oder
MVS) schon verfügbar ist, soll
DME dem Systemverwalter
Funktionen an die Hand geben,
heterogene Netze von einem
Arbeitsplatz aus komplett zu
administrieren und zu überwachen
(Abb. 3).
Wer solche Umgebungen schon
jetzt betreut und mit den diversen
Unterschieden der Plattformen
zu kämpfen hat, weiss, dass
dies ein “nobles”, aber nur mit
grossem Aufwand zu realisierendes
Unterfangen ist.
Heute sieht es leider noch so
aus, als würde ein funktionsfähiges
DME in der nächsten Zukunft
nicht zur Verfügung stehen
– Systemmanager müssen sich
also auf die Suche nach anderen
Lösungen machen.
(Erstveröffentlichung in UNIXopen
11/94).
Wer kennt sie nicht, die Schlagworte:
“Distributed processing;
Downsizing durch verteilte Systeme;
mit Rightsizing zur Client/Service-Architektur”?
Sind
Client/Server-Lösungen das
Mittel gegen den immer noch
herrschenden Anwendungsstau
und dem relativ neuen dezentralen
Informatik-Wildwuchs? Die
Referenten Michael Bauer und
Christian Nesslinger von der
Informatik Training GmbH, Radolfzell
mit einer langjährigen
Erfahrung im Informatik-Sektor
geben den Teilnehmern kompetente
Antworten auf diese Fragen.
Zielorientierte und wirkungsvolle
Gestaltung von Client/Server-Anwendungen
muss professionell
erfolgen. Nach dem
Seminar sollten die Kursteilnehmer
soweit sein, dass sie Methoden
und Techniken ebenso wie
die Architektur- und Wirtschaftlichkeitsüberlegungen
nicht nur
kennen, sondern auch umsetzen
können.
Der WIF bietet mit diesem
neuen Intensiv-Seminar die besten
Voraussetzungen für die
Anwendungsentwickler im Client/Server-Bereich.
Veranstaltungen
Gestaltung von Client/Server -Anwendungen
WIF - Intensiv-Seminar
Mittwoch, 7. bis Freitag, 9. Dezember 1994
im Hotel Zurzacherhof, Zurzach
Auszug aus dem Programm:
1. Tag
• Gestaltungsformen von C/S-
Anwendungen
• Einsatzgebiete von C/S
• Chancen von C/S für die Unternehmen
•5 Beispiele von C/S-Lösungen
• Kriterien, welche die Art der
C/S-Lösung bestimmen
•Fallstudie und Diskussion
2. Tag
• Gestaltung benutzergerechter
Oberflächen
• Integration mit PC und Multi-
Media
•Vorgehensweise beim Design
von C/S-Anwendungen
• Schaffung mehrfach verwendbarer
Server-Bausteine
•Fallstudie und Diskussion
3. Tag
• Anforderungen an “offene Systeme”
• Schnittstellen für Programm-
Programm-Kommunikation
• Unternehmensweiter Datenzugriff
• Gateway-Technologie und
Standard-Schnittstellen
•Tools für die Entwicklung von
C/S-Anwendungen

Betriebsbesichtigung Sihlpost
Donnerstag, 19. Januar 1995, 18.00 Uhr, Sihlpost
Die Besichtigung ist kostenlos.
Die Teilnehmerzahl ist beschränkt,
die Anmeldungen werden
in der Reihenfolge des Eingangs
berücksichtigt.
Anmeldeschluss ist Freitag, der
3. Dezember 1994. Die Anmeldung
wird bestätigt.
1. Statistische Angaben
Verlosung
1.1 Eidg. Berufsprüfung für Analytiker-Programmierer
Total
Geprüft 586
Bestanden 421
Bestanden in Prozenten 71%
Nicht bestanden 165
Beste Schlussnote 5,4
Gesamtdurchschnitt 4,1
1.2 Höhere Fachprüfung für Wirtschaftsinformatiker
Total
Geprüft 252
Bestanden 199
Bestanden in Prozenten 78%
Nicht bestanden 53
Beste Schlussnote 5,4
Gesamtdurchschnitt 4,2
WIF Wirtschaftsinformatik-Fachverband
Im Anschluss an die Besichtigung
werden die Gewinner unseres
Wettbewerbes Mitglieder
werben Mitglieder gezogen.
Höhere Prüfungen für
Wirtschaftsinformatik-Fachleute 1994
Am 29. Oktober 1994 fand in
Bern die Schlussfeier für die
Absolventen der
• eidg. Berufsprüfung für Analytiker
-Programmierer und
der
• höheren Fachprüfung für
Wirtschaftsinformatiker
statt.
Über 600 erfolgreiche Prüfungskandidaten
durften ihr hart erarbeitetes
BIGA-Diplom in Empfang
nehmen.
Der Wirtschaftsinformatik-
Fachverband (WIF) gratuliert allen
“frischgebackenen” Diplominhaber-innen!
Die nachfolgenden Zahlen zeigen
die Attraktivität der Fachprüfungen
auf. Der WIF freut
sich über den zahlreich vorhandenen
Willen, mehr als nur die
Arbeitszeit für die fachliche
Weiterbildung einzusetzen.
2. Die besten Kandidaten/Kandidatinnen
2.1 Eidg. Berufsprüfung für Analytiker-Programmierer
Name Vorname Schlussnote
Ducry André 5,4
Hofer Andreas 5,4
Schnyder Matthias 5,4
Dooley Kathrin 5,3
Fahrni Markus 5,3
Koller Daniel 5,3
Lerch Daniel 5,3
Müller Beat 5,3
Stoob Urs 5,3
Zünd Daniel Peter 5,3
Zürcher Christoph 5,3
Blaser Fritz 5,2
Canal Paul 5,2
Fuchs Stefan 5,2
Müller Andres 5,2
1.2 Höhere Fachprüfung für Wirtschaftsinformatiker
Name Vorname Schlussnote
Halonbrenner David 5,4
Looser Anton 5,3
Kruschitz Bernhard 5,2
Luginbühl Robert 5,2
Moll Alexander 5,2
Rolf Böhm, Emmerich Fuchs,
Gerhard Pacher: System-Entwicklung
in der Wirtschafts-
Informatik. 3. überarbeitete
und erweiterte Auflage 1994.
536 Seiten, Fr. 78.–, Zürich: vdf
Hochschulverlag an der ETHZ.
ISBN 3 7281 2092 8.
Die Autoren zeigen den Entstehungsvorgang
einer Applikation
detailliert auf, von der Formulierung
der Informatikstrategie bis
zur Implementierung der Programme.
Entsprechend eignet
sich der praxisorientierte Leitfaden
als Grundlage für die
Applikationsentwicklung im administrativ-kaufmännischenBereich,
aber auch als Lehrbuch.
Die Autoren, selber als Entwickler
und Ausbildner tätig, haben
Neue Bücher
sich bewusst am Profil des Wirtschaftsinformatikers
orientiert.
Das Buch richtet sich an Personen,
die in der Praxis mit
Systementwicklung beauftragt
sind, an alle Studierenden sowie
Kurs- und Seminarteilnehmer/innen
in der Wirtschaftsinformatik.
Neu in der dritten Auflage sind
die Kapitel Objektorientierte
Analyse und Objektorientiertes
Design. Das aktuelle Paradigma
der Objektorientierung hat einen
markanten Einfluss auf die Phasen
Analyse/Design und Implementierung.
Ebenso beeiflusst
die Optimierung der Geschäftsprozesse
die Systementwicklung.
INFORMATIK Nr. 6 (Dezember 1994) 53

Fachbeiträge • Contributions techniques
Gestaltung rechnergestützter intergrierter Produktionssysteme.
Arbeitspsychologische Konzepte und empirische Befunde.
Oliver Strohm 1/6
Une néo-gestion de l’informatique de l’utilisateur final ou
Micro-informatique: attention danger! Christophe Legrenzi 1/8
HERON: A computer-based tutoring system for solving
word arithmetic problems.
Alexander Kämpfer und Ruedi Stüssi 1/12
Mobile robot miniaturisation: A tool for investigation in
control algorithms.
Francesco Mondada, Edoardo Franzi and Paolo Ienne 1/17
SQL-Standards in Vergangenheit, Gegenwart und Zukunft.
Reinhold Weber 2/3
Arbeitsplatzrechner: Achtung Gefahr!
Christophe Legrenzi und François Louis Nicolet 2/11
Die Weltsicht der Informatik. Schwierigkeiten der
Modellbildung in der Informatik. Henk Goorhuis 2/17
De l’artisanat à l’industrialisation du logiciel.
Christophe Legrenzi et Thierry Declerc 3/3
Vision einer Softwaretechnologie der Zukunft.
Jürg Gutknecht 3/8
Object-oriented Analysis: Modelling Dynamic Behaviour.
Patrick Grässle 3/16
Einsatz von Standardsoftware: Management by Parameters?
Peter Mertens, Thomas Wedel und Markus Hartinger 3/20
Aus der Sicht des Anwenders: Die Praxis des Umgangs mit
CASE-Tools. Karl-Heinz Hauer 3/29
Prozesssteuerung durch wissensbasierte Systeme.
Norbert Kunde 4/3
Von der Sekundarschule zur Informatik.
Gianni Fried und Markus Estermann 5/3
Smalltalk – Ein Plädoyer für die andere Lösung.
Andreas Bär 5/8
Reverse Engineering: Sanierung bestehender Software.
Herbert Ritsch 5/15
Software-Qualitätsmanagement. Eine Einführung.
Karol Frühauf 6/3
Qualitätsmanagement in der Informationsverarbeitung
Ernest Wallmüller 6/6
54 INFORMATIQUE No 6 (décembre 1994)
Index 1994
INFORMATIK • INFORMATIQUE
1994
Risikobasiertes Qualitätsmanagement:
“Wir haben kein Q-System – wir sind eines!”.
Stefan Brantschen und Stefan Zeder 6/19
Ein QS-System für objektorientierte Softwareentwicklung
Simon Moser 6/30
Die Bootstrap-Methode: Standortbestimmung und
Vorbereitung der ISO 9001-Zertifizierung
Thomas Frühauf und Ernst Lebsanft 6/36
Objektorientierte Programmierung verteilter Systeme
Silvano Maffeis 6/43
Tagungsberichte • Comptes-rendus de conférences
Programmiersprachen und Systemarchitekturen.
Silvia Juana Ackermann 2/21
Rechtsschutz von Computerprogrammen. Das neue
Urheberrecht aus der Sicht der Informatiker.
Carl August Zehnder 2/31
Eine Informatikwoche geprägt von “Frauenpower”.
Andrea Kennel und Werner Hartmann 3/40
IGIS’94 International Workshop on Advanced Research in
Geographic Information Systems. Georg Smehil 3/41
SIS’94 Sicherheit in Informationssystemen.
Stefanie Teufel 3/42
Der programmierende Endbenutzer – Chance oder Risiko?
Michael Bauer 3/54
Ein Tag mit Grady Booch. Philippe Arm 4/22
Software-Engineering beim Einsatz von Standardsoftware.
Fachtagung SI-SE. Dorothea Beringer 4/28
European Conference on object-oriented programming
Rachid Guerraoui and Jean Vitek 5/37
Objektorientierte Technologien mit Prof. Manfred Buess.
Roland Wettstein 5/44
Mustererkennung. Workshop der DAGM und ÖAGM
Bruno T. Messmer 6/41
Buchbesprechungen • Notes de lecture
Das mechanische Denken. Ursula Kägi 1/21
Datentypen in objektorientierten Sprachen.
François Louis Nicolet 2/22

Aktualitäten • Actualités
Neugierig: Von der “SI-Information” zur “Informatik”
Carl August Zehnder 1/2
Curieux: En passant d’«SI-Information» à «Informatique»
Carl August Zehnder 1/3
Zum 60. Geburtstag von Professor Niklaus Wirth
Carl August Zehnder 1/5
50 Jahre Kommission zur Förderung der wissenschaftlichen
Forschung 1/22
Intelligent Manufacturing Systems 1/22
Zwei Informatikverbände stellen sich vor: Gespräch mit
den Präsidenten der SI, Helmut Thoma und des WIF,
Walter Wüst 3/34
Das schweizerische Datenschutzgesetz steht sein einem Jahr
in Kraft! Carl August Zehnder 3/37
ACM International Activities Meeting 4/16
ITHACA – An Integrated Toolking for Highly Advanced
Computer Applications. Oscar Nierstrasz 4/18
Nachdiplomkurs an der ETH Zürich 4/22
Prof. Kurt Bauknecht zum IFIP-Präsidenten gewählt 5/26
Schweizerische Beteiligungen an internationalen
Forschungsprojekten 5/27
Fonds national suisse de la recherche scientifique:
La réalité virtuelle au service de l’architecture 5/28
Stipendien für Forschungsaufenthalte in Berkeley 5/29
Zum 60. Geburtstag von Pror. Hansjürg Mey
Hanspeter Bieri 6/40
CEPIS News 1/23, 4/15, 5/29
IFIP News 1/23, 4/20
SVI/FSI
Schweizerischer Verband der Informatikorganisationen
Fédération suisse des organisations d’informatique
Delegiertenversammlung 1994. Kurzbericht
Assemblée des délégués 1994. Bref compte-rendu 3/44
Index 1994
SI
Schweizer Informatiker Gesellschaft
Société Suisse des Informaticiens
SI 1/24, 1/32, 2/35, 4/27, 5/31, 6/42
Ada in Swittzerland 1/25, 2/38, 5/35
CHOOSE 1/27, 3/46, 4/29, 5/37, 6/43
DBTA 3/48, 4/30, 5/39, 6/46
HypEdu 4/32
Informatik &Gesellschaft 1/30, 2/37, 6/46
Oberon 1/31, 2/38, 4/32
SAUG Swiss APL User Group 4/34
Security 2/39, 3/49, 5/40, 6/48
SGAICO 1/25, 2/36, 4/36, 5/39, 6/48
SIPAR Parallel Systems 1/30, 3/49, 4/37, 6/49
SI-SE Software Engineering 4/37, 6/49
SISR Section Romande 4/38, 5/41
WIF
Wirtschaftsinformatik-Fachverband
Brief des Präsidenten 2/26
Protokoll der 38. Generalversammlung 14.5.1993 2/27
Protokoll der ausserordentlichen GV 14.5.1993 2/28
Protokoll der ausserordentlichen GV 12.1.1994
Rechtsschutz von Computerprogrammen: Das neue
Urheberrecht aus der Sicht der Informatiker.
2/29
Carl August Zehnder 2/31
Wettbewerb: Mitglieder werben Mitglieder 3/51, 5/43
39. ordentliche Generalversammlung. Bericht 3/51
Der programmierende Endbenutzer – Chance oder Risiko?
Tagungsbericht. Michael Bauer 3/54
Informatik-Controlling. Tagungsankündigung
Objektorientierte Technologien mit Prof. Manfred Buess.
5/43
Tagungsbericht. Roland Wettstein
Verwaltung heterogener Systeme: Wer teilt, muss
5/44
zusammenfügen – Michael Abel 6/50
Höhere Prüfungen für Wirtschaftsinformatik-Fachleute 6/53
INFORMATIK Nr. 6 (Dezember 1994) 55