Messprogramm zur Minimierung der Fehlerrate in der Produktion des Produkts Top-Logic von Bauer & Partner Application2Web AP6

Größe: px
Ab Seite anzeigen:

Download "Messprogramm zur Minimierung der Fehlerrate in der Produktion des Produkts Top-Logic von Bauer & Partner Application2Web AP6"

Transkript

1 Messprogramm zur Minimierung der Fehlerrate in der Produktion des Produkts Top-Logic von Bauer & Partner Application2Web AP6 Autoren: Bernd Freimut (IESE) Jochen Hiller (Bauer & Partner) Ralf Kalmar (IESE) Teade Punter (IESE) Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministerium für Wirtschaft und Technologie unter den Förderkennzeichen 16IN0047 und 16IN0048 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. IESE-Report Nr /D Version Dezember, 2002 Eine Publikation des Fraunhofer IESE

2

3 Das Fraunhofer IESE ist ein Institut der Fraunhofer-Gesellschaft. Das Institut überträgt innovative Software-Entwicklungstechniken, -Methoden und -Werkzeuge in die industrielle Praxis. Es hilft Unternehmen, bedarfsgerechte Software-Kompetenzen aufzubauen und eine wettbewerbsfähige Marktposition zu erlangen. Das Fraunhofer IESE steht unter der Leitung von Prof. Dr. Dieter Rombach Sauerwiesen Kaiserslautern

4

5 Abstract Dieses Arbeitspapier dokumentiert Ziele, Fragen und Metriken gemäß der GQM-Methode und beschreibt die Erfassung und Auswertung der Messdaten eines Messprogramms, welches begleitend zu einem Entwicklungsprojekt der Bauer & Partner GmbH im Jahr 2002 durchgeführt wurde. Die Ziele von Bauer & Partner bestanden dabei im Kennenlernen und Erproben der messbasierten Verbesserung im Allgemeinen und der Erreichung des Verbesserungsziels Minimierung der Fehlerrate im Speziellen. Der Bericht dokumentiert dabei die Ergebnisse des Arbeitspakets 6.2 des Projekts Application2Web, in dessen Kontext diese Arbeiten durchgeführt wurden. Schlagworte: GQM, Metriken, Fehler, Regressionstest i

6

7 Inhaltsverzeichnis 1 Übersicht Einordnung Vorgehen Inhalt des Dokuments 2 2 Ziele Verbesserungsziel Messziel 4 3 Spezifikation der Messungen Fragen zu Qualitätsaspekten Fragen zu Einflussfaktoren auf die Qualitätsaspekte (engl. Variation Factor) 12 4 Messplan Auswahl der zu erfassenden Metriken Datenquellen und Messmethode Planung Datenerfassung Datenanalyse Interpretation der Daten 16 5 Ergebnisse Datenerfassung Interpretation der Ergebnisse Vollständigkeit der Datenerfassung Fehlerschwerpunkte im System Einfluss der Testabdeckung von Regressionstests Fehlerursache Auswirkung der Fehler Abgeleitete Maßnahmen Bewertung der Vorgehensweise und der Ergebnisse 20 Anhang A Datenerfassungsbögen 21 A.1 Projektcharakterisierung 21 A.2 Fehlererfassung 21 Anhang B Detaillierte Definition der Attribute zur Charakterisierung der Fehler. 24 iii

8 B.1 Defect Type (Defect Type for Target=Design/Code) 24 B.2 QUALIFIER (applies to Defect Type) 26 B.3 Impact 26 B.4 Location 26 B.5 Effort 27 B.6 Test-coverage 27 Anhang C Prozessübersicht Integrationstest 28 Anhang D Referenzen 29 iv Copyright Fraunhofer IESE 2001

9 1 Übersicht 1.1 Einordnung Das von BMWI und VDI geförderte Projekt Application2Web unterstützt Firmen methodisch bei der Implementierung/Portierung von Web-fähigen Applikationen. Bauer & Partner ist ein Mitglied des Projekt-Konsortiums, welches vom Forschungszentrum Informatik (FZI) und Fraunhofer Institut für Experimentelles Software-Engineering (IESE) geleitet wird. Ein Arbeitspaket des Projekts beschäftigt sich mit Qualitäts- und Prozessmanagement. Im Rahmen dieses Arbeitspaketes arbeiten Bauer & Partner und IESE zusammen an der Implementierung von Software- Metriken zur Prozess- und Produktverbesserung, die auf Basis des Goal- Question-Metrik Paradigmas (GQM) [vsol99] ermittelt und ausgewertet werden sollen. Dieses Arbeitspapier dokumentiert Ziele, Fragen und Metriken gemäß der GQM-Methode und beschreibt die Erfassung und Auswertung der Messdaten zur Unterstützung des Verbesserungsziels Minimierung der Fehlerrate des Produkts Top-Logic in der Produktion. Top-Logic ist Element einer größeren Produktfamilie. Da die Grundstruktur der Produkte und die Entwicklungsprozesse innerhalb der Familie gleich sind, können die hier dokumentierten Fragen und Metriken auch einfach auf entsprechende Messziele von anderen Mitgliedern der Produktfamilie angepasst werden. 1.2 Vorgehen Das Vorgehen hält sich an die beim Fraunhofer IESE etablierte und mehrfach erfolgreiche Anwendung des GQM-Ansatzes zur messbasierten Prozessverbesserung, der nachfolgend grob skizziert wird und in Abbildung 1 auf Seite 2 grafisch dargestellt ist. Gemeinsam mit Bauer & Partner wurde zunächst ein Verbesserungsziel definiert. Die Erreichung des Verbesserungsziels soll mit Hilfe von Messdaten unterstützt werden. Hierzu wurde ein Messziel abgeleitet, welches charakterisiert, welcher Aspekt des Entwicklungsprozesses zu welchem Zweck und unter welchem Gesichtspunkt mittels Messung untersucht werden soll. Der betroffene Teil des Entwicklungsprozesses wurde grafisch modelliert und dokumentiert. Mit Hilfe eines Interviews bei Bauer & Partner wurden für das Messziel Qualitätscharakteristika und Einflussfaktoren identifiziert, welche in Fragen formuliert wurden.hypothesen zu den möglichen Antworten charakterisierten das implizite Wissen. Aus den Fragen wurden die nötigen quantitativen und qualitativen Informationen abgeleitet, die zur Beantwortung nötig sind (in Form von Metriken). 1

10 Ausblick (die nächsten Schritte sind nicht mehr Teil dieses Dokuments): Nach Planung der Datensammlung werden Daten erfasst und eine Auswertung und Analyse der Messdaten erfolgt. Die Messdaten werden zur Entscheidungsunterstützung für die Ableitung von Prozessoptimierungen und Verbesserungsmaßnahmen genutzt. Verbesserungsziel validieren Verbesserung Messziel Fragen zum Ziel Interpretation Analyse Hypothesen zu Antw. Metriken für Antworten validieren Messdaten Datenerfassung Abbildung 1: Übersicht zum Vorgehen 1.3 Inhalt des Dokuments Die nachfolgenden Kapitel dokumentieren das in Abschnitt 1.2 beschriebene Vorgehen. Kapitel 2 enthält das Verbesserungsziel, sowie das daraus abgeleitete Messziel, Kapitel 3 die abgeleiteten Fragen und die Metriken zum Messziel. Die Durchführung der Messungen ist in Kapitel 4 beschrieben. Die Ergebnisse und Analysen der Messdaten sind nicht Teil dieses Dokuments. Die Anhänge enthalten Datenerfassungsbögen, eine Prozessübersicht zum Integrationstest, eine Liste mit Literaturreferenzen, Details zur Fehlerklassifikation und ein Glossar. 2 Copyright Fraunhofer IESE 2001

