Projektübergreifendes Testmanagement am Beispiel des Produkts Quality Center in einem Finanzunternehmen

Größe: px
Ab Seite anzeigen:

Download "Projektübergreifendes Testmanagement am Beispiel des Produkts Quality Center in einem Finanzunternehmen"

Transkript

1 Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Projektübergreifendes Testmanagement am Beispiel des Produkts Quality Center in einem Finanzunternehmen Bachelorarbeit im Studiengang Informatik von Sinan Botros Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Dr. Matthias Becker Hannover, 18. August 2006

2 Erklärung Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbstständig und ohne fremde Hilfe verfasst habe und keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel verwendet habe. Hannover, Sinan Botros 2

3 Danksagung Ich bedanke mich bei Herrn Dipl.-Math. Thomas Flohr für die hervorragende Betreuung meiner Bachelorarbeit. 3

4 Inhaltsverzeichnis 1 Einführung Motivation Zielsetzung Vorgehensweise Struktur der Arbeit Systematisches Testen von Software Begriff und Ziel des Testens Arten von Tests Probleme und Fehler beim Testen Tätigkeiten beim Testen Dokumentation beim Testen Testen im Unternehmen Vorstellung des TestDirectors TestDirector-Struktur Analyse und Reports Rollenkonzept Ist-Zustand der Projekte im TestDirector Probleme beim Reporting Standardisierungskonzept Zweck der Standardisierung Ordnerstruktur und ordnende Attribute Test Plan Test Lab Defects Reporting Listenadministration Rechtekonzept Zielorientiertes Messen von Software Motivation Ziele des Software-Messens Software-Metriken Indikatoren Goal-Question-Metric-Ansatz Messplanung Messinstrumentierung Datenerfassung Datenanalyse Ableitung von Metriken nach der GQM-Methode Metriken für Tester Metriken für Entwickler Metriken für QS-Manager Metriken für Projektleiter Metriken für projektübergreifendes Reporting

5 7 Projektübergreifendes Reporting Motivation zum Einsatz eines Reporting-Systems Verbesserung der Kommunikation Verbesserung der Dokumentation Voraussetzungen für den Einsatz eines Reporting-Systems Umsetzung eines Reporting-Systems Vorstellung des Quality Center Dashboards Beispielhafte Implementierung der Indikatoren Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Anhang A

6 1 Einführung 1.1 Motivation Das Unternehmen ist mit mehreren Tausend Mitarbeitern und Präsenzen in verschiedenen Bundesländern eins der größten Informationstechnologie-Dienstleister in der Finanz-Branche in Deutschland. Die zentralen Funktionen der Abteilung, in der diese Arbeit geschrieben wurde, sind die Sicherstellung der eingesetzten DV-Systeme im Gesamtzusammenhang aller Systeme unter Einhaltung der Ordnungsmäßigkeit und Prüfung der Datenverarbeitung und die Bereitstellung von Testsystemen und Testwerkzeugen. Darüber hinaus werden die Entwickler und Tester durch umfassenden Support und Schulungen bzgl. der Testsysteme und Tools unterstützt. Zur Dokumentation und Durchführung von Tests wird im Finanzdienstleister das Tool TestDirector der Firma Mercury 1 von über 90 Projekten verwendet (siehe Kapitel 3 Testen im Unternehmen). Der Finanzdienstleister legt großen Wert darauf, seinen Kunden ausreichend qualitativ gesicherte Anwendungssysteme zur Verfügung zu stellen. Eine der wichtigsten Maßnahmen, die zur Qualitätssicherung beiträgt, ist Testen. Deshalb müssen im Projektverlauf eine sehr große Anzahl von Tests durchgeführt und dokumentiert werden. Zur Unterstützung des Testprozesses wird der TestDirector im Finanzdienstleister als verbindliches Testfallverwaltungstool verwendet. Deshalb enthält der TestDirector eine sehr große Menge von Informationen über den Teststatus der Projekte. Die Ablagestruktur der Testfälle in den Projekten ist jedoch unterschiedlich, Attribute und Auswahllisten sind nur teilweise standardisiert. Auswertungen über den Teststatus können deshalb nur innerhalb eines Projektes mit genauer Kenntnis der projektspezifischen Ablagestruktur erstellt werden, sind jedoch von außen, z.b. durch die Integration und Abnahme, nicht nachvollziehbar. Diese Tatsache wurde durch eine interne Befragung bestätigt. Außerdem wird der Anspruch an TestDirector-Projekte immer größer, Anforderungsmanagement und Releasetest benötigen eine projektübergreifende standardisierte Sicht auf den Status der getesteten Anwendungen. Die projektübergreifende Sicht ist mit dem Quality Center Dashboard 2 realisierbar. Dies ist nur dann umsetzbar, wenn die Projekte eine einheitliche Struktur sowie einheitliche Attribute und Attributwerte aufweisen. Aus diesem Grund wurde die Entscheidung getroffen, ein Nutzungskonzept zur Standardisierung der TestDirector-Projekte zu erstellen. Dieses Konzept wird im Laufe dieser Arbeit vorgestellt (siehe Kapitel 4 Standardisierungskonzept) und stellt die Grundlage für die Erreichung des Ziels dieser Arbeit. 1.2 Zielsetzung Ziel dieser Arbeit ist, es zu ermöglichen, den Teststatus der TestDirector-Projekte anhand quantitativ bestimmbare Maßeinheiten, sog. Key Performance Indicators (KPIs), graphisch als Portlets im Quality Center Dashboard darzustellen. 1 Mercury ist einer der weltweit führenden Anbieter im Bereich Business Technology Optimization (BTO). Es wird Unterstützung in Form von Dienstleistungen und Software angeboten zur Optimierung der Qualität, Performance und Verfügbarkeit von Applikationen sowie beim Management von IT Kosten und Risiken. Weitere Infos im Internet unter 2 Beim Dashboard handelt es sich um ein Tool der Firma Mercury zur Visualisierung der Daten in Form von Diagrammen oder Tabellen. Es bietet die Möglichkeit, eigene Metriken für die Software-Güte zu konfigurieren und diese durch den gesamten Qualitätssicherungsprozess hinweg zu erfassen und zu verwalten. 6

