• Keine Ergebnisse gefunden

Seminar ‚Messen und Prüfen von Software‘, WS 2001/02erstellt vonPhilipp Suter (Wirtschaftsinformatik)0 Praxisbericht

N/A
N/A
Protected

Academic year: 2021

Aktie "Seminar ‚Messen und Prüfen von Software‘, WS 2001/02erstellt vonPhilipp Suter (Wirtschaftsinformatik)0 Praxisbericht"

Copied!
17
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Praxisbericht

Seminar ‚Messen und Prüfen von Software‘, WS 2001/02

erstellt von

Philipp Suter (Wirtschaftsinformatik)

(2)

05.02.2002 Prof. Dr. Martin Glinz Betreuer: Christian Seybold

Inhaltsverzeichnis

Einführung 2

1 Eingesetzte Verfahren 3

1.1 ISO 9000 3

1.2 Cocomo II 5

1.3 McCabe 5

1.4 Testverfahren 7

2 Elca und Sumex II 7

2.1 Elca 7

2.2 Sumex II 8

2.2.1 Anwendungsgebiet 8

2.2.2 Systemumgebung und Entwicklungstools 8

2.2.3 Entwicklungsgeschichte 8

3 Qualitätsmanagement und –sicherung bei Elca 9

3.1 Projektmanagement 9

3.2 Qualitätssicherung 10

4 Testverfahren im Rahmen von Sumex II 10

4.1 Verfahren 10

4.1.1 Vorgehen 10

4.1.2 Risikoanalyse 110

4.2 Testphasen 12

4.2.1 Unittests 12

4.2.2 Integrationstests 13

4.2.3 Systemintegrationstests 13

4.2.4 Abnahmetests 14

4.2.5 Vorlagen und Tools 14

Fazit 15

(3)

Einführung

Im Folgenden soll aufgezeigt werden, wie bereits vorgestellte Test- und

Qualitätsmanagementstandards in der Praxis eingesetzt werden. Dies wird anhand der Softwarefirma ELCA geschehen, die mir freundlicherweise die Möglichkeit gab, einen Nachmittag lang mit Herrn Mäder, COO, und Herrn Pfister, Projektleiter Sumex II, Interviews zu führen. Die folgenden Ausführungen basieren grösstenteils auf diesen Interviews. Selbstverständlich haben jede Firma und jedes Projekt ihre eigenen Gesetzmässigkeiten. Je kleiner das Projekt, umso weniger Strukturen sind zu

erwarten. Es lohnt sich schlicht und einfach nicht bei einem kleinem Projekt, das nur aus wenigen Leuten besteht, allzu viel Zeit für Formalismus aufzuwenden. Dasselbe gilt für eine kleine Firma. Im Allgemeinen sollte bei der Anwendung von formalen Managementinstrumenten immer ein Kosten/ Nutzen-Denken im Vordergrund stehen.

Und gar keine strukturierten Abläufe zu verwenden ist auch selten eine gute Grundlage für herausragende Erfolge.

(4)

1 Eingesetzte Verfahren

Bei ELCA werden drei Verfahren eingesetzt:

1. ISO 9001 [1]

2. Cocomo II [2]

3. McCabe IQ2 [3]

Die ISO-Zertifizierung bezieht sich auf die gesamte Firma. McCabe und Cocomo werden als Standards für die Testverfahren und Projektplanung benutzt.

Selbstverständlich werden die Erfahrungen und die Kennzahlen aus den abgeschlossenen und laufenden Projekten eingesetzt um die Grundlagen aller Verfahren kontinuierlich zu verbessern und genauer auf die Bedürfnisse der ELCA abzustimmen.

1.1 ISO 9000

Basierend auf dem British Standard 5750 wurde 1987 von der International

Organization for Standards der ISO 9000 Qualitätsmanagementstandard entwickelt.

ISO 9000 und auch ISO 14000, der Ressourcenmanagementstandard, verstehen sich als Leitfäden für Firmen, um ihre Prozesse in einer Art zu gestalten, die international festgelegt ist und der periodischen Kontrolle einer unabhängigen Instanz unterliegt.