11 2 Ziele Dieses Kapitel charakterisiert die Ziele des Projekts. Neben dem übergeordneten Verbesserungsziel wird das daraus abgeleitete Messziel definiert, welches den Ausgangspunkt für die Definition von Metriken darstellt Verbesserungsziel Das folgende Verbesserungsziel wurde definiert: Minimierung der Fehlerrate des Produkts Top-Logic in der Produktion. Definition Fehlerrate: Anzahl der in der Produktion 2 gefundenen bzw. gemeldeten Fehler pro Zeiteinheit. Die Minimierung soll erreicht werden durch eine Optimierung (Verbesserung) des Integrationstests und dort insbesondere der Regressionstests. Jeder Fehler, der bereits vor der Produktion gefunden und behoben wird, verringert die Gesamtfehlerrate in der Produktion. Dabei wird angenommen, dass während der Entwicklung eine konstante Anzahl von Fehlern in das System eingebracht werden. Daher bedeutet eine Erhöhung der gefundenen Fehler im Test eine Minimierung der Produktionsfehler. Man kann das Verbesserungsziel deshalb umformulieren zu: Minimierung des Anteils der in der Produktion gefundenen Fehler von der Gesamtfehlerzahl. min! [Produktionsfehler] / ([Integrationstestfehler] + [Produktionsfehler]), x% der in Integrationstest und Produktion entdeckten Fehler entfallen auf die Produktion Definition Produktionsfehler: Anzahl der in der Produktion gefundenen bzw. gemeldeten Fehler. Definition Integrationstestfehler: Anzahl der während des Integrationstests gefundenen bzw. gemeldeten Fehler. Bei Bauer & Partner wird über die Maßnahme Durchführung von Regressionstests versucht, die Testqualität zu verbessern. Deshalb soll die Einführung dieser Maßnahme über mehrere Releases mit Messungen beobachtet werden, um positive Effekte des Regressionstest zu 1 Bemerkung: neben dem hier dargestellten Verbesserungsziel bzgl. des Integrationstestprozesses wurde noch ein weiteres Verbesserungsziel Zuverlässigkeit bzgl. des Produkts Top-Logic definiert, welches erst später weiter verfolgt werden soll. 2 Unter Produktion wird hier die Zeitraum verstanden, in dem das Produkt im Betrieb beim Kunden eingesetzt wird, d.h. die Entwicklung (und damit alle entwicklungsinternen Tests) abgeschlossen sind. 3

12 dokumentieren und mit weiteren Maßnahmen schlussendlich eine Minimierung der Fehlerrate zu erreichen. 2.2 Messziel Das folgende Messziel wurde zur Unterstützung des Verbesserungsziels mit konkreten Messdaten aufgestellt. Für eine Minimierung ist es notwendig den aktuellen Stand, sowie die Ergebnisse nach zukünftigen Maßnahmen zu kennen: Charakterisiere die Qualität des Regressionstest für das Produkt Top- Logic aus Sicht des verantwortlichen Projektleiters. Qualitätsfaktor Unter Qualität des Regressionstest wird verstanden: Anzahl und Art der entdeckten Fehler (daraus lässt sich der prozentuale Anteil der mit Regressionstests gefundenen Fehler von der Gesamtfehlerzahl ermitteln). Testabdeckung (eine ausreichende Anzahl Testfälle existiert für jede funktionale Anforderung) Verhältnismäßigkeit der Tests (Aufwand Kodierung/Aufwand Test), Stichwort design for testability Zu messendes Objekt Zentrales Objekt der Untersuchung ist der Regressionstest. Regressionstests werden im Top-Logic Projekt nach dem JUnit-Framework mit dem gleichnamigen frei erhältlichen Tool JUnit-TestRunner durchgeführt. Auch ein Teil der grafischen Oberfläche wird mittels HttpUnit einem GUI- Regressionstest unterzogen. Um die Qualität der Regressionstests im Integrationstest besser beurteilen zu können, werden entdeckte Fehler von den folgenden Testprozessen (im Sinne des Entdeckungszeitpunkts) betrachtet (das Produkt in Produktion ist mit aufgeführt, damit die Gesamtfehlerzahl bestimmt werden kann): 4 Copyright Fraunhofer IESE 2001

13 Für das Messziel relevante Prozessschritte Integrationstestprozess Produktion Fehlerprotokoll (für Fehler in freigegebenen Klassen) Code-Review Trouble-Ticket System Implementierung/ Korr. Komponententest Check-In (Freigabe der Klasse) Bug-Review JUnit-Systemtest (Regressionstest) GUI-Test GUI-Regressionstest System in Produktion Fehlerprotokoll Legende Fehlerquelle Kontrollfluss Messen der Anzahl der Fehler Abbildung 2: Für die Messung relevante Teile des Entwicklungsprozesses Eine Übersicht zum gesamten Integrationstestprozess ist im Anhang C enthalten. Zielumgebung Top-Logic ist eine Plattform für Wissensmanagementsysteme. Top-Logic wird von einem Entwicklungsteam mit ca Entwicklern umgesetzt. Es handelt sich um eine webbasierte Anwendung, die auf Basis von Java Technologien (J2SE, J2EE) entwickelt wird. Die Plattform setzt auf generische Ansätze wie flexible Modelle durch änderbare Metaschemata, einsteckbare Komponenten und Services, Portalelemente, Workflows, Regeln etc. Zusätzlich zur Top-Logic Wissensmanagement-Plattform werden Lösungen auf Basis dieser Plattform entwickelt, die den Kunden bereitgestellt werden. Hier sind nochmals ca Entwickler beteiligt. Die Top-Logic Plattform besteht aus mehr als 2000 Java-Klassen, sowie mehr als 2000 Oberfächenelementen (JSP s, HTML). Eine Lösung besteht typischerweise aus mehr als 400 Klassen und mehr als 500 Oberflächenelementen. Alle Entwickler arbeiten sehr eng zusammen. Die Entwicklung findet in gemeinsamen Büroräumen statt, was eine hohe Teamkommunikation ermöglicht. Der Entwicklungsprozess basiert auf einer iterativen Vorgehensweise (auf Basis des Rational Unified Process (RUP)). Es werden kurze Iterationszyklen von ca. 3-4 Wochen definiert. Neue Produktreleases erscheinen 3-4 mal pro Jahr, dabei ist ein Major-Release. Wesentlicher Bestandteil des Entwicklungsprozesses ist eine testzentrierte Vorgehensweise, wie sie auch im Extreme Programming (XP) Paradigma definiert ist. Die Entwickler schreiben auf Basis von JUnit Entwicklertests, die 5

14 in einer Gesamttestsuite als Regressionstest reproduzierbar ausgeführt werden könnnen. Dies geschieht mindestens einmal pro Woche, in der Regel aber täglich als Teil des nächtlichen Build-Prozesses. Diese idealtypische Prozess wird nicht von allen Entwicklern gleichermaßen gut gelebt. Einzelne Komponenten sind sehr gut durch Regressionstests abgedeckt, während für andere Komponenten fast überhaupt keine Regressionstests existieren. Hier spielen Einflüssen wie die Akzeptanz der Vorgehensweise durch einen Entwickler, Aufwände für Regressionstests sowie die aktuelle Projektsituation mit Lieferterminen eine wesentliche Rolle. Rollen Es sind im Wesentlichen zwei Rollen für das Messziel relevant: der Entwickler/Tester und der Projektverantwortliche. Die Rolle des Testers bezieht sich hier auf Entwickler-Tests, es werden im Moment aufgrund der Projektgrößen keine fachlichen Abnahmetests berücksichtigt. Das Messziel ist aus Sicht des Projektverantwortlichen zu sehen, der gleichzeitig die Rolle eines Process Owners (d.h. Prozessverantwortlicher) innehat. Es ist abzusehen, dass auch die Entwickler/Tester bei der Datenerfassung involviert werden, da sie die Fehlerbehebung vornehmen (s. auch Darstellung des Integrationstestprozesses in Anhang C). 6 Copyright Fraunhofer IESE 2001