7 Der erste Schritt ist die Erstellung eines Konzepts zur Standardisierung der Testdokumentation der TestDirector-Projekte. Anschließend wird nach der Goal-Question- Metric-Methode vorgegangen, um Indikatoren und Metriken zur Überprüfung des Teststatus der Projekte abzuleiten. Diese Metriken richten sich an die verschiedenen Nutzergruppen entsprechend des Rollenkonzepts im Finanzdienstleister (Tester, Entwickler, QS-Manager, Projektleiter). Schließlich sollen die Indikatoren, die sich insbesondere für projektübergreifendes Reporting eignen, hervorgehoben und einige exemplarisch im Dashboard implementiert werden. Diese Indikatoren präsentieren eine Gesamtübersicht über den Teststatus der Projekte. Durch Bereitstellung dieser Gesamtübersicht über alle Projekte wird es zukünftig den Verantwortlichen möglich sein, auf einen Blick die Mängel sofort zu erkennen und dementsprechend zu handeln. Auf Basis dieser Übersicht können dann Messungen durchgeführt werden, um quantitative Aussagen zu bestimmten Systemqualitäten zu erhalten und den Fortschritt der Projekte zu kontrollieren. 1.3 Vorgehensweise Mit der Analyse des Ist-Zustandes der TestDirector-Projekte werden die benötigten Attribute verifiziert und für besseres Reporting geeignete Ablagestruktur der Testfälle mit den Projektmanagern diskutiert und abgestimmt. Anhand der daraus resultierenden Ergebnisse wird das Standardisierungskonzept erstellt. Anschließend wird nach der Goal-Question-Metric-Methode (GQM) vorgegangen, um Metriken und Indikatoren für den Status der TestDirector-Projekte abzuleiten. Zum Abschluss wird das Reportingtool Dashboard vorgestellt und dort exemplarisch einige Indikatoren implementiert. 1.4 Struktur der Arbeit In dem ersten Kapitel wurden Ziele der Arbeit und der Finanzdienstleister vorgestellt. Das zweite Kapitel ist ein Einstieg in das Thema Testen. Anschließend behandelt das dritte Kapitel das Testen im Finanzdienstleister und stellt den TestDirector ausführlich vor. Die im Zuge dieser Bachelorarbeit erarbeiteten Ideen zur Standardisierung der Testdokumentation der Projekte werden im vierten Kapitel erläutert. Zielorientiertes Software-Messen und die GQ(I)M-Methode stellen den Inhalt des fünften Kapitels dar. Im sechsten Kapitel werden die abgeleiteten Metriken für die verschiedenen Rollen präsentiert. Projektübergreifendes Reporting am Beispiel des Reportingtools Dashboard wird Thema des siebten Kapitels sein. Abschließend folgt im achten und letzten Kapitel eine Zusammenfassung dieser Arbeit. 7

8 2 Systematisches Testen von Software Einen wichtigen Beitrag zur Qualitätssicherung in der Software-Entwicklung wird durch systematisches Testen von Software gewährleistet. Ziel dieses Kapitels ist, einen Überblick über das Thema Testen und die damit verbundenen Begriffe und Aktivitäten zu geben. 2.1 Begriff und Ziel des Testens Die Intuition der meisten Menschen entspricht der Vorstellung, ein System auszuprobieren und aus den resultierenden Ergebnissen und Beobachtungen zu folgern, ob es seine Funktionen erfüllt, d.h. es zu testen. In der Wissenschaft wird der Begriff Testen jedoch genauer definiert. In der Literatur werden oft folgende Definitionen gefunden: Testen ist die Ausführung eines Programms mit dem Ziel Fehler zu entdecken [1]. und Testen ist die Vorführung eines Programms oder Systems mit dem Ziel zu zeigen, dass es tut, was es tun sollte [2]. Auf den ersten Blick scheinen sich die beiden Definitionen zu widersprechen und es stellt sich die Frage, welche die korrekte ist. In der Tat beide. Es wird jedoch nicht vom Gleichen gesprochen. Im ersten Fall wird Testen als ein Prüfverfahren vorgesehen, bei dem Systeme oder Programme ausgeführt werden, um vorhandene Defekte und Fehler zu finden. In diesem Sinne ist ein Test erfolgreich, wenn es zu einem Ergebnis führt, das sich von den spezifischen Anforderungen des Systems unterscheidet. Im zweiten Fall dient das Ausführen des Programms dem Nachweis, dass die Vereinbarten Leistungen erbracht worden sind. Das Software-Produkt wird validiert und erprobt, ob es die von ihm erwarteten Funktionalitäten erfüllt. Hier spricht man auch von Abnahmetest. Andererseits ist nicht jede Ausführung eines Programms ein Test. Unabhängig von der Methode und dem Ziel gehört zu der Spezifikation eines Tests immer ein vordefiniertes Soll- Ergebnis, das mit dem Ist-Ergebnis zu vergleichen ist. Eine genauere Definition des Testens und dessen Ziel, die zusätzlich auf die Testdaten und die Testreferenz eingeht, ist in deutschen Normierungen [DIN] wie folgt eingeführt: Ziel des Software-Tests ist es, durch Ausführung des Testobjekts auf einem Rechner mit ausgewählten Testdaten in einer definierten Umgebung festzustellen, ob sich das Testobjekt in diesen Fällen so verhält, wie es eine definierte Testreferenz vorschreibt. Zur Prüfung einer Software existieren mehrere Verfahren. Der Software-Test besitzt aber einen entscheidenden Vorteil: Der Test ist in der Praxis das einzige Verfahren, mit dem die realen Einsatzbedingungen eines Software-Systems, zum Beispiel Zielrechner, Compiler und Betriebssystem, angemessen berücksichtigt und die dynamischen Eigenschaften des Systems, beispielsweise das Laufzeit verhalten und die durch den Zielrechner gegebene Rechengenauigkeit, geprüft werden können [4]. 2.2 Arten von Tests Beim Testen wird immer ein bestimmtes Ziel verfolgt. Durch das Ziel wird festgelegt, auf welche Aspekte die Testfälle ausgelegt werden. In [6] werden im Wesentlichen folgende Testarten unterschieden: Fehlertest: Das Ziel beim Fehlertest ist die Aufdeckung der evtl. versteckten Fehler in einem Softwaresystem bevor dies an den Kunden ausgeliefert wird. Dabei wird versucht, ein unkorrektes Verhalten des Systems auszulösen um Fehler zu erkennen. 8