Dadurch wird es für den Kunden möglich, sich darauf zu verlassen, dass entweder die Qualität oder die Ressourcen besonders gepflegt werden. Der ISO 9000 wurde schon zweimal revidiert, 1994 und 2000. Ich beziehe mich im folgenden auf den 2000er Standard.

Die ISO Zertifizierung wird nicht durch die International Organisation of Standards selber durchgeführt sondern von externen Firmen. Die Organisation setzt nur den Rahmen für das Zertifikat. Alle drei Jahre muss eine registrierte Firma einen Audit durchführen, indem sie aufzeigt, wo sie sich verbessert und wo sie sich verschlechtert hat. Dies garantiert eine kontinuierliche Verbesserung. Es wird insbesonders auf die folgenden acht Punkte wert gelegt:

1. Kundenorientierung

Eine Firma sollte die Wünsche und Gebräuche ihrer jetzigen und zukünftigen Kunden kennen und versuchen sie zu übertreffen. Eine langfristige und stringente Kundenorientierung wird durch einheitliche Unternehmensziele und -visionen

(5)

erreicht. Dadurch kann besser auf den Markt eingegangen werden, Veränderungen werden schneller erkannt und adaptiert, Ressourcen werden besser eingesetzt und die Kunden sind zufriedener und loyaler.

2. Führung

Eine gut geführte Unternehmung lässt ihren Mitarbeitern Zeit und Raum ihre Aufgaben voll und ganz wahrzunehmen, ohne sich mit Aufgaben befassen zu müssen, die Sache des Managements wären. Durch klar kommunizierte Wünsche und Ziele gegenüber allen Stakeholdern wird den Mitarbeitern die Mögklichkeit gegeben, zufrieden und motiviert überdurchschnittliche Leistungen zu erbringen.

3. Mitarbeiterbeteiligung

Mitarbeiter die sich bestätigt und ernst genommen fühlen, setzen ihre Kreativität und Innovationsfähigkeit dafür ein, die Unternehmung besser zu machen. Dies kann durch Einbezug und Unterstützung eines jeden Mitarbeiters im täglichen Leistungs- und Kommunikationsprozess gefördert werden.

4. Prozessorientierung

Systematische und klare Verantwortungen und das Messen der Resultate in einem gut strukturierten Prozess führt zu schnelleren Produktionszyklen, besseren Produkten und klaren Verbesserungsmöglichkeiten. In den Prozess sollten Mitarbeiter, Kunden und Lieferanten einbezogen werden, um die Ressourcen und Aktivitätem optimal zu verteilen.

5. Systemorientierung des Management

Die optimale Einbindung aller Prozesse in das System Unternehmung mit Fokus auf den Kernprozess führt langfristig zu mehr Konsistenz, Effizienz und

Effektivität. Daher sollten die Abhängigkeiten, Verantwortlichkeiten,

Möglichkeiten und Rollen verstanden und kontinuierlich verbessert werden.

6. Kontinuierliche Verbesserung

Durch die ständige Reflexion der eigenen Leistung wird langfristig

unternehmensweite Flexibilität und Konsistenz erreicht. Ständige Schulung der Mitarbeiter und zielgerichtetes Messen und Verfolgen aller Prozesse führt zu Richtlinien die eine ständige Verbesserung ermöglichen.

7. Faktenbasierte Entscheidungsfindung

Effektive Entscheidungen basieren auf der Analyse von Informationen und Daten gepaart mit Erfahrung und Intuition. Die Grundlage dazu bietet eine strukturierte,

(6)

vertrauenswürdige und zugängliche Datenbasis, die mit allgemeingültigen Methoden analysiert wird.

8. Gegenseitiges Profitieren bei Lieferantenverbindungen

Eine Organisation und ihre Lieferanten stehen in gegenseitiger Abhängigkeit und haben gemeinsame zukünftige Interessen. Daher bietet sich die Möglichkeit, mit gegenseitigem Vertrauen Prozesse und Produkte langfristig zu verbessern und zu verbilligen. Lieferanten sollten gepflegt, aber gut assortiert und nicht zu breit gefächert sein.

Diese acht Prinzipien formen gemeinsam eine adäquate Basis, um eine Firma langfristig im Markt zu positionieren. Sie sind jedoch allgemein gefasst und jede Unternehmung sollte auf Grund ihres individuellen Hintergrundes selber entscheiden, welche Faktoren mehr oder weniger wichtig sind.