15 3 Spezifikation der Messungen Dieses Kapitel enthält eine Auflistung aller Fragen, deren Beantwortung die Erreichung des Messziels unterstützen. Die Fragen sind gruppiert bzgl. des Qualitätsaspekts und bzgl. der Einflussfaktoren. Fragen, die den Qualitätsaspekt betreffen beziehen sich direkt auf die Qualität des Regressionstests. Fragen zu den sogenannten Einflussfaktoren beziehen sich auf Umgebungscharakteristika, die einen Qualitätsaspekt positiv oder negativ beeinflussen (z.b. die Erfahrung eines Entwicklers beeinflusst die Entwicklungszeit, d.h. Entwickler entwickeln schneller mit längerer Erfahrung). Qualitätsaspekte und Einflussfaktoren wurden in einem Interview mit dem Projektverantwortlichen und einem erfahrenen Entwickler ermittelt. Die tatsächlich erfassten Metriken und damit die Fragen, welche beantwortet werden können, sind im Messplan (Kapitel 4) aufgeführt Fragen zu Qualitätsaspekten Fehleranzahl QF 1 Wie viele Fehler wurden in den folgenden Prozessen gefunden (absolut und relativ für ein Release): Komponententest, Code-Review, Regressionstests, GUI-Test, GUI-Regressionstest, Bug-Review, Produktion? Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion Wie viele Fehler wurden gefunden? Produkt Datum TopLogic R Fehlerzahl Komponententest Regressionstest GUI-Tests GUI-Regressionstests Produktion Prozess 7