9 Die wesentliche Arbeit beim Fehlertest ist die Auswahl von Eingabedaten, die mit hoher Wahrscheinlichkeit ein Fehlverhalten auflösen. Funktionstest: Eine andere Bezeichnung dafür ist Black-Box-Test, da das System wie eine Black Box ist, dessen Verhalten nur durch die Eingaben und die dazugehörigen Ausgaben untersucht wird. Dabei wird also nur die Funktion betrachtet und nicht die Art der Implementierung. Eine Funktion ist in der Regel die kleinste, beim Tests gesondert zu prüfende Programmeinheit. Eine Funktion ist also eine Software- Komponente, die innerhalb des Software-Systems eine spezielle, abgrenzende Aufgabe erfüllt. Die Funktionstests werden auf Grundlage der Spezifikation erstellt. Diese Tests sollen gewährleisen, dass die an das System gestellten Anforderungen erfüllt werden. Integrationstest: Beim Funktionstest werden die einzelnen Systemkomponenten untersucht. Werden durch die Integration mehrere Teile zusammengeführt, so muss beim Testen auch speziell auf das Zusammenspiel und die Schnittstellen zwischen diesen Teilen geachtet werden. Das Ziel des Integrationstest ist, die durch diesen komplexen Prozess aufgedeckten Fehler aufzufinden. Da die einzelnen Komponenten aufeinander zusammenwirken, ist es in der Regel schwierig, die Fehlerquelle zu identifizieren. Deshalb ist es ratsam, den Integrationsprozess inkrementell durchzuführen. Zunächst wird eine möglichst kleine Anzahl von Komponenten integrieret und getestet. Bei erfolgreichem Test werden neue Komponenten hinzugefügt und erneut getestet. Abnahmetest: Das Ziel des Abnahmetests ist zu zeigen, dass das System bei der Ausführung vordefinierter Abnahmetestfälle die Anforderungen bzw. Bedürfnisse des Auftraggebers erfüllt. Abnahmetest werden hauptsächlich in der Endphase des Projekts auf einer realen Umgebung des Auftraggebers durchgeführt. 2.3 Probleme und Fehler beim Testen Eine wesentliche Aufgabe beim Testen besteht darin, die Testdaten auszuwählen. Eine Schwäche des Tests ist, dass nur für die ausgewählten Daten nachgewiesen werden kann, dass das Testobjekt gemäß der Spezifikation keine Abweichungen aufweist und keine Fehlfunktionen enthält. Dijkstra (1972) beschreibt, dass Testen nur die Anwesenheit von Fehlern zeigen kann, aber nicht die Abwesenheit. Nur ein vollständiger Test mit allen Eingabewerten und allen möglichen Kombinationen kann die absolute Korrektheit eines Software-Programms nachweisen. In der Praxis kann so ein Test aufgrund von sehr großen Anzahl von Testfällen und die dafür benötigte Zeit nicht durchgeführt werden. Davon abgesehen, dass es bei einigen Fällen eine unendliche Anzahl von Eingabewerten geben kann. Ein anderes Problem tritt auf, wenn die Ist- und Sollergebnisse nicht korrekt ermittelt werden. Weicht nach der Testdurchführung das Soll- vom Ist-Ergebnis aus, so liegt nicht immer tatsächlich eine Fehlerwirkung des Testobjekts vor, da auch andere Faktoren wie z.b. Fehler in der Testspezifikation oder im Testfall selbst Ursache für eine beobachtete Differenz sein können. Zusätzlich können die Testergebnisse falsch interpretiert werden und so nicht fehlerhafte Funktionen als solche angesehen werden. 9

10 2.4 Tätigkeiten beim Testen Im Folgenden wird Testen durch die Testaktivitäten und ihr Zusammenwirken veranschaulicht. Abbildung 2.1 [4] zeigt eine graphische Darstellung dieser Aktivitäten. Die gegenseitige Beeinflussung wird durch die Pfeile dargestellt. Die Planung, Organisation und Dokumentation beziehen sich auf die Gesamtheit aller zu prüfenden Testobjekte. Die weiteren Tätigkeiten beziehen sich auf ein einzelnes Testobjekt. Abbildung 2.1: Testaktivitäten und ihr Zusammenwirken In Anlehnung an Systematisches Testen von Software [4] werden folgende Testtätigkeiten definiert: Die erste Tätigkeit, die sich auf ein Testobjekt bezieht ist die Testfallermittlung. In einem Testfall wird eine bestimmte Eingabekonstellation festgelegt, mit der das Testobjekt getestet werden soll. Die Testfälle werden in der Regel aus Anforderungen bzw. Spezifikationen abgeleitet. Das Ziel dabei ist Identifizierung von Testfällen, mit denen nachgewiesen werden kann, dass die System-Funktionen vorhanden und ausführbar sind. Die 10

11 Testfälle behandeln sowohl das Normalverhalten als auch das Ausnahmeverhalten des Systems. Bei der Testdatengenerierung werden den Testfällen konkrete Testdaten zugewiesen. Da die Anzahl der möglichen Eingabewerte sehr hoch ist, wird aus jedem Wertebereich ein Repräsentant ausgewählt. Bei der Bestimmung von Sollergebnissen werden zu jedem Testfall die Ausgangswerte aus der Testreferenz, i. A. der Anforderungsspezifikation oder des Software-Entwurfs, abgeleitet. Die Ermittlung des Sollergebnisses beim Testen hat eine sehr entscheidende Bedeutung, denn das Ergebnis eines Testfalls kann nur dann als erfolgreich bezeichnet werden, wenn ein gültiges Referenzergebnis zur Verfügung steht und anhand dessen das Fehlverhalten des zu testenden Objekts erkannt werden kann. Bei der Testdurchführung wird das Testobjekt mit den entsprechenden Eingabedaten ausgeführt. Voraussetzung dafür ist die Bereitstellung des zu testenden Systems. Dabei sind die Testergebnisse, d.h. die Ausgabewerte, die das Testobjekt generiert, in geeigneter Form festzuhalten. Um die Überwachung des Testablaufs werden durch Hard- oder Software realisierte Funktionen zur Verfügung gestellt. Dadurch wird während der Testdurchführung eine Aufzeichnung des Programms ermöglicht (Monitoring). Bei der Testauswertung werden die Testergebnisse, die bei der Testdurchführung erzeugt wurden, also das Ist-Verhalten, mit den in der Testspezifikation vordefinierten Sollergebnissen verglichen. Anhand dessen wird festgestellt, ob sich das System wie gewünscht verhält oder Fehler aufweist. Falls Abweichungen zwischen dem Ist- und Sollverhalten festgestellt werden, so ist als erstes zu überprüfen, ob das auf die getestete Software zurückzuführen ist und keine anderen Faktoren wie ungenaue Testspezifikation oder fehlerhafte Testfälle dafür verantwortlich sein könnten. Liegt tatsächlich ein Fehler vor, so wird dieser an den Entwickler gemeldet und die Behebung des Fehlers priorisiert. Nach der Behebung des Fehlers muss das Testobjekt erneut getestet werden bis der Testfall erfolgreich verläuft. Die Testplanung ist eine projektübergreifende Testaktivität. Dabei werden die Testobjekte, die zu testenden Merkmale, die Kriterien zur Auswahl der Testfälle sowie die Abbruch- und die Wiederaufnahmekriterien festgelegt. Weiterhin sind die Testfälle zu priorisieren und die Reihenfolge der Durchführung zu definieren. Ziel dabei ist, dass die kritischen Teile des Systems zuerst getestet werden. Darüber hinaus muss die Testumgebung, die Hardware- und Softwarekonfiguration einschließlich Betriebssystem festgelegt werden. Schließlich werden die für die Testdurchführung benötigte Zeit, Testpersonal sowie deren Aufgaben und Verantwortlichkeiten bestimmt. Im Rahmen der Testorganisation werden die Testfälle, Testdaten und die Testergebnisse verwaltet. Zu dem wird festgelegt, ob und welche Testunterstützungswerkzeuge eingesetzt werden. Weiterhin wird die Art der Dokumentation und die Speicherung der Testdaten festgelegt. Dies ist von entscheidender Bedeutung um Tests wiederholen zu können. Damit können Tests, die einen Fehler im System aufgedeckt haben, erneut ausgeführt werden um zu entscheiden, ob die Behebung des Fehlers erfolgreich war oder nicht. Eine sehr wichtige Testaktivität für die vorliegende Arbeit ist die Testdokumentation. Diese wird im nächsten Teilabschnitt ausführlich beschrieben. 11

