Qualitätssicherung - wi.wu-wien.ac.atwi.wu-wien.ac.at/studium/Abschnitt_2/LVA_ss03/6... · Juran argumentiert, dass Qualitätssicherung eine Aufgabe des Managements sei, das Management

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


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


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


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


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.


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-


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].


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-


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.


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


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.


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].


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.


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ä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


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


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


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].


2.1.1 Initialphase (Anfangsstufe)

Diese Stufe sei anhand Abbildung 2: Initialphase - Ablauf veranschaulicht:

Abbildung 2: Initialphase - Ablauf


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


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


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].


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


♦ 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


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]:


! 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


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)


! 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


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


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


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-


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


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


Aufseher Autorüberprüft überprüft

Diskussionsleiter Leser


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.


• 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].


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


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].


Abbildung 5: Ablauf Software Testing (angelehnt an O’Reg02, 81)


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


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


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


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


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].


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


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 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


! 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


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

Documents

Qualitätssicherung - wi.wu-wien.ac.atwi.wu-wien.ac.at/studium/Abschnitt_2/LVA_ss03/6... · Juran argumentiert, dass Qualitätssicherung eine Aufgabe des Managements sei, das Management