16 (b) QF 1 GUI-Regressionstests 4% Wie viele Fehler wurden gefunden? Produktion 9% Komponententest 29% Produkt Datum TopLogic R GUI-Tests 15% Regressionstest 43% Metrik Hypothese Bemerkung Defect_Count: Anzahl der Fehler pro Woche je Prozess (s.o.) Daten aus Produktionsphase sind erst nach Entwicklungsabschluss verfügbar Fehlerattribute QF 2 Was war die Fehlerursache für die in den Prozessen Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest, Produktion entdeckten Fehler? (Verteilung je Prozess und Gegenüberstellung mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 2 Was war die Fehlerursache? 100% 80% Produkt TopLogic R3 Datum Fehlerzahl 60% 40% 20% Ursache 5 Ursache 4 Ursache 3 Ursache 2 Ursache 1 0% Komponententest Regressionstest GUI-Tests GUI- Regressionstests Prozess Produktion Metrik Hypothese Defect_TestReliability Klassifikation jedes erfassten Fehlers nach seiner Ursache im Hinblick auf das Vorhandensein eines Testfalls: Skala: No tests Tests incomplete Tests raised 8 Copyright Fraunhofer IESE 2001

17 QF 3 Bemerkung Daten aus Produktionsphase sind erst nach Entwicklungsabschluss verfügbar Wie hoch war der Aufwand für die Fehlerkorrektur der in den Prozessen Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest, Produktion entdeckten Fehler? (Verteilung absolut/relativ je Prozess und im Vergleich mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 3 Wie lange dauerten Fehlersuche und -behebung? 100% 90% 80% 70% Produkt TopLogic R3 Datum Fehlerzahl 60% 50% 40% >1 Tag <1 Tag <1h 30% 27 20% 10% 0% Komponententest Regressionstest GUI-Tests GUI- Regressionstests Prozess 2 Produktion QF 4 Metrik Hypothese Bemerkung Defect_ETR Klassifikation jedes entdeckten Fehlers nach Aufwand zur Fehlersuche und Fehlerbehebung (Effort to Repair, ETR): Skala: small (<1h), medium (<0.5 day), large (>=0.5 day) Es ist kein Ziel den Gesamtaufwand zur Fehlersuche/- behebung zu erfassen. Wie hoch war die Schwere (Auswirkung, impact) der Fehler der in den Prozessen Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest, Produktion entdeckten Fehler? (Verteilung absolut/relativ je Prozess und im Vergleich mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 4 Wie war die Schwere der Fehler verteilt? 100% 90% 80% 70% Produkt TopLogic R3 Datum Fehlerzahl 60% 50% 40% 30% critical major minor 20% 10% 0% 2 Komponententest Regressionstest GUI-Tests GUI- Regressionstests 2 Prozess Produktion Alle Daten sind rein fiktiv! 9

18 Metrik Hypothese Bemerkung Defect_Impact Klassifikation jedes entdeckten Fehlers nach seiner Schwere aus Kundensicht: Skala: Component Functionality System/Application Workaround No Relevance Frage könnte noch in Unterfragen verfeinert werden: z.b. In welcher Phase wurden die meisten kritischen Fehler entdeckt? QF 5 Welche Fehlertypen wurden in den Prozessen Komponententest, Regressionstest, GUI-Test, Produktion entdeckt? (Verteilung absolut/relativ je Prozess und im Vergleich mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 5-1 Worin lag die Fehlerursache? - Fehlerbehebung Fehlerzahl Komponententest 2 9 Regressionstest GUI-Tests 3 90 GUI-Regressionstests 8 22 Produktion Functionality Checking Interfaces Concurrency Design Produkt TopLogic R3 Datum Checking Functionality Design Concurrency Interfaces Alle Daten sind rein fiktiv! (b) QF 5-2 Worin lag die Fehlerursache? - Art der Behebung Fehlerzahl 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Komponententest Regressionstest GUI-Tests GUI- Regressionstests Prozess Produkt TopLogic R3 Datum unnecessary incorrect missing 2 4 Produktion Alle Daten sind rein fiktiv! Metrik Defect_Type: Klassifikation jedes entdeckten Fehlers nach Art der Korrektur (Art) Skala (angelehnt an ODC/type): Requirements Robustness Functionality 10 Copyright Fraunhofer IESE 2001

19 Design Concurrency Interfaces Ext. comp. Defect_Qualifier: Klassifikation jedes entdeckten Fehlers nach Art der Korrektur (Aktion) Hypothese Bemerkung Skala (angelehnt an ODC/qualifier): Missing Incorrect Out of Scope Frage könnte noch in Unterfragen verfeinert werden: z.b. Verteilung von Impact ohne Fehler mit Qualifier externer Ursache usw. QF 6 Wie waren die in den Prozessen Komponententest, Regressionstest, GUI-Test, Produktion entdeckten Fehler bzgl. des Fehlerorts, d.h. die betroffende Anwendungs-Komponente, d.h. der ursächlichen Produktkomponente verteilt? Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 6 Wie verteilen sich die Fehler auf Komponenten? GUI 30% User-.Access- Management 2% Reports 17% DataAccess-Layer 6% Sonstige (mit kurzer Angabe) 1% KnowledgeBase 3% Produkt Datum TopLogic R KnowledgeClassification 41% Alle Daten sind rein fiktiv! Metrik Defect_Location Klassifikation jedes entdeckten Fehlers nach der Komponente, in der er behoben wurde. Skala: ContentAssistent Data Access Layer GUI Knowledge Base Other Search Security Wrapper WebDAV Sonstige (mit kurzer Angabe) 11

20 Hypothese Bemerkung Testabdeckung QF 7 Wie hoch ist die Testabdeckung einer einzelnen Anwendungs-Komponente? Unter Testabdeckung versteht man den prozentualen Anteil der mit Testfällen abgedeckten funktionalen Anforderungen. Objekt Indikator Metrik Hypothese Bemerkung Komponente Bei allen Komponenten: Scatter-Plot Test_Coverage Abschätzung insgesamt und für jede Komponente, wie hoch der Grad der Testabdeckung mittels Regressionstests (?) ist. Skala: rational Coverage_Java=(# JUnit Test-classes / # other classes) Coverage_JSP=(#HttpUnit Test-classes / # JSPpages+# Servlet)) Coverage_Java=40% Coverage_JSP=2-3% Fragen zu Einflussfaktoren auf die Qualitätsaspekte (engl. Variation Factor) VF 1 ErfahrungWie groß ist die Erfahrung der Entwickler/Tester im Projektteam? Objekt Indikator Entwickler und Tester Tabelle high medium low Entwickler Tester Metrik Hypothese Experience Abschätzung für jeden Entwickler und Tester, wie hoch die Erfahrung in Bezug auf die Softwareentwicklung und die verwendete Technologie ist. Skala: Principal Senior Junior Je größer die Erfahrung, desto weniger Aufwand für die Fehlerbehebung. 12 Copyright Fraunhofer IESE 2001

21 Je größer die Erfahrung, desto größer die Testabdeckung. Je größer die Erfahrung, desto weniger Fehler im entwickelten Code. Bemerkung Der Aufwand für die Fehlerkorrektur wird nicht absolut erfasst und kann nur grob geschätzt werden (s. QF1) Die vermuteten Zusammenhänge können erst mit Daten von mehreren Projekten überprüft werden. Die erhobenen Daten werden auch zur Projektcharakterisierung gezählt und werden für die Interpretation der Qualitätsfaktoren hinzugezogen. Zeitdruck VF 2 Wie hoch ist der Zeitdruck auf die Entwickler/Tester für die Fertigstellung einzelner Produktkomponenten? Objekt Indikator Metrik Hypothese Entwickler und Tester Bei allen Komponenten: Scatter-Plot Work_Pressure Abschätzung für jede Komponente, wie hoch der Projektdruck für die Entwicklung war. Skala: high normal Je größer der Zeitdruck, desto geringer die Testabdeckung. Je größer der Zeitdruck, desto mehr Fehler im entwickelten Code. Bemerkung Die vermuteten Zusammenhänge können erst mit Daten von mehreren Projekten überprüft werden. Die erhobenen Daten werden auch zur Projektcharakterisierung gezählt und werden für die Interpretation der Qualitätsfaktoren hinzugezogen. Komplexität VF 3 Wie hoch ist die Komplexität einer Klasse/einer Systemkomponente? Objekt Indikator Metrik Hypothese Klasse/Systemkomponente Tabelle; bei allen Komponenten: Scatter-Plot Complexity Abschätzung, wie hoch ihre Komplexität in Bezug auf die Aufgabenstellung im Projekt ist. Skala: high medium low Je höher die Komplexität, desto höher die Fehlerzahl. J höh di K l ität d t h A f d fü di 13

22 Je höher die Komplexität, desto mehr Aufwand für die Fehlerkorrektur. Bemerkung Die vermuteten Zusammenhänge können erst mit Daten von mehreren Projekten überprüft werden. Der Aufwand für die Fehlerkorrektur wird nicht absolut erfasst und kann nur grob geschätzt werden (s. QF1) Die erhobenen Daten werden auch zur Projektcharakterisierung gezählt und werden für die Interpretation der Qualitätsfaktoren hinzugezogen. 14 Copyright Fraunhofer IESE 2001

23 4 Messplan Der Messplan beschreibt welche Metriken erfasst werden, von wem und auf welche Art und Weise die Erfassung geschieht, und wann die Daten erfasst werden. 4.1 Auswahl der zu erfassenden Metriken Alle der in Kapitel 3 aufgeführten Metriken werden erfasst. 4.2 Datenquellen und Messmethode Die benötigten Daten werden von den Projektmitarbeitern geliefert. Allgemeine Informationen werden vom Projektleiter abgefragt, Daten zu Fehlern liefern die Entwickler. Alle Daten werden zunächst mittels Fragebögen auf Papier erfasst. Eine elektronische Datenerfassung wird jedoch mittelfristig angestrebt. Die Datenerfassung erfolgt in englischer Sprache. Entwürfe für die Datenerfassungsfragebögen sind in Anhang A enthalten. 4.3 Planung Datenerfassung Charakterisierung Das Projekt wird vom Projektleiter zu Beginn des Projektes charakterisiert, um den Kontext der Datenerfassung (z.b. allgemeine Einflussfaktoren) festzuhalten. Hierzu ist vom Projektleiter ein Projektcharakterisierungsbogen auszufüllen (s. Abschnitt A.1). Zum Ende des Projekts werden die Daten noch einmal kontrolliert und ggf. aktualisiert. Fehlererfassung Für jeden behobenen Fehler wird vom Entwickler ein Eintrag in einen Fehlererfassungsbogen vorgenommen (s. Abschnitt A.2). Da die meisten Daten erst zum Ende der Fehlerbehebung vorliegen, sollten Eintragen nach einer erfolgreichen Fehlerbehebung erfolgen. Je Entwickler ist ein eigener Fragebogen zu verwenden. Die Fragebögen werden wöchentlich an eine Person weitergeleitet. Die Daten aus den Fragebögen werden in eine einfache Datenbank übertragen, die eine einfach Aggregation und Analyse erlaubt. 15

24 Abbildung 3 Testabdeckung Eingabemaske zur Übertragung der Fragebögen in eine Datenbank (MS Access) Daten, die zur Ermittlung der allgemeinen Testabdeckung dienen, werden wöchentlich beim Build-Prozess automatisch extrahiert und in elektronischer Form weitergegeben. Die Testabdeckung pro Komponente wird einmal pro Monat abgeschätzt Datenanalyse Die Auswertung und Erzeugung aufbereiteter Diagramme erfolgt nach Bedarf, angepasst an Termine für die Interpretation sowie den Projektverlauf. Eine Intervall von mehr als zwei Monaten sollte jedoch nicht überschritten werden. Eine Verfolgung der Datenvollständigkeit und korrektheit wird wöchentlich durchgeführt, um die Validität der erfassten Daten und damit den Erfolg der Messungen insgesamt zu kontrollieren und zu steuern Interpretation der Daten Die Interpretation der Daten im Hinblick auf das Messziel und das Verbesserungsziel. Die Daten werden gemeinsam von den Datenlieferanten (Projektleiter, Entwickler) und dem Stakeholder (hier der Projektleiter) bewertet und interpretiert. Eine Interpretation der Daten erfolgt mindestens einmal nach der Produktfreigabe, sowie zur Kontrolle der Qualität hinsichtlich der in der Betriebsphase entdeckten Fehler zwei Monate (?) nach Produktfreigabe. 16 Copyright Fraunhofer IESE 2001

25 5 Ergebnisse 5.1 Datenerfassung Begleitend zu einem konkreten Projekt zur Erstellung einer Web-Applikation wurden im Zeitraum Mai-August 2002 Daten gemäß des spezifizierten Messplans erfasst. Die Erfassung endete zwei Wochen nach Auslieferung des Produkts. Insgesamt wurden so 115 Fehler erfasst und dokumentiert. Die Daten wurden anhand der spezifizierten Fragen aggregiert und grafisch aufbereitet dargestellt. 5.2 Interpretation der Ergebnisse Die Ergebnisse wurden zweimal, am und am im Projektteam besprochen und interpretiert. Dabei ergaben sich einige interessante Diskussionen in Bezug auf den Entwicklungsprozess und die Qualitätseigenschaften des Produkts. Einige der Ergebnisse sind hier beispielhaft zusammen mit ihrer Interpretation aufgeführt: Vollständigkeit der Datenerfassung Die Vollständigkeit der erfassten Daten wird auf 30-50% geschätzt. Die niedrige Rate wird auf die geringe Zeit im Projekt und den für die Beteiligten ungewohnten Prozessschritt Datenerfassung zurückgeführt. Aufgrund der fehlenden Daten konnten die Werte nicht hinsichtlich absoluter Werte interpretiert werden. Allen Interpretationen liegt die Annahme zugrunde, dass die erfassten 40-50% repräsentativ für alle entdeckten Softwarefehler sind. 17

26 5.2.2 Fehlerschwerpunkte im System QF 6 Wie verteilen sich die Fehler auf Komponenten? Other 18% Search 7% Security 7% WebDAV 3% Wrapper 9% Produkt Datum TopLogic R ContentAssistent 6% Knowledge Base 6% Data Access Layer 8% GUI 36% Auswertung Die konzeptionell und hinsichtlich ihrer Aufgaben unterschiedlichen Systemteile zeigen, dass es Fehlerschwerpunkte gibt. Die Verteilung war keine große Überraschung für das Team, verdeutlichte jedoch auch das Potential, das die systematische Einführung von automatisierten GUI-Tests hat. Die Fehlerverteilung wurde von den Projektmitgliedern ergänzend gegenüber der Größe der Komponenten und der aktuellen Projektsituation (Neuentwicklung/Änderungen) bewertet Einfluss der Testabdeckung von Regressionstests Testabdeckung in Bezug auf mit Regressionstests gefundene Fehler Wrapper 43,75% WebDAV 93% Security Search Other 17% 20% 0 Knowledge Base 23,50% GUI 4% Data Access Layer 30% ContentAssistent 14% 0% 10% 20% 30% 40% 50% 60% 70% Anteil mit Regressionstests gefundener Fehler Testabdeckung [%]: #JUnit# JUnit-Klassen / # andere Klassen Bei der Erstellung von Testklassen spielt die Abwägung von Kosten und Nutzen eine wichtige Rolle. Als mittelfristiges allgemeines Ziel wurde 50% Testabdeckung genannt. In einem Piloten wäre die Effektivität von einer hohen Testabdeckung noch zu prüfen. Aufgrund der in einigen Systemteilen 18 Copyright Fraunhofer IESE 2001

27 wenigen Daten können nicht alle Werte zum Ziehen von Schlüssen herangezogen werden (z.b. WebDAV). Generell sind positive Effekte durch Regressionstests jedoch abzulesen. Es wurde beschlossen, in Zukunft ein anderes Maß für die Testabdeckung zu nutzen, welches nicht auf Klassenebene, sonder auf tatsächlicher Pfadüberdeckung arbeitet (JProbe), da eine hohe Abdeckung auf Test-Klassenebene nur indirekt die tatsächliche Abdeckung annähern kann Fehlerursache QF 2 Was war die Fehlerursache? 3 9 Produkt Datum TopLogic R Design External Component Functionality Requirements Robustness Interfaces Auswertung Der Anteil der Fehler, die auf Robustheit zurückgeführt wurde, wurde als unerwartet hoch angesehen. Gezielte Beachtung von Grenzfällen bei Code- Reviews wurde als Lösungsmöglichkeit genannt Auswirkung der Fehler QF 4 Wie war die Auswirkung der Fehler verteilt? 5% 2% 11% Produkt Datum TopLogic R % 51% --- Functionality No Relevance System/Application Workaround Component 18% Auswertung

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

p^db=`oj===pìééçêíáåñçêã~íáçå=

p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for

Mehr

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena http://www.im.uni-jena.de Contents I. Learning Objectives II. III. IV. Recap

Mehr

Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part II) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Mehr

Employment and Salary Verification in the Internet (PA-PA-US)

Employment and Salary Verification in the Internet (PA-PA-US) Employment and Salary Verification in the Internet (PA-PA-US) HELP.PYUS Release 4.6C Employment and Salary Verification in the Internet (PA-PA-US SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten.

Mehr

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Eine Betrachtung im Kontext der Ausgliederung von Chrysler Daniel Rheinbay Abstract Betriebliche Informationssysteme

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

! " #! $! % & ' ' (! " # # $

!  #! $! % & ' ' (!  # # $ ! " #! $! % & ' ' (! " # # $ Abstract Software integration testing can be divided into three sections: The static analysis, the symbolic execution and the dynamic test. While the static analysis exposes

Mehr

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Zielsetzung: System Verwendung von Cloud-Systemen für das Hosting von online Spielen (IaaS) Reservieren/Buchen von Resources

Mehr

Effizienz im Vor-Ort-Service

Effizienz im Vor-Ort-Service Installation: Anleitung SatWork Integrierte Auftragsabwicklung & -Disposition Februar 2012 Disposition & Auftragsabwicklung Effizienz im Vor-Ort-Service Disclaimer Vertraulichkeit Der Inhalt dieses Dokuments

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

Klausur Verteilte Systeme

Klausur Verteilte Systeme Klausur Verteilte Systeme SS 2005 by Prof. Walter Kriha Klausur Verteilte Systeme: SS 2005 by Prof. Walter Kriha Note Bitte ausfüllen (Fill in please): Vorname: Nachname: Matrikelnummer: Studiengang: Table

Mehr

XML Template Transfer Transfer project templates easily between systems

XML Template Transfer Transfer project templates easily between systems Transfer project templates easily between systems A PLM Consulting Solution Public The consulting solution XML Template Transfer enables you to easily reuse existing project templates in different PPM

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Bayerisches Landesamt für Statistik und Datenverarbeitung Rechenzentrum Süd. z/os Requirements 95. z/os Guide in Lahnstein 13.

Bayerisches Landesamt für Statistik und Datenverarbeitung Rechenzentrum Süd. z/os Requirements 95. z/os Guide in Lahnstein 13. z/os Requirements 95. z/os Guide in Lahnstein 13. März 2009 0 1) LOGROTATE in z/os USS 2) KERBEROS (KRB5) in DFS/SMB 3) GSE Requirements System 1 Requirement Details Description Benefit Time Limit Impact

Mehr

EEX Kundeninformation 2002-09-11

EEX Kundeninformation 2002-09-11 EEX Kundeninformation 2002-09-11 Terminmarkt Bereitstellung eines Simulations-Hotfixes für Eurex Release 6.0 Aufgrund eines Fehlers in den Release 6.0 Simulations-Kits lässt sich die neue Broadcast-Split-

Mehr

1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3

1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3 User Manual for Marketing Authorisation and Lifecycle Management of Medicines Inhalt: User Manual for Marketing Authorisation and Lifecycle Management of Medicines... 1 1. General information... 2 2. Login...

Mehr

Titelbild1 ANSYS. Customer Portal LogIn

Titelbild1 ANSYS. Customer Portal LogIn Titelbild1 ANSYS Customer Portal LogIn 1 Neuanmeldung Neuanmeldung: Bitte Not yet a member anklicken Adressen-Check Adressdaten eintragen Customer No. ist hier bereits erforderlich HERE - Button Hier nochmal

Mehr

1.1 IPSec - Sporadische Panic

1.1 IPSec - Sporadische Panic Read Me System Software 9.1.2 Patch 2 Deutsch Version 9.1.2 Patch 2 unserer Systemsoftware ist für alle aktuellen Geräte der bintec- und elmeg-serien verfügbar. Folgende Änderungen sind vorgenommen worden:

Mehr

SAP PPM Enhanced Field and Tab Control

SAP PPM Enhanced Field and Tab Control SAP PPM Enhanced Field and Tab Control A PPM Consulting Solution Public Enhanced Field and Tab Control Enhanced Field and Tab Control gives you the opportunity to control your fields of items and decision

Mehr

USBASIC SAFETY IN NUMBERS

USBASIC SAFETY IN NUMBERS USBASIC SAFETY IN NUMBERS #1.Current Normalisation Ropes Courses and Ropes Course Elements can conform to one or more of the following European Norms: -EN 362 Carabiner Norm -EN 795B Connector Norm -EN

Mehr

Software Engineering und Projektmanagement 2.0 VO

Software Engineering und Projektmanagement 2.0 VO Software Engineering und Projektmanagement 2.0 VO Inhalte der Einheit Was ist Usability? Wieso ist Usability wichtig? Vorlesung 2009W Usability Engineering (Christoph Wimmer) Sicherheit in der Softwareentwicklung

Mehr

Cooperation Project Sao Paulo - Bavaria. Licensing of Waste to Energy Plants (WEP/URE)

Cooperation Project Sao Paulo - Bavaria. Licensing of Waste to Energy Plants (WEP/URE) Cooperation Project Sao Paulo - Bavaria Licensing of Waste to Energy Plants (WEP/URE) SMA 15.10.2007 W. Scholz Legal framework Bayerisches Staatsministerium für European Directive on Waste incineration

Mehr

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define

Mehr

eurex rundschreiben 094/10

eurex rundschreiben 094/10 eurex rundschreiben 094/10 Datum: Frankfurt, 21. Mai 2010 Empfänger: Alle Handelsteilnehmer der Eurex Deutschland und Eurex Zürich sowie Vendoren Autorisiert von: Jürg Spillmann Weitere Informationen zur

Mehr

Disclaimer & Legal Notice. Haftungsausschluss & Impressum

Disclaimer & Legal Notice. Haftungsausschluss & Impressum Disclaimer & Legal Notice Haftungsausschluss & Impressum 1. Disclaimer Limitation of liability for internal content The content of our website has been compiled with meticulous care and to the best of

Mehr

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part XI) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Mehr

Ingenics Project Portal

Ingenics Project Portal Version: 00; Status: E Seite: 1/6 This document is drawn to show the functions of the project portal developed by Ingenics AG. To use the portal enter the following URL in your Browser: https://projectportal.ingenics.de

Mehr

Parameter-Updatesoftware PF-12 Plus

Parameter-Updatesoftware PF-12 Plus Parameter-Updatesoftware PF-12 Plus Mai / May 2015 Inhalt 1. Durchführung des Parameter-Updates... 2 2. Kontakt... 6 Content 1. Performance of the parameter-update... 4 2. Contact... 6 1. Durchführung

Mehr

Software development with continuous integration

Software development with continuous integration Software development with continuous integration (FESG/MPIfR) ettl@fs.wettzell.de (FESG) neidhardt@fs.wettzell.de 1 A critical view on scientific software Tendency to become complex and unstructured Highly

Mehr

Patentrelevante Aspekte der GPLv2/LGPLv2

Patentrelevante Aspekte der GPLv2/LGPLv2 Patentrelevante Aspekte der GPLv2/LGPLv2 von RA Dr. Till Jaeger OSADL Seminar on Software Patents and Open Source Licensing, Berlin, 6./7. November 2008 Agenda 1. Regelungen der GPLv2 zu Patenten 2. Implizite

Mehr

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg "GIPS Aperitif" 15. April 2010 Referat von Stefan Illmer

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg GIPS Aperitif 15. April 2010 Referat von Stefan Illmer GIPS 2010 Gesamtüberblick Dr. Stefan J. Illmer Credit Suisse Agenda Ein bisschen Historie - GIPS 2010 Fundamentals of Compliance Compliance Statement Seite 3 15.04.2010 Agenda Ein bisschen Historie - GIPS

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle Mit Legacy-Systemen in die Zukunft Dr. Roland Schätzle Der Weg zur Entscheidung 2 Situation Geschäftliche und softwaretechnische Qualität der aktuellen Lösung? Lohnen sich weitere Investitionen? Migration??

Mehr

Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH

Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH What is a GEVER??? Office Strategy OXBA How we used SharePoint Geschäft Verwaltung Case Management Manage Dossiers Create and Manage Activities

Mehr

Robotino View Kommunikation mit OPC. Communication with OPC DE/EN 04/08

Robotino View Kommunikation mit OPC. Communication with OPC DE/EN 04/08 Robotino View Kommunikation mit OPC Robotino View Communication with OPC 1 DE/EN 04/08 Stand/Status: 04/2008 Autor/Author: Markus Bellenberg Festo Didactic GmbH & Co. KG, 73770 Denkendorf, Germany, 2008

Mehr

Wie agil kann Business Analyse sein?

Wie agil kann Business Analyse sein? Wie agil kann Business Analyse sein? Chapter Meeting Michael Leber 2012-01-24 ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS

DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS Master Seminar Empirical Software Engineering Anuradha Ganapathi Rathnachalam Institut für Informatik Software & Systems Engineering Agenda Introduction

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

EEX Kundeninformation 2007-09-05

EEX Kundeninformation 2007-09-05 EEX Eurex Release 10.0: Dokumentation Windows Server 2003 auf Workstations; Windows Server 2003 Service Pack 2: Information bezüglich Support Sehr geehrte Handelsteilnehmer, Im Rahmen von Eurex Release

Mehr

Aufnahmeuntersuchung für Koi

Aufnahmeuntersuchung für Koi Aufnahmeuntersuchung für Koi Datum des Untersuchs: Date of examination: 1. Angaben zur Praxis / Tierarzt Vet details Name des Tierarztes Name of Vet Name der Praxis Name of practice Adresse Address Beruf

Mehr

Eine industriell erprobte Methode für den. Review und Test von Anforderungen mit Hilfe von Fehlertaxonomien 28.11.2013

Eine industriell erprobte Methode für den. Review und Test von Anforderungen mit Hilfe von Fehlertaxonomien 28.11.2013 Eine industriell erprobte Methode für den Review und Test von Anforderungen mit Hilfe von Fehlertaxonomien Michael Felderer 1, Armin Beer 2 1 Universität Innsbruck & QE LaB Business Services Innsbruck,

Mehr

Algorithms for graph visualization

Algorithms for graph visualization Algorithms for graph visualization Project - Orthogonal Grid Layout with Small Area W INTER SEMESTER 2013/2014 Martin No llenburg KIT Universita t des Landes Baden-Wu rttemberg und nationales Forschungszentrum

Mehr

Critical Chain and Scrum

Critical Chain and Scrum Critical Chain and Scrum classic meets avant-garde (but who is who?) TOC4U 24.03.2012 Darmstadt Photo: Dan Nernay @ YachtPals.com TOC4U 24.03.2012 Darmstadt Wolfram Müller 20 Jahre Erfahrung aus 530 Projekten

Mehr

Supplier Status Report (SSR)

Supplier Status Report (SSR) Supplier Status Report (SSR) Introduction for BOS suppliers BOS GmbH & Co. KG International Headquarters Stuttgart Ernst-Heinkel-Str. 2 D-73760 Ostfildern Management Letter 2 Supplier Status Report sheet

Mehr

TVHD800x0. Port-Weiterleitung. Version 1.1

TVHD800x0. Port-Weiterleitung. Version 1.1 TVHD800x0 Port-Weiterleitung Version 1.1 Inhalt: 1. Übersicht der Ports 2. Ein- / Umstellung der Ports 3. Sonstige Hinweise Haftungsausschluss Diese Bedienungsanleitung wurde mit größter Sorgfalt erstellt.

Mehr

Cloud Architektur Workshop

Cloud Architektur Workshop Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

PPM Integrated UI Project Management Tabs into Item Detail

PPM Integrated UI Project Management Tabs into Item Detail Project Management Tabs into Item Detail A PLM Consulting Solution Public This consulting solution enables you to streamline your portfolio and project management process via an integrated UI environment.

Mehr

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint at a Glance Build Solutions in Less Time Provide a Better User Experience Maintain Your Platform at Lower Cost 2 MatchPoint

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

(Prüfungs-)Aufgaben zum Thema Scheduling

(Prüfungs-)Aufgaben zum Thema Scheduling (Prüfungs-)Aufgaben zum Thema Scheduling 1) Geben Sie die beiden wichtigsten Kriterien bei der Wahl der Größe des Quantums beim Round-Robin-Scheduling an. 2) In welchen Situationen und von welchen (Betriebssystem-)Routinen

Mehr

Frequently asked Questions for Kaercher Citrix (apps.kaercher.com)

Frequently asked Questions for Kaercher Citrix (apps.kaercher.com) Frequently asked Questions for Kaercher Citrix (apps.kaercher.com) Inhalt Content Citrix-Anmeldung Login to Citrix Was bedeutet PIN und Token (bei Anmeldungen aus dem Internet)? What does PIN and Token

Mehr

A Practical Approach for Reliable Pre-Project Effort Estimation

A Practical Approach for Reliable Pre-Project Effort Estimation A Practical Approach for Reliable Pre-Project Effort Estimation Carl Friedrich Kreß 1, Oliver Hummel 2, Mahmudul Huq 1 1 Cost Xpert AG, Augsburg, Germany {Carl.Friedrich.Kress,Mahmudul.Huq}@CostXpert.de

Mehr

Praktikum Entwicklung von Mediensystemen mit ios

Praktikum Entwicklung von Mediensystemen mit ios Praktikum Entwicklung von Mediensystemen mit ios WS 2011 Prof. Dr. Michael Rohs michael.rohs@ifi.lmu.de MHCI Lab, LMU München Today Heuristische Evaluation vorstellen Aktuellen Stand Software Prototyp

Mehr

Virtual PBX and SMS-Server

Virtual PBX and SMS-Server Virtual PBX and SMS-Server Software solutions for more mobility and comfort * The software is delivered by e-mail and does not include the boxes 1 2007 com.sat GmbH Kommunikationssysteme Schwetzinger Str.

Mehr

Programmentwicklung ohne BlueJ

Programmentwicklung ohne BlueJ Objektorientierte Programmierung in - Eine praxisnahe Einführung mit Bluej Programmentwicklung BlueJ 1.0 Ein BlueJ-Projekt Ein BlueJ-Projekt ist der Inhalt eines Verzeichnisses. das Projektname heißt wie

Mehr

RailMaster New Version 7.00.p26.01 / 01.08.2014

RailMaster New Version 7.00.p26.01 / 01.08.2014 RailMaster New Version 7.00.p26.01 / 01.08.2014 English Version Bahnbuchungen so einfach und effizient wie noch nie! Copyright Copyright 2014 Travelport und/oder Tochtergesellschaften. Alle Rechte vorbehalten.

Mehr

TomTom WEBFLEET Tachograph

TomTom WEBFLEET Tachograph TomTom WEBFLEET Tachograph Installation TG, 17.06.2013 Terms & Conditions Customers can sign-up for WEBFLEET Tachograph Management using the additional services form. Remote download Price: NAT: 9,90.-/EU:

Mehr

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich?

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich? KURZANLEITUNG Firmware-Upgrade: Wie geht das eigentlich? Die Firmware ist eine Software, die auf der IP-Kamera installiert ist und alle Funktionen des Gerätes steuert. Nach dem Firmware-Update stehen Ihnen

Mehr

Risiko Datensicherheit End-to-End-Verschlüsselung von Anwendungsdaten. Peter Kirchner Microsoft Deutschland GmbH

Risiko Datensicherheit End-to-End-Verschlüsselung von Anwendungsdaten. Peter Kirchner Microsoft Deutschland GmbH Risiko Datensicherheit End-to-End-Verschlüsselung von Anwendungsdaten Peter Kirchner Microsoft Deutschland GmbH RISIKO Datensicherheit NSBNKPDA kennt alle ihre Geheimnisse! Unterschleißheim Jüngste Studien

Mehr

Frontend Migration from JSP to Eclipse Scout

Frontend Migration from JSP to Eclipse Scout Frontend Migration from JSP to Eclipse Scout Peter Nüdling Raiffeisen Schweiz Jérémie Bresson, Peter Barthazy BSI Business Systems Integration AG Eclipse Finance Day, Zürich, 31. Oktober 2014 Seite 1 WebKat:

Mehr

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart Softwaretests Christoph Betschart 27. Oktober 2014 Inhaltsverzeichnis Einführung Arten von Softwaretests Prinzipien Seven Principles of Software Testing Continuous Integration Tests in FLOSS-Projekten

Mehr

Aber genau deshalb möchte ich Ihre Aufmehrsamkeit darauf lenken und Sie dazu animieren, der Eventualität durch geeignete Gegenmaßnahmen zu begegnen.

Aber genau deshalb möchte ich Ihre Aufmehrsamkeit darauf lenken und Sie dazu animieren, der Eventualität durch geeignete Gegenmaßnahmen zu begegnen. NetWorker - Allgemein Tip 618, Seite 1/5 Das Desaster Recovery (mmrecov) ist evtl. nicht mehr möglich, wenn der Boostrap Save Set auf einem AFTD Volume auf einem (Data Domain) CIFS Share gespeichert ist!

Mehr

Continuous Auditing eine gut gemeinte aber schlechte Idee kommt zurück

Continuous Auditing eine gut gemeinte aber schlechte Idee kommt zurück Continuous Auditing eine gut gemeinte aber schlechte Idee kommt zurück Michel Huissoud Lic.iur, CISA, CIA 5. November 2012 - ISACA/SVIR-Fachtagung - Zürich Überwachung Continuous Monitoring Continuous

Mehr

Softwareanforderungen für Microsoft Dynamics CRM Server 2015

Softwareanforderungen für Microsoft Dynamics CRM Server 2015 Softwareanforderungen für Microsoft Dynamics CRM Server 2015 https://technet.microsoft.com/de-de/library/hh699671.aspx Windows Server-Betriebssystem Microsoft Dynamics CRM Server 2015 kann nur auf Computern

Mehr

TMF projects on IT infrastructure for clinical research

TMF projects on IT infrastructure for clinical research Welcome! TMF projects on IT infrastructure for clinical research R. Speer Telematikplattform für Medizinische Forschungsnetze (TMF) e.v. Berlin Telematikplattform für Medizinische Forschungsnetze (TMF)

Mehr

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Transparenz 2.0. Passive Nachverfolgung und Filterung von WebApps auf dem Prüfstand

Transparenz 2.0. Passive Nachverfolgung und Filterung von WebApps auf dem Prüfstand Matthias Seul IBM Research & Development GmbH BSI-Sicherheitskongress 2013 Transparenz 2.0 Passive Nachverfolgung und Filterung von WebApps auf dem Prüfstand R1 Rechtliche Hinweise IBM Corporation 2013.

Mehr

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2 ReadMe zur Installation der BRICKware for Windows, Version 6.1.2 Seiten 2-4 ReadMe on Installing BRICKware for Windows, Version 6.1.2 Pages 5/6 BRICKware for Windows ReadMe 1 1 BRICKware for Windows, Version

Mehr

Nichttechnische Aspekte Hochverfügbarer Systeme

Nichttechnische Aspekte Hochverfügbarer Systeme Nichttechnische Aspekte Hochverfügbarer Systeme Kai Dupke Senior Product Manager SUSE Linux Enterprise kdupke@novell.com GUUG Frühjahrsfachgespräch 2011 Weimar Hochverfügbarkeit Basis für Geschäftsprozesse

Mehr

Product Lifecycle Manager

Product Lifecycle Manager Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM is powerful, economical and based on standard technologies. Directory

Mehr

WebSphere Portal 8 Migrationen

WebSphere Portal 8 Migrationen WebSphere Portal 8 Migrationen Enrico Regge IT Specialist reggeenr@de.ibm.com André Hagemeier IT Specialist andre.hagemeier@de.ibm.com 2014 IBM Corporation Agenda Suche & Security Theme WCM Applikationen

Mehr

1.1 VoIP - Ruf abgewiesen. 1.3 VoIP - Abbruch eines SIP-Rufs

1.1 VoIP - Ruf abgewiesen. 1.3 VoIP - Abbruch eines SIP-Rufs Read Me System Software 9.1.10 Patch 6 RNA Deutsch Folgende Fehler sind in Systemsoftware 9.1.10 Patch 6 korrigiert worden: 1.1 VoIP - Ruf abgewiesen (ID 19486) Es konnte vorkommen, dass ein eingehender

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

Customer Experience Week

Customer Experience Week Customer Experience Week Die Macht der Sterne Einfluss von Bewertungen auf die Kaufentscheidung Sebastian von Dobeneck BIG Social Media Senior Account Manager www.big-social-media.de Wem vertrauen Kunden?

Mehr

Workflows, Ansprüche und Grenzen der GNSS- Datenerfassung im Feld

Workflows, Ansprüche und Grenzen der GNSS- Datenerfassung im Feld Workflows, Ansprüche und Grenzen der GNSS- Datenerfassung im Feld Alexander Fischer Senior Application Engineer Asset Collection & GIS 1 Leica Zeno GIS Agenda Erfassung im Feld VS Erfassung im Office Validierung

Mehr

Process Management Office Process Management as a Service

Process Management Office Process Management as a Service Process Management Office Process Management as a Service Unsere Kunden bringen ihre Prozesse mit Hilfe von ProcMO so zur Wirkung, dass ihre IT- Services die Business-Anforderungen schnell, qualitativ

Mehr

Requirements Engineering als Baustein im ITILorientierten

Requirements Engineering als Baustein im ITILorientierten Requirements Engineering als Baustein im ITILorientierten IT Betrieb Sabine Wildgruber HOOD GmbH Berater für RM&E, ITIL Dr.-Ing. Richard Baumann Knorr-Bremse Nutzfahrzeuge GmbH Leiter IT-Abteilung T/PI4

Mehr

3A03 Security Löcher schnell und effizient schließen mit HP OpenView Radia

3A03 Security Löcher schnell und effizient schließen mit HP OpenView Radia 3A03 Security Löcher schnell und effizient schließen mit HP OpenView Radia Alexander Meisel HP OpenView 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change

Mehr

Delivering services in a user-focussed way - The new DFN-CERT Portal -

Delivering services in a user-focussed way - The new DFN-CERT Portal - Delivering services in a user-focussed way - The new DFN-CERT Portal - 29th TF-CSIRT Meeting in Hamburg 25. January 2010 Marcus Pattloch (cert@dfn.de) How do we deal with the ever growing workload? 29th

Mehr

IBM Security Lab Services für QRadar

IBM Security Lab Services für QRadar IBM Security Lab Services für QRadar Serviceangebote für ein QRadar SIEM Deployment in 10 bzw. 15 Tagen 28.01.2015 12015 IBM Corporation Agenda 1 Inhalt der angebotenen Leistungen Allgemeines Erbrachte

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

Mehr

SolidQ Flex Services Walkthrough Part I

SolidQ Flex Services Walkthrough Part I Part I Im Folgenden stellen wir Ihnen in Text und Bild die wichtigsten Funktionen der SolidQ Flex Services vor. 1. Dashboard Nach dem Einloggen sieht man zunächst das Dashboard. Dies gilt sowohl für den

Mehr

Instruktionen Mozilla Thunderbird Seite 1

Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Dieses Handbuch wird für Benutzer geschrieben, die bereits ein E-Mail-Konto zusammenbauen lassen im Mozilla Thunderbird und wird

Mehr

Bedeutung von Compliance u. Riskmanagement für Unternehmen

Bedeutung von Compliance u. Riskmanagement für Unternehmen Bedeutung von Compliance u. Riskmanagement für Unternehmen Michael Junk IT-Security & Compliance Manager MJunk@novell.com Zertifiziert bei T.I.S.P / ITIL / CISA / ISO Compliance 2 Es geht also wieder mal

Mehr

Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas. Mr. Niemczik, Mr. Koppatz (SuDiLe GbR)

Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas. Mr. Niemczik, Mr. Koppatz (SuDiLe GbR) Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas in cooperation with Mr. Niemczik, Mr. Koppatz (SuDiLe GbR) Our idea: Fachbereich Wirtschaft, Verwaltung und Recht Simple strategies of lifelong

Mehr

PA-CONTROL CANopen Fehlerliste Ab Version 5.15 Ausgabe: 06/2008 Art.-Nr.:1082211. Technische Dokumentation

PA-CONTROL CANopen Fehlerliste Ab Version 5.15 Ausgabe: 06/2008 Art.-Nr.:1082211. Technische Dokumentation Technische Dokumentation PA-CONTROL CANopen Fehlerliste Ab Version 5.15 Ausgabe: 06/2008 Art.-Nr.:1082211 IEF Werner GmbH Wendelhofstr. 6 78120 Furtwangen Tel.: 07723/925-0 Fax: 07723/925-100 www.ief-werner.de

Mehr

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige

Mehr

GCOS Climate Monitoring Principles Bedeutung und Umsetzung. Holger Vömel, DWD Meteorologisches Observatorium Lindenberg GRUAN Lead Center

GCOS Climate Monitoring Principles Bedeutung und Umsetzung. Holger Vömel, DWD Meteorologisches Observatorium Lindenberg GRUAN Lead Center GCOS Climate Monitoring Principles Bedeutung und Umsetzung Holger Vömel, DWD Meteorologisches Observatorium Lindenberg GRUAN Lead Center Die GCOS Monitoring Principles 1. The impact of new systems or changes

Mehr

Entwicklungsoptimierung mit einem ALM Tool Positionierung mit Fallstudie

Entwicklungsoptimierung mit einem ALM Tool Positionierung mit Fallstudie Entwicklungsoptimierung mit einem ALM Tool Positionierung mit Fallstudie Gerald Heller Agenda Standortbestimmung ALM Typischer industrieller Setup und Probleme Vorstellung von QualityCenter als ALM tool

Mehr

Requirements-Engineering Requirements-Engineering

Requirements-Engineering Requirements-Engineering -Engineering Copyright Chr. Schaffer, Fachhochschule Hagenberg, MTD 1 Was ist ein Requirement? IEEE-Standard (IEEE-726 83) A condition or capability needed by a user to solve a problem or achieve an objective.

Mehr

SmartClass Firmware-Update Vorgehensweise

SmartClass Firmware-Update Vorgehensweise Benutzeranweisungen SmartClass Firmware-Update Vorgehensweise 2008.01 (V 1.x.x) Deutsch Please direct all enquiries to your local JDSU sales company. The addresses can be found at: www.jdsu.com/tm-contacts

Mehr

GESCHÄFTSSTELLENERÖFFNUNG HAMBURG, 25. APRIL 2013

GESCHÄFTSSTELLENERÖFFNUNG HAMBURG, 25. APRIL 2013 OSC Smart Integration GmbH SAP Business One GOLD-Partner in Norddeutschland GESCHÄFTSSTELLENERÖFFNUNG HAMBURG, 25. APRIL 2013 SAP Business One v.9.0 Heiko Szendeleit AGENDA OSC-SI 2013 / SAP Business One

Mehr

Zugangsvoraussetzungen für Airworthiness Review Staff gem. Part-M.A.707

Zugangsvoraussetzungen für Airworthiness Review Staff gem. Part-M.A.707 1) Zusammenfassung der relevanten Part-M Paragraphen und AMC M.A.707 Airworthiness review staff (a) To be approved to carry out reviews, an approved continuing management organisation shall have appropriate

Mehr

Künstliche Intelligenz

Künstliche Intelligenz Künstliche Intelligenz Data Mining Approaches for Instrusion Detection Espen Jervidalo WS05/06 KI - WS05/06 - Espen Jervidalo 1 Overview Motivation Ziel IDS (Intrusion Detection System) HIDS NIDS Data

Mehr

Testsequenz "Cloud-User Unmount volume" (ID 243) Testprotokoll. Testsequenz Projekt > System Test > Cloud-User Unmount volume (ID 243)

Testsequenz Cloud-User Unmount volume (ID 243) Testprotokoll. Testsequenz Projekt > System Test > Cloud-User Unmount volume (ID 243) Testprotokoll Testsequenz Projekt > System Test > Cloud-User Unmount volume (ID 243) Beschreibung Bemerkung Tester SUT Mindestpriorität Testzeit Dauer The test cases for the use-case "Unmount volume".

Mehr

Beschwerdemanagement / Complaint Management

Beschwerdemanagement / Complaint Management Beschwerdemanagement / Complaint Management Structure: 1. Basics 2. Requirements for the implementation 3. Strategic possibilities 4. Direct Complaint Management processes 5. Indirect Complaint Management

Mehr