1.2 Cocomo II

Im Rahmen dieser Veranstaltung wurde Cocomo II bereits ausführlich behandelt und wird hier nur kurz zusammengefasst. Dieses Verfahren dient der Projektplanung und basiert auf Zahlen zur Abgrenzung eines Projektes, die im Rahmen von grösseren Softwareentwicklungen evaluiert wurden. Der Wiederverwendbarkeit und

Wartbarkeit wird besondere Aufmerksamkeit geschenkt. Voraussicht, Flexibilität, Architektur/Risikoauflösung, Teamzusammenhalt und Prozessreife ihm

Zusammenhang mit der Anzahl Lines of Code und Function Points sind die

Kernfaktoren zur Bestimmung der zu erwartenden Anzahl Personenmonate, welche wiederum die Länge und Kosten eines Projektes repräsentieren. Die folgenden drei Phasen oder Spiralzyklen sind das Herz von Cocomo II:

1. Prototyping der essentiellen Bausteine

2. Entwicklung alternativer Architekturen und Entwicklungsszenarien

3. Lebenszyklusmodel um die Kostentreiber und -träger genauer zu spezifizieren

1.3 McCabe IQ2

Auch auf dieses Testwerkzeug wurde im Rahmen der Veranstaltung bereits kurz hingewiesen. McCabe IQ2 wurde von McCabe & Associates im Laufe der letzten zwanzig Jahre suksessive entwickelt. Es unterstützt die Verlässlichkeit, Wartbarkeit und Stabilität von Applikationen durch die Möglichkeit, Testaktivitäten besser zu

(7)

planen, durchzuführen und nachzubearbeiten. Des weiteren unterstützt es das Configuration und Change Management. Es besteht aus folgenden sechs Bausteinen:

1. Quality Assurance

Dieses Modul dient als Unterstützung der Qualitätssicherung durch die grafische Abbildung der Komplexität. Die Komplexität einer Software sollte minimiert werden um die Qualität sicherzustellen. Dies wird erreicht, indem die Anzahl der möglichen Pfade in der Software auf ein absolutes Minimum beschränkt werden.

2. Test (Basis Path Testing, i.e. Structured Testing)

Hier wird die Testumgebung mit der Unterstützung von grafischen Wekzeugen erschaffen. Das Testen hängt direkt von der Komplexität der Software ab. Es sollte auf die Teile einer Software konzentriert sein, die eine grosse Tendenz haben, Fehler zu produzieren. Durch präzisses Beobachten der Fehler werden auch die interaktionsbedingten Fehler besser entdeckt.

3. Coverage Server

Dieses Modul dient der Speicherung von Testfällen und entdeckten Fehlern.

Insbesondere die Komplexitäts-Masse und die Lines of Code dienen als

Grundlage für die Testumgebung. Es wird erfasst, was schon erledigt ist und was noch in welcher Form zu tun ist.

4. Reengineer

Durch verschiedene Farben wird der Status eines bestimmten Softwaremoduls angezeigt. Die System Analyse und das vermeiden von redundantem und doppelt vorhandenem Codes wird erleichtert.

5. TRUEchange

Das Change Management und Versioning einer Software wird erleichtert. Dieses Tool ähnelt dem bekannten CVS. Es können die gemeldeten Bugs und die entsprechenden Reparaturen erfasst werden und Notfalls steht eine frühere Version zur Verfügung.

6. TRUEtrack

Probleme mit den gleichen Ursachen werden zusammengefasst. Es können Pendenzen und Verantwortlichkeiten bestimmt werden. Die anfallenden Aenderungen während eines Change Cycles können genau beobachtet werden.

(8)

7. TestCompress

Grosse Datenmengen können zu kleinen, testbaren Subsets zusammengefasst werden, damit sie effizient getestet werden. Dieses Tool erleichtert die Auswahl einer repräsentativen Stichprobe und verkleinert die Anzahl Tests.

1.4 Testverfahren

