qualitätssicherung - wi.wu-wien.ac.atwi.wu-wien.ac.at/studium/abschnitt_2/lva_ss03/6... · juran...
TRANSCRIPT
Qualitätssicherung Seite 1
Qualitätssicherung
Gruppenmitglieder:
Sabine Kuzdas [email protected]
Michaela Pichlmayer [email protected]
Igor Testen [email protected]
Lehrveranstaltung: Vorlesung: „Analyse von Informationssystemen „
Semester: SS 2003
Lehrveranstaltungsleiterin: Dr. Madlberger
Qualitätssicherung Seite 2
Inhaltsverzeichnis
1 Qualitätssicherung..........................................................................................6
1.1 Geschichte der Qualitätssicherung ..........................................................6
1.2 Ansätze für Qualitätssicherung ................................................................7
1.2.1 Walter Shewhart Modell.................................................................7
1.2.2 Demings 14-Schritte Programm.....................................................8
1.2.3 Jurans 10-Schritte Programm......................................................11
1.2.4 Crosbys 14-Schritte Programm....................................................12
2 Capability Maturity Modell (CMM).................................................................16
2.1 Aufbau des CMM....................................................................................17
2.1.1 Initialphase (Anfangsstufe) ..........................................................18
2.1.2 Wiederholbarkeit..........................................................................19
2.1.3 Definitionslevel.............................................................................19
2.1.4 Managed Level ............................................................................19
2.1.5 Optimierung .................................................................................20
2.1.6 Key Process Areas (KPAs)..........................................................20
2.2 Implementierung des CMM ....................................................................21
3 ISO 9000-NORM ..........................................................................................22
3.1 Einführung..............................................................................................22
3.2 Implementierung.....................................................................................23
3.3 ISO 9000: Version 2000.........................................................................24
3.4 Qualitätsmanagementsystem.................................................................25
3.5 Managementverantwortung....................................................................26
3.6 Ressourcenmanagement .......................................................................26
3.7 Produkt- oder Servicerealisierung ..........................................................27
3.8 Messung, Analyse und Verbesserung....................................................27
3.8.1 ISO 9000, Verbesserungen und Aktionsplan...............................28
4 Der SPICE (15504) Standard .......................................................................29
Qualitätssicherung Seite 3
4.1 Einführung..............................................................................................29
4.2 SPICE Modell und Prozesse ..................................................................29
5 Software Inspections and Testing.................................................................33
5.1 Rollen einer Überprüfung .......................................................................34
5.2 Fagan Methode ......................................................................................35
5.3 Software Testing ....................................................................................36
5.3.1 Testplanung und Testwerkzeuge.................................................37
6 Formale Methoden und Design ....................................................................40
6.1 Software Configuration Management.....................................................40
6.2 Software Usability...................................................................................41
6.3 Formelle Verfahren.................................................................................41
7 Metrik und Problemlösung............................................................................43
7.1 Goal Question Metric Paradigma ...........................................................43
7.2 Balance Scorecard (BSC) ......................................................................44
7.3 Die Implementierung eines Metrikprogrammes......................................46
7.4 Problemlösungstechniken ......................................................................47
8 Conclusion....................................................................................................49
Abbildungsverzeichnis
Abbildung 1: Prozesstriangle des CMM............................................................16
Abbildung 2: Initialphase - Ablauf .....................................................................18
Abbildung 3: Key Process Areas ......................................................................21
Abbildung 4: Akteure einer Überprüfung...........................................................34
Abbildung 5: Ablauf Software Testing (angelehnt an O’Reg02, 81)..................38
Qualitätssicherung Seite 4
Tabellenverzeichnis
Tabelle 1: Demings 14-Schritte Programm.......................................................10
Tabelle 2: Jurans 10-Schritte Programm ..........................................................12
Tabelle 3: Crosbys 14-Schritte Modell ..............................................................14
Tabelle 4: Crosbys Reifegrade .........................................................................15
Tabelle 5: Skala für Attributbewertung..............................................................31
Qualitätssicherung Seite 5
Einleitung
In einem Zeitalter in dem ein Unternehmen sich mehr und mehr auf die Wich-
tigkeit der Kundenloyalität besinnt, ist Qualitätssicherung unerlässlich. Software
Engineering ist eine große Herausforderung, Projektmanagement, das Schät-
zen der Kosten und die rechtzeitige Fertigstellung des Projekts sind die wich-
tigsten Aspekte, die man hier beachten sollte. Dazu muss eine Organisation
wissen, wie gut ihre Einschätzungsmechanismen funktionieren bzw. um diese
zu verbessern. Ein solcher Mechanismus ist das Nützen von Software Metriken,
weiters Risikomanagement, das mögliche Risiken bei Initiation des Projekts
aufzeigt. Um die Auswirkungen eines schlecht geplanten Projekts besser zu
veranschaulichen, sei das TAURUS Projekt an der Londoner Börse kurz ange-
sprochen. Dieses wurde nie abgeschlossen, es war 11 Jahre zu spät dran und
kostete der Stadt London 800 Millionen Pfund. Die anfängliche Schätzung des
Budgets betrug 6 Millionen Pfund. Es wurde schließlich abgelehnt [vgl. Man95
in O’Reg02, 2].
Entspricht beispielsweise ein Softwareprodukt nicht den Erwartungen des Käu-
fers, wird er in Zukunft seine benötigten Güter von Konkurrenzunternehmen
beziehen. Im vorliegender Arbeit werden Ansätze beschrieben, die im Software
Engineering eingesetzt werden um die Qualität der Software zu gewährleisten.
Im folgenden Kapitel beschäftigen sich die Autoren unter anderem mit ver-
schiedenen Vordenkern in der Qualitätssicherung (siehe Kapitel 1.2). Weiters
gehen die Autoren auf verschiedene Modelle ein, wie man Qualitätssicherung
betreiben kann, so wird im Kapitel 2 auf das Capability Maturity Modell einge-
gangen, im Kapitel 3 auf die ISO 9000 Norm und Kapitel 4 beschäftigt sich mit
dem SPICE Standard. Die Verbesserung der Qualität erfordert auch, dass das
Unternehmen die neuesten Entwicklungen beobachtet und diese auch einsetzt.
Qualitätssicherung Seite 6
1 Qualitätssicherung
1.1 Geschichte der Qualitätssicherung
Im Mittelalter war der Hersteller eines Produkts für dessen Qualität verantwort-
lich. Deshalb versuchte er ein hohes Niveau an Qualität zu gewährleisten. In
der Industriellen Revolution bekam die Arbeit einen hohen Organisationsgrad
und die Arbeiter waren nur mehr für einen bestimmten Teil im Lebenszyklus
eines Produktes verantwortlich. Das Interesse eines Produzenten, sein eigenes
Produkt möglichst qualitativ zu gestalten, entfiel hier. Dies führte zur Entwick-
lung verschiedener Managementpraktiken, wie das Planen, das Organisieren,
das Implementieren und die Kontrolle. Es wurden Kontrolleure eingesetzt um
Produktivität und Qualität sichern zu können [vgl. O’Reg02, 6].
Ein modernerer Ansatz ist das „Total Quality Management“ (TQM). TQM ist ei-
ne Management Philosophie, die folgende Aspekte beinhaltet [vgl. O’Reg02, 7]:
- Bezug auf Kunden
- Verbesserung der Prozesse
- Aufbau einer „Qualitätskultur“
- Errichtung eines Analyse- und Messprogrammes innerhalb der Organisation
Zusammengefasst bezeichnet das TQM, dass alle Funktionen in einer Organi-
sation (zB. Marketing, Verkauf, Distribution) sehr hohen Standards folgen sol-
len. Qualität soll also ins Produkt miteinfließen. Dies soll mit Hilfe der Gewähr-
leistung, dass bei jedem einzelnen Schritt, den das Produkt durchläuft, die
Qualität miteinbezogen wird erreicht werden [vgl. O’Reg02, 7].
Ein weiterer Schritt stellt die Software Qualitätskontrolle dar. Diese beinhaltet
Inspektionen und Tests. Inspektionen werden üblicherweise von Experten
durchgeführt, die verschiedene Dokumente der Software analysieren, wie zB.
den Quellcode. Ziel dieser Untersuchung ist es, Fehler zu finden bzw. die Rich-
Qualitätssicherung Seite 7
tigkeit zu bestätigen, eine anerkannte Methode einer Inspektion hat Michael
Fagan entwickelt, der in der Folge noch erwähnt werden wird [vgl. O’Reg02, 7].
Das Testen von Software kann entweder in Form eines „white box Verfahrens1“
oder eines „black box Verfahrens2“ geschehen.
1.2 Ansätze für Qualitätssicherung
Im Folgenden werden verschiedene Ansätze bzw. Modelle, wie man Qualitäts-
sicherung betreiben kann, erläutert.
1.2.1 Walter Shewhart Modell
Das Walter Shewart Modell (auch PDCA-Modell) beinhaltet 4 Schritte, die dafür
benutzt werden, einen Prozess kontinuierlich zu verbessern. Die 4 Schritte sind
[vgl. O’Reg02, 9]:
1. Plan: Dieser Schritt zeigt eine Verbesserungsmöglichkeit auf und beschreibt
das Problem bzw. den Prozess, der behandelt werden soll.
2. Do: Hier wird der verbesserte Prozess ausgeführt und dem Plan (Schritt 1)
gefolgt. Dieser Schritt kann auch eine Art „Pilotlösung“ der Veränderungen
beinhalten.
3. Check: Es wird das Ergebnis der Veränderung untersucht und die Nützlich-
keit der Veränderungen analysiert.
4. Act: Dieser Schritt beinhaltet das Agieren gemäß der Analyse und der emp-
fohlenen Änderungen. Schritt 4 mündet dann in weiteren Verbesserungs-
plänen.
1 Hierbei wird der Programmablauf im Quellcode analysiert und die Testdaten ergeben sich aus dem Quellprogramm bzw. dem zugehörigen Programmgraphen [vgl. Winc01, 53]. 2 Hier wird überprüft, ob das (Quell-)Programm sämtliche Anforderungen aus der Algo-rithmenbeschreibung erfüllt, aus der Testdaten abgeleitet werden [vgl. Winc01, 53].
Qualitätssicherung Seite 8
Shewart argumentierte, dass Qualität und Produktivität verbessert werden, so-
bald sich die Prozessvariabilität verringert, diesen Ansatz publizierte er 1931
und in den 50er Jahren wurde jener Ansatz von japanischen Ingenieuren un-
termauert [vgl. O’Reg02, 9].
1.2.2 Demings 14-Schritte Programm
Beeinflusst von Shewarts Ansatz und dem Krieg in Japan war W. Edwards
Deming der Auffassung, dass es nicht genügt, dass jeder sein „Bestes“ tut,
sondern einerseits eine klare Aufgabenabgrenzung vorhanden sein muss und
die Organisation eine klare Linie verfolgt. Deming kritisierte die amerikanische
Art, Qualität zu erhalten (z.B. mit Slogans wie „Do it right the first time“ etc.).
Grob kann man die 14 Punkte folgendermaßen zusammenfassen [vgl.
O’Reg02, 10f]:
- Constancy of purpose
- Quality built into the product
- kontinuierliche „Verbesserungskultur“
Genauer betrachtet sehen die 14 Schritte wie folgt aus:
1. Constancy of purpose Unternehmen stehen langfristigen und
kurzfristigen Problemen gegenüber.
Das erfordert langfristige Planung, In-
vestitionen in Forschung und Entwick-
lung und Verbesserung von bestehen-
den Produkten und Dienstleistungen.
2. Adaption einer neuen Philoso-
phie
eingebürgerte Einstellungen fallen las-
sen und Neues ausprobieren
3. Build quality in Inspektionen des Produktes sind weni-
Qualitätssicherung Seite 9
ger sinnvoll als die Verbesserung des
Produktionsprozesses
4. Preis und Qualität Deming meint, der Produkte nur nach
dem Preis zu beurteilen sei falsch, erst
die Qualität entscheidet.
5. kontinuierliche Verbesserung Verbesserung ist ein fundamentaler
Aspekt bei Demings Ansatz. Dafür ist
es nötig z.B. die Kundenbedürfnisse,
Testmethoden und Design zu verste-
hen.
6. Institute Training Es soll ein Trainingsprogramm für
Mitarbeiter als auch für das Manage-
ment entwickelt werden, das den Ak-
teuren die Wichtigkeit des 14-Schritte
Programms verdeutlicht und die Mitar-
beiter zum aktiven Mitmachen moti-
viert.
7. Institute Leadership Das Management soll Hindernisse be-
seitigen und innovative Lösungen su-
chen.
8. Angst eliminieren Angst verhindert Diskussion und somit
Lösungsfindung.
9. Hindernisse beseitigen Abteilungen sollen zusammenarbeiten.
Es genügt nicht, dass eine Abteilung
im eigenen Umfeld optimal agiert.
10. Slogans eliminieren Deming findet Slogans wie z.B. „Keine
Fehler“ oder „Mach es beim ersten Mal
richtig“ unangebracht, weil meist der
Fehler dem System zuzurechnen ist
und nicht dem Einzelnen.
Qualitätssicherung Seite 10
11. Sollwerte eliminieren Sollwerte demotivieren Arbeitnehmer,
die durchschnittlich arbeiten.
12. Stolz auf die Arbeit Faktoren, die den Arbeitnehmer die
Freude an der Arbeit nehmen (ver-
gleichbar mit dem Fehlen der Hygiene-
faktoren nach Herzberg). Wird z.B.
eine Maschine längere Zeit nicht repa-
riert, verliert der Arbeitende die Motiva-
tion.
13. Selbstverbesserung Das Motivieren der Mitarbeiter zur
Schulung und dauerndem Lernen.
14. die 14 Prinzipien anwenden Das Management soll dieses Pro-
gramm unterstützen und den Beschäf-
tigten des Unternehmens klarmachen,
warum es Veränderungen gibt.
Tabelle 1: Demings 14-Schritte Programm
Quelle: O’Regan A Practical Approach to Software Quality 2002, 11f
Deming nannte außerdem die fünf tödlichen Krankheiten, die westliche Unter-
nehmen befallen können [vgl. O’Reg02, 13]:
- Fehlen einer Constancy of Purpose
- Konzentration auf kurzfristigen Profit
- Verhaltensforschung
- Mobilität des Management
- Exzessives Messen
Qualitätssicherung Seite 11
1.2.3 Jurans 10-Schritte Programm
Juran argumentiert, dass Qualitätssicherung eine Aufgabe des Managements
sei, das Management hat also die Aufgabe, Qualität zu planen, kontrollieren
und zu verbessern (Juran-Trilogie) [vgl. O’Reg02, 14].
1. Kunden identifizieren Juran unterscheidet den internen und
externen Kunden. Den internen Kun-
den stellt die Entwicklergruppe dar,
und den externen Kunden der Enduser
der Software.
2. Kundenwünsche bestimmen Durch Kommunikation mit dem Kun-
den sollen Erwartungen ermittelt wer-
den.
3. Übersetzen Die Kundenwünsche sollen in die
Sprache des Anbieters übertragen
werden.
4. Einheiten für Messeinrichtungen
aufbauen
Messeinrichtungen werden definiert.
5. Messen Qualität und Prozesse werden durch
Messprogramme untersucht und ana-
lysiert.
6. Produkt entwickeln Das Produkt sollte so entwickelt wer-
den, dass es den Kundenwünschen
entspricht.
7. Produktdesign optimieren Das Design des Produktes soll optimal
sein, um den Kunden anzusprechen.
Qualitätssicherung Seite 12
8. Prozess optimieren Hier sollen Prozesse entwickelt wer-
den, die Produkte produzieren, die die
Kunden erwarten.
9. Prozessfähigkeit optimieren Schritt 9 soll gewährleisten, dass der
Prozess so optimal ist, dass das Pro-
dukt hochqualitativ ist.
10. Transfer Der letztes Schritt enthält das Transfe-
rieren des Prozesses in eine normalen
Produktionsentwicklungsoperation.
Tabelle 2: Jurans 10-Schritte Programm
Quelle: O’Regan A Practical Approach to Software Quality 2002, 14
1.2.4 Crosbys 14-Schritte Programm
Crosbys Programm beeinflusste das Capability Maturity Modell, welches in Ab-
schnitt 2. näher beleuchtet wird. Er unterscheidet zwei Gründe, warum Fehler
auftreten [vgl. O’Reg02, 16]:
- Fehlen von Wissen
- Unvorsichtigkeit des Individuums
Ersteres könnte man durch Schulung vermeiden, jedoch hängt zweiteres völlig
vom Individuum selbst ab und könnte nur durch eine Einstellungsänderung ver-
bessert werden. Crosby erschuf demnach ein Programm, das vom Manage-
ment unterstützt werden sollte und von einem eigens zusammengestellten
Qualitätsverbesserungs-Team, welches das Programm verwirklichen soll. Das
Programm, das Crosby als „Null-Fehler-Programm“ bezeichnet, soll den Mitar-
beitern des Unternehmens kommuniziert werden um so eine eventuelle Einstel-
lungsänderung erwirken zu können [vgl. O’Reg02, 16].
Qualitätssicherung Seite 13
1. Unterstützung und Partizipation seitens des Managements
2. Qualitätsverbesserungsteam Jede Abteilung entsendet einen Rep-
räsentanten in das Team um zu ge-
währleisten, dass alle Interessen der
einzelnen Abteilungen berücksichtigt
werden.
3. Qualitätsmessung Hier soll die gegenwärtige Qualitätsla-
ge untersucht und dargestellt werden,
wo Verbesserungen nötig sind.
4. Kosten der Qualitätsevaluierung Wieviel kostet die Qualitätssicherung
im Unternehmen?
5. Qualitätsbewußtsein Die Mitarbeiter werden von der Wich-
tigkeit guter Qualität unterrichtet.
6. Korrekturen Alle Probleme werden gelöst und
Probleme, die nicht lösbar sind, dem
Management zur Kenntnis gebracht.
7. Null-Fehler-Programm Das soll nicht als Motivationsschritt
gesehen werden, sondern eher (wie es
z.B.. Deming nicht favorisiert) als Slo-
gan „Mach es beim ersten Mal gleich
richtig“, also Vermittlung der Botschaft
an die Mitarbeiter, keine Fehler zu ma-
chen.
8. Manager werden für das 14-Schritte Programm ausgebildet
9. Null-Fehler-Tag Ein Tag im Jahr wird dazu verwendet,
um den Mitarbeitern die Wichtigkeit
von fehlerfreiem Arbeiten näherzubrin-
gen.
Qualitätssicherung Seite 14
10. Zielsetzung Die Mitarbeiter sollen darauf trainiert
werden, in Zielen zu denken und Ziele
zu realisieren.
11. Fehlerursache entfernen Für jeden einzelnen Mitarbeiter werden
fehlerverursachende Aspekte unter-
sucht und beseitigt.
12. Aufmerksamkeit Hier wird den Arbeitnehmern Beach-
tung geschenkt, die noch über das
Maß hinaus Beiträge zum Erreichen
der Unternehmensziele leisten.
13. Qualitätsgremien Es werden Gremien von verschiede-
nen Experten gebildet, die Ideen aus-
tauschen.
14. Do it over again! Kontinuierliche Verbesserung ist ein
Schlüsselelement der Qualitätssiche-
rung, denn Verbesserung endet nie.
Tabelle 3: Crosbys 14-Schritte Modell
Quelle: O’Regan A Practical Approach to Software Quality 2002, 16f
Crosby misst mit in Tabelle 3: Crosbys 14-Schritte Modell abgebildetem Pro-
gramm die Reife eines bestehenden Qualitätssystems unter Berücksichtigung
mehrerer Qualitätsmanagementkategorien. Er unterscheidet 6 Kategorien, die
jeweils auf einer Skala von 1-5 eingestuft werden (siehe Tabelle 4: Crosbys
Reifegrade). Dieses Modell hat auch Einzug in das in Abschnitt 2 behandelte
Capability Maturity Modell gehalten [vgl. O’Reg02, 18].
Name Beschreibung
Level 1 Unsicherheit Das Unternehmen hat keine organisierten Verbesse-
rungsaktivitäten, die Wurzel der Probleme wird nicht
untersucht, und es (das Unternehmen) macht für alle
Qualitätssicherung Seite 15
Qualitätsprobleme die Qualitätsabteilung verantwort-
lich.
Level 2 Awakening Das Management beginnt zu merken, dass Qualitäts-
management sinnvoll sein kann. Es will jedoch keine
Investitionen tätigen oder Zeit verbrauchen. Es werden
zwar Teams gebildet, dennoch gibt es keine langfristi-
gen Lösungen.
Level 3 Enlightment Das Management erfährt mehr über das Qualitätsver-
besserungsprogramm und agiert unterstützender.
Probleme werden erkannt und zur Lösung freigegeben.
Level 4 Weisheit Das Management arbeitet stark mit und versteht die
Wichtigkeit eines Qualitätsmanagement. Es werden
Vorschläge angenommen und Probleme früher identifi-
ziert. Die Fehlervermeidung wird Teil der Unterneh-
menskultur.
Level 5 Sicherheit Die gesamte Organisation ist in der kontinuierlichen
Verbesserung involviert.
Tabelle 4: Crosbys Reifegrade
Quelle: O’Regan A Practical Approach to Software Quality 2002, 18
Capability Maturity Modell (CMM) Seite 16
2 Capability Maturity Modell (CMM)
Das „Capability Maturity Modell“ ist wird verwendet um Softwareprozesse zu
definieren. Wie bereits oben erwähnt, entstand das CMM unter Einfluss von
verschiedensten Ideen z.B.. von Crosby, Deming und Juran. Crosbys fünf Qua-
litätsmanagement – Reifegrade wurden in das CMM übernommen, verfeinert,
was zur Entwicklung eines „Process Maturity Modells“ (PMM) führte. Aus dem
PMM wurde dann durch TQM (Total Quality Management) das CMM [vgl.
O’Reg02, 129].
Der Vorteil des CMM ist, dass das Unternehmen einem logischen Weg der
Verbesserung folgen kann und wenn es den Maturity Levels folgt, ihre eigene
Entwicklung erfahren kann [vgl. O’Reg02, 130].
Abbildung 1: Prozesstriangle des CMM
Quelle: O’Regan A Practical Approach to Software Quality 2002, 130
In Abbildung 1: Prozesstriangle des CMM kann man sehen, worauf das CMM
grundlegend basiert, nämlich auf gutem Softwareengineering, also Menschen,
Technologie und Prozessen. Viele Probleme resultieren aus einem fehlerhaften
Prozess und man ist bemüht eher den Prozess zu verbessern als die Men
Prozess
Menschen Technologie
Capability Maturity Modell (CMM) Seite 17
schen zu verantworten. Das führt zu einer offeneren Kultur der Diskussion von
Problemen und Lösungsfindung [vgl. O’Reg02, 130].
Der Softwareprozess wird als ein Bündel an Aktivitäten, Methoden, Praktiken
und Transformationen bezeichnet, das Menschen nutzen um Software zu ent-
wickeln und zu warten [vgl. O’Reg02, 131].
2.1 Aufbau des CMM
Das CMM beschreibt eine Art Pfad, an der sich eine Organisation orientieren
soll, um von einem suboptimalen Prozess zu einem optimalen Prozess zu ge-
langen [vgl. O’Reg02, 133]. Dabei unterscheidet das CMM fünf Level [vgl.
O’Reg02, 133]:
1. Initialphase (Anfangsstufe)
2. Wiederholung
3. Definierte Stufe
4. Managed level
5. Optimierung
Die Unternehmung bewegt sich von einer Stufe in die nächste [vgl. O’Reg02,
133].
Capability Maturity Modell (CMM) Seite 18
2.1.1 Initialphase (Anfangsstufe)
Diese Stufe sei anhand Abbildung 2: Initialphase - Ablauf veranschaulicht:
Abbildung 2: Initialphase - Ablauf
Quelle: O’Regan A Practical Approach to Software Quality 2002, 133
Die Initialphase bezeichnet die Stufe, in der das Unternehmen noch keinen
Plan des Prozesses vorbereitet hat. Vielmehr stützt sich der Prozess auf Ad-
hoc Entscheidungen und wenig Definiertem. Organisationen, die sich in Level 1
befinden, sind oft reaktionär und auf einzelne „Heldentaten“ von Individuen an-
gewiesen. Es bestehen zwar Prozessdefinitionen, sie werden aber nicht ein-
gehalten. Das heisst aber nicht, dass eine Organisation nicht erfolgreich sein
Initialphase
Wiederholung
Definition
Managed
Optimierung
Geregelter Prozess
Standard Consistent Process
Vorhersehbarer Pro-zess
kontinuierlicher Verbesse-rungsprozess
Capability Maturity Modell (CMM) Seite 19
kann, wenn sie in Level 1 eingestuft wird. Es kann jedoch zB. an der Wieder-
holbarkeit von gut gelungenen Projekten mangeln, weil es an der nötigen Infra-
struktur mangelt [vgl. O’Reg02, 133f].
2.1.2 Wiederholbarkeit
Das wichtigste Merkmal von Level 2 Organisationen ist die Betonung der Ma-
nagementprozesse. Das Planen und Management von Projekten wird auf Er-
fahrungen in vergangenen Projekten gestützt. Es bestehen bestimmte Regeln,
wie man Softwareprojekte implementiert. Dies soll zur Wiederholbarkeit von
erfolgreichen Prozessen führen. Der Projektmanager stellt einen Plan auf, der
unter anderem definierte Meilensteine oder Risikomanagement umfasst. Es
gibt eine eigene Qualitätssicherungsgruppe, die gewährleistet, dass das Soft-
wareprojekt transparent (übersichtlich) ist [vgl. O’Reg02, 134].
2.1.3 Definitionslevel
Eine weitere Stufe erreichen Organisationen, die das Level 3 erreichen. Sie
besitzen bereits einen Organizational Standard Software Prozess (OSSP) für
die Entwicklung und Wartung der Software. Dieser Standardprozess wird für
bestimmte Projekte entworfen. Es gibt eine Gruppe, die dafür zuständig ist,
solch einen OSSP zu definieren, diesen zu verbessern und Veränderungen zu
adaptieren (Software Engineering Process Group = SEPG). Diese Gruppe hat
auch zur Aufgabe, Mitarbeiter in den Prozessablauf einzuschulen. In diesem
Level wird außerdem die Kommunikation in der Organisation gefördert [vgl.
O’Reg02, 134f].
2.1.4 Managed Level
Im 4. Level bestehen Kontrolllimits, es werden Qualitätsziele gesetzt, einerseits
für das Produkt und andererseits für den Prozess. Es wird korrigierend einge-
griffen, sollten die Ziele nicht erreicht werden. Es wird sich also nicht mehr so
auf die Prozessdefinition konzentriert sondern auf Verbesserung der Qualität
des Prozesses. Ein hochqualitativer Prozess soll vorhersehbar sein, das wird
Capability Maturity Modell (CMM) Seite 20
mithilfe von Prozessverbesserungen versucht. Ein Unternehmen im Level 4
sollte ein funktionierendes Programm besitzen, welches Prozesse kontrolliert.
Dieses Programm erfordert außerdem, dass ein OSSP bereits definiert wurde
[vgl. O’Reg02, 135].
2.1.5 Optimierung
Der Optimierungslevel ist auf ständige Verbesserung des Prozesses bedacht.
Fehler werden analysiert, deren Ursachen bestimmt und schließlich eliminiert.
Es werden neue Prozesse und Technologien ausprobiert und Effektivität jener
geprüft. Die Organisation im Level 5 untersucht, ob Veränderungen des Soft-
wareprozesses verbessernde Auswirkungen verursachen. In diesem Level soll
Unnötiges im Prozess vernichtet und Ineffizienzen vermieden werden um so
den Prozess zu verbessern. Es basiert auf den Analysen, die in Level 4 erstellt
werden [vgl. O’Reg02, 136].
2.1.6 Key Process Areas (KPAs)
Jedes einzelne Level eines CMM (außer das 1. Level) besteht aus verschiede-
nen „Key Process Areas“ (KPAs). Jedes KPA beinhaltet ein Bündel an Aktivitä-
ten und Zielen, die erreicht werden sollen. Das CMM umfasst 18 KPAs, jedes
davon ist ein Baustein für weitere Verbesserungen des Prozesses. Das CMM
soll nur als richtungsweisendes Modell angesehen werden, erst die KPAs indi-
vidualisieren das Modell für das jeweilige Unternehmen um die benötigten An-
forderungen zu treffen [vgl. O’Reg02, 137].
Capability Maturity Modell (CMM) Seite 21
Abbildung 3: Key Process Areas
Quelle: O’Regan A Practical Approach to Software Quality 2002, adaptiert von 137
2.2 Implementierung des CMM
Zur Implementierung eines CMM benötigt man neben viel Einsatz seitens des
Managements, adäquate Ressourcen, Teambildung und Schulung auch einen
Implementierungsplan, der im Detail festlegt, was für die Implementierung be-
nötigt wird. Dieser Plan wird den Mitarbeitern nähergebracht und Schulung wird
bereitgestellt. Auch enthält dieser Plan eine Zeitspanne, in der die Implementie-
rung abgeschlossen werden soll. Es wird ein Team gebildet, welches die Arbeit
überwacht und die Koordination übernimmt [vgl. O’Reg02, 151].
Maturity Level
KPAs
Common Fea-
tures
Key Pracitses
ISO 9000-NORM Seite 22
3 ISO 9000-NORM
3.1 Einführung
Der ISO 9000 Standard wurde von der Internationalen Standardisierung Orga-
nisation zur standardisierten Qualitätssicherung entwickelt. Das Ziel ist durch
standardisierte Methoden und Verfahren Fehler zu vermeiden, Prozesse zu
dokumentieren und Kontrollmechanismen zu entwickeln. ISO 9000 ist für die
verschiedensten Organisationsarten (verarbeitende Industrie, Software, Servi-
ceorganisation) verwendbar und ein Merkmal für ein sondiertes Qualitätssys-
tem. In erster Linie wurde diese internationale Norm zur Beurteilung und Prü-
fung von Subunternehmern (Lieferanten) entwickelt. Die letzte veröffentlichte
Version spezialisiert sich auf Konsumentenbefriedigung und ständige Verbes-
serung, und beinhaltet ein Prozessmodell [vgl. O’Reg02, 87f].
Das standardisierte Qualitätssystem dient zur Selektion eines Unternehmers für
den Konsumenten oder eines Subunternehmens für einen früheren Unterneh-
mer. Die Motivationen zur Implementierung von ISO 9000 sind [vgl. O’Reg02,
88, Abb.3.1]:
♦ Erhöhung der Glaubwürdigkeit der Organisation
♦ Marketingvorteil
♦ Anzeichen das Konsumentenbefriedung und Qualität Kernpunkte des Un-
ternehmens
♦ Verpflichtung zur ständigen Innovation und Verbesserung des Unterneh-
mens
♦ Zeichen für Qualität in der Produktentwicklung
♦ hochqualitative Software
♦ Präventionsansatz und Kontrollmechanismen
♦ loyale Konsumenten
ISO 9000-NORM Seite 23
♦ Fokus auf dem Lösen und Lernen von Problemen
♦ Schutz vor Rechtsstreitigkeiten (Dokumentation und Protokollierung von
Arbeitsschritten)
♦ bietet ein Verbesserungsmodell
♦ weniger Nachbearbeitung von defekten Produkten
♦ Steigerung der Moral in der Organisation
3.2 Implementierung
Das Ziel der Implementierung von ISO 9000 ist die Verbesserung der Qualität
und der Konsumentenzufriedenheit und die Zertifikation ist das Merkmal eines
standardisierten und geprüften Qualitätssystem für eine Organisation. Im All-
gemeinen besteht dieser Vorgang aus den folgenden Schritten [vgl. O’Reg02,
96f]:
a.) Aufklärungstraining
Der erste Schritt zur Implementierung besteht aus dem Briefing Manage-
ment (Instruktionen) und der Einführung in ISO 9000. Der Qualitätsmanager
wird demzufolge einen Kurs über ISO 9000 besuchen und den Manage-
mentteam die Resultate mitteilen.
b.) Teambildung
Die Bildung eines Teams ist essentiell für die Implementierung dieser Norm.
Diese Phase ist verantwortlich für den effektiven Ablauf und die Verwirkli-
chung dieses Projektes. Vor allem der Zeitplan und die Erreichung der Ziel-
setzungen haben oberste Priorität.
c.) Erreichung des ISO 9000 Status
ISO 9000-NORM Seite 24
Zur Prüfung der Norm wird im Zuge der Einführung ein externer Gutachter
beauftragt, um das Qualitätssystem zu prüfen, das ISO 9000 System zu
vergleichen und gegebenenfalls Verbesserungen anzustreben.
d.) Bereitstellung eines Aktionsplans
ISO 9000 beinhaltet einen Aktionsplan für die Implementierung des Sys-
tems. Ein Aktionsplan beinhaltet vordefinierte Ziele, die dazu benötigten
Ressourcen und deren zeitliche Erfüllung.
e.) Ausführung des Aktionsplans
In dieser Phase ist es wichtig, Feedback und Updates zu geben und dies
auch während des ganzen Projekts beizubehalten, um es in den Projektab-
lauf einzubauen.
f.) Statusprüfung des Aktionsplans
g.) ISO 9000 Bewertung
Es findet eine Überprüfung des Aktionsplans und der Anforderungen an das
System statt und ob die ISO 9000 Norm für diese Organisation geeignet ist.
h.) Zertifizierungsphase
i.) Offizielle Prüfung und Evaluierung von ISO 9000
j.) Verbesserungen, Feedback
3.3 ISO 9000: Version 2000
Die letzte veröffentlichte ISO 9000 Norm ist die Version 2000, die im folgenden
Abschnitt näher dargestellt werden soll. Diese Version ist benutzerfreundlicher
und logischer als die Version 1994, wobei sich beide auf das Qualitätsmana-
gement von der verarbeitenden Software- und Serviceindustrie spezialisieren.
ISO 9000 besteht aus fünf Abschnitten [vgl. O’Reg02, 93ff]:
ISO 9000-NORM Seite 25
! Qualitätsmanagementsystem (siehe Kapitel 3.4)
! Managementverantwortung (siehe Kapitel 3.5)
! Ressourcenmanagement (siehe Kapitel 3.6)
! Produkt- oder Servicerealisierung (siehe Kapitel 3.7)
! Messung, Analyse und Verbesserung (siehe Kapitel 3.8)
In den folgenden Kapiteln werden die Abschnitte der ISO 9000 Norm näher
diskutiert und erläutert.
3.4 Qualitätsmanagementsystem
Dieser Abschnitt ist mit der Implementierung und der Dokumentation des Quali-
tätssystems beschäftigt, wobei die ISO 9000 (Version 2000) Anforderungen an
die Bedürfnisse und Ziele einer Organisation individuell angepasst werden.
Dieser Abschnitt beinhaltet die folgenden Prozesse [vgl. O’Reg02, 102ff]:
! Qualitätshandbuch (Schlüsseldokument zur Qualitätssicherung)
! Dokumentenkontrolle (standardisiertes Layout)
! Kontrolle der Protokollierung (Konformität)
! Interne Prüfung
! Kontrolle der nicht übereinstimmenden Produkte
! Korrigierende und präventive Aktionshandlungen
ISO 9000-NORM Seite 26
3.5 Managementverantwortung
Diese Phase definiert die Aufgaben des Managements im Qualitätssystem, die
Planung und die Zielsetzungen sowie das Qualitätshandbuch. Resultierend ist
das Management für die Qualitätspolitik der Organisation verantwortlich und
fördert auch die Motivation der Mitarbeiter über die ganze Organisation [vgl.
O’Reg02, 94].
Das Topmanagement spielt in dieser Entwicklung eine entscheidende Rolle,
daher ist das Engagement der Führungskräfte essentiell. Die ISO 9000 Norm
ist konsumentenorientiert, und daher sind die Konsumentenanforderungen und
die Konsumentenbefriedigung die abgeleiteten Kriterien. Die Qualitätspolitik ist
ein weiterer wichtiger Faktor des Qualitätssystems, die sich auf alle Ebenen der
Organisation und auf den einzelnen Mitarbeiter auswirkt. Daher ist es entschei-
dend, die Mitarbeiter in die Implementierung und die Planung zu involvieren
und informieren. Die Qualitätspolitik und die Organisationsphilosophie spiegeln
sich in den quantitativen meßbaren Zielen und Qualitätsmerkmalen, die den
Bedürfnissen der Konsumenten entsprechen, wie hohe Qualität und verlässli-
che Software, wieder. Die Durchführung der Implementierung erfordert außer-
dem eine Autorität, die für die Protokollierung, die Evaluierung und die Verbes-
serung des Systems zuständig ist. In diesem Zusammenhang ist die Förderung
der internen Kommunikation unerlässlich [vgl. O’Reg02, 105].
3.6 Ressourcenmanagement
Zur Lieferung hochqualitativer Software müssen menschliche Ressourcen so-
wie physikalische Infrastruktur zur Verfügung stehen. Es sollten daher die nach-
folgenden Voraussetzungen erfüllt werden [vgl. O’Reg02, 108f]:
! Bereitstellung der Ressourcen wie Gebäude und Mitarbeiter sowie die
Kalkulation der zukünftigen Anforderungen wie Training und Schulungen
! Menschliche Ressourcen (Anwerbung, Anreize für Mitarbeiter, Karriere-
planung)
ISO 9000-NORM Seite 27
! Infrastruktur wie Gebäude, Büroausstattung und Technologie entspre-
chen den Kriterien der jeweiligen Organisation
! Arbeitsumgebung und Förderung der Zufriedenheit, der Motivation und
Arbeitserfüllung der Mitarbeiter.
3.7 Produkt- oder Servicerealisierung
Das Management ist in dieser Phase mit der effizienten Produkt- und terminge-
rechte Servicerealisierung beschäftigt, um den Anforderungen der Kundenwün-
sche zu entsprechen. Dieser Abschnitt beschäftigt sich mit sechs entscheiden-
den Punkten [vgl.O’Reg02, 110ff]:
! Die Planung der Produktrealisierung (Anwendungsbereich, Aktivitäten, Ab-
laufplan, Schlüsselindikatoren)
! Verwirklichung konsumentenorientierter Anforderungen (Anwendungsbe-
reich, Unternehmenskontext, funktionaler Bereich, Systemanforderungen,.. )
! Design und Entwicklung (Planung, Entwicklungsinput und -output, Verifikati-
on, Validierung) der Software wird anhand einer Checkliste beurteilt.
! Einkaufsprozess (adäquat und informativ)
! Bereitstellung von Produkt und Service
! Kontrollmechanismen für die Software und Überwachung des Entwicklungs-
prozesses mit Hilfe von Testskript vor allem in der verarbeitenden Industrie
3.8 Messung, Analyse und Verbesserung
Um die Funktionalität des Systems zu verbessern, werden vor allem Messun-
gen der Konsumentenzufriedenheit und Kontrolle von Defekten durchgeführt
[vgl. O’Reg02, 117ff].
Die Bedürfnisse der Kunden werden mit Hilfe eines Fragebogens evaluiert und
ausgewertet. Anhand dieses Feedbacks werden Aktionspläne ausgearbeitet
ISO 9000-NORM Seite 28
und verwirklicht. Die Einhaltung des Prozesses wird anhand eines internen Prü-
fungsteams durch Interviews kontrolliert [vgl. O’Reg02, 117ff].
Die Defekte der ISO 9000 Norm werden durch Arbeitsblätter und Hilfsinstru-
mente erfaßt und stellen das aktuelle Qualitätssystem dar. Durch deren Analy-
se und Ausarbeitung können negative Trends identifiziert und aktive Verbesse-
rungsmaßnahmen durchgeführt werden [vgl. O’Reg02, 123].
3.8.1 ISO 9000, Verbesserungen und Aktionsplan
Die ISO 9000 Norm unterstützt Unternehmen bei der Bewertung ihres aktuellen
Qualitätsstatus und der Identifizierung ihrer Schwachpunkte. Zur Erreichung der
qualitativen Exzellenz sind Selbstbewertungen sinnvoll [vgl. O’Reg02, 123].
Eine Selbstbewertung mißt die Reife der Qualitätssoftware anhand von Zielen
und deren Skalierung, wobei dieses Bewertungsschema auf dem SPICE Stan-
dard basiert. Anhand der Auswertung werden die ausgesuchten Organisations-
bereiche in Reifeebenen eingeteilt und die passenden Maßnahmen vorge-
schlagen. Das Output dieser Bewertung zeigt die Stärke eines Unternehmens
und verbesserungswürdigen Bereiche. Der Aktionsplan hilft in diesem Zusam-
menhang die detaillierten Maßnahmen zu definieren, den Zeitplan zu setzen
und den Status zu bestimmen [vgl. O’Reg02, 125].
Der SPICE (15504) Standard Seite 29
4 Der SPICE (15504) Standard
4.1 Einführung
Der ISO SPICE (Software Process Improvement and Capability Determination)
Standard wurde als neuer internationaler Standard aus mehreren
konkurrierenden alten Standards erhoben. Ziel ist es, Resultate der alten
Standards vergleichbar zu machen. Spice stellt ein Gerüst zur Verfügung,
welches es nach seiner Implementierung möglich macht, bestehende
Prozesse, insbesonders Softwareprozesse eines Unternehmens zu
analysieren, zu bewerten und gezielt zu verbessern. Darüber hinaus bietet
Spice gute Anregungen im Bezug auf das definieren von neuen Prozessen, die
bis dato im Unternehmen noch nicht existieren [vgl. O’Reg02, 169].
4.2 SPICE Modell und Prozesse
Prozesse können wahlweise im eigenem oder im fremden Unternehmen
bewertet werden, um zu erfahren ob man nun selbst die Kapazitäten bzw. die
Fähigkeiten besitzt, eine Software zu entwickeln und wenn nicht, welcher
Lieferant dazu fähig wäre [vgl. O’Reg02, 181].
Zuerst können die Prozesse in fünf Kategorien eingeteilt werden: Engineering
Processes, Customer-Supplier Processes, Management Processes und
Organizational Processes, aus dennen sich auch die individuellen Prozesse
ergeben. Spice gibt eine Auflistung von schon implementierten Prozessen,
andere können neu definiert und zusätzlich benutzt werden [vgl. O’Reg02,
182ff].
Die Bewertung der Prozesse findet durch den so genanten SPICE Assessment
statt. Dies ist ein formell geplanter Prozess, der periodisch stattfindet.
Anschliessend werden die Resultate ausgewertet und darurch sich ergebende
Verbesserungen implementiert. Schlussendlich findet ein neues Assessment
Der SPICE (15504) Standard Seite 30
statt um die Änderungen zu überprüfen und um die Prozesse in die nächste
Ebene einzuleiten [vgl. O’Reg02, 198].
Die vordefinierten Prozessniveaus sind: Incomplete Process, Performed
Process, Managed Process, Established Process, Predictable Process und
Optimizing Process. Jeder dieser Prozesse wird zusätzlich mittels Attributen
beschrieben, die am besten zum jeweiligen Niveau passen. Durch die
Bewertung dieser Attribute ergibt sich dann das derzeitige Entwicklungsniveau
eines Prozesses [vgl. O’Reg02, 177].
Beim Incomplete Process handelt es sich um das niedrigste Niveau. Hier
werden Prozesse adhoc geführt. Keins der Attribute wird erfüllt [vgl. O’Reg02,
198].
Der Performed Process erreicht stets Ziele, ist jedoch nicht formell geplant.
Individuen begreifen, das etwas getan werden muß und tun es. Weil es beim
Beobachten des Prozesses um die Frage der Erreichung der Ziele geht, sind
die dazugehörigen Attribute Process Performance [vgl. O’Reg02, 177].
Eine Stufe höher, beim Managed Process wird eine geplante, kontrollierte
Arbeitsweise angenommen. Die Performance Management Attribute beschreibt
das Bestreben, die Leistung des Prozesses zu bestimmen, während die Work
Product Management Attribute die Kontrolle der Prozess In- und Outputs
begründet [vgl. O’Reg02, 177].
Beim Established Process wird eine gewisse Reife angenommen. Durch die
Process Definition Attribute wird die Standardisierung des Prozesses
beschrieben, während bei Process Ressource Attribute die Steuerung der
Resourcen in Vordergrund steht [vgl. O’Reg02, 178].
Der Predictable Process ist vollständig vorhersehbar. Die Attribute Measurable
und Process Control schildern das Sammeln von quantitativen Daten und deren
Anwendung in der Prozesskontrolle [vgl. O’Reg02, 178].
Das höchste Niveau hat der Optimizing Process. Beschrieben durch die
Process Change Attribute kann jener Prozess nach Belieben den Umständen
entsprechend angepasst werden. Zusätzlich kann er durch die Continues
Der SPICE (15504) Standard Seite 31
Improvement Attribute ständig analysiert und verbessert werden [vgl. O’Reg02,
178].
Wenn das Assessment stattfindet, wird unter anderem auch das aktuelle
Prozessniveau ermittelt. Jedes der oben genannten Attribute wird mit folgender
Skala bewertet:
Unbefriedigend Es gibt nur wenig
Fortschritte im
Prozessattribut.
0-15%
Teilweise befriedigend Es gibt einen
systematischen Ansatz,
dennoch unterscheiden
sich die Prozessattribute.
16%-50%
großteils befriedigend Hier besteht ein gutes
System, und Erfolge sind
sichtbar.
51%-85%
vollständig befriedigend Der Erfolg ist gesichert
durch ein komplettes und
systematisch
einwandfreies
Prozessattribut.
86%-100%
Tabelle 5: Skala für Attributbewertung
Quelle: selbst erstellt
Eine Zuteilung in das entsprechende Niveau ergibt sich durch die „vollständige
Befriedigung“ alle minderwertigen Niveaus (d.h. deren Attribute) und zumindest
„großteils befriedigend“ im aktuellen Niveau. Zum Beispiel, wenn Process Per-
formance, Performance Management, Work Product Management Vollständig
befriedigend sind und entweder Process Resource oder Process Definition zu-
Der SPICE (15504) Standard Seite 32
mindest großteils befriedigend sind, ergibt das ein Established Process Niveau
[vgl. O’Reg02, 179].
Um SPICE in ein Unternehmen dauerhaft zu integrieren, bedarf es einer langen
Planungsphase, in der die bestehenden Prozesse auf SPICE abgebildet wer-
den. Dazu wird ein eigenes Projektteam gegründet, welches den Integrations-
prozess während der gesammelten Dauer anführt. Nach der Bewertung des
derzeitigen Zustandes müssen Verbesserungsvorschläge eingesammelt und
ausgewertet werden und später dann integriert. Es ist notwendig, den Mitarbei-
tern schon in frühen Stadien der Einführung den Sinn und Zweck von SPICE
verständlich zu machen (die Anwendung ist für alle eine große Umstellung), um
eine unternehmensweite Akzeptanz und Benutzung zu erlangen [vgl. O’Reg02,
201].
Die hohen Anforderungen und Formalisierung dieses Standard ermöglichen
eine gute Bewertung des Ist-Zustands des Unternehmens. Leider werden die
Vorschläge zur Verbesserung eines Prozesses, sei es jetzt Fehleranalyse oder
Ausarbeitung der Verbesserungen nicht näher spezifiziert. Um mit SPICE den-
noch gute Resultate zu erzielen. müssen hoch qualifizierte Leute eingesetzt
werden, sonst bleibt eine Prozessverbesserung und Steigerung in ein höheres
Niveau aus. Andererseits macht es dieser Standard möglich, in der heutigen
Globalisierten Welt Prozessauswertungen Unternehmens- bzw. länderübergrei-
fend zu vergleichen [vgl. O’Reg02, 201f].
Software Inspections and Testing Seite 33
5 Software Inspections and Testing
Um qualitativ hochwertige Software anbieten zu können und
Entwicklungskosten niedrig zu halten, müssen moderne Unternehmen die
Softwareentwicklung einer Qualitätsbegutachtung unterwerfen. Diese
Begutachtung geht weit über das bloße Testen der Software hinaus. Der ganze
Entwicklungsprozess wird beobachtet, ausgewertet und dauernd verbessert.
[vgl. O’Reg02, 49]. Fehler im Prozess werden so beseitigt, um vorzubeugen,
dass die gleichen Fehler bei der nächsten Entwicklung nicht wieder passieren
[vgl. O’Reg02, 50].
Das lohnt sich ökonomisch gesehen, trotz den hohen Kosten, da etwaige
Korrekturkosten noch höher sein könnten, weil diese umso mehr steigen, je
länger in ein Fehler, bzw. Abweichung von der Spezifikation unentdeckt bleiben
[vgl. O’Reg02, 51].
Die eingesetzten Verfahren werden nach Grad der Formalität in drei Kategorien
eingeordnet [vgl. O’Reg02, 51f]:
! informelle,
! semiformelle und
! formelle Überprüfungsverfahren
Welcher Grad an Formalität und Umfang in einem Unternehmen eingesetzt
wird hängt in hohem Maß von der jeweiligen Unternehmenskultur und der
Anforderung an die Wichtigkeit und die Qualität der Funktionalität der
Entwicklung ab. Weil der Schaden, den eine sicherheitskritische Applikation
verursachen kann viel höher ist als der eines Computerspiels, sollte die
Entwicklung solcher Applikationen gründlicher (also mit höheren Formalität)
begutachtet werden [vgl. O’Reg02, 52].
Alle drei Kategorien von Überprüfungsverfahren haben gemeinsam, dass es
sich nicht nur um eine einzelne Tätigkeiten handelt, sondern um Prozesse die
sorgfältig geplant und ausgeführt werden müssen. Auf jeden Fall muss im
Voraus definiert werden, wie die Vorbereitung auf eine Begutachtung, und die
Software Inspections and Testing Seite 34
Begutachtung selbst stattzufinden haben und welche die Ein- und
Ausgangskriterien sind [vgl. O’Reg02, 52].
Wichtige Faktoren, die zu einer gesteigerten Effektivität einer Begutachtung
führen, sind die Expertise der Teilnehmer, die Vorbereitung und die
Geschwindigkeit der Überprüfung [vgl. O’Reg02, 52].
5.1 Rollen einer Überprüfung
Im Normalfall werden für jede, noch so informelle Überprüfung zumindest zwei
Rollen definiert. Diese Abstrahierung ermöglicht es zuerst Aufgaben
zuzuweisen, und die Rollen erst anschließend mit Personen zu besetzen. Die
zwei notwendigen Rollen sind die des Autors, der für das Verfassen eines
Werks (z.B. Softwarekomponenten, etc.) zuständig ist und die des Aufsehers,
der das Werk des Autors überprüft. Auf weitere Rollen, wie die des
Diskussionsleiters, des Prüfers und des Lesers, werden später behandelt [vgl.
O’Reg02, 53].
Abbildung 4: Akteure einer Überprüfung
Quelle: selbst erstellt
Aufseher Autorüberprüft überprüft
Diskussionsleiter Leser
Software Inspections and Testing Seite 35
Am Ende jedes Entwicklungsschrittes muss die Qualität stimmen.
Wünschenswert ist deshalb einen neuen Schritt erst anzufangen nachdem der
letzte Schritt als einwandfrei gilt.
5.2 Fagan Methode
Ein bekanntes formelles Verfahren zur Überprüfung von Software ist die Fagan
Methode. In sieben Schritten werden sämtliche Fehler im Produkt, so wie auch
im Prozess der Entwicklung erkannt und beseitigt [vgl. O’Reg02, 58].
Folgende Rollen werden in Zusammenhang mit der Fagan Prüfung definiert:
Der Moderator (bzw. Diskussionsleiter) ist für die gesamte Überprüfung
zuständig. Der Autor ist für die Erstellung der Entwicklung zuständig. Der Leser
umschreibt sie aus einer unvoreingenommenen Sicht. Der Tester ist für ihre
formale Überprüfung der zuständig [vgl. O’Reg02, 59].
Der Kontrolleur ist für das Design verantwortlich, inwiefern es den
Anforderungen entspricht, bzw. ob sich die Implementierung an das Design
hält. Begutachtet werden: Anforderungslisten, Design, Code und Tests [vgl.
O’Reg02, 64].
Die einzelnen Schritte des Fagan Begutachtungsprozesses sind [vgl. O’Reg02,
51ff].
• Plannung – Hier wird alles vorbereitet, Rollen besetzt, Arbeitsmaterial
verteilt und Termine koordiniert.
• Übersicht – Der Autor stellt seine Entwicklung vor.
• Vorbereitung – Alle Inspektoren bereiten sich auf ihre Rolle beim Treffen
• Begutachtung – Die Begutachtung (formelles Treffen) findet statt. Es
sollen vorläufig nur Fehler und keine Lösungen gesucht werden.
• Verfahrensverbesserung – Hier befasst man sich mit der Verbesserung
des Entwicklungs- und Überprüfungsverfahrens.
• Nachbesserung – Fehlerkorrektur und Bereinigung noch offener Fragen.
Software Inspections and Testing Seite 36
• Nachträgliche Aktivitäten – Der Moderator überprüft ob alle Fehler
beseitigt wurden.
Sämtliche gefundene Fehler werden nach ihrem Härtegrad klassifiziert
(wesentlich, gering, Prozessverbesserung, Nachforschen) und in einer
Datenbank zusammengefasst (zwecks Dokumentaion und Auswertung) [vgl.
O’Reg02, 65]. Damit der ganze Prozess effizient verläuft, sollten bestimmte
Leitlinien befolgt werden. So wird das Ausmaß der Begutachtung
beschränkt um die Qualität der Arbeit zu erhalten [vgl. O’Reg02, 62].
Zusätzlich sollen bestimmte Eintrittskriterien erfüllt werden. Unter anderem
müssen die Teilnehmer qualifiziert und vorbereitet sein, sowie alle Schritte
bis zum Treffen sorgfältig durchgearbeitet werden [vgl. O’Reg02, 62].
Als Ausgangskriterien gelten die Fehlerfreiheit der Anforderungslisten, des
Designs, des Codes und der Tests auf allen Ebenen [vgl. O’Reg02, 65].
5.3 Software Testing
Softwaretests sind eine Maßnahme zur Steigerung der Qualität von Software.
Idealerweise werden sie schon im frühesten Stadium definiert und in den
Prozess der Entwicklung integriert [vgl. O’Reg02, 70].
Übliche Testverfahren sind Unit Tests (Modultests), Integration
(Zusammenspiel der Module, bzw. Komponenten), System (Zusammenspiel
der Software im ganzen System), Regression (Überprüfung ob neue
Änderungen der Spezifikation entsprechen), Leistung (ob auch unter erhöhten
Bedingungen alles funktioniert) und Abnahme (Ob der Kunde mit der Software
zufrieden ist) [vgl. O’Reg02, 75].
Zu dem wird zwischen den so genannten Black- und White-Box Tests
unterschieden. Bei White-Box handelt es sich um einen Test der die Richtigkeit
des Codes innerhalb einen Moduls nachweist, beim Black-Box Test wird
dagegen die gewünschte Funktionalität überprüft [vgl. O’Reg02, 70].
Software Inspections and Testing Seite 37
5.3.1 Testplanung und Testwerkzeuge
Um effektiv zu sein, muss ein Testprozess sorgfältig geplant werden. Es
müssen genügend fähige Mitarbeiter einbezogen werden, ein Zeitplan und ein
Arbeitsplan mit genügend Tiefe erstellt werden. Zusätzlich müssen
Mechanismen eingesetzt werden, die diesen Prozess beobachten und
verbessern, um künftig Fehler in gesamten Prozess der Entwicklung, nicht nur
im Testbereich zu vermeiden [vgl. O’Reg02, 70f].
Ein gutes Testszenario leitet sich immer von der Spezifikation ab, deshalb wird
eine so genannte Traceability-Matrix eingesetzt, um die Anforderungen mit der
Implementierung und Tests zu verbinden [vgl. O’Reg02, 85].
Besonders hilfreich ist der Einsatz von Testwerkzeugen, allerdings nur, wenn
auch deren Einsatz in Vorhinein sorgfältig geplant ist. Das Management
überwacht den Gesamtprozess und ermöglicht gute Zusammenarbeit der
einzelnen Tester, sowie eine leichte Überwachung des Fortschritts. Andere
Teams können z.B. den Code analysieren und auf noch nicht getestete
Passagen hinweisen. Wiederum andere, automatisieren die Regressionstests.
Schlussendlich wird realitätsnahe Benutzung (Zugriffe, Abfragen, etc.) simuliert
um so die Leistung der Software unter Beweis zu stellen [vgl. O’Reg02, 78f].
Einen Sonderfall stellen dabei E-Commerce Applikationen dar, weil hier andere
Variablen (Zugriffsgeschwindigkeit, Erreichbarkeit, Ladezeiten, Sicherheit) über
den Erfolg entscheiden, muss auch der Testfokus an die richtige Stelle bewegt
werden [vgl. O’Reg02, 80].
Zuerst werden mittels statischen Tests HTML Dateien auf die Syntaxrichtigkeit
überprüft. Mit Unit Tests wird die Einhaltung der Anforderung überprüft, nämlich
Design, Navigation, Inhalt und Verknüpfungen. Mit Funktionstests werden nun
typischen Szenarien getestet. Durch einen Browsertest wird die Kompatibilität
zu verschiedenen Browsern überprüft. Hier können sich im besten Fall nur
Darstellungsunterschiede, im schlimmsten Fall sogar Funktionsstörungen
ergeben [vgl. O’Reg02, 81].
Software Inspections and Testing Seite 38
Abbildung 5: Ablauf Software Testing (angelehnt an O’Reg02, 81)
Quelle: selbst erstellt
Es wird die Benutzbarkeit eine Seite ermittelt sowie die Sicherheit der
durchzuführenden Aktionen sicherstellt. Schlussendlich wird die E-Commerce
Applikation diversen Stresstests unterzogen die die Stabilität und die
Erreichbarkeit kontrollieren sollen[vgl. O’Reg02, 81f].
statischer Test
Unit Tests
Browserkompatibilitätstest
Funktionstest
Stresstest
Software Inspections and Testing Seite 39
Der Testprozess geht über den bloßen Softwaretest hinaus und verbessert die
Qualität der gesamten Softwareentewicklung. Aufgrund des Prozesses kann
prognostiziert werden, wie lange die Entwicklung noch dauernd wird. Außerdem
werden daraus Erfahrungswerte ermittelt, wie viele Probleme in welchem
Stadium (Entwicklung, Systemtests, Übernahmetests, Kundenreport) gefunden
werden. Es ist eine Anforderung an den Softwaretestprozess, die
Fehlererkennung möglichst ins Anfangstadium, nämlich in die Entwicklung zu
verlagern [vgl. O’Reg02, 82].
Formale Methoden und Design Seite 40
6 Formale Methoden und Design
6.1 Software Configuration Management
Software Configurations Management sichert die Kontrolle bei der Entwicklung
von Software. In der frühen Phase der Entwicklung wird sichergestellt, dass
mittels Source Code Control Management die unterschiedlichen Versionen des
Quellcodes gesondert gespeichert werden und dass der Zugang dazu geregelt
wird. Mit Software Release Mangement wird eine koordinierte Übergabe der
Software an das Test Team, bzw. and den Kunden bezweckt. Ein formell
überprüfter Teil des Quellcodes wird als Baseline bezeichnet und dient als
Grundlage für die Weiterentwicklung [vgl. O’Reg02, 244].
Software Configuration Management besteht aus vier Teilen.
1. Configuration Identification: Es wird ein Versionsnumerrierungssystem
entwickelt, Vereinbarung über Namesgebung getroffen und
Statuszustände definiert.
2. Configuration Control heisst der Teil, indem die formelle Organisation
erzwungen wird. Quellbestände dürfen der Gesamtheit nur kontrolliert
entnommen werden. Solche Entnahmen werden markiert und die
Dokumente, bzw. Quellcode für andere Benutzer gesperrt.
Darüberhinaus herrscht ständige Überwachung über die Versionen die
in das System hinzugefügt werden. Schlussendlich werden auch die
geplanten Tätigkeiten und Codeveränderungen aufgezeichet.
3. Status Accounting ist die Berichterstellung, die von den Kontrollebenen
in Anspruch genommen wird. Es können sehr leicht der Fortschritt,
Qualität der Entwicklung und die Arbeit der beteiligten Gruppen
ausgewertet werden.
4. Configuration Auditing beschäftigt sich mit der formellen Überprüfung
der Arbeit. Unter anderem werden aus Codebeständen Baselines
Formale Methoden und Design Seite 41
definiert und Berichte and die Beteiligten weitergeleitet. Zusätzlich wird
auf Einhaltung der Standards und Verfahren geprüft.
6.2 Software Usability
Software Nutzbarkeit ist ein relativ neues Feld in der Software Entwicklung und
befasst sich mit der Möglichkeit, die Benutzung der Software zu erleichtern, es
effizienter und benutzerfreundlicher zu machen, um dadurch den Einstieg zu
beschleunigen. Viel Forschung wird durch Befragungsbögen betrieben. Dabei
konzentrieren sich die Fragen in fünf Richtungen: Nützlichkeit der Software,
Kontrolle über die Steuerung, bzw Tätigkeit, Geschwindigkeit und Aufwand des
Einarbeitens, Effizienz bei erledigen der Aufgaben, Emotionelle Reaktion.
Sämtliche Standards sind schon definiert. ISO 9241 schreibt die Anforderungen
an ein EDV Produkt vor, neben Hardware relevanten Teilen wird auch die
Software angesprochen. Die relevanten Kriterien sind: Darstellung der
Information, Benutzerführung, Menüführung. Interationsinhalt, und
Formulardesign [vgl. O’Reg02, 250ff].
ISO13407 geht im Gegensatz dazu einen anderen Weg. Es wird ein
Benutzerfreundliches Design angestrebt in dem Endbenutzer in den
Entwicklungsprozess eingebunden werden [vgl. O’Reg02, 251ff].
6.3 Formelle Verfahren
Formelle Verfahren sind Verfahren, die den Plannungsprozess einer Software
mittels mathematischer Symbolik und Logik darstellen. Zusätzlich kann ein
formeller Beweis über die Richtigkeit bzw. Funktion des Softwaredesigns
erbracht werden. Dies hat eine erhöhte Genaugkeit zur Folge, weniger Raum
für Interpretation und dadurch eine Entwicklung, die den Anforderungen
entspricht [vgl. O’Reg02, 258].
Weitere Gründe für die Benutzung formeller Verfahren sind direkte und
indirekte Kostenreduktion, sowie die Anforderung seiten der Auftraggeber diese
Verfahren Einzusetzen, um zum Beispiel die einwandfreie Funktion der
Formale Methoden und Design Seite 42
Software in sicherheitskritischen Einsatzfeldern zu gewährleisten [vgl. O’Reg02,
259].
Formelle Methoden werden in zwei Kategorien geteilt,
! die modellorientierten und
! die algebraischen.
Bei den modellorientierten Methoden wird ein Modell des zukünftigen
Softwaresystems erstellt und überprüft, inwieweit dieses Modell repräsentativ
ist. Bei Nichtübereinstimmung zwischen Modell und Wirklichkeit, wird das
Modell verbessert, oder durch ein neues passenderes ersetzt [vgl. O’Reg02,
263].
Im Gegensatz zu modellorientierten Methoden, werden bei algebraischen
Methoden nicht die Auswirkungen der Interaktion mit dem Modell, sondern nur
die Eigenschaften des zugrundeliegenden Konstrukts beschrieben – die
Implementierung ist von vornherein nicht definiert. Beim Benutzen einer
algebraischen Methode kann es passieren, dass es für die gewünschten
Eigenschaften keine mögliche Implementierung gibt. Zusätzlich zum formellen
Beweis der Gültigkeit muß auch ein Beweis der Implementierbarkeit erbracht
werden [vgl. O’Reg02, 264].
Metrik und Problemlösung Seite 43
7 Metrik und Problemlösung
Die Messungen quantitativer Werte in einer Software Entwicklungsumgebung in
einer Organisation dienen zur Identifizierung der Ziele, der Leistungsfähigkeit
und der Sichtbarkeit funktionaler Ebenen. Die Analyse von Trends und Daten
ermöglichen die Erstellung von Aktionsplänen, die wiederum zu Verbesserun-
gen führen. Die Metrik wiederum zeigt die interne Sicht der Qualität eines Soft-
wareprodukts [vgl. O’Reg02, 205].
7.1 Goal Question Metric Paradigma
Dieses Paradigma basiert auf einem zielorientierten Ansatz und auf den integ-
rierten Zielen, Fragen und Meßinstrumenten. Zu Beginn werden die Unterneh-
mensziele identifiziert und die Fragen zur Erreichung der Ziele formuliert. Für
jede Frage wird eine Metrik definiert, die eine Zielantwort zu einer speziellen
Frage darstellt. Das GQM Metrikprogramm beinhaltet drei Schritte [vgl.
O’Reg02, 205ff]:
- Festlegung expliziter Ziele (bevor die Metrik definiert wird)
- Top-Down-Definition der Metriken (vom Ziel ausgehend werden Maße de-
finiert)
- Bottom-Up-Interpretation (wenn die Daten erfasst sind, werden sie im
Kontext des Ziels interpretiert und die Definition und Interpretation erfolgt in
enger Zusammenarbeit mit den Projektmitgliedern
Das Ziel definiert das spezielle, strategische Problem eines Unternehmens, um
Verbesserungsmaßnahmen durchzuführen. Im folgenden Schritt werden
Schlüsselfragen formuliert, um das Ziel zu prüfen, bestimmen und letztendlich
zu erreichen. Jede Frage wird so bestimmt und analysiert, daß man eine objek-
tive Antwort geben kann und die Metrik identifiziert wird. Die Metrik stellen die
objektiven Meßwerkzeuge für quantitative Antworten dar [vgl. O’Reg02, 205ff].
Metrik und Problemlösung Seite 44
7.2 Balance Scorecard (BSC)
BSC stellt ein Managementinstrument dar, das die Visionen und Strategie einer
Organisation definiert und in einen Aktionsplan umsetzt. Es existieren vier Per-
spektiven [vgl. O’Reg02, 207ff]:
1. Kundenperspektive
2. Finanzperspektive
3. Geschäftsprozessperspektive
4. Lern- und Entwicklungsperspektive (Mitarbeiterperspektive)
Jede dieser einzelnen Perspektiven wiederum hat individuelle Ziele, die identifi-
ziert, gemessen und verfolgt werden müssen. Im Allgemeinen besteht das BSC
aus finanziellen und nicht finanziellen Maßnahmen. Der Vorteil dieses Instru-
ments ist die zukunftsorientierte Identifikation von Problemen und Verbesse-
rungspläne einer Organisation, die sich in folgende Schritte gliedern [vgl.
O’Reg02, 207ff]:
- Verdeutlichung und Identifikation von zukünftigen Visionen und Strategien
- Die daraus formulierten Ziele werden mit der Hilfe der internen Kommunika-
tion und verbindenden Maßnahmen an alle Mitarbeiter weitergeleitet
- Planung und aktive Zielsetzung für Kunden und Shareholders
- Strategisches Feedback und Lernen (Training) fördert die Motivation und
Fähigkeiten der Mitarbeiter
Die Metrik wird anhand der vier Perspektiven objektiv identifiziert und von der
Balance Scorecard beeinflußt wie zum Beispiel für das Finanzielle wird als Indi-
kator die Reduzierung der Kosten genannt [vgl. O’Reg02, 207ff].
• Metrik innerhalb einer Organisation
Metrik und Problemlösung Seite 45
Die Verwendung der Metrik versucht, die Transparenz der verschiedensten Be-
reiche in einer Softwareorganisation darzustellen und die Veränderungen und
Verbesserungen zu fördern. Die Metrik wird von der führenden Management-
ebene verwendet und analysiert und in verschiedenen funktionalen Bereichen
angewandt [vgl. O’Reg02, 210ff].
• Messung der Konsumentenzufriedenheit
Die Metrik der Konsumentenzufriedenheit wird in Kategorien unterteilt (wie der
Wert und die Verwendbarkeit) und wird in einem Graphen dargestellt und be-
wertet. Diese Beurteilung stellt ein Feedback zum Thema Kundenzufriedenheit
dar [vgl. O’Reg02, 210f].
• Metrik der Prozessverbesserung
Die Analyse stellt vordefinierte Verbesserungsvorschläge, die Effektivität der
Verbesserungen, die Qualität, die Durchlaufzeiten und die Produktivität von
einer Softwaregemeinschaft dar [vgl. O’Reg02, 212f].
• Human Ressources und Training Metrik
Es werden in der Human Ressources Abteilung die Hauptziele definiert, und
abgeleitete Fragen und die Metrik wie Personalstand werden analysiert [vgl.
O’Reg02, 214f].
• Metrik des Projektmanagements
Im Rahmen des Projektmanagements wird die Effektivität der Indikatoren eines
Softwareprojekts, wie Aktualität, Qualität, Kosten und Inhalt gemessen [vgl.
O’Reg02, 215f].
• Metrik der Qualitätsentwicklung
Diese Analyse von Daten gibt Einsicht in die Entwicklung und das Testen von
Softwareprodukten. Diese Metrik veranschaulicht die Risikobewertung von un-
entdeckten oder übersehenen Problemen und Defekten eines Produktes [vgl.
O’Reg02, 217f]
Metrik und Problemlösung Seite 46
• Metrik der Qualitätsprüfung
Diese Analyse gibt Einsicht in die Anzahl der Überprüfungen, den Status und
den Aktionstyp [vgl. O’Reg02, 218f].
• Metrik der Kundenbetreuung
Die Indikatoren für die Kundenbetreuung sind effiziente und schnelle Beantwor-
tung von Kundenproblemen, höchster Qualitätsstandard des Service und die
Verläßlichkeit. Die Wichtigkeit wird oft in der Schnelligkeit, Anzahl und Dauer
der Beantwortung von Kundenanfragen und die Verfügbarkeit und Verwend-
barkeit des Softwaresystems gemessen. Diese Analysen werden zur Präventi-
on und Unterbrechung von Aktionen verwendet [vgl. O’Reg, 221ff] .
7.3 Die Implementierung eines
Metrikprogrammes
Die Attribute müssen immer der jeweilige Organisation angepaßt und adaptiert
werden. Bei der Implementierung treten folgende Schritte für jede Abteilung
individuell auf [vgl. O’Reg02, 225f]:
Identifizierung der Unternehmensziele
! Identifizierung der Fragen
! Identifizierung der Metrik
! Identifizierung der Hilfsmittel
! Identifizierung der Daten
! Identifizierung und Bereitstellung der Ressourcen
Metrik und Problemlösung Seite 47
! Datenerfassung
In diesem Fall wird die Identifizierung der Daten nach dem Top down Prinzip
verwirklicht (Vom Unternehmensziel zur Frage) und die Effektivität gemessen,
wobei die Daten auf Anforderungen, Design und Beurteilung geprüft werden.
Im zweiten Schritt die Identifizierung eines Defekts und dessen Ursprung und
schließlich die Protokollierung der Anzahl der Defekte und deren Phasen [vgl.
O’Reg02, 226f].
! Identifizierung von Kontrollmechanismen
7.4 Problemlösungstechniken
Die Problemlösung stellt den Kernpunkt der Qualitätssicherung dar. Es gibt
verschiedenste Hilfsmittel zur Lösung und Veranschaulichung von Problemen
wie Trend Charts, Bar Charts, Scatter Diagramme, Fishbone Diagramme,
Histogramme, Control Charts und Pareto Analysen. Das Team für die
Problemlösung weist die Merkmale einer Gruppe und verfügt auch über einen
Leiter, der für die Aktivitäten, das Training, die Koordination, die
Untersuchungen, das Training der Mitglieder verantwortlich ist. Die Lösung
eines Problems erfolgt in folgenden Schritten [vgl. O’Reg02, 227f]:
1. Selektion und Identifizierung des Problems
2. Stand des Problems
3. Datenerfassung
4. Brainstorming
5. Aktionsplan wählen
6. Präsentation
7. Erfolgsmessung
Metrik und Problemlösung Seite 48
Im weiteren sind negative Determinanten, wie der Zeit- und Geldfaktor oder
Produktivität, Defekte und Präventionskultur wichtig [vgl. O’Reg02, 227f].
Conclusion Seite 49
8 Conclusion
Aufgrund der Literaturrecherche konnten sich die Autoren einen ausgiebigen
Einblick in die Thematik der Qualitätssicherung verschaffen. Es steht außer
Frage, dass standardisierte Qualitätssicherungsprogramme in Organisationen
unumgänglich sind um die Prävention und Früherkennung von möglichen Feh-
lerquellen und Defekten zu gewährleisten. Die Kundenloyalität soll gehalten
werden und um das zu erreichen ist es unerlässlich, die Produktqualität konti-
nuierlich zu verbessern. Jedoch besteht die Problematik, dass viele Organisati-
onen die Sinnhaftigkeit eines solchen Qualitätssicherungsprogrammes nicht
erkennen. Viele argumentieren dagegen und nennen als ausschlaggebende
Gründe die Höhe der Investitionskosten, Schulungskosten und den zeitlichen
Aufwand.
Die Autoren befassten sich mit den in der behandelten Literatur genannten
Standards:
- ISO 9000
- Capability Maturity Modell
- SPICE Standard
Diese stellen einen ausführlichen Ansatz dar, wie man Qualitätssicherungspro-
zesse gestalten kann und welche Aufgaben zu erfüllen sind. Trotz der, wie die
Autoren finden, gut durchdachten Strukturen dieser Modelle sollte man sich nie
von der Tatsache entfernen, dass viele Organisationen diese Standards nicht
anwenden und trotzdem erfolgreich sind. Es ist zwar fraglich, ob dies Einzelfälle
sind, dennoch ist zu überlegen, ob zuviel Strukturierung nicht die Bürokratie in
einer Organisation fördert, was bekanntlich die Kreativität leiden lässt.
Conclusion Seite 50
Quellenverzeichnis
[O’Reg02] O‘Regan, Gerard.: A Practical Approach to Software Quality. Sprin-ger, New York et al. 2002 [Winc01] Winckler, Michael J.: EDV-Organisation II. 2001: http://www.iwr.uni-heidelberg.de/~Michael.Winckler/VWA/Skripte/se-skript.pdf, Abruf am 5.5.2003, 22:21, S. 53
[Schuh02] Schuhmacher, Thomas: Theorie und Praxis der Balanced Scorecard , Teil 2 http://www.bindereport.de/html/download/man_bc/bin05_bc_t2.pdf, Ab-ruf am 6.5.2002, S. 16-18