12 2.5 Dokumentation beim Testen Um Tests systematisch auszuführen, müssen sie vorher sorgfältig geplant und vorbereitet werden. Diese Tätigkeiten erfordern einen großen Ressourcen- und Zeitaufwand. Deshalb sollte der größtmöglichen Nutzen aus diesem Aufwand gezogen werden. Die Dokumentation von Tests ist von zentraler Bedeutung für diesen Nutzen [5]. Die Dokumentation enthält die geplanten Testfällen sowie die beim Ausführen resultierten Ergebnissen. Auch bei der Beschreibung der Testfälle und bei der Testdurchführung können Fehler auftreten. Werden diese aber dokumentiert, so kann die Dokumentation selbst geprüft werden und die Fehler nachvollzogen werden. Die meisten Software-Programme sind an den Bedürfnissen der Kunden ausgerichtet und werden damit mit der Zeit aktualisiert und angepasst. Dabei muss erneut eine hohe Anzahl von Tests evtl. nur mit geringen Veränderungen durchgeführt werden. Die Dokumentation kann diesen Aufwand deutlich verringern und die Wiederholbarkeit von Testfällen sicherstellen. Werden Beim Testen Fehler entdeckt, so kann der Entwickler mit der Hilfe der Dokumentation den gleichen Testfall unter gleichen Bedingungen in gleicher Testumgebung wiederholen um den Fehler zu lokalisieren und zu beheben. Deshalb ist es nur dann sinnvoll, Programme zu testen, die unter Konfigurationskontrolle stehen. Denn nur so kann die getestete Version des Programms wiederhergestellt werden. Die Testdokumentation besteht aus mehreren Teilen. Dazu gehört der Testplan, die Beschreibung der Testfälle, die Testdaten und die Bedingungen, unter denen die Tests durchgeführt wurden sowie die Testergebnisse und die Dokumentation der evtl. gefundenen Fehler. Bei mittleren oder großen Projekten ist die Anzahl der durchzuführenden Testfällen und die damit verknüpften Testdokumenten so hoch, dass allein die Verwaltung dieser Dokumente einen großen Aufwand erfordert. Aus diesem Grund werden Testdokumentationswerkzeuge eingesetzt um den Testdokumentationsprozess zu unterstützen. An dieser Stelle ist noch mal darauf hinzuweisen, dass im Finanzdienstleister das Testdokumentationstool TestDirector als verbindliches Tool zur Dokumentation von Tests verwendet wird (siehe Kapitel 3 Testen im Finanzdienstleister). 12

13 3 Testen im Unternehmen Der Finanzdienstleister ist sich über die Bedeutung des Testens im Klaren und legt sehr großen Wert darauf, seinen Kunden ausreichend getestete und qualitativ gesicherte Anwendungssysteme anzubieten. Um den Testprozess und die Tester bei ihren Aktivitäten zu unterstützen, setzt der Finanzdienstleister den TestDirector als verbindliches Werkzeug zur Testüberstützung ein. 3.1 Vorstellung des TestDirectors Der TestDirector ist ein webbasiertes Tool zur Dokumentation, Verwaltung und Durchführung von Testfällen. Darüber hinaus unterstützt der TestDirector die Erfassung und Verfolgung des Status von Anforderungen und Defects 3. Zusätzlich können (halb-)automatisch Statistiken und Analyse-Reports über den aktuellen Status des Testprozesses generiert werden TestDirector-Struktur Der TestDirector besteht aus folgenden vier Komponenten: 1. REQUIREMENTS Anforderungen des Kunden werden zunächst in RequisitePro 4 erfasst. RequisitePro hat eine Schnittstelle zum TestDirector. Nächtlich findet eine Synchronisation statt, sodass alle Anforderungen in den TestDirector-Beriech REQUIREMENTS übertragen werden. Im TestDirector werden den Anforderungen Testfälle zugeordnet. Jede Anforderung hat dann abhängig vom Status der ihr zugeordneten Testfälle ihren eigenen Status. Werden einer Anforderung keine Testfälle zugeordnet, so hat diese Anforderung den Status Not Covered. Sonst ist der Cover-Status einer Anforderung der Ausführungsstatus der damit verknüpften Testfälle. Siehe Ausführungsstatus eines Testfalls in Tabelle 4.3. Zur besseren Übersicht und effizienteren Verwaltung werden die Anforderungen in einer hierarchischen Struktur abgelegt. Siehe Abbildung 3.1. Abbildung 3.1: Anforderungs-Struktur und Status in einem TestDirektor-Projekt 3 In der Terminologie des Unternehmens sind Defects Abweichungen, Fehler oder Fehlverhalten in einem Programm, die während des Testens erkannt werden. 4 Bei RequisitePro handelt es sich um ein Anforderungsmanagementtool der Firma IBM Rational, das im Unternehmen zur Unterstützung des Anforderungsmanagements eingesetzt wird. 13

14 Weiterhin können jeder Anforderung zusätzliche Attribute zugeordnet werden, wie z.b. Priority für die Angabe der Priorität, mit der diese Anforderung umgesetzt werden soll, oder Type zur Beschreibung des Anforderungstyps, z.b. funktional oder nicht funktional. Siehe Abbildung TEST PLAN Abbildung 3.2: Attribute einer Anforderung Die Erstellung und Beschreibung der Testfälle geschieht im Bereich TEST PLAN. Die Testfälle können in einer hierarchischen Struktur abgelegt werden. Jeder Testfall besteht aus mehreren Schritten. In jedem Schritt werden die Eingangs- und die erwarteten Ausgangsdaten beschrieben. Siehe Abbildung 3.3. Abbildung 3.3: Testfall-Struktur und Beschreibung eines Testfalls 14