Im hier vorgestellten Projekt werden die folgenden Testverfahren benutzt. Sie werden nicht weiter kommentiert, da sie im Rahmen dieser Veranstalung im besonderen und im Rahmen des WI-Studium im allgemeinen schon öfters vorgestellt wurden.

 Code Inspektion (Code wird gemeinsam durchgelesen und besprochen.)

 Funktionale Tests (Sind alle spezifizierten Funktionen korrekt implementiert?)

 Debugger (Schrittweises Ausführen aller Programmteile.)

 Coverage Tests (Wurden alle Codezeilen einmal getestet?)

 Performance Tests (Wie ist so die Antwortszeit?)

 Stress Tests (Was passiert, wenn alle gleichzeitig das gleiche wollen?)

 Robustheitstests (Ist Datenintegrität bei Ausfällen gegeben?)

 Langzeittests (Läuft die Software auch noch nach zwei Wochen?)

 Installation (Kann die Software effektiv auf allen Plattformen installiert werden?)

2 ELCA [4] und Sumex II

Im folgenden werde ich nun die besuchte Unternehmung und eines ihrer Produkte vorstellen.

2.1 ELCA

300 Ingenieure aus 18 verschiedenen Ländern bilden zusammen das Software- Unternehmen ELCA mit Hauptsitz in Lausanne und Büros in Zürich, Bern, Genf, London und Ho-Chi-Minh-City. Ursprünglich war sie eine Tochterfirma der SBB, in den letzten Jahren wurde sie jedoch durch eine Management-Buyout suksessiv privatisiert. Der Umsatz wurde seit 1998 massiv gesteigert und lag im Geschäftsjahr 2000 bei über 42 Millionen CHF. Die Kundschaft erstreckt sich von der Verwaltung über Transportuntenehmen, Banken, Nahrungsmittelsektor bis zu Luftfahrt- und Telekomunternehmen. Enwickelt wird in Java / C++ / C# / Uniface.

(9)

2.2 Sumex II [6]

2.2.1 Anwendungsgebiet

Sumex II ist eine Software für Kranken- und Unfallversicherungen, die eingesandte Rechnungen, in elektronischer oder physischer Form, auf ihre Richtigkeit überprüft und dann die notwendigen Schritte veranlässt. Diese sind entweder Rückweisung, manuelle Vervollständigung oder elektronische Weiterbearbeitung im Rahmen der Buchhaltung und der Geschäftsprozesse der Versicherung. Die Rechnungen werden auf ihre Korrektheit in Abhängigkeit von TARMED[5], dem Tarif der FMH, getestet.

Dieser erlaubt neu eine Aufteilung der Leistung in einen medizinischen Teil, der Inhalt und Umfang der Leistung wiederspiegelt, und einen technischen Teil, der die Art und Weise der Rechnungslegung aufzeigt. Des weiteren wird der

Ausbildungsgrad und die zur Verfügung stehende Infrastruktur des Behandelnden in die Berechnung des Tarifes miteinbezogen. TARMED wurde auf Grund des

Krankenversicherungsgesetzes aus dem Jahre 1994 entwickelt.

2.2.2 Systemumgebung und Entwicklungstools

Sumex II ist ein datenbankbasiertes Java-Framework. Es addiert die Beträge auf den Rechnungen, multipiziert die verschiedenen TARMED-Faktoren und vergeicht die Daten der behandelnden Ärzte und deren Patienten mit den bereits erfassten. Die Datenbanken, die momentan unterstützt werden, sind DB2, Oracle und RTB. Im Projektmanagement werden verschiedene Tools eingesetzt. JBuilder für die

Entwicklung, CVS für das Versioning, JUnit für das Unittesting und GNATS für die Problemreports. Das zu Grunde liegende Betriebssystem ist Windows NT.

2.2.3 Entwicklungsgeschichte

Vor 2 1/2 Jahren wurde das Projekt ins Leben gerufen und ist im Moment in der Version 2 erhältlich. Es wurden sieben beta-Versionen erstellt, bis Version 1 released wurde. Sumex II wurde als Framework konzipiert, um es für verschiedene

Versicherungen einfach anpassen zu können.

(10)

3 Qualitätsmanagement und -sicherung bei Elca