15 Einem Testfall können eine Menge von Attributen angehören wie z.b. Status, das den momentanen Status des Testfalls angibt und darüber informiert, ob der Testfall in der Beschreibungsphase Design oder Bereit zum Ausführen Ready ist. Siehe Abbildung 3.4. Abbildung 3.4: Attribute eines Testfalls Zusätzlich können verschiedene Arten von Dokumenten oder Bildern einem Testfall unter Attachments angehängt werden. Unter Regs Coverage kann einem Testfall eine oder mehrere Anforderungen zugeordnet werden. 3. TEST LAB Im Bereich TEST LAB findet die Testausführung statt. Zunächst werden die einzelnen Testfälle zu einem so genannten TestSet zusammengefasst. Ein TestSet besteht aus einem oder mehreren Testfällen, die in einer logischen Reihenfolge ausgeführt werden. Um verschiedene Testszenarien abzubilden, können die Testfälle in mehreren TestSets unterschiedlich kombiniert werden. Die Aufteilung der einzelnen TestSets in einer Baumstruktur erlaubt eine flexible Zusammenstellung der TestSets je nach Release, Teststufe oder Anwendung. Siehe Abbildung 3.5. Abbildung 3.5: TestSet-Struktur und Status in einem TestDirektor-Projekt 15

16 Einem TestSet können verschiedene beschreibende Attribute angehören wie z.b. Close Date, das angibt, an welchem Datum diese Tests aufgeführt wurden. Siehe Abbildung 3.6. Abbildung 3.6: Attribute eines TestSets Auch einem TestSet können unter Attachments verschiedene Dokumente angehängt werden. 4. DEFECTS Werden während des Testens Abweichungen oder Fehler festgestellt, so werden diese vom Testdurchführenden als ein Defekt im Bereich DEFECTS erfasst und einem Bearbeiter zugeordnet. Darüber hinaus kann ein Defekt einem entsprechenden Testfall zugeordnet werden. Beim Erstellen eines Defekts können verschiedene Attribute zur besseren Beschreibung des Defekts gefüllt werden. Siehe Abbildung 3.7. Abbildung 3.7: Attribute eines Defekts 16

17 Eins der wichtigsten Attribute ist der Status eines Defekts. Beim Erstellen des Defekts wird der Status auf New gesetzt. Wird der Defekt vom Lösungsverantwortlichen z.b. aufgrund falscher Zuordnung abgelehnt, so setzt dieser den Status auf Rejected. Nimmt er den Defekt an, so setzt er den Status auf Open. Nach Behebung des Defekts wird der Status auf Fixed gesetzt. Falls die Lösung vom Defektersteller nicht akzeptiert wird, so setzt dieser den Status auf Not accepted. Der Lösungsverantwortliche dokumentiert dann die erneute Annahme durch den Status Reopen. Wird der Defekt erfolgreich behoben und die Lösung akzeptiert, ist der Status auf Closed zu setzen. Siehe Abbildung 3.8 [3]. New Rejected Open Reopen Fixed Not accepted Closed Abbildung 3.8: Lebenszyklus eines Defekts als Aktivitätsdiagramm 17

18 3.1.2 Analyse und Reports In allen Bereichen des TestDirectors (REQUIREMENTS, TEST PLAN, TEST LAB, DEFECTS) können Standard-Reports in Form von Graphen oder Diagramme über den aktuellen Status eines TestDirector-Projekts erstellen werden. Mit Graphen wird eine Fortschrittanalyse der Daten auf Zeitbasis gezeigt. Eine Zusammenfassung der Datenbereiche kann als Diagramm dargestellt werden. Abbildung 3.9 zeigt ein Beispiel-Report für den aktuellen Stand der Defects bzgl. Status und Priorität in einem TestDirector-Projekt. 3.2 Rollenkonzept Abbildung 3.9: Beispiel-Report in einem TestDirector-Projekt Zur Administration und Nutzung des TestDirectors im Finanzdienstleister werden verschiedene Gruppen mit unterschiedlichen Rechten definiert. Im Folgenden eine Zusammenfassung der Aufgaben und Verantwortlichkeiten der für diese Arbeit relevanten Gruppen: TDAdmin: Dieser Gruppe gehört nur der technische User admin der TestFactory an. Er ist für die Einrichtung von TestDirector Repositories und die zentrale Benutzereinrichtung verantwortlich. Defect_Bearbeiter: Die Angehöriger dieser Gruppe haben ausschließlich eine Sicht auf den TestDirector-Bereich DEFECTS und dort nur eingeschränkte Modifikationsrechte. 18

19 Tester: In dieser Gruppe haben die Benutzer alle Rechte außer Löschen auf alle TestDirector- Bereiche. Im Allgemeinen werden folgende Rollen dieser Gruppe zugeordnet: Tester, Entwickler, Qualitätssicherer oder Integratoren und Abnehmer. Projekt_Manager: Diese Gruppe hat alle Rechte auf die TestDirector-Bereiche und zusätzliche Rechte zur Administration eines TestDirector Projektrepositories. Dieser Gruppe werden i.a. folgende Rollen zugeordnet: Projektleiter und Projektmanager. 3.3 Ist-Zustand der Projekte im TestDirector Momentan werden durch die Testfacotry keine Vorgaben oder Empfehlungen gegeben, wie die Ablagestruktur der Testfälle im TestDirector aussehen soll. So ist es jedem Projekt überlassen, die eigene Ordnerhierarchie in den Bereichen TEST PLAN und TEST LAB zu bestimmen. Demzufolge sind die Reihenfolge und die Anzahl der Ebenen sowie die Kriterien zur Gliederung der Objekte in den Projekten völlig unterschiedlich. Abbildung 3.10 zeigt beispielhaft die Strukturen von drei TestDirector-Projekten. In a) wird nach Teststufe, dann nach Release und Anwendung gegliedert. Bild b) zeigt eine Gliederung nach Release, Testart, Baseline und Team. In Bild c) wird eine Gliederung nach Anwendung, Release, Betriebssystem und Testart gezeigt. Abbildung 3.10: Strukturen von drei TestDirector-Projekten Außerdem sind die Attribute in den Projekten bzgl. Reihenfolge und Bestimmung von obligatorischen Feldern unterschiedlich. Einige Projekte enthalten zusätzliche Attribute, die in anderen Projekten nicht verwendet werden. Abbildung 3.11 a) und b) zeigt beispielhaft die Attribute im Bereich DEFECTS in zwei TD-Projekten. Formatiert Abbildung 3.11: a) Attribute im Bereich DEFECTS in einem TestDirector-Projek 19

20 Abbildung 3.11: b) Attribute im Bereich DEFECTS in einem anderen TestDirector-Projekt Auch die Attributwerte und Attributbezeichnungen sind nicht in allen Projekten einheitlich. Abbildung 3.12 zeigt die verschiedenen Werte des Attributes Priority in drei TestDirector- Projekten. Abbildung 3.12: Werte des Attributs Priority in drei TestDirector-Projekten 3.4 Probleme beim Reporting Um aussagekräftige Reports zu erstellen ist die genaue Kenntnis der projektspezifischen Ablagestruktur, der Attribute und deren Werte erforderlich. Eine Gesamtübersicht über den Teststatus von außen, z.b. aus Sicht der Integration und Abnahme, ist sehr schwer nachvollziehbar. Eine einheitliche Sicht über mehrere Projekte ist nicht möglich. Außerdem können die generierten Reports abweichende Ergebnisse vom tatsächlichen Status enthalten wenn einige Fälle nicht betrachtet werden wie z.b. das Verschieben von Testfällen in neuen Ordnern im jeweiligen Projekt oder das Kopieren und Einfügen von Testfällen zwischen verschiedenen Projekten. Solche Aktivitäten können zu Verlusten von Daten Führen wenn einige Attribute im neuen Projekt nicht existieren. Sind die Attribute physikalisch in verschiedener Reihenfolge gespeichert, so kommt es zu unkorrekten Zuordnung der Attributwerte. Demzufolge können die Statistiken keine korrekte Ergebnisse zeigen. Im TestDirector sind also eine große Menge von relevanten Informationen, die wegen fehlender einheitlicher Struktur nicht genutzt werden können, was ein großer Verlust für das Testmanagement darstellt. 20

Projektstrukturierung und eine maßgeschneiderte Reportinglösung für HP QC

Projektstrukturierung und eine maßgeschneiderte Reportinglösung für HP QC Projektstrukturierung und eine maßgeschneiderte Reportinglösung für HP QC Christian Köster Talanx Systeme AG Test Competence Center Bad Neuenahr 2014 Test Compentence Center (TCC) IT-Architektur TSY-AR.T

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

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

TESTPLAN

TESTPLAN <Projektname> Firma TESTPLAN ID Version Ersteller: ------------------- Vorgesetzter des Erstellers:

Mehr

Testmanagement bei SAP-Projekten

Testmanagement bei SAP-Projekten Testmanagement bei SAP-Projekten Erfolgreich Planen Steuern Reporten bei der Einführung von SAP-Banking von Alberto Vivenzio, Domenico Vivenzio 1. Auflage Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung 2007 Dr. Klaudia Dussa-Zieger P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung Testberichterstattung Lehrplan

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Testkonzept. Tipp-Star

Testkonzept. Tipp-Star Tipp-Star Version: V1.0-27.09.2015 Ablageort: Tipp-Star/01_Projektmanagement/03_Test Status: Fertig gestellt (In Bearbeitung / fertig gestellt / geprüft / freigegeben) Anzahl Seiten: 9 Autoren: tse Sergeyeva

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Messsystemanalyse (MSA)

Messsystemanalyse (MSA) Messsystemanalyse (MSA) Inhaltsverzeichnis Ursachen & Auswirkungen von Messabweichungen Qualifikations- und Fähigkeitsnachweise Vorteile einer Fähigkeitsuntersuchung Anforderungen an das Messsystem Genauigkeit

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit

Mehr

Dokumentation Eigenwartung

Dokumentation Eigenwartung Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Copyright... 3 1.2 Einstieg... 3 2 Ordner Navigation... 4 3 Menüleiste... 5 3.1 Alle/Keine Elemente auswählen... 5 3.2 Kopieren... 5 3.3 Ausschneiden... 5 3.4

Mehr

Neuerungen in SASUnit, insbesondere Ermittlung der Testabdeckung

Neuerungen in SASUnit, insbesondere Ermittlung der Testabdeckung Neuerungen in SASUnit Neuerungen in SASUnit, insbesondere Ermittlung der Testabdeckung Dr. Patrick René Warnat HMS Analytical Software GmbH Rohrbacher Str. 26 69115 Heidelberg patrick.warnat@analytical-software.de

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung Testen II (Management, Tools) Daniela Rose Fachgebiet Softwaretechnik und Systemgestaltung 12.12.2007 Gliederung 1. Motivation 2. Der grundlegende Testprozess 3. Testen im Softwareentwicklungsprozess 4.

Mehr

Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung

Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung Der Stammesverbund Inhaltsverzeichnis Software-Qualitätssicherung Fachliche Testautomatisierung Test-Outsourcing Test-Virtualisierung

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG Medizin- und Informationstechnik AG Testautomatisierung Märchen, Möglichkeiten und praktischer Nutzen Richard Seidl 21. Januar 2013 TU Dresden Kardiologische Funktionsdiagnostik Vitalfunktions-Monitoring

Mehr

Testmanagement Zentraler Prozess im ALM

Testmanagement Zentraler Prozess im ALM Testmanagement Zentraler Prozess im ALM DI Manfred Baumgartner, ANECON 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

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann. Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE)

Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann. Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE) Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE) superdata auf einen Blick Produkte FIT Testverfahren

Mehr

Von Excel zur ALM Einsatz des HP Quality Centers bei der parcit GmbH. Dr. Thorsten Schmidt parcit GmbH 22. November 2012

Von Excel zur ALM Einsatz des HP Quality Centers bei der parcit GmbH. Dr. Thorsten Schmidt parcit GmbH 22. November 2012 Von Excel zur ALM Einsatz des HP Quality Centers bei der parcit GmbH Dr. Thorsten Schmidt parcit GmbH 22. November 2012 Agenda Vorstellung - Rahmenbedingungen Einführung des TestDirector 8.0 Verbesserungen

Mehr

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0 Leistungsbeschreibung PHOENIX Archiv Oktober 2014 Version 1.0 PHOENIX Archiv Mit PHOENIX Archiv werden Dokumente aus beliebigen Anwendungen dauerhaft, sicher und gesetzeskonform archiviert. PHOENIX Archiv

Mehr

Zwei starke Werkzeuge mit Methodik vereint Dynamic Process Testing (DPT)

Zwei starke Werkzeuge mit Methodik vereint Dynamic Process Testing (DPT) Zwei starke Werkzeuge mit Methodik vereint Dynamic Process Testing (DPT) Agenda 1 2 3 4 5 6 Testpille - Die Herausforderung Testpille - Die Realisierung Testpille - Die Keyfacts Testpille - Der Prozess

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

SixCMS 6 Tutorial - Content-Manager. So erfassen Sie Inhalte mit SixCMS

SixCMS 6 Tutorial - Content-Manager. So erfassen Sie Inhalte mit SixCMS SixCMS 6 Tutorial - Content-Manager So erfassen Sie Inhalte mit SixCMS Inhalt Inhalt So erfassen Sie Inhalte mit SixCMS 3 Zu diesem Tutorial 3 Ablageort definieren 5 Content-Container erstellen 6 Einträge

Mehr

IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf

IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf Pressemeldung Frankfurt am Main, 02. Februar 2012 IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf Software Quality Assurance wird nicht geliebt aber praktiziert. Die

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