Wie bereits erwähnt ist ELCA ISO 9001-zertifiziert. Durch die schnelleren Enwicklungszyklen und den grösseren Marktdruck in den letzten, vom eBusiness gezeichneten Jahren wird es immer wichtiger, dass eine Unternehmung parallele Abläufe in immer grösseren Projekten zu managen weiss. Effiziente Testverfahren und ein klares Risikomanagement sind die wohl wichtigsten Grundlagen.

3.1. Projektmanagement

Projekte werden bei der ELCA auf Spezialwünsche des Kunden hin gestartet.

Enwickelt wird nach dem Wasserfallmodell. Wichtig ist dabei die Uebersetzung der Kundenwünsche in eine für Softwareentwickler verständliche Sprache, dies geschieht durch die Abbildung der Prozesse in die Unified Modelling Language (UML) mit der Hilfe von Rational Rose. Meistens wird ein erster Prototyp erstellt, um dem Kunden die Möglichkeiten besser aufzeigen zu können. Danach wird mit Cocomo II eine Aufwandschätzung auf Grund von eigenen Erfahrungszahlen vorgenommen. Diese sind im Laufe der Zeit gesammelt worden. Einige wichtige Kennzahlen wären:

 # GUI-Masken oder Web-Seiten

 # Klassen und deren Methoden

 LoC / Testaufwand

 # Dokumentseiten

 # Sitzungsstunden

 # Code Reviews

Eine Offerte wird erstellte, die sich über den ganze Lebenszyklus einer Software (Entwicklung, Implementation und Wartung) erstreckt. Die Entwicklungsumgebung wird mit Hilfe von McCabe IQ2 modelliert. Die Einhaltung und Gestaltung aller Kriterien ist Sache des Projektleiters, erfolgt jedoch auf Grund von Vorgaben der Geschäftsleitung. Der Einsatz von Managementverfahren sollte sich im Vergleich zum effektive Aufwand im Optimum befinden um die gegebenen Ressourcen bestens ausnutzen zu können. Das Optimum lässt sich durch eigene Erfahrung und gesunden Menschenverstand abschätzen. Für ein zweimonatiges Projekt, das zwei Leute beschäftigt, lohnt es sich kaum mehr als ein paar Tage zu planen. Aber für eine Entwicklung, die ein halbes Jahr in Anspruch nimmt und mehr als zehn Leute beschäftigt, ist es klar, dass bis zu einem Monat oder mehr der Vorbereitung dienen.

(11)

3.2 Qualitätssicherung

ELCA verfügt über ein internes Qualitätshandbuch, in dem folgendes vorgegeben ist:

 Entwicklungsrichtlinien

 Managementaktivitäten (Projekt-, Change- und Konfigurationsmanagemnt)

 Kontrollaktivitäten (Statistiken, Tests und Enwicklungsprozess)

 Qualiätserhaltungsaktivitäten (Qualitätsbedürfnisse, Messkriterien und Qualitätsplan)

Des weiteren wurden spezifische Dokumente zur technischen Realisation und Entwicklung sowie zum Projektmanagement entwickelt, um ein einheitliches Vorgehen bei Projekten und die durchgehende Messbarkeit der Projektdaten zu gewährleisten. Über die Jahre können so die erfassten Metriken verfolgt werden und ergeben Anhaltspunkte für Verbesserungen. Damit lässt sich der komparative Wettbewerbsvorteil der ELCA erklären, der sich eindrücklich in den

Wachstumszahlen der letzten Jahre niederschlägt.

4 Testverfahren im Rahmen von Sumex II

Bevor das Projekt Sumex II in Angriff genommen wurde, hat man ein Testkonzept entwickelt. Es legt die Teststrategie und das Vorgehen bei der Planung von Tests im Projekt fest. Es werden jedoch keine konkreten Testfälle entwickelt. Ein solches planmässiges Vorgehen ermöglicht den effizienten Einsatz aller zur Verfügung stehenden Ressourcen.

4.1 Verfahren

Zuerst wird das genaue Vorgehen bestimmt um möglichst viele Fehler zu finden und zu überprüfen. In Verbindung mit dem zeitlichen Druck ergibt ein strukturiertes Vorgehen einen Rahmen, in dem die Fehler möglichst früh entdeckt werden sollen.

Wichtig ist auch das Kosten-Nutzen Verhältnis hinsichtlich des Testaufwandes. Als Grundlage dient eine Risikoanalyse, welche vorgibt, was zuerst getestet werden muss.