LISTENFILTER FÜR DIE MITARBEITER-STAMMDATEN

LISTENFILTER FÜR DIE MITARBEITER-STAMMDATEN LISTENFILTER FÜR DIE MITARBEITER-STAMMDATEN PRODUKT(E): KATEGORIE: Vivendi PEP Stammdaten VERSION: 2.95 ERSTELLT AM: 26.03.2014 Frage: Wie filtert man in Vivendi PEP die Mitarbeiterdaten nach bestimmten

Mehr

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com Use Cases REQEDIT CLIENT Mai 2014 Übersicht 1. Einführung Anforderungsmanagement 2. Einführung Anforderungsmanagementtools und Austauschformate 3. Warum ReqEdit? 4. Use Cases - kleinere und mittlere Unternehmen

Mehr

Performance Zertifizierung

Performance Zertifizierung Performance Zertifizierung Alois Schmid alois.schmid@itf-edv.de www.itf-edv.de Copyright 2012 ITF-EDV Fröschl GmbH Inhalt Firma.... Kapitel 1 Gründe für die Zertifizierung der Massendatentauglichkeit.....

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Abweichungsmanagement. Probleme hat doch jeder

Abweichungsmanagement. Probleme hat doch jeder 1 Abweichungsmanagement Probleme hat doch jeder SEQIS Software Testing Know-how Veranstaltungen 2011 24.03.2011 16.06.2011 22.09.2011 24.10.2011 Nicht zuviel und nicht zuwenig: Testdokumentation Theorie

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

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0 Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014 Gültig für Release 1.0.0.0 Inhalt 1 WebPart Site Informationen 3 1.1 Funktionalität 3 1.2 Bereitstellung und Konfiguration 4 2 WebPart

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Prüfbericht. Produktprüfung FastViewer

Prüfbericht. Produktprüfung FastViewer Nr. 028-71325195-000 Rev. 1 Produktprüfung FastViewer Gegenstand FastViewer - Desktop-Sharing Anwendung Prüfungsart Produktprüfung Grundlage TÜV-Süd Prüfkatalog zur Qualität von Anwendungs-Software auf

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

Critical Testing Process

Critical Testing Process Critical Testing Process Überblick über die Inhalte des Buches von Rex Black GI-TAV TAV-TM TM Treffen 22. Juni 2007 by Maud Schlich - IT-PROJECT-SERVICE Seite 1 von 24 Vorstellung seit über 20 Jahren in

Mehr

ALLG. METHODEN DES SOFTWAREENGINEERING

ALLG. METHODEN DES SOFTWAREENGINEERING Test und Testdokumentation ALLG. METHODEN DES SOFTWAREENGINEERING Agenda Maßnahmen zur Qualitätssicherung und Steigerung Tests, Testkategorien und Fehlerarten Teststufen und Testplanung Testdokumentation

Mehr

Vector Software W H I T E P A P E R. Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen

Vector Software W H I T E P A P E R. Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen Vector Software W H I T E P A P E R Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen Einführung Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den gesamten Software Entwicklungszyklus.

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

Zeitweise wurden Dokumente nicht eindeutig im Verzeichnis abgespeichert. Was zur Folge hatte, dass gleichnamige Dokumente überschrieben wurden.

Zeitweise wurden Dokumente nicht eindeutig im Verzeichnis abgespeichert. Was zur Folge hatte, dass gleichnamige Dokumente überschrieben wurden. NEUSTA GmbH Contrescarpe 1 28203 Bremen Fon: +49(0)421.2 06 96-0 Fax: +49(0)421.2 06 96-99 www.neusta.de Release Notes Version 6.2.2 Upload von Dokumenten Zeitweise wurden Dokumente nicht eindeutig im

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11 xiii 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Fundamentaler Testprozess 11 2.1 Testplanung und -steuerung........................

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

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Cross Border Reporting

Cross Border Reporting Cross Border Reporting Matthias Sturzenegger Stv. Leader Service Integration, LISR Filip Milikic CEO and Founder The Same Tough Question in Software QA Wir sind seit über 140 Jahren eine verlässliche

Mehr

Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein.

Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein. Pfade einstellen Stand: Dezember 2012 Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein. Diese Anleitung soll zeigen, wie man Pfad-Favoriten

Mehr

Anforderungen an ein modernes Projektmanagement

Anforderungen an ein modernes Projektmanagement Anforderungen an ein modernes Projektmanagement In Unternehmen aller Branchen scheitern nach unabhängigen Studien ca. 30% aller Projekte. Hierbei handelt es sich sowohl um Projekte des Betriebszwecks als

Mehr

Ticket Center Quick Start

Ticket Center Quick Start AdNovum Informatik AG. Juli 13 2 Wozu dient das? Indem Sie Ihre Fehlermeldungen, Anfragen und Vorschläge zur Software stets im erfassen, helfen Sie uns, die Informationen zur einzelnen Meldung konsistent

Mehr

Anleitung fu r die Vorlage restpunkte.xlsx

Anleitung fu r die Vorlage restpunkte.xlsx Anleitung fu r die Vorlage restpunkte.xlsx Inhalt 1 Einleitung... 1 2 Grundsätzliche Bedienungshinweise... 1 3 Wichtige Regeln für das Ausfüllen... 2 4 Erfassen der Information... 2 4.1 Das Blatt Inspektionen...

Mehr

Jens Borchers. Kritische Erfolgsfaktoren beim Abnahmetest in Redevelopment- Projekten Erfahrungen aus einem Großprojekt

Jens Borchers. Kritische Erfolgsfaktoren beim Abnahmetest in Redevelopment- Projekten Erfahrungen aus einem Großprojekt Chemnitz 24.11.2006 Jens Borchers Kritische Erfolgsfaktoren beim Abnahmetest in Redevelopment- Projekten Erfahrungen aus einem Großprojekt Vortrag bei der RePro2006 in Chemnitz am 24. November 2006 Kritische

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

Testen von Data-Warehouse- und Business-Intelligence-Systemen

Testen von Data-Warehouse- und Business-Intelligence-Systemen Edition TDWI Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte von Herbert Stauffer, Beat Honegger, Hanspeter Gisin 1. Auflage Testen von Data-Warehouse- und

Mehr

Universal Testing. Intelligentes & effizientes Testen mit Universal. Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35

Universal Testing. Intelligentes & effizientes Testen mit Universal. Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35 Universal Testing Consor AG Ottikerstrasse 14 CH-8006 Zürich +41 44 368 35 35 Copyright 2001-2009 Consor AG Seite 1 von 5 Komplexe Applikationen, Geschäftsprozesse und Produktentwicklungen, die kontinuierlich

Mehr

ERP-Systemeinsatz bewerten und optimieren