4.1.1 Vorgehen

Es werden vier Testphasen unterschieden: Unit-, Integrations-, Systemintegrations- und Abnahmetest, auf die in Kapitel 4.2 eingegangen wird. Die bereits besprochenen Testtypen werden festgelegt. Ein Testablauf wird detailliert bestimmt:

(12)

1. Ueberwachen der Testphase (Koordination) 1.1. Planung der Tests (Risikoanalyse, Zeitbedarf) 1.2. Prüfen des Testplanes (Vollständigkeit, Prioritäten) 1.3. Ueberwachen der Testfälle (aktuellen Stand überwachen)

1.3.1. Informationslieferant für Testfälle (Dokumentation) 1.3.2. Design der Testfälle (Notwendigkeit)

1.3.3. Schreiben der Testfälle 1.3.4. Prüfen der Testfälle 1.3.5. Vorbereiten der Testdaten

1.4. Ueberwachen der Testdurchführung (Verwaltung und Koordination) 1.4.1. Konfigurationsmanagement (Test-Version)

1.4.2. Zuständigkeit für Testumgebung (Ausrüstung)

1.4.3. Durchführen der Tests (Aufzeichnen Resultate und Dauer) 1.4.4. Change Management (Fehlerprioritäten)

1.4.5. Abschluss der Tests (oder abbrechen)

Diese Liste verdeutlicht jedoch nur die wichtigsten Aktivitäten und ist nicht als strenge sequentielle Abfolge zu verstehen, das Meiste findet parallel statt.

Die Testwerkzeuge werden festgelegt:

 Selbstgeschriebene Tools in Java (besonders heikel da selber geschrieben)

 Javascope (Coverage-Tool)

 Optimizelt (Performance für CPU und Speicher)

 Cyrano Workbench (Performance der Datenbank)

4.1.2 Risikoanalyse

Wichtige oder sehr komplexe Teile des Systems müssen identifiziert werden um die Wirksamkeit und Effizienz der Tests zu steigern. Prioritäten werden zugeteilt um bei plötzlichem Termindruck eine sinnvolle Auswahl treffen zu können. Das Risiko wird aus der Eintrittswahrscheinlichkeit und den Auswirkungen berechnet:

R = W * A

Die jeweiligen Skalen reichen von eins bis drei (unwahrscheinlich bis oft / klein bis gross). Es wird zwischen funktionalen (Klassen und Methoden) und nicht

(13)

funktionalen (Hardware, Daten, Datenmenge, Schnittstellen und Sicherheit) Risiken unterschieden. Die Priorität wird nun berechnet, wobei sich der Aufwand auf Stunden, respektive finanzielle Kosten bezieht:

Priorität = Risiko / Aufwand

Eine funktionale Risikoanalyse wird bei Integrations- und Systemintegrationstests durchgeführt, eine nicht funktionale Risikoanalye nur beim Systemintegrationstest.

Die Verantwortung und somit auch die Risikoanalyse für die Abnahmetests ist Sache des Kunden.

4.2 Testphasen

Die einzelnen Unittests finden sowohl bei der ELCA, als auch beim Kunden statt. Der Inegrationstest der ELCA-Units führt die ELCA alleine durch. Der

Systemintegrationstest wird gemeinsam mit den vom Kunden entwickelten Units gemacht. Der Abnahmetest entfällt alleine auf den Kunden. Bei Bestehen des Tests wird dies in einem Dokument festgehalten, um eventuell bei späteren rechtlichen Problemen darauf zurückgreifen zu können.

4.2.1 Unittests

Die in Kapitel 4.1.1 beschriebenen Aufgaben werden wie folgt wargenommen: 1, 1.1, 1.2, 1.3, 1.4.2 durch den Projektleiter, der Rest durch den Entwickler der einzelnen Units. Diese Units bestehen aus einem Modul, einer Klasse oder gar einer ganzen Kollektion von Klassen. Kritische Units werden in einer speziell dafür entworfenen Liste (Klassen/Package Name, Entwicklername, Testbeschrieb, Schnittstellen- übersicht, anderes) aufgeführt.

Ein Unit durchläuft normalerweise folgende Tests:

 Code Inspektion (nicht durch Enwickler, auf Klarheit und Verständlichkeit)

 Funktionale Tests (Testprogramme, Bottom-Up, Methoden als Blackbox)

 Coverage Tests (100% für kritische Units)

 Performance Tests

Die Testdurchführung wird gemäss einer Spezifikation für Testfiles dokumentiert.

Testdaten sind künstliche oder reale aber anonymisierte Daten.

(14)

4.2.2 Integrationstests

Der Uebergang zum Integrationstest ist fliessend, da schon Units zu immer grösseren Einheiten zusammengefasst werden. Es werden jedoch vor allem noch die

Schnittstellen in die Tests mit einbezogen. Von verschiedenen Teams entwickelte Teilsysteme werden zum erstenmal zusammentgefügt. Die in 4.1.1 beschriebenen Aufgaben werden wie folgt aufgeteilt. 1, 1.1, 1.2, 1.3, 1.3.2, 1.4, 1.4.2, 1.4.4, 1.4.5 Projektleiter; 1.3.3, 1.3.5, 1.4.1, 1.4.3 Entwickler; 1.3.1, 1.3.4 beide. Somit testet niemand mehr seinen eigenen Code, das Change Management obliegt nun ausschliesslich dem Projektleiter. Es wird wiederum eine Liste aller kritischen Komponenten (Komponentenname, Entwicklername, Testbeschrieb, Uebersicht Schnittstellen, Teilkomponentennamen, anderes) erstellt. Im Gegensatz zum Unittest ist der Zeitaufwand nicht mehr Teil der Entwicklungszeit, sondern wird separat berechnet.

Technische Anforderungen, Benutzeranforderungen und die Risikoanalyse sind die Grundlagen der Testfälle. Generell werden Blackbox-Tests angewandt. Die

durchgeführten Tests sind die folgenden:

 Funktionale Tests (gültige und ungültige Parameter)

 Performance Tests (z. T. schon bei Unittests)

 Stresstests

 Robustheitstests

 Langzeittests

Daten (Datenbank und Logfiles) werden in Stichproben inspiziert. Die Testphase ist abgeschlossen, wenn alle hochprioritären Tests und etwa 95% der niedrigprioritären durchgeführt sind. Die Probleme werden dokumentiert, das Risiko wird abgeschätzt, je eine Liste der durchgeführten Tests, der abgedeckten Anforderungen und der gemeldeten Problemmeldungen wird geführt.

4.2.3 Systemintegrationstests

Vor der Lieferung sollte das ganze System überprüft werden. Somit wird

gewährleistet, das alle technischen und alle Benutzeranforderungen erfüllt sind. Die Aufgaben nach 4.1.1 teilen sich wie folgt auf: 1, 1.1, 1.2, 1.3, 1.3.2, 1.4, 1.4.2, 1.4.4.,

(15)

1.4.5 Projektleiter; 1.3.3, 1.3.5, 1.4.1, 1.4.3 Entwickler; 1.3.1, 1.3.4 beide. Die separat beim Kunden und bei der ELCA entwickelten Teilsysteme werden zusammengeführt und getestet. Im Gegensatz zum Integrationstest werden auch „grossmassstäbliche“

Tests durchgeführt. Dadurch werden die optimale Dimensionierung und

Konfiguration des Systems, sowie potentielle Leistungsprobleme und Riskien erkannt.

Folgende grossmassstäbliche Tests werden mit realen aber anonymisierten Daten durchgeführt:

 Simulation von grossen Lasten

 Messung der Performance bei Lastspitzen

 Test betreffend Langzeitverhalten

 Test betreffend Ressourcenverbrauch

 Tests betreffend Robustheit (Verfügbarkeit, Gewährleistung der Datenintegrität, Verhalten bei Pannen).

Die Ablaufplanung und Durchführung erfolgt analog zum Integrationstest, ebenso verhält es sich mit den Testfiles.

4.2.4 Abnahmetests

Nach der Lieferung des Systems werden die Abnahmetests vom Auftraggeber durchgeführt. Eventuell wird der Produzent zur Abwicklung des Tests beigezogen.

Gewisse Funktionalitäten können erst beim Abnehmer getestet werden. Daher wird zuerst ein Pilottest durchgeführt, damit sichergestellt wird, dass auch eventuelle kritische Geschäftsprozesse erfolgreich abgewickelt werden können. Die Planung, Durchführung und Dokumentation erfolgt analog zum Integrations- oder

Systemintegrationstest.

4.2.5 Vorlagen

Folgende Vorlagen können während der Tests benutzt werden, um das Erstellen von Dokumenten zu erleichtern:

 Komponentenliste (Unittest (UT), Inegrationstest (IT), Systeminegrationstest (ST), Abnahmetest (AT))

 Testliste (UT)

 Code Review Report (UT)

 Testfall (IT, ST, AT)

(16)

 Liste durchgeführter Tests (IT, ST, AT)

 Abdeckung der Anforderungen (IT, ST, AT)

 Liste von Problem und Fehlermeldung (IT, ST, AT)

 Vorlage für Problem und Fehlermeldung (IT, ST, AT)

 Checkliste für Testbereitschaft (IT, ST, AT)

Fazit

Die obigen Ausführungen geben einen kleinen und sehr spezifischen Einblick in die praktische Welt des Qualitätsmanagments und des Softwaretestens. Leider ist es nicht möglich allgemein gültige Aussagen zu machen. Jedes Problem verlangt nach seiner eigenen Lösung und auch nach einer eigenen Umgebung, in der es gelöst wird. Ein Vorgehen wie eben beschrieben lässt sich nur für grosse Projekte mit einer Laufzeit von mehreren Monaten verwirklichen. Bei kleinen Projekten testet jeder für sich selber und schlussendlich wird integriert, meist ohne grosse Schnittstellenprobleme.

Und wenn doch, dann lassen sich diese meist schneller anpassen, als dass eine passende Testumgebung entwickelt werden kann.

Mir hat der Einblick in eine grosse Softwareentwicklungsfirma mit strukturierten Abläufen und einem klaren Ziel sehr viel Spass gemacht. Und ich hoffe, dass ich die dabei gewonnenen Erkenntnisse auch selber einmal einzusetzen weiss.

(17)

Literatur:

[1] http://www.iso.ch/iso/en/iso9000-14000/iso9000/qmp.html (2002) [2] Boehm, Barry und andere (seit 1998), Modelentwurf erhältlich unter

ftp://ftp.usc.edu/pub/soft_engineering/COCOMOII/cocomo99.0/modelman.pdf (2002) [3] http://www.mccabe.com/products/mccabe_iq.htm (2002)

[4] http://www.elca.ch/Home/1.html (2002)

[5] http://www.tarmed.ch/deutsch/i_infos/i_aus_f.htm (2002) [6] Pfister, A. (2001) Testkonzept und -plan zu Sumex II

Referenzen

ÄHNLICHE DOKUMENTE

Zeller Linus Krumrey 9 Template Meta-programming for Haskell Mathias. Weber Johannes Schultz 12 Parsing - Parser

Vortrag (ca 45min + Diskussion) + Ausarbeitung (ca 12-15 S.), 3 LP Allgemeine Einf ¨uhrung zum Thema heute..

Sobald alle Variablen eines Systems private sind und nur von den klasseneigenen Methoden verändert werden können, steigt nicht nur die Wiederverwendbarkeit dieser Services, sondern

Wir müssen sie unterstützen: einmal durch Medien- nutzung- oder auch Medienunterricht in den Schulen und seitens der Ministerien oder anderer Institutio- nen durch Tipps,

Gilli, als Ärztin setzen Sie sich in der Praxis und im Nationalrat für die Kom- plementärmedizin ein.. Welche Art von Komplementärmedizin setzen Sie als

574/72 wird für die Umrechnung von auf eine Währung lautenden Beträgen in eine andere Währung der von der Kommission errechnete Kurs verwendet, der sich auf das

Aus den knapp zehn Jahren Erfahrung mit der Prävalenzmessung können Herausforderungen beim Messen von Qualität auf na- tionaler Ebene abgeleitet und Empfehlungen zu deren

Diese Platten berühren sich in der Mauermitte nicht, sind aber, an den Stossfugen nur in einem Saums_chlage sich berührend, auf das engste schliessend gearbeitet.. Auch in den