ERP-Systemeinsatz bewerten und optimieren ERP-Systemeinsatz bewerten und optimieren Handlungsfelder zur Optimierung des ERP-Systemeinsatzes ERP-Lösungen werden meist über viele Jahre lang eingesetzt, um die Geschäftsprozesse softwaretechnisch

Mehr

Automatisiertes Testen von Prüfplätzen

Automatisiertes Testen von Prüfplätzen EXCO. The Quality Company Solutions for Industry and R&D Automatisiertes Testen von Prüfplätzen Am Beispiel einer Prüfplatz-Software stellen wir einen toolgestützten Prozess zur Erstellung der erforderlichen

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

CVS-Einführung. Sebastian Mancke, mancke@mancke-software.de

CVS-Einführung. Sebastian Mancke, mancke@mancke-software.de CVS-Einführung Sebastian Mancke, mancke@mancke-software.de Grundlagen Motivation und Anforderung Sobald ein Softwaresystem anwächst, ergeben sich Probleme im Umgang mit dem Quell Code. CVS (Concurrent

Mehr

IAWWeb PDFManager. - Kurzanleitung -

IAWWeb PDFManager. - Kurzanleitung - IAWWeb PDFManager - Kurzanleitung - 1. Einleitung Dieses Dokument beschreibt kurz die grundlegenden Funktionen des PDFManager. Der PDF Manager dient zur Pflege des Dokumentenbestandes. Er kann über die

Mehr

Application Delivery. Optimierung der Applikationsqualität und -performance. Michael Fahden, Mercury

Application Delivery. Optimierung der Applikationsqualität und -performance. Michael Fahden, Mercury Application Delivery Optimierung der Applikationsqualität und -performance Michael Fahden, Mercury Das Unternehmen Mercury Mio. $ $506 32,81%* $400 $361 $307 $188 $121 1998 1999 2000 2001 2002 2003 2004

Mehr

Unsere Datenschutzerklärung

Unsere Datenschutzerklärung Unsere Datenschutzerklärung Cookies Das Akzeptieren von Cookies ist keine Voraussetzung zum Besuch unserer Webseiten. Jedoch weisen wir Sie darauf hin, dass die Nutzung der Warenkorbfunktion und die Bestellung

Mehr

Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering

Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Requirements Engineering Seminar im WS 07/08 Metriken als Basis für das

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria Diese Diese Kommentarfelder Kommentarfelder können können Sie Sie über über das das Menü Menü Ansicht Ansicht -Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Dies Dies ist ist die die

Mehr

Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern. Dazu klicken Sie bitte auf Ihren Namen.

Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern. Dazu klicken Sie bitte auf Ihren Namen. 1 Passwort ändern Nach Ihrer erstmaligen Anmeldung sollten Sie Ihr Passwort ändern Dazu klicken Sie bitte auf Ihren Namen Abb 1-1 Erstmaliger Anmeldung Danach erscheint ein PopUp indem Sie Ihr Passwort

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

Testskripten Beispiele für System- und Akzeptanztests

Testskripten Beispiele für System- und Akzeptanztests Testskripten Beispiele für System- und Akzeptanztests Dokument-Information Dokument-ID: BA-TSKR Version: 1.0, gültig ab: 01.05.2010 Ersetzt Version: Autor(en): Isabelle Neuburg Geltungsbereich: Entwicklung

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Von Excel zur ALM Einsatz des HP Quality Centers bei der. Dr. Thorsten Schmidt parcit GmbH 05. Oktober 2011

Von Excel zur ALM Einsatz des HP Quality Centers bei der. Dr. Thorsten Schmidt parcit GmbH 05. Oktober 2011 Von Excel zur ALM Einsatz des HP Quality Centers bei der parcit GmbH Dr. Thorsten Schmidt parcit GmbH 05. Oktober 2011 Agenda Vorstellung - Rahmenbedingungen g Einführung des TestDirector 8.0 Verbesserungen

Mehr

Risk Management. Überblick RIM 1.5.100

Risk Management. Überblick RIM 1.5.100 Risk Management Überblick - 1 - OMNITRACKER Risk Management im Überblick Effizientes Risikomanagement mit dem OMNITRACKER Risk Management Ein Werkzeug zur Abdeckung des gesamten Prozesses von der Risikoerfassung

Mehr

Handbuch Schulungsdatenbank

Handbuch Schulungsdatenbank Handbuch Schulungsdatenbank Inhaltsverzeichnis Hinweise... 3 Überblick... 4 Themen... 5 Schulungsprogramm Verwalten... 6 Details... 7 Schulungsprogramm bearbeiten... 9 Anstehende Termine... 10 Schulungen

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

KURZANLEITUNG CLOUD BLOCK STORAGE

KURZANLEITUNG CLOUD BLOCK STORAGE KURZANLEITUNG CLOUD BLOCK STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung......Seite 03 2. Anlegen eines dauerhaften Block Storage...Seite 04 3. Hinzufügen von Block Storage

Mehr

Agenda ITIL v3 Framework

Agenda ITIL v3 Framework Agenda ITIL v3 Framework Overview & Allgemeines ITIL Service Lifecycle Service Strategies Service Design Service Transition Service Operation Continual Service Improvement ITIL V3 Continual Service Improvement

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Start-Ziel-Sieg für Ihren Validierungsprozess

Start-Ziel-Sieg für Ihren Validierungsprozess Risikobasierte Validierung des CSB-Systems Start-Ziel-Sieg für Ihren Validierungsprozess Risikobasierte Validierung des CSB-Systems Programmiert für Ihren Erfolg D DIE VORTEILE FÜR IHR UNTERNEHMEN AUF

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

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster Webseitennavigation mit dem Content-Management-System Imperia Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster 10. Januar 2006 Inhaltsverzeichnis 1. Einführung 4 2. Rubrikenstruktur

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Administrative Tätigkeiten

Administrative Tätigkeiten Administrative Tätigkeiten Benutzer verwalten Mit der Benutzerverwaltung sind Sie in der Lage, Zuständigkeiten innerhalb eines Unternehmens gezielt abzubilden und den Zugang zu sensiblen Daten auf wenige

Mehr

Service Innovation Lab. Prozessoptimierung für Dienstleistungen

Service Innovation Lab. Prozessoptimierung für Dienstleistungen Service Innovation Lab Prozessoptimierung für Dienstleistungen 2 Dienstleistungsprozesse im Unternehmen Ein reibungsloser Ablauf der unternehmensinternen Prozesse ist die Basis des wirtschaftlichen Erfolgs

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen

Mehr

1 Einleitung. 2 Anmeldung

1 Einleitung. 2 Anmeldung Deployment-Portal 1 Einleitung Das Deployment-Portal von MODUS Consult bildet die zentrale Plattform zum Austausch von Programmobjekten wie Servicepacks und Programmanpassungen. Mit Hilfe von personalisierten

Mehr

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr