Inhaltsverzeichnis 1. EINLEITUNG Hintergrund der Diplomarbeit Inhalt der Diplomarbeit Aufbau der Diplomarbeit...

Größe: px
Ab Seite anzeigen:

Download "Inhaltsverzeichnis 1. EINLEITUNG... 4 1.1 Hintergrund der Diplomarbeit... 4 1.2 Inhalt der Diplomarbeit... 5 1.3 Aufbau der Diplomarbeit..."

Transkript

1 Evaluierung und Bereitstellung von Release/Konfigurationsmanagement-Werkzeugen zur unterstützenden Qualitätssicherung für Software-Entwicklung und -Design im Nearshoring-Umfeld Diplomarbeit an der Fachhochschule Frankfurt am Main FB2 Informatik und Ingenieurwissenschaften zur Erlangung des akademischen Grades Diplom-Informatiker (FH) vorgelegt von: Mehmet Ömer, Matr bei Dipl. Phys. Dr. Erwin Hoffmann Koreferent: Prof. Dr. Matthias Wagner Frankfurt am Main 2009

2 Inhaltsverzeichnis 1. EINLEITUNG Hintergrund der Diplomarbeit Inhalt der Diplomarbeit Aufbau der Diplomarbeit QUALITÄTSSICHERUNG Was ist Qualitätssicherung? Testmethoden-Übersicht Ablauf und Durchführung der Tests Vorteile der Qualitätssicherung Qualitätssicherung bei der GIP Qualitätssicherungs-Phasen THEORETISCHER TEIL Projektmanagement Konfigurationsmanagement Entwicklung ohne Konfigurationsmanagement Ziele des Konfigurationsmanagements Normen zur Umsetzung der KM-Ziele Continuous Integration Was ist Continuous Integration? Repository Idee der Kontinuierlichen Integration (Continuous Integration) Warum Continuous Integration und Vorteile, die sich daraus ergeben DAS UNTERNEHMEN Gesellschaft für innovative Personalwirtschaftssysteme mbh Produktbeschreibung KIDICAP P KIDICAP P5 PPay KIDICAP P5 PView KIDICAP P5 PPlan KIDICAP P5 PTravel KIDICAP P5 PView Details KIDICAP P5 PView von der technischen Seite AUFGABENSTELLUNG Momentane Situation Aufgabenbeschreibung/Zielsetzung Meine Aufgaben GROBKONZEPT Grobentwurf Erstellung des Grobkonzepts Anforderungen der Entwicklung ANFORDERUNGSANALYSE Zentrale Anforderungen Anforderungen zwischen der Verbindung Cluj Offenbach Anforderungen an das Versionskontrollsystem Anforderungen des Konfigurationsmanagements an das Versionskontrollsystem Anforderungen der Entwickler an das Versionskontrollsystem Anforderungen des Fachbereichs an das Versionskontrollsystem Versionskontrollsystem Was ist ein Versionskontrollsystem? Versionskontrollsystem Subversion

3 7.4.3 Funktionsweise von Subversion Vor- und Nachteile von Subversion Versionskontrollsystem Visual SourceSafe Funktionsweise von Visual SourceSafe Vor- und Nachteile von Visual SourceSafe Versionskontrollsystem MKS Integrity Suite Funktionsweise von MKS Integrity Suite Vor- und Nachteile von MKS Integrity Suite Auswertung des Punktesystems Anforderungen an das Continuous Integration System Analyse von Continuous Integration Systemen Continuous Integration mit AnthillPro Das Konzept von AnthillPro Continuous Integration mit CruiseControl Das Konzept von CruiseControl Probleme während der Installation Fazit der Anforderungsanalyse FEINKONZEPT Aufbau des Feinkonzepts Verbindung zwischen Cluj und Offenbach Continuous Integration mit CruiseControl.NET Deployment Update der Test- bzw. Entwicklungsumgebung Erläuterung der Arbeitsschritte IMPLEMENTIERUNG Aufbau der Implementierung Installation und Konfiguration von Visual SourceSafe Erstellen eines Repositories mit Visual SourceSafe Installation und Konfiguration von CruiseControl.NET Konfiguration des Build Scripts Automatisiertes Deployment mit der C#-Anwendung Isolierte Umgebung sperren und Benutzer abmelden De-/Registrieren, sichern und kopieren Datenbanksicherung Datenbank-Update der entsprechenden Umgebung Isolierte Test- und Entwicklungsumgebung aktualisieren Update-Protokoll kopieren und umbenennen Anwendungsbeschreibung anpassen Gesperrte isolierte Umgebung wieder freigeben Benachrichtigung über SCHLUSSWORT/FAZIT QUELLENANGABE ANHANG 1: VORLAGE TESTSPEZIFIKATION ANHANG 2: TESTABSCHLUSS-BERICHT ANHANG 3: CCNET.CONFIG ANHANG 4: PVIEW_DEFAULT.BUILD

4 1. Einleitung 1.1 Hintergrund der Diplomarbeit In Hinblick auf die gemeinsame Arbeit im Projekt stellen große, verteilt entwickelnde Softwareprojekte besondere Ansprüche an Entwicklerteams. Das Besondere an solch einem Softwareprojekt ist die gemeinsame Entwicklung mehrerer Entwickler auf derselben Quellcodebasis. Dies bedeutet nicht, dass alle Entwickler gleichzeitig zusammen an derselben Systemkomponente arbeiten. Es findet eine überschneidende Entwicklung mit einer Aufteilung der Gesamtentwicklung statt. Die Zusammenführung der verteilten Gesamtentwicklung erfolgt durch eine regelmäßige Integration der Änderungen in die zentrale Quellcodebasis. Da Änderungen nicht sofort in die zentrale Quellcodebasis integriert werden, ergeben sich vorab unterschiedliche Entwicklungsstände. Der Grund dafür ist, dass mehrere qualitätssichernde Maßnahmen eine Rolle spielen, wie z.b. die konsequente Ausführung der Tests. Es erfordert aber auch ein hohes Maß an Disziplin, die Tests nach jeder Änderung auszuführen. Schließlich gibt es auch Tests, die nach dem Zusammenführen aller Änderungen der Entwickler durchgeführt werden. Es kann also durchaus sein, dass an einem Arbeitsplatz die durchgeführten Tests erfolgreich abgeschlossen werden. Gleichzeitig können diese jedoch auf der gesamten Quellcodebasis im Zusammenspiel mit anderen Änderungen der Entwickler scheitern. Somit kann der erfolgreiche Testlauf eventuell an eine spezielle Umgebung gebunden sein, die nur auf einem Arbeitsrechner eingerichtet wurde. Das Zusammenführen von Quellcode-Änderungen findet in einem so genanten Versionskontrollsystem (engl. Source Control Management System) statt, welches ich im Laufe dieser Diplomarbeit noch ausführlich beschreiben werde. Zusätzlich ergibt sich die Möglichkeit, regelmäßige Abzüge der System-Zwischenstände aus diesem Versionskontrollsystem zu erstellen. So genannte Releases 1, die dem Kunden zu Demonstrations- und Testzwecken zur Verfügung gestellt werden können. Zudem kann ein Release auch als eine Version oder als ein fertiges Produkt veröffentlicht werden. 1 Release wird als ein Abzug des Softwaresystems bezeichnet, der als eine neue Version oder als ein fertiges Produkt dem Auftraggeber übergeben wird. 4

5 1.2 Inhalt der Diplomarbeit Diese Diplomarbeit befasst sich mit der Einführung eines Continuous Integration 2 Systems in ein verteilt entwickeltes Entwicklungsprojekt. Die Einführung wird in einer realen Entwicklungsumgebung der Firma GIP mbh erfolgen. Dabei werden keine bestimmten Werkzeuge oder Arbeitsabläufe in den Vordergrund gestellt. Alle notwendigen Arbeitsschritte werden im Laufe dieser Diplomarbeit analysiert und mit Absprache der zuständigen Personen durchgeführt. Ziel ist es, die Qualitätssicherung des Entwicklungsteams, welches sich in einem Nearshoring-Umfeld befindet, mit Einführung eines Continuous Integration Systems zu verbessern und damit transparenter für die GIP mbh zu gestalten. Es soll also eine zusätzliche Qualitätssicherungsmaßnahme eingeführt werden und keine neue Entwicklung der Qualitätssicherung erfolgen. Zusätzlich soll ein Deploy-Mechanismus entwickelt werden, welcher die Ergebnisse des Entwicklungsteams in einer Testumgebung anwendet. Auch hierfür sind keine festen Anordnungen gegeben; diese werden erst im Laufe der Analyse je nach Anforderung und Situation ermittelt. 1.3 Aufbau der Diplomarbeit Die Diplomarbeit besteht insgesamt aus neun Kapiteln, die aufbauend strukturiert sind. Die ersten vier Kapitel beinhalten grundlegende Kenntnisse, die zur Umsetzung der gestellten Anforderungen dienen. Die restlichen Kapitel, fünf bis neun dagegen befassen sich mit dem praktischen Teil der Diplomarbeit. Daraus ergibt sich folgende Gliederung: 1. Kapitel: Einleitung 2. Kapitel: Kurze Beschreibung über Qualitätssicherung 3. Kapitel: Erläuterung von Begrifflichkeiten 4. Kapitel: Informationen über die Firma 5. Kapitel: Momentane Situation und Aufgabenstellung 6. Kapitel: Grobkonzepts 7. Kapitel: Anforderungsanalyse 8. Kapitel: Feinkonzepts und Deployment 9. Kapitel: Implementierung Da die Diplomarbeit sich mit der Entwicklung einer Maßnahme zur Qualitätssicherung beschäftigt, möchte ich im Vorfeld einige Wörter über Qualitätssicherung erzählen. Dabei werden die allgemeine Qualitätssicherung und insbesondere die Qualitätssicherung, welche bei der GIP durchgeführt wird, erläutert. Als nächstes werden zusammenhängende Begrifflichkeiten in Verbindung mit Continuous Integration gebracht und vor allem deren Vorteile erläutert. Im letzten theoretischen Teil der Diplomarbeit möchte ich noch Informationen über die Firma Gesellschaft für innovative Personalwirtschaftssysteme mbh (GIP mbh), bei der ich diese Diplomarbeit durchführen darf, näher vorstellen. Es werden auch Angaben über die Produkte der GIP gemacht. Das Augenmerk wird sich dabei auf das Produkt PView richten, da im Endeffekt das gesamte Konzept dieser Diplomarbeit darauf angewandt wird. Im ersten Kapitel des praktischen Teils möchte ich das Thema der Diplomarbeit bzw. die Aufgabenstellung näher erläutern. Dabei wird versucht, ein 2 Wird ausführlich im Kapitel 3.2 Continuous Integration ausgearbeitet. 5

6 Lösungsweg zu erarbeiten, der es ermöglicht, aus dem momentanen Ist-Zustand den angestrebten Endzustand zu realisieren. Mit dem Grobkonzept wird erst einmal durchexerziert, wie das Gesamtsystem aussehen könnte. Dazu wird ein Grobentwurf vom Konfigurationsmanagement erstellt, welcher als Vorlage für die anderen Bereiche dienen soll. Schließlich wird anhand der Vorschläge des Fachbereichs und der Entwicklung aus dem Grobentwurf ein Grobkonzept erstellt. Anhand des Grobkonzepts kann dann die Anforderungsanalyse durchgeführt werden. Durch die Anforderungsanalyse werden die Anforderungen für die jeweiligen Tools bestimmt, die das Gesamtsystem bilden sollen. Mit diesen Anforderungen wird eine Tool-Evaluierung durchgeführt und ausgewertet. Nachdem die Tools bestimmt worden sind, kann das Feinkonzept erstellt und das Deployment beschrieben werden. Schließlich wird das Feinkonzept mit der Implementierung umgesetzt. Dabei werden auch die Installationen und Konfigurationen der einzelnen Tools erläutert, die für den Aufbau des Gesamtsystems notwendig sind. 6

7 2 Qualitätssicherung 2.1 Was ist Qualitätssicherung? Die Qualitätssicherung war in der Vergangenheit in der Softwareentwicklung negativ besetzt. Viele Projekte sind auf Grund mangelnder Qualitätssicherung gescheitert. Darunter waren sehr teure Projekte, deren Schaden in den Milliarden-Bereich gehen. Ein Beispiel dafür war die Ariane 5. Die Rakete sollte vier Satelliten in das Weltall befördern; sie musste aber nur nach 42 Sekunden durch Selbstzerstörung gesprengt werden. Damit gingen 1,7 Milliarden DM verloren. Der Grund für die Zerstörung war, dass Teile der Softwareentwicklung aus dem Vorgängermodell (Ariane 4), ohne Tests durchzuführen, übernommen wurden. Der Fehler kam durch eine Konvertierung eines 64-bit-floatingpoint-Wertes in einen 16-bit-Integer-Wert zustande. Der Wert der Gleitpunktzahl konnte damit nicht dargestellt werden. Die Ariane 5 hatte im Vergleich zum Vorgängermodell eine höhere Horizontalbeschleunigung, damit reichte ein 16-bit-Integer nicht mehr aus und ein Überlauf wurde auch nicht abgefangen. Heute sind die Codezeilen im Internet nachzulesen, die zu diesem traurigen Ereignis geführt haben.... declare vertical_veloc_sensor: float; horizontal_veloc_sensor: float; vertical_veloc_bias: integer; horizontal_veloc_bias: integer;... begin declare pragma suppress(numeric_error, horizontal_veloc_bias); begin sensor_get(vertical_veloc_sensor); sensor_get(horizontal_veloc_sensor); vertical_veloc_bias := integer(vertical_veloc_sensor); horizontal_veloc_bias := integer(horizontal_veloc_sensor);... exception when numeric_error => calculate_vertical_veloc(); when others => use_irs1(); end; end irs2; 3 Mit solchen Misserfolgen steigt natürlich die Wichtigkeit der Qualitätssicherung. Qualitätssicherung sind Ansätze und Maßnahmen, die gewährleisten sollen, dass ein Produkt ein definiertes Qualitätsniveau erreicht. Dabei spielt die Definition des Qualitätsniveaus eine wichtige Rolle. Denn nach ISO 9000 geht es lediglich darum, ein vorgegebenes Niveau zu halten, und nicht darum, die Qualität zu optimieren. Es könnte also auch ein niedriges Niveau definiert werden und darauf die Qualitätssicherung durchgeführt werden. Bestritten ist sicherlich dann die Qualität des Produktes, wofür letztendlich die Qualitätssicherung angewandt wird. Damit verbunden stellt sich die Frage, was überhaupt Qualität ist. Balzert beschreibt Qualität mit folgenden Worten: Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht Stand März [1] 4 Lehrbuch der Software-Technik/Balzert 2008, S

8 Da die Produkte oder Projekte für bestimmte Zielgruppen entwickelt werden, entstehen auch bestimmte Anforderungen. Der Kunde erwartet z.b. von einer Anwendung, dass diese ihren Einsatzzweck erfüllt, und er stellt den Anspruch, dass der Arbeitsprozess nicht andauernd mit irgendwelchen Programmierfehlern unterbrochen wird. Die organisatorischen Maßnahmen, die während der Verbesserung eines Produktes eingebracht werden, werden als Qualitätsmanagement bezeichnet. Das Qualitätsmanagement hat die Aufgabe, neben der Einhaltung der Qualität, die Effektivität der Arbeit zu erhöhen. Dabei arbeitet das Qualitätsmanagement nicht am eigentlichen Entwicklungsprozess mit, sondern beschäftigt sich mit allem rund um die Gestaltung und Leitung des Produkts. Typische Aufgaben wären z.b. die Optimierung der Standards, das Erstellen einer Kommunikationsstruktur, die Motivation sowie Aus- bzw. Weiterbildung der Mitarbeiter. Es gibt ein Konstruktives und ein Analytisches Qualitätsmanagement. Das Konstruktive Qualitätsmanagement befasst sich mit zwei Maßnahmen. Zum einen sind es die technischen und zum anderen sind es die organisatorischen Maßnahmen. Das Konstruktive Management stellt sicher, dass es definierte Vorgehensweisen für den Entwicklungsprozesse gibt. Dabei beschäftigen sich die technischen Maßnahmen eher mit Methoden, Werkzeugen und Sprachen, wobei sich die organisatorischen Maßnahmen eher mit Richtlinien, Checklisten und Standards befassen. Das analytische Qualitätsmanagement dagegen umfasst Bestands- und Gesamttests. Dabei gibt es analysierende bzw. testende Verfahren. Analysierende Verfahren beschäftigen sich mit Reviews, Audits und Verifikationen. Testende Verfahren dagegen führen verschiedene Tests wie z.b. dynamische Tests sowie symbolische Tests durch oder führen Simulationen aus. 8

9 2.2 Testmethoden-Übersicht Bezogen auf Software-Entwicklungsprojekte ist das Testen eines der wichtigsten Ereignisse der Qualitätssicherung. Es darf aber nicht der Eindruck entstehen, dass Testen gleich Qualitätssicherung bedeutet. Das Testen ist nur Werkzeug, um die Qualitätssicherung zu gewährleisten. Folglich werden einige Testmethoden erläutert, die in Softwareprojekten unvermeidlich sind. Statische Tests: Dynamische Tests: Funktionale Tests: Strukturelle Tests: Bei einem statischen Test wird die Software nicht ausgeführt. Um Fehler zu finden, wird der Quellcode meistens mit manuellen Verfahren analysiert. Ein statischer Test ist ein Teil des Analytischen Qualitätsmanagements. Dabei werden analytische Verfahren wie z.b. Inspektionen und Reviews durchgeführt. Solche Arten von Tests bzw. Analysen werden auch als White-Box -Tests bezeichnet. Im Gegensatz zum statischen Tests wird die Software hier ausgeführt. Weiterhin wird bei den dynamischen Tests zwischen funktionalen Tests und strukturellen Tests unterschieden. Bei einem funktionalen Test hat der Tester keinerlei Informationen über die Struktur der Software. Deswegen wird dieser Test auch als Black- Box-Test bezeichnet. Der Tester erhält als Information, wie der Endverbraucher, nur eine Produktbeschreibung, Installationsanleitung und ein Benutzerhandbuch. Ein vollständiger Test ist hier nicht durchführbar, da dieser jede Kombination von zulässigen und unzulässigen Eingabewerten erforderlich macht. Dieser Test setzt voraus, dass die Struktur der Software bekannt ist. Zur Erstellung der Testfälle werden Informationen aus dem Feinentwurf oder sogar der Quellcode benutzt. Hierbei muss im Datenflussdiagramm bzw. Kontrollflussgraphen jeder Pfad vom Eingang bis zum Ausgang mindestens einmal durchlaufen werden. Ein solcher Test ist sehr umfangreich, weil jeder Modulabschnitt im Code getestet wird. Enthält der Code z.b. eine Schleife, die 30-mal durchlaufen werden muss und in der eine if -Abfrage enthalten ist, resultiert allein aus diesem Abschnitt eine Struktur von 2^30 verschiedenen Pfaden. Strukturelle Tests werden auch als White- oder Glass-Box-Tests bezeichnet. 2.3 Ablauf und Durchführung der Tests Nachdem die Tests in statische und dynamische Tests aufgeteilt wurden, ist als nächster Punkt der Ablauf bzw. die Durchführung des Testablaufs entscheidend. Es sollte ein stufenweiser und aufeinander aufbauender Ablauf durchgeführt werden. Zuerst werden die statischen Tests durchgeführt. Im Anschluss daran wird ein Modultest durchgeführt. Dieser wird in der Regel vom Entwickler selbst erstellt und ausgeführt, dabei werden kleine 9

10 Programmeinheiten getestet. Im nächsten Schritt erfolgt ein Integrationstest, der in definierten Teilen einen kompletten Softwarestand mit allen Komponenten bzw. Modulen aufbaut und testet. Hierbei ist es wichtig, das Zusammenspiel der Einzelkomponenten zu beachten. Der Integrationstest wird vom Entwickler selbst erstellt und getestet. Der darauf folgende Systemtest muss auf dem Zielsystem ausgeführt werden. Simulatoren oder der Aufbau einer Testumgebung sind nicht erlaubt. Dieser Test umfasst das Verhalten des Gesamtsystems. Der Systemtest wird vom Qualitätssicherer erstellt und vom Qualitätssicherer, Entwickler und Benutzer ausgeführt. Zum Abschluss erfolgt der Abnahmetest, der in der realen Umgebung von dem endgültigen Benutzer ausgeführt wird. Dieser hat auch neben dem Testen einen politischen Hintergrund, denn hier kann das Vertrauen in das Produkt für den Einsatz beim Kunden gerechtfertigt werden. Dazu werden vom Auftraggeber Testfälle erstellt und ebenfalls vom Auftraggeber durchgeführt, um das Produkt sorglos abzunehmen. Abschließend bleibt der Regressionstest zu erwähnen. Ein Regressionstest ist eigentlich eine Wiederholung der bereits durchgeführten Tests. Er dient zur Überprüfung der korrekten Funktion, nachdem ein Modul geändert wurde, wie z.b. nach der Änderung einer Fehlerkorrektur. Er wird parallel nach jeder Modifikation zum Modultest, Integrationstest und Systemtest durchgeführt. Regressionstest Regressionstest Zusammenfassung: Name Beispiele Ersteller Ausführender Modultest Integrationstest Systemtest Unit-Test, Komponententest, Klassentest, Entwicklertest Schnittstellentest, Interfacetest, Entwicklertest Funktionstest, Akzeptanztest, Anwendertest Entwickler Entwickler Qualitätssicherer Entwickler Entwickler Qualitätssicherer, Entwickler, Benutzer Abnahmetest Akzeptanztest, Verbundtest Auftraggeber Auftraggeber, Auftragnehmer 10

11 2.4 Vorteile der Qualitätssicherung Ganz nach dem Motto Bessere Qualität zu niedrigeren Kosten beansprucht die Qualitätssicherung zwar während des Erstellungsprozesses einen gewissen Aufwand, bringt aber auch viele Vorteile und hilft vor allem Kosten zu sparen. Bereits während des Anfangsstatus eines Projekts wird damit begonnen, die definierte Qualität zu sichern. Damit entsteht nicht nur ein Konzept für die Entwicklung des Projekts, sondern auch ein Weg zur Erhaltung der gesetzten Qualität. Da alle Abläufe geplant und definiert werden, stellt sich auch die Aufgabenstellung für das Entwicklungsteam als sehr transparent dar. Damit ist es auch einfacher, gegenüber neuen Mitarbeitern den Anschluss im Team zu finden. Mit der Qualitätssicherung öffnen sich auch ganz neue Märkte auf einem höheren Niveau. In einer globalen Welt nimmt die ISO-9001-Zertifizierung zur Qualitätssicherung eine immer wichtigere Rolle ein. Viele Auftraggeber setzen auch zum Abschluss eines Vertrages auf den Besitz solch einer Zertifizierung. Wie bereits erwähnt, ist die Qualitätssicherung eine erfolgreiche Maßnahme, um Kosten während eines Entwicklungsprozesses zu sparen. Aus diesem Grund möchte ich mich speziell auf diesen Vorteil der Qualitätssicherung konzentrieren. So wie in der Alltagswelt die konstante Belastung durch eine Sorge schließlich zu fatalen Auswirkungen führen kann, verhält es sich auch in der Softwareentwicklung. In der Softwareentwicklung sind es zwar nicht die Sorgen, aber dafür die Fehler, die am Anfang entstehen und erst am Ende entdeckt werden. Genau in dieser Hinsicht unterstützt die Qualitätssicherung das Entwicklungsprojekt. Es fördert die Einplanung von Maßnahmen, um das Entwickelte Schritt für Schritt nach gewissen Änderungen und Erneuerungen durchzuführen und nicht nur am Ende der Entwicklung nach Fehlern zu suchen. Häufig ist es so, dass wenn man einen Fehler beseitigen will, zum Ursprung zurückgehen muss. In vielen Situationen sind Rückkopplungen jedoch ausgeschlossen oder nur mit sehr großem Aufwand zu ermöglichen. Aufwand bedeutet immer viel Zeit. Zeit dagegen beansprucht Investitionen, die wiederum Kosten verursachen. Folgende Abbildung veranschaulicht, welche Kosten entstehen, die in bestimmten Entwicklungsphasen entdeckt werden. 5 5 H. Balzert, 1998; Boehm, [3] 11

12 Wie die Abbildung zeigt, sind die Kosten für die Beseitigung der Fehler, die am Ende eines Projekts entdeckt werden, viel höher als die Kosten für die Tilgung von Fehlern, die am Anfang entdeckt und behoben werden. 2.5 Qualitätssicherung bei der GIP Die GIP ist ein ISO-zertifiziertes Unternehmen und alle Produktentwicklungen entsprechen auch dieser Norm. Da die GIP für den öffentlichen Sektor Dienstleistungen anbietet, wird an das V-Modell anlehnend gearbeitet. D.h., es wird nicht strickt nach den Regeln des V-Modells entwickelt. Das Unternehmen ist zwar nicht verpflichtet, dieses Softwaremodell zu nutzen, aber verfolgt dennoch die Ziele des V-Modells. 6 Bei der GIP werden die Testspezifikationen bereits während der Konzeption erstellt. Eine Konzeption ist ein strategisch zu planendes Vorhaben. Es ist eine umfangreiche Zusammenstellung der vorgenommenen Ziele. Daraus abgeleitete Strategien und Maßnahmen vervollständigen diese Konzeption. Darüber hinaus beinhaltet die Konzeption eine Zeit- und Maßnahmenplanung, Chancen-Risiko-Abwägung und eine Ressourcenplanung. Die Zeit- und Maßnahmenplanung beinhalten Informationen und Begründungen über die geschätzte Zeit, die das Projekt in Anspruch nehmen wird. Zusätzlich sind alle definierten Änderungen, die das Projekt enthalten wird, schon mit aufgenommen worden, damit auch die Kernziele. Bei einer Chancen-Risiko-Abwägung werden die Chancen und Risiken des Projekts gegeneinander abgewogen. Dabei werden jeweils die Chancen und Risiken einander gegenübergestellt und verglichen, welche im Vergleich zu den anderen überwiegen. Die Ressourcenplanung ist die Planung darüber, wie viel Zeit, Geld, Material und Personal benötigt werden, um das Projekt durchführen zu können. Diese Aufgaben werden in der Regel mit Hilfe einer Anwendung durchgeführt. Es gibt zahlreiche Softwareprodukte, die am Markt 6 Stand März [4] 12

13 vertreten sind, MS-Projekt, Open Workbench und viele andere. Folgende Abbildung soll wiedergeben, wie eine Ressourcenplanung im Detail aussehen kann. Die Testspezifikation ist eine genaue Beschreibung der Testfälle. Prinzipiell werden Testfälle in logische und konkrete Testfälle unterschieden. Logische Testfälle beschreiben den tatsächlichen fachlichen Ablauf, d.h., es ist ein Testfall ohne Angabe konkreter Werte für Einund Ausgaben. Der konkrete Testfall dagegen ist mit dem jeweiligen dazugehörenden Datensatz angereichert und enthält damit konkrete Eingabe- und Ausgabewerte. Zudem beinhaltet er die Testspezifikation Testszenarien. In dieser wird beschrieben, wie ein Test auszusehen hat und was getestet werden soll. Ein Testszenario legt fest, auf welche Weise die jeweils anschließend aufgeführten Testfälle durchzuführen sind. Es enthält Informationen über die Voraussetzungen des Tests, die vor dem Start des Testszenarios vorliegen müssen, und beinhaltet genaue Informationen darüber, wie der Tester das Testszenario durchzuführen hat. Ein Testfall zum Testszenario wäre z.b. ein positiver oder negativer Test. In einem positiven Test werden Eingaben bestätigt, die in einem zu erwartenden Bereich liegen. Zum Beispiel könnte der zu erwartende Bereich zwischen A und Z liegen, damit wäre die Eingabe von M eine erwartete Eingabe. Ein negativer Test dagegen unterscheidet sich vom positiven dahingehend, dass negative Tests aus einem nicht zu erwartenden Bereich kommen und nicht funktionieren dürfen bzw. abgefangen werden müssen. Eine Testspezifikation wird bei der GIP anhand einer vordefinierten Vorlage 7 abgearbeitet. Auf dem Deckblatt der Testspezifikation werden allgemeine Angaben wie eine Kurzbeschreibung, das letzte Änderungsdatum und der Name des Verfassers angegeben. Als Nächstes (Kapitel 1) werden Angaben zum Testgegenstand gemacht. Da in der Regel Software getestet wird, werden Informationen über das Produkt (Engine), die Version, eine kurze Beschreibung des Produktleistungsmerkmals (PLMs), über den Stand der Anwenderdokumentation, den Stand der Installationsanleitung und über das Ziel dieses Tests gegeben. Im zweiten Kapitel werden Angaben zum Testverfahren und der Umgebung gemacht. 7 Anhang 1: Vorlage Testspezifikation. 13

14 Beispiele Testverfahren: - manuelle Überprüfung von Erfassungsmasken - Datenerfassung und anschließende Echtberechnung - Durchführung einer sog. Zeitreise (Abrechnen mehrerer Monate hintereinander und Betrachtung bestimmter Daten oder Listen nach jeder Monatsabrechnung bzw. nach Abschluss der Zeitreise) Mit den Angaben zur Testumgebung soll festgelegt werden, wie die Systemlandschaft genau aussehen muss, in welcher der Test durchgeführt wird. Dazu werden die Komponenten bestimmt und die Vorgaben definiert, die erfüllt werden müssen. Im dritten Kapitel der Testspezifikation werden alle besonderen Anforderungen und/oder Vorbereitungen, die zur Durchführung der Testspezifikation erforderlich sind, festgehalten. Im letzten Kapitel werden die Testszenarien und die dazugehörigen Testfälle beschrieben. Aus der Testspezifikation erfolgt der Testabschluss-Bericht 8, in dem die Ergebnisse der Testspezifikation festgehalten und erläutert werden. Es werden Angaben zum Testverlauf und Ergebnis gemacht. Dabei wird angegeben, zu wie viel Prozent die Testspezifikation getestet wurde. Falls dieser nicht zu 100% durchgeführt wurde, werden die jeweiligen nicht ausgeführten Abschnitte angegeben. Zudem müssen Gründe genannt werden, warum diese Abschnitte nicht getestet wurden. Schließlich werden alle Fehler aus der Testspezifikation festgehalten und mit einer PTrack-Ticket-Nummer versehen. PTrack ist ein Ticketing-System, bei dem die aufgetretenen Fehler dokumentiert werden. Damit bekommt jeder Fehler, der beim Testen aufgetreten ist, eine eindeutige Nummer zur Identifizierung zugewiesen. Schließlich weist eine zentrale Person dieses Ticket bzw. den Fehler zur Behebung an einen Zuständigen zu, der diesen Fehler beheben soll. Nachdem der Fehler behoben wurde, wird das Ticket geschlossen. Somit ist es jederzeit möglich, alle aufgetretenen Fehler durch Reports zu ermitteln und sich diese anzeigen zu lassen. 8 Anhang 2: Testabschluss-Bericht. 14

15 2.5.1 Qualitätssicherungs-Phasen Die Qualitätssicherung wird durch fünf Phasen bei der GIP unterstützt. Manche dieser Phasen werden schon vor dem Entwicklungsschluss bzw. auch parallel zur Entwicklung durchgeführt. Darunter fallen alle Entwicklertests wie z.b. Unit-Test, Komponententest, Klassentest, Schnittstellentest und Interfacetest. Dies ist die erste Qualitätssicherungs-Phase, die durchlaufen werden muss. Diese Tests werden in der jeweiligen Entwicklungsumgebung durchgeführt. Mit der zweiten Phase beginnen auch schon die Regressionstests, die bis zum Abnahmetest parallel in jeder darauf folgenden Phase durchgeführt werden. Die dritte Phase beschäftigt sich ausführlich mit der Testspezifikation. Die Testspezifikation unterteilt sich in einen anwenderorientierten Test und in Tests, die von internen und externen Testern durchgeführt werden. Hierbei werden auch die Grundfunktionalitäten des Produkts getestet. Eine wichtige Rolle spielt auch der subjektive Eindruck des externen Testers. Dieser Eindruck ermöglicht es, die Sichtweite der durchgeführten Tests zu erweitern und nicht aus einer starren Perspektive heraus zu betrachten. Mit der vierten Phase werden Beta-Tests beim Kunden vor Ort durchgeführt. Der Vorteil eines Beta-Tests ist, dass die Software auch einmal auf einer anderen Umgebung bzw. auf einem anderen System durchgeführt werden kann. Damit können auch die Kompatibilitätsprobleme, die beim Testen mit eigenen Systemen nicht entdeckt worden sind, mit anderen Systemen untersucht werden. Zum Schluss erfolgt der Abnahmetest. 15

16 3. Theoretischer Teil 3.1 Projektmanagement Als die Kosten für die Fehlerbeseitigung höher waren als die wesentliche Softwareentwicklung, wurde der Qualitätssicherung eine wichtige Rolle in der Softwareentwicklung zugeteilt. Es wurden systematische Vorgehensmodelle entwickelt und Standards definiert, an die sich die Entwickler zu halten hatten. Als die Projekte aber immer umfangreicher wurden, erschwerte diese Tatsache, die Kontrolle über das Projekt zu behalten. Um die Kontrolle über das Geschehen im Projekt zu bewahren, ist eine vielseitige Kommunikation unumgänglich. Für diese übersichtliche Kommunikation wird ein Fundament benötigt, wo- rauf aufgebaut und infolgedessen erfolgreich gearbeitet werden kann. Dieses Fundament bietet uns das Projektmanagement. Jedes Projekt lebt mit seinen Ergebnissen. Egal unter welchen Umständen das Projekt geführt wird, das Einzige, was am Ende zählt und womit dieses immer wieder in Verbindung gebracht wird, ist die Qualität des Produkts. Wie kann jedoch die Qualität gewährleistet werden? Diese Frage lässt sich sicherlich nicht einfach beantworten, aber schließlich entscheidet auch der Weg, der gegangen wird, wie gut ein Produkt am Ende wird Konfigurationsmanagement Das Konfigurationsmanagement, was hier beschrieben wird, ist nicht mit der ITIL 9 - Ebene zu verwechseln. Dieses bezieht sich lediglich auf die Versionsverwaltung. Ein Produkt oder Projekt durchläuft viele Lebensphasen, von seiner Entstehung bis zu seiner Vollendung. Dieses Produkt bzw. diese Projektphasen zu kontrollieren und in die richtige Richtung zu führen ist die Aufgabe des Konfigurationsmanagements. Die Evolution eines Projektes ist genaustes zu beschreiben und in bestimmten Zuständen sogar zu sichern, so dass einzelne Schritte wiederherzustellen sind. Es muss also durchaus möglich sein, bestimmte Zustände des Projektes oder Produktkonfigurationen rückwirkend wiederherzustellen und den Zugriff auf diese früheren Konfigurationen jederzeit zu gewährleisten. Eine Konfiguration besteht aus einer Vielzahl von verschiedenen Objekten, die das Produkt in der jeweiligen Lebensphase beschreiben. Diese Objekte können nicht nur Quellcode-Änderungen, sondern auch Materialien, Dokumentationen oder andere Objekte, die in dieses Produkt eingebracht wurden, sein. All diese Objekte verändern sich mit jeder Phase, womit sich auch die Zusammenarbeit verschiedener Komponenten ändert. Solch eine Veränderung festzustellen und diese bekannt zu geben ist Gegenstand eines Konfigurationsmanagements. Die Schwierigkeiten und Probleme treten genau bei solchen Bekanntmachungen der Veränderungen auf. Falls ein Projekt aus nur zwei Mitgliedern besteht, ist es einfacher, die Kommunikation zwischen den Beteiligten herzustellen, als wenn sich das Projekt aus fünfzig Mitgliedern zusammensetzt. Ein Projekt bricht selbst in sich zusammen, wenn die Kommunikation innerhalb eines Projektes nicht funktioniert. 9 IT Infrastructure Library ist eine Sammlung von Definitionen und Regeln, die für einen optimalen Betrieb einer IT-Infrastruktur die notwendigen Prozesse, Organisation und die Werkzeuge beschreibt. 16

17 3.1.2 Entwicklung ohne Konfigurationsmanagement Um das Konfigurationsmanagement zu verstehen, müssen zuerst einmal die Probleme erkannt werden, die ohne den Einsatz des Konfigurationsmanagements auftreten. Im folgenden Beispiel werden Probleme anhand Szenarien beschrieben, um bestimmte Problematiken besser zu verstehen. Szenario 1: 10 Der Fehler war doch schon mal behoben, wieso taucht er schon wieder auf? Mögliche Beispielursache: Der Fehler war behoben, aber es wurde mit der falschen Datei weitergearbeitet. Szenario 2: Warum funktioniert dieses Programm nicht mehr, es hat doch gestern noch funktioniert? Mögliche Beispielursache: An der Entwicklung arbeiten mehrere Personen gemeinsam. Änderungen, die gestern getätigt wurden, sind heute wieder von jemand anderem verändert worden. Szenario 3: Ein unerwarteter Fehler ist aufgetreten, wir müssen in der Version , die wir vor zwei Monaten ausgeliefert haben, eine Änderung vornehmen. Wie bekommen wir den Stand von vor zwei Monaten wieder her? Mögliche Beispielursache: Die ausgelieferten Versionen wurden nicht richtig in den jeweiligen Versionen archiviert. All diese Szenarien haben ein gemeinsames Kriterium, welches zu Kommunikationsproblemen zwischen den Beteiligten führt. Sobald in einem Projekt mit mehreren Personen gearbeitet wird, ist das Konfigurationsmanagement unvermeidbar Ziele des Konfigurationsmanagements Das Hauptziel eines Projektes ist sicherlich, ein qualitatives Produkt zu konstruieren. Das Ziel eines Konfigurationsmanagements dagegen ist die Gewährleistung, dass sämtliche Ergebnisse im laufenden Projekt zurückverfolgbar und wieder rekonstruierbar sind. Hauptziele des Konfigurationsmanagements: Im Hinblick auf eine Änderung muss die Entscheidung, die darüber getroffen wurde, nachvollziehbar sein. Die Arbeit mehrerer Personen am selben Element gewährleisten, ohne dass irgendwelche Änderungen von anderen Personen verloren gehen. Es muss eine parallele Entwicklung zur wesentlichen Entwicklung garantiert sein. 10 (sinngemäße Abbildung Seite 35). [5] 17

18 3.1.4 Normen zur Umsetzung der KM-Ziele Nach Stephen Berczuk 11 existieren mittlerweile über 200 Konfigurationsmanagement- Standards entwickelte das US-Militär bereits den ersten Standard (AFSCM-375-1) für das KM im Bereich Hardware. Allein die Anzahl der Standards zeigen, wie wichtig das KM in der Softwareentwicklung ist. Diesbezüglich sind im Folgenden Standards 12 aufgelistet, die heute international anerkannt sind. ISO12207:1995 Software life cycle processes ISO 10007:1995 Deutsches Institut für Normung: Qualitätsmanagement - Leitfaden für Konfigurationsmanagement ISO/IEC, 1998 International Organisation for Standardisation, International Electrotechnical Commission: ISO/IEC TR Information technology - Software life cycle processes - Configuration management. IEEE Std Institute of Electrical and Electronics Engineers: IEEE Standard for Software Configuration Management Plans. Institute of Electrical and Electronics Engineers, Continuous Integration Die Entwicklung an einer Software wird nie mit der ersten Version beendet. Denn erst dann beginnt meist die wesentliche Arbeit, die Fehlerbeseitigung. Sei es in Form von so genannten Updates, Service Packs oder Hotfixes. All diese Aktualisierungen dienen dazu, Fehler, die in der Entwicklung nicht bemerkt wurden, im Nachhinein zu beseitigen. Mit der Größe eines Projekts wächst auch dessen Verwaltungs-Aufwand. Wenn zusätzlich noch mehrere Entwickler an diesem Projekt beteiligt sind, werden Fehler unumgänglich. Sicherlich lässt sich dies nicht auf jedes Projekt übertragen, aber damit die Prozessabläufe in einer größeren Entwicklungsumgebung mit vielen Entwicklern reibungslos miteinander harmonieren, muss die Kommunikation zwischen allen Beteiligten funktionieren. Dadurch, dass mehrere Entwickler unabhängig voneinander entwickeln, entstehen spätestens bei der Zusammenführung des Quellcodes unbemerkte Fehler. So genannte Integrationsfehler schleichen sich früher oder später ein. Um über diese kleinen Fehler nicht am Ende des Projekts zu stolpern, müssen diese Änderungen gleich im Anschluss nach der Zusammenführung getestet werden Was ist Continuous Integration? Continuous Integration ist ein Begriff aus der Informatik und bedeutet Kontinuierliche Integration. Sie ist ein Prozess, der regelmäßig Quelltext-Erneuerungen in ein Verwaltungssystem oder Versionskontrollsystem (Repository) einpflegt und anschließend testet. Systeme wie CruiseControl 13 und AnthillPro 14 sind die bekanntesten Continuous 11 Software Configuration Management Patterns, Addison-Wesley [6] 12 Stand Oktober [7] 13 Stand November [8] 18

19 Integration Systeme und ermöglichen eine kontinuierliche Software-Integration innerhalb eines Entwicklungsprozesses Repository Repository ist ein englischer Begriff und ist mit den deutschen Begriffen wie Lager, Aufbewahrungsort, Datenbehälter, Depot etc. gleichzusetzen. Ein Repository beinhaltet meistens immer den gesamten Quellcode. Einzelne Dateien werden jeweils ausgecheckt bearbeitet und wieder eingecheckt oder es kommen direkt neue Methoden hinzu. In der Softwareentwicklung wird dieser Begriff oft in Verbindung mit einem Versionskontrollsystem erwähnt. Die zu verwaltenden Quelltexte, die in einem Repository abgelegt werden, können in einer Datenbank oder unter einer Verzeichnisstruktur abgelegt werden, welche meist mit einem Versionskontrollsystem zusammenhängt. Solch ein Ablage- System bringt viele Vorteile für Entwicklungs-Teams, die zusammen an einem Projekt entwickeln. Die derzeit bekanntesten Open Source-Versionskontrollsysteme sind Subversion 15 und CVS Idee der Kontinuierlichen Integration (Continuous Integration) Ein Softwareentwickler checkt in regelmäßigen Abständen Quellcode-Änderungen (Methoden) in ein Verwaltungssystem ein; dies können auch mehrere Entwickler sein, die am selben Projekt arbeiten. Anschließend werden die Änderungen neu gebaut bzw. kompiliert und mit automatisierten Tests getestet. Nach einem erfolgreichen Testdurchlauf werden die daraus neu erzeugten Komponenten an eine höhere Instanz zur Bearbeitung weitergegeben. Falls aber dieser Test nicht erfolgreich ausgeführt wurde, werden die Änderungen wieder zurückgenommen und den Beteiligten zur Wiederbearbeitung erneut zur Verfügung gestellt Warum Continuous Integration und Vorteile, die sich daraus ergeben Das große Problem der Softwareentwicklung ist die Fehlerbeseitigung. Die Kosten steigen erheblich, wenn die Entwicklungsfehler erst am Ende des Projektes auftreten oder danach beim Kunden. Es ist mehrfach bewiesen worden, dass Softwarefehler, die am Ende eines Projektes entdeckt werden, viel teurer bei der Fehlerbeseitigung sind als am Anfang eines Projektes. Die Vorgehensweise von Continuous Integration versucht genau diese Schwachstellen in einer Softwareentwicklung abzudecken. Continuous Integration ist nur ein Vorgehen und entdeckt lediglich Fehler zur Kompilierzeit. Oft wird dieses Konzept auch mit Extreme Programming (XP) in Verbindung gebracht. XP erfüllt die Anforderung des Kunden in wiederholten kleinen Schritten unter der Verwendung von so genannten Rückkopplungen und einer sehr intensiven Kommunikation zwischen den Entwicklern und dem Kunden. Die beiden Vorgehensweisen sind nicht voneinander abhängig. Die Verbindung besteht eigentlich 14 Stand November [9] 15 Stand November [10] 16 Stand November [11] 19

20 nur darin, dass Continuous Integration im Rahmen von Extreme Programming populär wurde. Continuous Integration setzt voraus, dass die Projekte bzw. Quelltexte in einem Versionskontrollsystem verwaltet werden. Der Einsatz solch eines Konzepts macht auch nur Sinn, wenn immer funktional korrekte Blöcke oder Änderungen in das Versionskontrollsystem eingepflegt werden. Genau das ist einer der wichtigsten Gründe, warum Continuous Integration überhaupt eingesetzt werden soll. Denn die Fehlerbeseitigung fängt schon mit dem Einchecken an. Somit wird das Risiko, auf Fehler zu stoßen, immer geringer. Die permanente Integration von Quellcodes in ein Versionskontrollsystem bringt bedeutende Vorteile mit sich. Vorteile von Continuous Integration: 17 Sofortige Tests nach der Integration sorgen dafür, dass Fehler nicht erst am Ende der Entwicklung entdeckt werden. Somit laufen die Tests parallel zu der Entwicklung. Falls die Zusammenführung der Programm-Komponenten nicht geglückt ist, werden Warnungen sofort an die verantwortlichen Personen übermittelt. Somit kann direkt mit der Fehlerbeseitigung begonnen werden. Dadurch, dass Änderungen aufgezeichnet werden, sind Fehler leichter lokalisierbar und ältere Versionsstände jederzeit wiederherstellbar. Die Projektsituation ist laufend einsehbar, damit sind auch die Projekt-Fortschritte genauer identifizierbar, was für die Qualitätssicherung von großem Vorteil ist. 17 (sinngemäße Abbildung). [12] 20

21 4. Das Unternehmen 4.1 Gesellschaft für innovative Personalwirtschaftssysteme mbh Die Gesellschaft für innovative Personalwirtschaftssysteme mbh (GIP mbh) wurde 1996 gegründet. Ihr Ursprung geht auf die Kirchliche Gemeinschaftsstelle für elektronische Datenverarbeitung e.v. (KIGST e.v.) zurück, die 1968 in Frankfurt konstituiert wurde. KIGST e.v. hatte die Aufgabe, alle Möglichkeiten zu prüfen, um auch in der Kirche mit fortschrittlichen Techniken die Verwaltungsarbeit zu vereinfachen. Diese Investition zahlte sich aus und bereits nach zwei Jahren waren erste Fortschritte zu verzeichnen wurde ein Abrechnungsverfahren für die Besoldung von Beamten eingeführt, dem ein Jahr später ein Programm für die Vergütung folgte. Drei Jahre später begann die Entwicklung von KIDICAP, was heute das Hauptprodukt der GIP mbh darstellt. Der Name KIDICAP entstand aus folgenden Begriffen: KI = Kirche, DI = Diakonie, CA = Caritas und P = Personalwirtschaft. Aus der KIGST heraus wurde die Gesellschaft für innovative Personalwirtschaftssysteme mbh am 26. November 1996 in Frankfurt gegründet. Das Unternehmen sollte sich voll auf die Weiterentwicklung des Produktes KIDICAP konzentrieren und sich vor allem auch auf neue Zielgruppen fokussieren. Da die Software damals hauptsächlich für Gemeinden und Kommunen entwickelt wurde und die Funktionen eng mit Gesetzesvorlagen verbunden sind, muss auch bei allen tariflichen und gesetzlichen Änderungen die Software neu angepasst werden. Es sind aber nicht nur Tarif- und Gesetzesänderungen, welche die Entwicklungen von KIDICAP mit bestimmen, sondern vor allem Kundenwünsche und neue Zielgruppen. Mit den Jahren entwickelte sich das Produkt KIDICAP und es wurden Erneuerungen und Erweiterungen hinzugefügt. Somit entstand die fünfte Generation von KIDICAP und diese wurde in KIDICAP P5 umbenannt. Das P5 stand für die fünf Produkte, die mit KIDICAP auf einer offenen serviceorientierten Plattform angeboten wurden PPay - Das Basismodul für die Bezügeabrechnung - PView - Personalinformationen und Verwaltung - PPlan - Personalplanung und -controlling - PBox - Mitarbeiter-Self-Service - PKom - Prozesskommunikation Heute besteht KIDICAP P5 hauptsächlich aus drei Engines: PPay Engine, PView Engine und PTravel. Mittlerweile befindet sich die Zentrale der GIP mbh in Offenbach am Main. Derzeit sind ca. 60 Mitarbeiter im Inland und 20 Mitarbeiter im Ausland für die GIP tätig 19. Die GIP arbeitet mit Servicepartnern, Outsourcing-Rechenzentren und Kunden- Kompetenzzentren (Service Center) zusammen und erreicht so mit KIDICAP P5 eine intensive, regionale und gleichzeitig bundesweite Präsenz. Zurzeit betreut die GIP 20 Service Center in Bund, Ländern, Kommunen und Sozialeinrichtungen. Diese sind für den technischen Betrieb und personalwirtschaftliche Dienstleistungen von insgesamt 2,4 Mio KIDICAP P5-Personalfällen zuständig. Die Service Center verfügen über eigene Vertriebs-, Beratungs- und Organisationsstrukturen und betreuen zurzeit ca Arbeitgeber. 18 Aus der hausinternen Broschüre KIDICAP CHRONIK. [13] 19 Stand Oktober

22 Eine weitere Gruppe von Dienstleistungsanbietern in der Personalwirtschaft sind die Zentralen Gehaltsabrechnungsstellen (ZGASten) mit über Abrechnungsfällen monatlich. Ihr Geschäftsmodell umfasst den Fullservice von der Bruttofestsetzung bis zur Zahlbarmachung von Arbeitergebern unterschiedlichster Größenordnungen aus den Bereichen: Kirchliche Verwaltung, Gesundheitswesen, soziale Einrichtungen und öffentlicher Dienst. KIDICAP P5 bietet eine Vielzahl von Funktionen, die speziell auf das Dienstleistungsangebot der Zentralen Gehaltsabrechnungsstellen ausgerichtet sind. 20 In folgenden Service Centern wird KIDICAP angeboten: COMRAMO IT Holding AG - KID Performa Nord Niedersächsisches Landesamt für Bezüge und Versorgung Hewlett-Packard GmbH Landesleitstelle für Bezügezahlungen ITEBO GmbH Zentrum für Informationsverarbeitung und Informationstechnik Rechenzentrum Volmarstein GmbH EDV-Centrum für Kirche und Diakonie GmbH Stiftung Kirchliches Rechenzentrum Südwestdeutschland Landeskirchenamt-Rechenzentrum Bischöfliches Ordinariat Landesamt für Finanzen Zentrale Bezügestelle des Landes Brandenburg Rechenzentrum Nordelbien-Berlin Auswahl von KIDICAP-Anwendern: Bund Auswärtiges Amt, Berlin Zentrum für Informationsverarbeitung und Informationstechnik, Bonn Bundesamt für Zentrale Dienste und offene Vermögensfragen, Bonn Länder Land Bremen Niedersächsisches Landesamt für Bezüge und Versorgung, Hannover Landesleitstelle für Bezügezahlungen, Magdeburg Landesamt für Finanzen, Dresden Zentrale Bezügestelle des Landes Brandenburg, Cottbus 20 Stand Oktober [14] 22

23 Bistümer/Caritasverbände Bischöfliches Ordinariat, Besoldungsstelle Laien, Augsburg Caritasverband für die Erzdiözese Bamberg e.v., Bamberg Caritasverband für die Diözese Würzburg e.v., Würzburg Bischöfliches Ordinariat Eichstätt, Besoldung, Eichstätt Erzbischöfliches Ordinariat, Besoldung, Bamberg Bischöfliches Ordinariat, Würzburg Gesundheitswesen/soziale Einrichtungen Von Bodelschwinghsche Anstalten - Bethel, Bielefeld Städtische Kliniken Bielefeld Kreiskrankenhaus Hameln Kirchliche Verwaltung Evangelische Kirche im Rheinland, Düsseldorf Landeskirchenamt Bielefeld Öffentlich-rechtliche Einrichtungen Fachhochschule für Technik und Wirtschaft, Berlin Studentenwerk Köln Zentrale Gehaltsabrechnungsstellen KID ZGASt Düsseldorf GmbH, Düsseldorf 4.2 Produktbeschreibung KIDICAP P5 Wie schon vorher erwähnt, besteht KIDICAP P5 aus mehreren Programmen, die untereinander kompatibel sind und sich ergänzen. KIDICAP P5 ist eine ganzheitliche Anwendung für ein Personalwirtschaftssystem im öffentlichen Dienst KIDICAP P5 PPay Die Hauptaufgabe von PPay ist das Erstellen von Mitarbeiter-Abrechnungen. Mit der KIDICAP PPay bietet die GIP eine integrierte Gesamtlösung für den Geschäftsprozess Versorgung von der Administration bis hin zur Abrechnung. Die KIDICAP PPay unterstützt den Sachbearbeiter bei der Erstellung von: Erstfestsetzungen bei Eintritt bzw. Versetzung eines Beamten in den Ruhestand. Hinterbliebenenfestsetzung beim Tod eines Beamten oder Ruhestandsbeamten mit versorgungsberechtigten Hinterbliebenen unter Nutzung der Funktionalitäten zur Verwaltung eines Familienverbandes. Änderungsfestsetzungen bei Änderung der Festsetzungsgrundlagen, so dass eine Anpassung vorgenommen werden muss. informatorischen Festsetzungen als Auskunft für einen Beamten über seine zukünftigen Versorgungsbezüge nach dem Motto: Was wäre, wenn ich morgen in 23

24 Ruhestand ginge? Darin enthalten ist auch die Möglichkeit, mehrere Simulationen durchführen zu können. Auskünften an die Rentenversicherungsträger über die Beschäftigungszeiten, die als ruhegehaltfähige Dienstzeiten im Rahmen der Festsetzung von Versorgungsbezügen einfließen. Auskünften an die Familiengerichte zur Ermittlung von Versorgungsansprüchen bzw. Versorgungsanwartschaften im Zusammenhang mit der Ermittlung eines Versorgungsausgleichs bei Scheidung. Hierfür stellt die KIDICAP PPay folgende Funktionen zur Verfügung: die Ermittlung der ruhegehaltfähigen Dienstzeiten 21 die Feststellung des Ruhegehaltssatzes 22 die Eruierung der Verminderung des Ruhegehaltes (Versorgungsabschlag) die Berechnung der ruhegehaltfähigen Dienstbezüge die Berechnung des Bruttoversorgungsbezuges die Erstellung und Ausgabe von Anlagen für die Festsetzungsbescheide bzw. Auskunftsschreiben KIDICAP P5 PView Das Produkt KIDICAP P5 PView ist ein Personalprozess sowie eine Personalverwaltungsanwendung. Es ermöglicht die Verwaltung aller Personalprozesse, beginnend mit der Bewerbung bis hin zur Beendigung des Arbeitsverhältnisses. Das Basismodul PView bietet vordefinierte Formulare und Musterlisten, um bestimmte Arbeitsabläufe in der Personalverwaltung zu erleichtern. Auf Basis der Stamm- und Ereignisdaten aus der Personalabrechnung PPay werden individuelle Abfragen und Auswertungen mit PView erstellt. Diese Ergebnisse können auch auf Microsoft Office- Anwendungen übertragen werden. Neben dem Basismodul offeriert PView weitere Optionen wie Profile, Bewerber, Seminare und Zeiten an. Diese Optionen können auf die Bedürfnisse der Kunden angepasst werden. PView Profile: PView Profile erfasst alle Informationen zu einem Mitarbeiter. Dadurch wird der Verwaltungsaufwand so weit wie möglich auf ein Minimum gesenkt. Mit dieser Option können persönliche Angaben und Daten über den Mitarbeiter verwaltet werden. Dabei sind es nicht nur Personal- und Abrechnungsdaten, die verwaltet werden können, sondern auch Angaben über die schulischen, beruflichen, internen und externen Werdegänge, Qualifikationen und Kompetenzen. Personalwirtschaftliche Sachverhalte wie Bewährungszeiträume oder Befristungen sind natürlich auch Bestandteil dieser Anwendung. 21 Ruhegehaltfähige Dienstzeiten sind die Zeiten, die nach Vollendung des 17. Lebensjahres im Beamtenverhältnis verbracht worden sind. 22 Das Ruhegehalt ist die Altersversorgung eines Beamten. 24

25 Neben diesen Datenerfassungen können anhand der Daten automatisch generierte Serienbriefe und Listen wie z.b. Muster für Kündigungen erstellt werden. PView Bewerber: KIDICAP PView Seminare bietet interne oder auch externe Seminarplanungen bzw. Bildungsmaßnahmen an. Diese können z.b. Einweisungsseminare neuer Mitarbeiter oder externe Schulungen für Kunden sein. Damit verbunden sind auch die Erstellung von Seminarkatalogen, die Verwaltung von Teilnehmer- bzw. Wartelisten sowie von Bildungsressourcen und Referentenpools. Zusätzlich können auch die Kostenplanungen und die Überwachungen über PView Seminare erfolgen. PView Zeiten: Diese Option verwaltet mit einer grafischen Oberfläche die Urlaubs- und Fehlzeiten der Mitarbeiter. Es werden detaillierte Urlaubskonten für jeden Mitarbeiter geführt. Somit kann anhand der grafischen Darstellung direkt erkannt werden, wenn gewisse Engpässe entstehen KIDICAP P5 PPlan Auf Basis von PPay (Abrechnungen) errechnet PPlan zu erwartende Personalkosten (Prognose) für einen beliebigen zukünftigen Zeitraum. Abrechnungen aus PPay werden verwendet, um die Berechnungen möglichst genau zu simulieren. Um schwer planbare Gehaltsbestandteile wie Zeitzuschläge, Aufschläge, Mehrarbeitszuschläge usw. mit planen zu können, werden vorfristige Erfassungen mitberücksichtigt. PPlan unterstützt die Durchführung folgender Planungen: Finanzplanung Statistik Soll- und Ist-Vergleich Budgetierung und Budgetüberwachung Cash Management Haushalts- und Stellenplanungen/Kassenvoranschläge etc KIDICAP P5 PTravel Wie der Name bereits andeutet, handelt es sich bei diesem Produkt um Reisen, und zwar speziell um Dienstreisen. PTravel ermöglicht es, Dienstreisen von der Planung bis zur Dienstreiseabrechnung zu managen. Eine Dienstreise durchläuft viele Phasen, bis sie endgültig auf der Dienstreiseabrechnung erscheint. PTravel ermöglicht Abläufe wie Planung Antrag Buchung Abrechnung Prüfung/Auswertung und Finanzbuchhaltung ganz komfortabel nicht nur für den Sachbearbeiter, sondern auch für den Dienstreisenden, wenn dieser seine diesbezüglichen Angelegenheiten abwickeln möchte. 25

26 PTravel bietet auch eine Web-Option mit KIDICAP P5 PTravel Web an. Hiermit können die Mitarbeiter weltweit über das Internet mit einem Webbrowser auf das System zugreifen und ihre Dienstreisedaten bearbeiten. Die KIDICAP P5 PTravel mobile Komponente dagegen offeriert den Mitarbeitern zusätzlich die Möglichkeit, offline ihre Dienstreisedaten zu bearbeiten. Bei der nächsten Anmeldung im Büro werden die Änderungen automatisch in das zentrale Verwaltungssystem übertragen und mit den Stammdaten abgeglichen. 4.3 KIDICAP P5 PView Details Da sich die Diplomarbeit auf PView beziehen wird, möchte ich auch gerne dieses Produkt näher beschreiben. Um im weiteren Verlauf die Zusammenhänge zu verstehen, ist es sinnvoll, bestimmte Details hier zu erwähnen KIDICAP P5 PView von der technischen Seite Wie schon im vorherigen Teil dieses Kapitels erwähnt, ist PView ein Werkzeug für das Personalmanagement und deckt Themen wie Personalentwicklung, Personalbeschaffung, Abbildung der Personalprozesse ab und beinhaltet Auswertungstools. PView ist ein Client- Server-System, welches mit Microsoft-Technologien realisiert wird. Die Anwendung selbst wird auf den Client-Systemen installiert, wobei die System- und Kundendaten auf einem Serversystem als relationale 23 Datenbanken hinterlegt werden. Auf den Client-Systemen kann die Anwendung als Windows-Vollclient und auch als webbasierter Client zur Verfügung gestellt werden. Der Webclient wird seit der Version 6.1 nicht mehr weiter- entwickelt und ist auch nicht mehr im Einsatz. PView bietet insgesamt drei mögliche Betreibermodelle bzw. Einsatztechnologien an, neben der Vollclient-Anwendung und dem webbasierten Client wird auch ein Terminal Server-Betreibermodell offeriert. Bei allen drei Modellen bleibt die Verbindung zur Datenbank und zum Host bestehen, es ändert sich lediglich nur die Client- Ansicht. PView wird in den meisten Fällen mit anderen KIDICAP-Anwendungen wie z.b. PPay, aus dem die Stamm- und Ereignisdaten bezogen werden, zusammen betrieben. Die Daten werden in solchen Situationen aus dem jeweiligen Rechenzentrum (Host), in dem sich weitere KIDICAP-Komponenten befinden, bezogen. Trotzdem ist PView eine eigenständige Anwendung, die auch unabhängig von anderen KIDICAP-Anwendungen angewandt werden kann. Betreibermodell Client-Server-System: Mit dieser klassischen Variante wird die PView-Anwendung komplett auf Client-Systemen installiert. Die Bearbeitung der Daten kann jeweils aus diesen Client-Systemen ausgeführt werden. Um PView betreiben zu können, müssen die Verbindungen zum Host und zum Datenbank-Server sichergestellt sein. 23 In den relationalen Datenbanken sind die Daten in mehreren Tabellen hinterlegt, die miteinander verknüpft sind. Z.B. ist Microsoft Access eine relationale Datenbank. Nichtrelationale Datenbanken hinterlegen sämtliche Daten in einer einzigen großen Tabelle (Datensatz). 26

27 Ein großer Vorteil dieses Betreibermodells ist, dass die Anwendung flexibel einsetzbar bzw. den Bedürfnissen der Kunden anpassbar ist. Der Vollclient beinhaltet eine umfassende grafische Oberfläche, mit der die ganzen Handlungen abgewickelt werden können. Nachteile könnten durch Softwarekonflikte der Geräteabhängigkeiten auftreten. Dadurch, dass sich die Clients hardwaretechnisch (z.b. PC, Laptop) voneinander unterscheiden, werden die dezentrale Verwaltung und Wartung aufwändig. Betreibermodell Webbrowser (seit der Version 6.1 nicht mehr im Einsatz): Mit dieser Einsatztechnik sind die Softwareverteilungen und die expliziten Installationen von PView auf jeden einzelnen Rechner damit überflüssig. Es wird lediglich eine webbasierte Anwendung über den Browser gestartet. Damit ist diese Einsatztechnik plattformunabhängig. Allerdings hat der Client jetzt keine direkte Verbindung zur Datenbank und zum Host. Die Kommunikation wird in diesem Modell über einen Webserver abgewickelt. 27

28 Anwendungen, die über einen Webbrowser angeboten werden, haben in der Regel einen geringeren Funktionsumfang als eine Vollclient-Anwendung. Der Grund liegt darin, dass bestimmte Handlungen mit dieser Methode einfach nicht realisierbar sind. Ein zweiter Nachteil fällt erst dann auf, wenn ein solches Betreibermodell in Betrieb genommen wurde. Auch wenn die Internet-Leitungen immer schneller und Datenspeicher-Probleme nicht mehr im Vordergrund stehen, ist es trotzdem wichtig, auf einen schnellen Seitenaufbau mit hoher Datenmenge zu achten. Zusätzlich könnte es Abhängigkeiten zwischen verschiedenen Browserversionen geben. Betreibermodell Terminal Server: Bei dieser Einsatztechnik findet die eigentliche Verarbeitung auf dem Terminal Server statt. Auf den Terminal Clients läuft lediglich die Emulation 24 ab. Die Grundidee der Terminal Server-Technologie ist das Verbinden der Vorteile der Client-Server- und Terminal-Host- Architektur. Die Clientanwendungen werden mit ihrem vollen Funktionsumfang auf dem Server zentral installiert und ausgeführt. Die Benutzer greifen über ein bestimmtes Terminalprogramm auf die Applikation zu. Dem Client bzw. User wird vom Server nur die Oberfläche in Form von Pixeln übertragen. Andersherum, also vom User, werden nur die Mausbewegungen und die Tastatureingaben zum Server übertragen. 24 Funktionale Nachbildung eines Systems durch ein anderes. 28

29 Technische Voraussetzungen: Die drei möglichen Betreibermodelle können auf verschiedenen Plattformen installiert werden, wodurch auch verschiedene Voraussetzungen entstehen. PView arbeitet in Verbindung mit einem Datenbank-Server und dem Host. Für die Client- und Serverinstallation von KIDICAP PView müssen folgende Voraussetzungen erfüllt sein: Server Microsoft Windows 2000 Server oder Windows Server 2003 Microsoft Internet Information Server (IIS) 5.0 oder höher Microsoft Internet Explorer 6 oder höher Microsoft DATA Access Components (MDAC) 2.8 Microsoft Office 2000, Office XP oder Office 2003 Terminal Server Microsoft Windows 2000 Server oder Windows Server 2003 aktivierte Microsoft Terminal Services oder Citrix Metaframe XP Microsoft Office 2000, Office XP oder Office 2003 Microsoft Internet Explorer 6 oder höher Microsoft Data Access Components (MDAC) 2.8 Datenbank-Server Microsofts Windows 2000 Server oder Windows Server 2003 Microsoft SQL Server 2000 Microsoft Data Access Components (MDAC)

30 Host KIDICAP PPay Personalabrechnung EntireX 25 Einrichtung Business Integrator Clientsichten 25 Softwareanwendung der Firma SoftwareAG. 30

31 5. Aufgabenstellung 5.1 Momentane Situation PView beruht auf dem Produkt eines Entwicklungspartners und wird von der Nearshore-Entwicklung der GIP in Rumänien um die Anforderungen der Kunden der GIP im öffentlichen Sektor angepasst und erweitert. Die derzeitige Vorgehensweise, wie aktualisierte Versionsstände und Service Packs für das Produkt PView dem Produkt- und Konfigurationsmanagement in Offenbach zur Verfügung gestellt werden, sieht folgendermaßen aus. Zu definierten Zeitpunkten stellt der Entwicklungspartner den Quellcode mit den aktuellen Programmänderungen und neuen Features der Standardfunktionalitäten sowie aus diesem Code erstellte Komponenten (exe, dll) für die GIP-Entwicklung in Rumänien zum Download zur Verfügung. Die GIP- Entwicklung codiert im Anschluss daran die GIP-spezifischen Anforderungen und stellt dem Konfigurationsmanagement die daraus kompilierten Programmkomponenten zur Verfügung. Dieses installiert die neuen Programmstände und Datenbank-Updates in die entsprechenden Umgebungen. Diese Umgebungen, in die das Konfigurationsmanagement die Änderungen installiert, sehen derzeit folgendermaßen aus: 31

32 Es existieren zwei isolierte Installationen der PView-Anwendung auf dem Citrix Presentation Server 26. Die eine Installation wird als die fachliche Entwicklungsumgebung ( pview_development_current ) und die andere als Testumgebung ( pview_qa_current ) bezeichnet. Die Entwicklungs- bzw. Testumgebung lagert jeweils explizit ihre Daten auf einem Microsoft SQL Server, die völlig unabhängig von einander sind. Jede Umgebung hat zwei Datenbanken: Auf der einen Instanz sind die Kundeninformationen und auf der anderen sind die System-Informationen abgelegt. Die Änderungen, die von der GIP-Entwicklung aus Rumänien kommen, werden wie schon vorher erwähnt, von dem Konfigurationsmanagement in Offenbach erst einmal in die Testumgebung installiert. Darüber hinaus wird die dazugehörige Datenbank aktualisiert. Nach erfolgreichen Tests werden diese Änderungen auch in die Entwicklungsumgebung installiert und die Datenbank wieder entsprechend aktualisiert. Dazu stellt die Entwicklung aus Rumänien in einem bestimmten File-System die dafür benötigten Dateien bereit. Diese Dateien werden nach einem vordefinierten Arbeitsvorgang in die jeweilige Umgebung installiert. Für das Durchführen der Updates müssen sechs bestimmte Schritte nacheinander, die mehr oder weniger manuell abgearbeitet werden, durchgeführt werden. 1. Die jeweilige Anwendung bzw. Test- oder Entwicklungsumgebung sperren, damit sich User nicht mehr anmelden können. 2. Falls User die Anwendung noch ausführen, diese auffordern, sich abzumelden. Ggf. Zwangsabmeldung durchführen. 3. Die Umgebung und die dazugehörige Datenbank sichern. 4. Deregistrierung (Script) aller Komponenten der jeweiligen Umgebung. 5. Update (Binärdateien) einspielen und anschließend die Komponenten wieder registrieren (Script). 6. Umgebung wieder freigeben. Diese Vorgehensweise vereint mehrere Nachteile: Aktualisierte Programmstände werden nur zu bestimmten Zeitpunkten geliefert. In der Zwischenzeit ist allen Projektverantwortlichen unklar, inwieweit geplante Änderungen 26 Citrix ist ein Produkt, welches eine Anwendungs-Virtualisierung ermöglicht. Einzelne Anwendungen werden auf diesem System installiert und den Anwendern auf ihren Rechnern visualisiert dargestellt. Somit muss die Anwendung nicht explizit auf jedem Rechner installiert werden und der Benutzer hat die Möglichkeit, Anwendungen parallel zu betreiben. [15] 32

33 bereits umgesetzt worden sind. Tests und qualitätssichernde Maßnahmen können erst durchgeführt werden, nachdem die Änderungen bereitgestellt wurden. Integrationsfehler können durch ein fehlendes Continuous Integration System (Daily Build) nicht zeitnah erkannt werden. Ein tägliches Deployment der Komponenten in die Testumgebungen bzw. fachliche Entwicklungsumgebung findet nicht statt. Diese Umgebungen bestehen aus einer Citrix Presentation Serverfarm und einem Microsoft SQL Server mit mehreren Instanzen. GIP hat keinen direkten Zugriff auf den aktuellen Quellcode, da dieser in einem Repository in Rumänien gehalten wird. Somit kann auch nicht eingeschätzt werden, welche Änderungen am Quellcode für welche Korrekturen nötig waren. 5.2 Aufgabenbeschreibung/Zielsetzung Es ist Ziel dieser Diplomarbeit, ein System zu entwerfen, mit dem der Quellcode für PView in einem Versionskontrollsystem hier in Offenbach verwaltet werden kann und das den Zugriff für die Entwicklung in Rumänien gewährleistet. Weiterhin soll im Rahmen der Diplomarbeit ein Build- und Deployment-Konzept für die Test- und fachliche Entwicklungsumgebung definiert und implementiert werden. Mit einem geeigneten Continuous Integration-Werkzeug soll eine zyklische Überprüfung auf Quellcodeänderungen vorgenommen werden. Bei Änderungen soll ein automatisierter Build der betroffenen Softwarekomponente durchgeführt werden. Die Durchführung eines Nightly Builds soll den tagesaktuellen Stand der Entwicklung sicherstellen. 5.3 Meine Aufgaben Meine Aufgabe in dieser Diplomarbeit ist es erstmal die Anforderungen der einzelnen Bereiche zu ermitteln. Mit diesen Anforderungen muss ich mir ein Konzept erstellen, mit dem ich die gestellten Anforderungen realisieren kann. Dazu muss ich eine Tool-Evaluierung durchführen um die entsprechenden Werkzeugen für das System zu bestimmen. Nach dem die Tools ermittelt worden sind, ist es wiederum meine Aufgabe das Continuous Integration System aufzubauen. Die Anpassungen und Konfigurationen der ausgewählten Tools, werden im Rahmen dieser Diplomarbeit von mir erstellt bzw. Entwickelt. Dazu gehören sowohl die Installationen als auch das Erstellen von verschienen Build Scripten. Zusätzlich soll ein automatischer Deploy-Mechanismus (C#-Anwendung) aufgebaut bzw. programmiert werden, um die Installationen der Produktentwicklung zu automatisieren, dieser wird ebenfalls im Rahmen der Diplomarbeit von mir entwickelt. 33

34 6. Grobkonzept 6.1 Grobentwurf Im dritten Kapitel Aufgabenstellung wurden die momentane Situation im PView- Umfeld sowie der Umgang mit einem Update erläutert. In diesem Kapitel dagegen wird ein Grobkonzept entworfen, um die Nachteile der jetzigen Situation zu beheben und ein automatisches Deployment einzuführen. Die PView-Entwicklung wird bei der GIP hauptsächlich von drei Bereichen aus begleitet. Zu diesen Bereichen gehören die Entwicklung, das Konfigurationsmanagement und der dazugehörige Fachbereich. Im ersten Schritt fertigt das Konfigurationsmanagement einen Grobentwurf an. Dieser Entwurf wird als Fundament für die weiteren Anforderungen der jeweiligen Bereiche dienen. Denn im zweiten Schritt wird das entworfene Grobkonzept dem zuständigen Fachbereich und der Entwicklung vorgestellt. Während die Anforderungen der beiden anderen Bereiche (Fachbereich und Entwicklung) berücksichtigt werden, entsteht schließlich das endgültige Grobkonzept. Bevor das definitive Grobkonzept entworfen wird, soll folgende Abbildung einen Grobentwurf des Konfigurationsmanagements darstellen. Wie aus der Abbildung deutlich wird, sollen die Entwickler aus Rumänien Zugriff auf das Repository bekommen, indem sie Änderungen ein- und auschecken können. Das Repository dagegen soll vom Continuous Integration System auf Änderungen hin überprüft werden. Falls Änderungen entdeckt werden, sollen diese mit Hilfe von Build Scripts kompiliert und in Fehlersituationen die Entwickler per informiert werden. Dieser Kompilier-Prozess soll sich so lange wiederholen, bis ein Release abgeschlossen und zur Installation freigegeben wird. Anschließend sollen die Änderungen mit dem automatischen Deploy-Mechanismus in die jeweilige Umgebung insalliert werden. 34

35 6.2 Erstellung des Grobkonzepts Die erste Überlegung besteht natürlich darin, dass die Nachteile, die derzeit existieren, so schnell wie möglich behoben werden. Die Neuerungen dürfen jedoch in der Zukunft keine Nachteile mit sich bringen. Deswegen müssen die Anforderungen mit jedem Bereich, der mit PView in irgendeiner Weise in Verbindung steht, besprochen und abgestimmt werden. Um die Kommunikation zwischen den Entwicklern in Rumänien und des Fachbereichs in Offenbach über Quellcode-Änderungen untereinander effektiver und einfacher zu gestalten, soll der gesamte Quellcode in einem Repository in Offenbach verwaltet werden. Damit haben der dazugehörige Fachbereich und das Konfigurationsmanagement jederzeit Einsicht in den aktuellen Stand der Entwicklung. Solch eine Übersicht über das aktuelle Geschehen bzw. über die Entwicklung zu haben, erleichtert es im Gegenzug, qualitätssichernde Maßnahmen mit einzuplanen. Dies bringt enorme Vorteile für die Qualitätssicherung mit sich. Der Zugriff auf das Ropository soll über die vorhandene Verbindung (Offenbach Cluj) mittels einer VPN- Verbindung erfolgen. Die Entwickler aus Rumänien können sich dann über das Netzwerk eine Abbildung des Quellcodes vom Repository lokal auf ihre Arbeitsplätze holen. Sobald ein Entwickler eine bestimmte Änderung an einer Methode, Klasse oder Funktion bearbeiten möchte, muss er die erforderlichen Komponenten aus dem Repository auschecken. Dadurch wird die Komponente über das Versionskontrollsystem für alle anderen Entwickler sichtbar gesperrt, sodass keine gleichzeitige Bearbeitung möglich ist. Solch eine Logik wird als Pessimistic Revision Control bezeichnet und ist eine der Anforderungen des Fachbereichs. Die Antithese zu dieser Logik ist Optimistic Revision Control. Hier haben mehrere Entwickler gleichzeitigen Zugriff auf die Datei und können unabhängig voneinander mit einer lokalen Kopie arbeiten bzw. Änderungen vornehmen. Anschließend werden die Änderungen zusammengeführt (Merge) und in das Repository eingecheckt. 27 Änderungen, die eingecheckt werden, sollen in bestimmten Zeitabständen durch das Continuous Integration System auf Änderungen hin überprüft, mit Hilfe von Build Scripts kompiliert und die daraus erzeugten Binärdateien (*.dll und *.exe) in einer vordefinierten Verzeichnisstruktur abgelegt werden. Das regelmäßige Kompilieren hat den Vorteil, frühzeitig Integrationsfehler zu vermeiden. Als Folge können Methoden bzw. einzelne Komponenten im Voraus getestet werden. Denn jeder kennt das It works on my machine -Phänomen und möchte nicht am Ende des Projektes unzählige Fehler zu beheben haben. Schließlich soll in frei definierbaren Zeitabständen oder sogar mit manuell (Maus-Klick) steuerbaren Systemen das Continuous Integration System die Entwicklungsumgebung oder die Testumgebung mit den kompilierten *.dlls- und *.exe- Dateien (die sich in einer bestimmten Verzeichnisstruktur befinden) aktualisieren. Die auf dem SQL Server dazugehörige Datenbank soll mit aktualisiert werden können. Die Installationen der PView-Anwendungen auf dem Citrix Presentation Server sollen mit zwei weiteren Installationen auf insgesamt vier Umgebungen erweitert werden. Somit kommen zu der Entwicklungs- und Testumgebung zwei weitere Testumgebungen hinzu. Auf der Entwicklungsumgebung führt der Fachbereich die Qualitätssicherung und das Methodendesign durch. Das Methodendesign wird anschließend in Form einer XML-Datei exportiert. Die bisherige Konstellation konnte weder eine Archivierung der Methoden in ein zentrales System noch eine Versionierung ermöglichen. Mit der neuen Umstellung soll das Methodendesign im File-System in einer bestimmten Verzeichnisstruktur abgelegt und zusätzlich im Repository versioniert werden. Der Vorteil ist, dass die neu entwickelten Methoden durch den automatischen Deploy-Mechanismus in die Testumgebung installiert werden können. Die zweite Testumgebung soll den Stand vor der Auslieferung an den Kunden widerspiegeln. Diese Testumgebung wird durch das Konfigurationsmanagement 27 Eine ausführliche Beschreibung und Unterschiede zwischen verschiedenen Systemen sind im Kapitel Anforderungsanalyse unter dem Punkt Versionskontrollsystem enthalten. 35

36 manuell mit den sich im File-System befindenden Binärdateien, *.dll, *.exe und zusätzlich mit den XML-Dateien aus dem Methodendesign durch das Erzeugen einer Setup-Datei aktualisiert. Nach erfolgreichen Tests wird dieser Stand freigegeben und auch beim Kunden installiert. Anschließend soll dieser Stand auf die dritte Testumgebung übertragen werden. Somit hat die dritte Testumgebung den aktuellen Stand, der momentan beim Kunden im Einsatz ist. Die dritte Testumgebung dient dazu, um ggf. Fehler-Situationen, die beim Kunden auftreten, abzubilden und Lösungen für das nächste Update zu erstellen. Diese dritte Testbzw. Wartungsumgebung ist nicht Bestandteil der Diplomarbeit, wird aber hier im Zusammenhang mit dem Grobkonzept erwähnt. 6.3 Anforderungen der Entwicklung Mit Absprache der Entwickler aus Rumänien wurden einige Anforderungen mit in das Grobkonzept aufgenommen. Den Entwicklern soll ein direkter Vollzugriff auf das File-System, in dem sich die kompilierten Dateien befinden, gewährleistet werden. Nach einem nicht funktionierenden Update auf die jeweilige Umgebung muss im Zweifelsfall auf die letzten drei funktionierenden Versionen zurückgegriffen werden können. Es muss die Möglichkeit geben, dass ein Update auf ältere Versionsstände zu installieren ist. Darüber hinaus soll eine Auswahl getroffen werden können, welche kompilierten Dateien mit welcher Version auf welche Umgebung zu aktualisieren sind. Das Repository muss mehrere Versionsstände gleichzeitig verwalten können. All diese Anforderungen sollen mit in das Feinkonzept einfließen. Die einzelnen Details und die technischen Funktionsweisen werden im Feinkonzept erläutert. Folgende Abbildung soll das Grobkonzept, welches mit den Anforderungen des Konfigurationsmanagements, des zuständigen Fachbereichs und der Entwicklung erstellt wurde, illustrieren. 36

37 37

38 7. Anforderungsanalyse 7.1 Zentrale Anforderungen Mit dem Grobkonzept wurden Anforderungen von der Entwicklung, dem zuständigen Fachbereich und vom Konfigurationsmanagement an das Komplett-System gestellt. Um diese Anforderungen analysieren zu können, wird das System in verschiedene Aufgabenbereiche aufgeteilt. Verbindung zwischen den Entwicklern in Rumänien und dem Versionskontrollsystem (Repository) in Offenbach. Die Analyse verschiedener Versionskontrollsysteme und ihrer Funktionen. Continuous Integration System und die Kompatibilität zu anderen Komponenten. Build- und Deployment-Konzept. Durch eine detaillierte Analyse der einzelnen Bereiche ergibt sich folglich das Feinkonzept, welches letztendlich die Basis für das Komplett-System definieren wird. Dabei werden diese Bereiche einzeln untersucht. Da aber die Kommunikation zwischen den einzelnen Systemen unumgänglich ist, wird auch eine Analyse zwischen den Systemen, um Kompatibilitätsprobleme zu lösen, zwingend erforderlich sein und besitzt eine große Bedeutung für die endgültige Entscheidung. Um die oben genannten Anforderungen leichter verständlich zu gestalten, ist im Folgenden eine Grafik abgebildet, welche die einzelnen Anforderungen visualisiert. Diese sind auch gleichzeitig die zentralen Anforderungen an das komplette System. 38

39 7.2 Anforderungen zwischen der Verbindung Cluj Offenbach Der Quellcode bzw. das Repository wird auf Anforderung des Fachbereichs in Offenbach verwaltet. Dadurch wird den Entwicklern in Cluj ein permanenter Zugriff auf das Repository in Offenbach ermöglicht. Aus diesem Grund ist die Standhaftigkeit der Verbindung mit einer 100-prozentigen Stabilität zu gewährleisten. Nach einer Analyse der momentan existierenden Standleitung mit Cluj kann mit hoher Wahrscheinlichkeit garantiert werden, dass die Ausfallquote dieser Standleitung sehr gering ist. Dennoch sollte ein Plan B existieren, wenn die Verbindung wirklich einmal wegbrechen sollte. Solch eine Alternative zu entwickeln ist nicht Bestandteil dieser Diplomarbeit, wird aber als eine Anforderung der Entwickler festgehalten. Eine mögliche Lösung könnte der Einsatz eines zweiten Repositories sein. Und zwar soll dann das Haupt-Repository weiterhin in Offenbach verwaltet werden, welches sich über Nacht mit dem Repository in Cluj automatisch synchronisiert. Mit dem auslagern des Repositories ändert sich für die Entwickler nicht viel. Denn auch wenn das Repository jetzt nicht mehr vor Ort, den Entwickler zur Verfügung steht, haben die Entwickler nach wie vor Zugriff auf das Repository. Den wesentlichen Vorteil hat dadurch der Fachbereich. Diese können jetzt die Entwicklung über das Versionskontrollsystem in Offenbach beobachten und somit kalkulieren in welchem Status die Entwicklung sich befindet. 7.3 Anforderungen an das Versionskontrollsystem Die Auswahl der momentan auf dem Markt existierenden Versionskontrollsysteme ist recht groß. Umso schwieriger ist es auch, sich für ein passendes System zu entscheiden. Anhand einer Tool-Evaluierung der verschiedenen Versionskontrollsysteme soll ein geeignetes Tool ausgewählt werden. Dabei werden aber nur Anwendungen (Tools) betrachtet, die die Hauptkriterien der GIP erfüllen. Um eine Vorauswahl zu treffen, werden ausschließlich Anwendungen begutachtet, die im Faktor Kosten nicht ausufern und schon bei der GIP im Einsatz sind. Die Evaluierung wird anhand eines Punktesystems, jedoch mit verschiedenen Prioritäten der Anforderungen ermittelt. Eine Anforderung kann damit eine Priorität von 1 bis 10 erhalten. Die Höhe der Ziffer gibt die Wichtigkeit einer Anforderung an, also hat die wichtigste Anforderung eine Priorität von 10 und die unwesentlichste Anforderung eine Priorität von 1. Die Antworten auf die Anforderungen der einzelnen Anwendungen dagegen werden mit Ja oder Nein gegeben. Hierfür werden ebenfalls Punkte auf einer Skala von 1 bis 10 vergeben. Die Punkte dienen hier zur Bewertung der Anwendung. Die Punktevergabe bzw. die Bewertung der Anwendungen ist unabhängig davon, ob eine Antwort Ja oder Nein lautet. Die Bewertung zeigt lediglich, in welchem Maße die gestellte Anforderung von der jeweiligen Anwendung erfüllt wird. Angenommen, wir haben zwei Anwendungen Tool1 und Tool2, die miteinander anhand der Anforderung Lizenzgebühr und Einsatz bei der GIP verglichen werden. Dabei haben die Anforderungen eine Gewichtung von 10, also höchste Priorität. Beide Tools verlangen eine Lizenzgebühr und sind bei der GIP im Einsatz. Damit werden die Anforderungen logischerweise mit Ja beantwortet. Anhand der Punkteskala kann man jetzt die geforderte Lizenzgebühr zum Ausdruck bringen. Ist die geforderte Lizenzgebühr hoch, so kann man dies mit der Vergabe von niedrigen Punkten zum Ausdruck bringen. In unserem Fall bekommt das Tool1 vier und das Tool2 nur zwei Punkte, weil Tool2 eine höhere Lizenzgebühr 39

40 verlangt als Tool1. Die zweite Anforderung ( Einsatz bei GIP ) wird auch von beiden Tools mit Ja beantwortet und erhält damit zehn von zehn Punkten. Hier ist zu beachten, dass die Antwort auf die Anforderung, die mit Ja beantwortet wurde, aber trotzdem keine zehn Punkte bekommen hat. Wie wir in diesem Beispiel gesehen haben, kann eine Anforderung, die mir Ja beantwortet wurde, einmal niedrige und ein anderes Mal hohe Punkte bekommen. Ein Tool wird nur dann mit hohen Punkten bewertet, wenn die gestellten Anforderungen zu Gunsten der GIP sind und nicht wenn diese mit Ja beantwortet werden. Am Ende dieses Punktesystems werden die Punkte der jeweiligen Tools mit der dazugehörigen Anforderungspriorität multipliziert; diese Multiplikation wird für jede Anforderung explizit durchgeführt und die Ergebnisse der Multiplikationen miteinander addiert. Die Höhe der Gesamtsumme entscheidet dann über die Auswahl der Tools. Beispiel mit nur zwei Anforderungen: Anforderung Priorität Tool1 Tool2 Lizenzgebühr 10 X Ja / 4 Ja / 2 Einsatz bei GIP 10 X Ja / 10 Ja / 10 Gesamt Σ Hier würde die Auswertung des Punktesystems ein eindeutiges Ergebnis liefern, und zwar zur Gunsten von Tool1. Tool1 = ((10 X 4) + (10 X 10)) = 140. Tool2 = ((10 X 2) + (10 X 10)) = 120. Die Anforderungen sollen Kriterien für die Auswahl der Tools festlegen. Dabei werden Kriterien aus allen drei Bereichen (Entwicklung, Fachbereich und Konfigurationsmanagement) bestimmt. Im Wesentlichen bestehen die Anforderungen aus drei Kriterien. Funktionale Aspekte: Operationelle und operative Aspekte: Ökonomische Aspekte: Funktionale Aspekte sind auf das Tool selbst bezogene Eigenschaften. In der Regel sind es die Entwickler, die solche Anforderungen stellen. Dieser Aspekt bezieht sich im Allgemeinen auf die organisatorischen Maßnahmen die das Tool mit sich bringt. Dabei ist es auch wichtig den Aufwand, der da durch entsteht zu beachten. Die Operationellen bzw. operativen Überlegungen entstehen meistens vom Konfigurationsmanagement. Ökonomische Aspekte beziehen sich dagegen auf Kosten, die mit der Einführung des Tools entstehen oder noch entstehen werden. 40

41 7.3.1 Anforderungen des Konfigurationsmanagements an das Versionskontrollsystem Die Anforderungen des Konfigurationsmanagements beziehen sich hauptsächlich auf administrative Tätigkeiten. Denn das Konfigurationsmanagement wird nicht nur während der Installation des Systems mitwirken, sondern wird dieses auch während der gesamten Laufzeit nach der Installation betreuen. Somit ist es sehr wichtig, mit genau definierten Anforderungen die jeweiligen Tools zu untersuchen und auszuwählen, um im laufenden Betrieb auf anfallende Probleme so schnell wie möglich zu reagieren. Angenommen, das Continuous Integration System befindet sich voll im Einsatz und das Entwicklerteam ist darauf konzentriert, mit den Werkzeugen des Systems zu entwickeln. Im Laufe der Zeit kommen neue Entwickler ins Team und möchten ebenfalls mit den Werkzeugen arbeiten. In diesem Fall muss das Konfigurationsmanagement schnell reagieren und dem Mitarbeiter die Entwicklungswerkzeuge zur Verfügung stellen bzw. installieren. Denn jetzt stellt sich die entscheidende Frage, was für ein Tool im Einsatz ist bzw. wie sich das Tool installieren lässt? War die Anforderungsanalyse effektiv, so wurde auch sicherlich auf die Bequemlichkeit der Installationen geachtet. Wurde diese aber nicht berücksichtigt, so kann es sein, dass sich die Einrichtung eines neuen Arbeitsplatzes in die Länge zieht. Anforderungen des Konfigurationsmanagements: Es muss ein Versionskontrollsystem sein, welches bei der GIP schon eingesetzt wird. Lizenzgebühren dürfen nicht zu teuer sein. Der Schulungsaufwand bzw. die Einarbeitung der Mitarbeiter in die neue Anwendung soll nicht lange andauern. Die Installation der Software soll ohne großen Aufwand durchgeführt werden können. Das Versionskontrollsystem muss kompatibel mit den anderen Bausteinen des Systems sein. 41

42 Erläuterungen und Begründungen zu den gestellten Anforderungen Anforderung: Es muss ein Versionskontrollsystem sein, welches bei der GIP schon eingesetzt wird. Begründung: Momentan sind drei Versionskontrollsysteme bei der GIP vertreten. Ein weiteres würde den Betreu- und Wartungsaufwand erhöhen. Anforderung: Die Lizenzgebühren dürfen nicht zu teuer sein. Begründung: Das Versionskontrollsystem soll nicht unbedingt lizenzfrei sein, sondern das Preisleistungsverhältnis sollte stimmen. Anforderung: Der Schulungsaufwand bzw. die Einarbeitung der Mitarbeiter in die neue Anwendung soll nicht lange andauern. Begründung: Es könnte sein, dass die Mitarbeiter nicht mit der neuen Anwendung vertraut sind und geschult werden müssen. Eine Schulung bringt Kosten mit sich, die eventuell wieder das Budget sprengen könnten. Das Wichtigste ist aber, dass die laufende Produktivität sicherlich mit einer Umstellung der Arbeitsumgebung abnehmen wird. Denn die Entwickler werden in der Anfangszeit eher mit der Handhabung der neuen Anwendung beschäftigt sein als mit ihrer eigentlichen Arbeit, der Entwicklung. Anforderung: Die Installation der Software soll ohne großen Aufwand durchgeführt werden können. Begründung: Wenn die Installation zu komplex ist, bringt dies natürlich einen gewissen Aufwand mit sich und es stehen wieder ganz andere Faktoren im Vordergrund. Bei jeder Erweiterung oder Änderung müssen größere Zeitrahmen in Anspruch genommen werden. Die Flexibilität würde beeinträchtigt werden. Anforderung: Das Versionskontrollsystem muss mit den anderen Bausteinen des Systems kompatibel sein. Begründung: Das Versionskontrollsystem muss mit dem Continuous Integration System und mit dem Deploy-Mechanismus zusammenarbeiten, um überhaupt ein automatisches Buildund Deployment-Konzept realisieren zu können Anforderungen der Entwickler an das Versionskontrollsystem Die Entwickler betrachten das Versionskontrollsystem aus einer anderen Perspektive. Es sind im Endeffekt die Personen, die täglich mit der Anwendung arbeiten werden. Daher konzentrieren sich ihre Anforderungen eher auf die Handhabung der Anwendung. Denn falls die Bedienung der Anwendung nicht leicht überschaubar ist, wird diese ihre eigentliche Aufgabe (Programmieren) behindern. Anforderungen der Entwickler: Eine grafische Oberfläche wird bevorzugt. Es muss die Möglichkeit geben, Entwicklungsumgebungen einzubinden. Das Versionskontrollsystem muss mehrere Repositories verwalten können. 42

43 Erläuterungen und Begründungen zu den gestellten Anforderungen Anforderung: Eine grafische Oberfläche wird bevorzugt. Begründung: Die Handhabung ist leichter und das Arbeiten viel angenehmer. Die Entwickler sollen sich hauptsächlich auf ihre eigentliche Arbeit fokussieren. Anforderung: Es muss die Möglichkeit geben, Entwicklungsumgebungen einzubinden. Begründung: Eine Entwicklungsumgebung verschafft dem Anwender eine bessere Übersicht. Mit seinen vielen Funktionen (abhängig von der jeweiligen Entwicklungsumgebung) unterstützt es den Entwickler. Z.B. eine Debugging-Funktion. Anforderung: Das Versionskontrollsystem muss mehrere Repositories verwalten können. Begründung: Ein Produkt hat während der Entwicklung viele Versionen, die gepflegt und gewartet werden müssen. Die Entwickler benötigen auch Zugriffe auf ältere Versionsstände, die in separaten Repositories gehalten werden müssen Anforderungen des Fachbereichs an das Versionskontrollsystem Der Fachbereich interessiert sich primär für die Qualitätssicherung. Die Verantwortung für eine qualitative Software liegt also in seinen Händen, auch wenn die Software von der Entwicklung durchgeführt wird. Er arbeitet praktisch mit den Ergebnissen der Entwickler. Das Testen der Software ist Beispiel dafür. Der Fachbereich hat also keinen direkten Bezug zum Versionskontrollsystem. Dennoch sollte das Versionskontrollsystem einige Funktionen zur Erleichterung der Überschaubarkeit mitbringen. Das Tool sollte einen direkten Vergleich (auf Textebene) zwischen zwei oder mehreren Quelltextversionen anbieten. Das Tool sollte eine History über fortlaufende Änderungen anzeigen können. Erläuterungen und Begründungen zu den gestellten Anforderungen Anforderung: Das Tool sollte einen direkten Vergleich zwischen zwei oder mehreren Quelltextversionen anbieten. Begründung: In der Qualitätssicherung werden Aufwandsberechnungen für bestimmte Abläufe oder Änderungen durchgeführt. Um den Aufwand bzw. die Änderungen zwischen zwei Versionen festzustellen, ist es praktisch, sich diese direkt anzeigen zu lassen. Anforderung: Das Tool sollte eine History über fortlaufende Änderungen anzeigen können. Begründung: Es ist vorteilhaft, sich Änderungen, die gemacht wurden, anzeigen zu lassen gerade bei Projekten, bei denen mehrere Entwickler gemeinsam entwickeln. 43

44 7.4 Versionskontrollsystem Die Softwareentwicklung nimmt immer mehr an Bedeutung zu. Es werden zunehmend intelligente Systeme entwickelt, die den menschlichen Alltag vereinfachen sollen. Mittlerweile gibt es Systeme, die heute in jeder Größe vertreten sind wie z.b. ein intelligentes Haus, programmierbare Taschenrechner, reaktionsstarke Bremssysteme oder viele andere Systeme, die hier nicht erwähnt worden sind. All diese Systeme haben einen bestimmten Entwicklungsweg durchlaufen. Auch die Softwareentwicklung an sich hat eine Evolution erlebt, von den Lochkarten bis zu den Großrechnern. Mit der Komplexität eines Systems wächst der Programmieraufwand und damit auch die Größe einer Source-Datei. Die Aufgaben werden auf Grund ihrer Komplexität zusätzlich in Teams gelöst. Es existiert jetzt nicht mehr ein Entwickler, sondern mehrere, die gemeinsam entwickeln. Der Verwaltungsaufwand wird dadurch immer größer und ist schwerer kontrollierbar. Um den Verwaltungsaufwand zu minimieren, gibt es Versionskontrollsystem. Heute ist es üblich, bei größeren Entwicklungsprojekten ein Versionskontrollsystem zu nutzen. Auch wenn zurzeit die Anzahl der Versionskontrollsysteme noch überschaubar ist, existieren bereits einige Systeme, die schon relativ ausgereift sind. Berücksichtigt man die Anforderungen der GIP kommen drei Versionskontrollsysteme in Frage. Subversion Microsoft Visual SourceSafe MKS Integrity Suite Was ist ein Versionskontrollsystem? Es ist ein zentrales System, welches in der Softwareentwicklung Quelltexte verwaltet und den gemeinsamen Zugriff auf diese kontrolliert. Der Begriff verwaltet impliziert die eigentliche Intelligenz eines solchen Systems. Der Inhalt, in dem der Quelltext verwaltet wird, wird als Repository bezeichnet. Die fortlaufenden Änderungen werden versioniert und im Repository gesichert. Zu einem späteren Zeitpunkt können diese Zustände wiederhergestellt werden. Viele Systeme speichern nicht nur die Änderungen, sondern auch zusätzliche Informationen zu den Änderungen wie z.b. Benutzerinformationen, Uhrzeit und Datum. Ein weiteres Merkmal eines Versionsverwaltungssystems ist die gemeinsame Nutzung der Quelltexte. Es gibt von System zu System verschiedene Ansätze, wie die gemeinsame Nutzung geregelt ist. Pessimistic Revision Control Sperre Ändern Schreiben Optimistic Revision Control Kopieren Ändern Zusammenführen Die Pessimistic Revision Control-Methode bietet keinen gemeinsamen Zugriff auf die Datei. Bevor die Datei modifiziert wird, muss sie vorher gesperrt werden. Folglich ist die Datei für alle anderen Benutzer gesperrt und kann nicht bearbeitet werden. Die Datei kann erst wieder zur Bearbeitung für andere Benutzer freigegeben werden, wenn sie eingecheckt und freigegeben wurde. Wenn aber vergessen wird, die Datei freizugegeben, behindert das den flüssigen Arbeitsverlauf. Die Optimistic Revision Control-Methode dagegen arbeitet mit einer anderen Logik. Die Datei kann von mehreren Benutzern gleichzeitig bearbeitet werden. Die Benutzer arbeiten nicht mit einer zentralen Datei, sondern jeder Einzelne hat seine eigene Arbeitskopie. Somit 44

45 kann die Datei ganz unabhängig von anderen Benutzern bearbeitet werden. Die Änderungen werden anschließend zusammengeführt (Merge). Der Nachteil an dieser Methode wird dann sichtbar, wenn zwei Anwender Änderungen nacheinander in das Repository einchecken. Das System übernimmt automatisch die letzte Änderung als die aktuelle, somit ist die vorletzte Änderung gleich überschrieben und schon veraltet. Der Entwickler muss sich also selbst darum kümmern, ob seine Änderungen eingecheckt sind Versionskontrollsystem Subversion Subversion ist ein frei verfügbares Versionskontrollsystem der Firma CollabNet, die Anfang 2000 mit dessen Entwicklung begann. Subversion ist in seinem Konzept sehr ähnlich wie das Concurrent Version System 28 (CVS) aufgebaut, sollte aber die Nachteile des CVS beheben. Auf Grund seines Konzepts hat CVS einige Schwächen, die nicht zu übersehen sind. Z.B. können nur einzelne Dateien versioniert werden und nicht ganze Verzeichnisse. Damit ist auch das Umbenennen, Verschieben, Löschen und Kopieren von Dateien nicht gewährleistet, da diese Operationen Auswirkungen auf den Inhalt der Verzeichnisse haben und CVS diese Umstellung nicht in der Versionshistorie festhalten kann. Damit könnte zu einem späteren Zeitpunkt der ursprüngliche Zustand nicht wiederhergestellt werden. CVS war zur damaligen Zeit in der Open Source-Gemeinde eines der am weitesten verbreiteten Versionskontrollsysteme. Mit der Einführung von Subversion im Jahre 2004 nahm das Interesse aber ab. Der Grund dafür war, dass die Schwächen des CVS mit Subversion behoben und die Stärken nach wie vor vorhanden waren Funktionsweise von Subversion Wie auch schon sein Vorgänger, das Versionskontrollsystem CVS, arbeitet Subversion standardmäßig mit der Optimistic Revision Control-Logik. Zusätzlich wird die Pessimistic Revision Control-Logik auch unterstützt. Somit ist dem Benutzer freigestellt, ob er die Datei vor der Bearbeitung sperren oder nicht sperren möchte. Die Architektur von Subversion basiert auf einem Client-Server-System. Auf einem zentralen Rechner im Netzwerk wird der Subversion Server installiert. Mit einem Client können Benutzer über das Netzwerk auf den Server (Subversion svnserve) zugreifen. Der Standard Client ist eine Kommandozeilen- Anwendung. Daneben werden aber auch zahlreiche grafische Werkzeuge angeboten, die das Arbeiten mit Subversion vereinfachen. Subversion benutzt ein eigenes Protokoll (svn) zur Kommunikation mit dem Server. Zusätzlich bietet Subversion die Möglichkeit, anhand eines Moduls die Kommunikation über das HTTP- Protokoll zu regeln und einen Apache2 Server zu benutzen. Dazu muss allerdings ein Apache2 Server installiert werden. Der Zugriff auf das Repository kann dann anhand eines der beiden Protokolle erfolgen. Eine dritte Zugriffsmöglichkeit bietet das FTP-Protokoll, welches vom Client aus direkt auf das Repository zugreift. Diese Zugriffsmöglichkeit stellt jedoch ein Sicherheitsrisiko dar. Der Client benötigt hierfür alle Zugriffsrechte auf das Installationsverzeichnis des Repositories. Subversion arbeitet mit einer lokalen Arbeitskopie, welche sich der Entwickler am Anfang eines Entwicklungszyklus einmalig anlegt, und schließlich muss er nur noch die Änderungen mit dem Repository abgleichen. Die Arbeitskopie liegt lokal auf dem Rechner des 28 Concurrent Versions System [16] 45

46 Entwicklers. Das Arbeiten mit Subversion ist in etwa mit einem zyklischen Prozess zu vergleichen und läuft folgendermaßen ab: 1. Eine Arbeitskopie vom Subversion Server anfordern. 2. Falls bereits eine Arbeitskopie vorhanden ist, diese mit dem Repository abgleichen. 3. Optionaler Schritt: Auflösen von aufgetretenen Konflikten. 4. Entwickeln auf der Arbeitskopie. 5. Übernahme der Änderungen aus der lokalen Arbeitskopie in das Repository. Schritt eins wird einmalig beim Anlegen eines Projekts durchgeführt. Die Schritte zwei bis fünf dagegen müssen nach jeder Änderung durchgeführt werden Vor- und Nachteile von Subversion Die Pessimistic Revision Control-Logik wird von Subversion nicht empfohlen, aber auch unterstützt, welches aber mit der angebotenen Sperrstrategie einen Nachteil bietet. Dadurch, dass andere Benutzer erst dann sehen können, dass die Datei gesperrt ist, nachdem sie ihre Arbeitskopie aktualisiert haben, bildet diese Vorgehensweise einen deutlichen Nachteil. Angenommen, zwei Benutzer wollen in derselben Datei einen Bug beheben. Benutzer1 sperrt die Datei und beginnt mit der Fehlerbeseitigung. Benutzer2 dagegen beginnt, ohne seine Arbeitskopie zu aktualisieren, mit der Bearbeitung derselben Datei. Benutzer2 ist kurz vorher mit der Bearbeitung fertig und möchte einchecken. Erst jetzt stellt Benutzer2 fest, dass die Datei gesperrt ist. Benutzer1 dagegen kann ungestört seine Änderungen einchecken. In diesem Fall muss der Benutzer2 (immer der, der zuletzt Änderungen vorgenommen hat) auch den Konflikt lösen. Notfalls müssen sich beide Entwickler zusammensetzen und Änderungen wieder durchgehen. 46

47 Subversion bietet die Möglichkeit, das Repository durch eine Authentifizierung vor Unbefugten zu schützen, leider ist aber der Authentifizierungsmechanismus von svnserve (Subversion Server) sehr einfach und legt die Passwörter im Klartext ab. Eine gute Alternative stellt dagegen das Apache Servermodul dar. Dieses kann im Gegensatz zu svnserve die Passwörter mit MD5 als Hashwert hinterlegen. Ein klarer Vorteil ist, dass Subversion die komplette Infrastruktur, welche durch den Apache Server angeboten wird, ausnutzen kann Versionskontrollsystem Visual SourceSafe Visual SourceSafe (VSS) ist ein Versionskontrollsystem aus dem Hause Microsoft. Die aktuelle Version ist Visual SourceSafe Die Anwendung wird nicht nur als Einzelpaket VSS 2005, sondern auch mit dem Entwicklungspaket Visual Studio vermarktet, welches aber in der Standardversion von Visual Studio nicht mit enthalten ist. Es ist im Gegensatz zu Subversion lizenzpflichtig und für jeden Anwender wird eine eigene Lizenz verlangt Funktionsweise von Visual SourceSafe Visual SourceSafe arbeitet ebenfalls mit einem Client-Server-System. Die Clients greifen über das Netzwerk auf die zentral im Netz freigegebene Datenbank zu. Was bei Subversion als Repository bezeichnet wird, wird bei Microsoft als Datenbank bezeichnet, was mit dem Ablageformat zu begründen ist. VSS legt die Dateien in Form einer Datenbank im File-System ab. Die Verwaltung der Datenbank wird über das mitgelieferte Administrationstool geregelt. Der Administrator erstellt eine Datenbank und legt Benutzer an, denen er verschiedene Zugriffsrechte erteilen kann. Benutzer können Lese- und Schreibrechte oder auch nur Leserechte erhalten. Die Datenbank wird mit Hilfe eines Wizards erstellt. Während der Erstellung hat man die Möglichkeit, eine Arbeitslogik festzusetzen, die für diese Datenbank gilt und später auch nicht veränderbar ist. VSS 2005 unterstützt sowohl die Pessimistic Revision Control- als auch die Optimistic Revision Control-Logik. Als Client bietet VSS den Visual SourceSafe Explorer an. Dieser wird bei der Installation standardmäßig mit installiert. Neben dem VSS Explorer mit einer grafischen Oberfläche wird auch ein Visual SourceSafe-Befehlszeilendienstprogramm Ss.exe angeboten. Dieses ermöglicht es, nach dem Einrichten der Umgebungsvariable über die Kommandozeile, dass Befehle, die vom VSS Explorer nicht unterstützt werden, ausgeführt werden. 47

48 Vor- und Nachteile von Visual SourceSafe VSS benötigt einen direkten Zugriff auf das Repository im Dateisystem. D.h., jeder Anwender bzw. Entwickler, der mit VSS arbeitet, benötigt einen direkten Zugriff auf eine Windows-Netzwerkfreigabe. Eine Verschlüsselung für die Kommunikation ist nicht gegeben. Bei größeren Projekten mit vielen Entwicklern, die außerhalb eines Netzwerks im selben Projekt arbeiten, kann VSS daher nicht angewendet werden. Ein weiterer Nachteil sind die hohen Lizenzkosten. Dafür aber ist die Handhabung, von der Installation bis zur Inbetriebnahme und dem Arbeiten mit VSS, äußerst anwenderfreundlich aufgebaut Versionskontrollsystem MKS Integrity Suite 2005 MKS Integrity Suite 2005 (MKS IS) ist ein Produkt der Firma MKS Inc., welche 1984 in Kanada gegründet wurde. Das Unternehmen beschäftigt heute weltweit über 300 Mitarbeiter. MKS IS ist eine J2EE-Applikation, welche mit einem Server (MKS Integrity Server) bzw. einer Client- (MKS Integrity Client) Komponente geliefert wird. Der MKS Integrity Server verwaltet die Objekte und Quellcode-Dateien, die sich auf dem Server befinden. Er läuft unter einem Applikations-Server verpackt. MKS Integrity verwendet FLEXlm 30 als einen Lizenzmanager. Der MKS Integrity Client besteht dagegen aus drei logischen Teilen: MKS Source Integrity Enterprise, MKS Integrity Manager und einem Administrationsclient. MKS Source Integrity Enterprise ist die Versionskontrollschnittstelle, während der MKS Integrity Manager die Prozess- und Workflow Management-Aktivitäten erleichtert. 29 Stand September [17] 30 FLEXML ist eine Software, die für die Verwaltung von Softwarelizenzen eingesetzt wird. 48

49 7.4.9 Funktionsweise von MKS Integrity Suite 2005 MKS IS arbeitet wie Subversion und VSS auch mit einem Client-Server-System. Basierend auf einer Datenbank, kann der MKS Integrity Server auf einem zentralen System installiert werden. Es besteht die Möglichkeit, eine von MKS IS integrierte, mitgelieferte Datenbank zu verwenden. Zusätzlich können auch weitere externe Datenbanken wie MS SQL Server, Oracle und DB2 verwendet werden. Allerdings müssen die externen Datenbanken vor der Installation des MKS Integrity Servers installiert werden. Für das lokale Arbeiten an MKS- Projekten werden Sandboxen benötigt. Entwickler müssen also solch eine Sandbox anlegen. Im Wesentlichen gibt es zwei Typen: normale Sandboxen und so genannte Variants. Die normale Sandbox wird für Entwicklungszwecke und die Variants werden für die Wartung benötigt. Zudem sind Variants Ausprägungen, die den Zugriff auf verschiedene Zweige ermöglichen können. Zusätzlich gibt es noch einen Administrationsclient, womit man administrative Tätigkeiten, wie z.b. das Anlegen von Projekten, User anlegen bzw. in Gruppen aufteilen etc., abwickeln kann Vor- und Nachteile von MKS Integrity Suite 2005 Das Produkt kann einiges mehr leisten als nur die kontinuierliche Integration von Quelltexten. Einen Nachteil stellt jedoch der hohe Preis dieses Systems dar. Der Vorteil dagegen besteht darin, dass MKS ein vollständiges Produkt ist und nicht an irgendwelche externen Anwendungen gebunden ist. Es ermöglicht aber die Nutzung anderer Datenbank- Systeme. Der MKS Integrity Server bietet den Projektbeteiligten die Möglichkeit, dass sie über das Internet auf das Repository zugreifen können. Die einzige Voraussetzung dafür ist, dass der Server von außen erreichbar ist. 7.5 Auswertung des Punktesystems Folglich werden Subversion, Visual SourceSafe und MKS Integrity Suite 2005 anhand des Punktesystems ausgewertet. Dazu werden die Anforderungen der einzelnen Bereiche in Frage gestellt. 49

50 Priorität der Anforderung Anforderung Subversion Punkte Bemerkung Wird eine Lizenzgebühr verlangt? 10 nein 10 Subversion wird unter freier Software-Lizenz veröffentlicht und vertrieben. Wird die Software schon bei der GIP mbh eingesetzt? Entsteht ein Schulungsaufwand der Mitarbeiter beim Einsatz dieser Software? 10 ja 10 9 ja 4 Subversion wird zwar bei der GIP eingesetzt, aber nicht im PView-Umfeld. Entwickler müssen in die Subversion-Umgebung umgeschult werden. Ist die Installation aufwändig? 9 nein 10 Dies ist nur auf die reine Installation von Subversion bezogen. Ist der Einsatz dieser Software zusätzlich an externe Werkzeuge gebunden? 9 nein 31 3 Für einen umfassenden Einsatz sind aber ein Apache2 Server und eine GUI unverzichtbar. Sind die Werkzeuge untereinander kompatibel? 9 nein 3 Ist die Anwendung selbst benutzerfreundlich? 8 nein 3 Nur bestimmte Versionen der Werkzeuge sind kompatibel. Subversion ist eine Kommandozeilenanwendung; Werkzeuge wie TortoiseSVN oder RapidSVN bieten für Subversion eine GUI an. Existiert eine grafische Oberfläche? 8 nein 3 Nur über externe Anbindungen, s.o. Können Entwicklungsumgebungen eingebunden werden? 8 ja 10 Es existiert sogar eine Entwicklungsumgebung (Subclipse), mit integrierten Subversion-Befehlen. Können mehrere Repositories verwaltet werden? Ist das Tool in der Lage, einen Vergleich zwischen zwei Quelltexten herzustellen? 8 ja 10 7 ja 7 Gesamtsumme 637 Subversion kann auf der Kommandozeilenebene die Unterschiede zwischen Dateien anzeigen. Einige GUIs benötigen dafür jedoch externe Plugins. 31 Subversion ist zwar nicht an externe Werkzeuge gebunden, bietet aber nur eine Kommandozeilenanwendung an. 50

51 Priorität der Anforderung Anforderung Visual SourceSafe 2005 Punkte Bemerkung Wird eine Lizenzgebühr verlangt? 10 ja 4 VSS benötigt für jeden Anwender eine eigene Lizenz. Eine Vollversion beträgt ca. 620 und ein Upgrade ca Wird die Software schon bei der GIP mbh eingesetzt? 10 ja 10 Die Entwickler in Cluj arbeiten mit VSS. Entsteht ein Schulungsaufwand der Mitarbeiter beim Einsatz dieser Software? 9 nein 10 Da die Entwickler schon damit arbeiten, wird keine Schulung benötigt. Ist die Installation aufwändig? 9 nein 10 Die Installation erfolgt durch einen MSI Installer. Ist der Einsatz dieser Software zusätzlich an externe Werkzeuge gebunden? 9 nein 10 Alle zusätzlich benötigten Werkzeuge werden mit dem VSS Explorer und dem VSS Administrator abgedeckt. Sind die Werkzeuge untereinander kompatibel? 9 10 VSS benötigt keine externen Werkzeuge. Ist die Anwendung selbst benutzerfreundlich? 8 ja 10 Windows-Benutzer finden sich ohne Probleme zurecht. Existiert eine grafische Oberfläche? 8 ja 10 Mit dem VSS Explorer können alle Arbeitsabläufe über die GUI abgewickelt werden. Können Entwicklungsumgebungen eingebunden werden? 8 ja 10 VSS ermöglicht z.b. die komplette Integration von Visual Studio. Können mehrere Repositories verwaltet werden? Ist das Tool in der Lage, einen Vergleich zwischen zwei Quelltexten herzustellen? 8 ja 10 7 ja 10 Gesamtsumme 890 VSS ermöglicht ein direkten Vergleich zwischen zwei oder mehreren Dateien. Zusätzlich hat man auch eine komplette History-Ansicht über eine Datei. 51

52 Priorität der Anforderung Anforderung MKS Integrity Suite 2005 Punkte Bemerkung Wird eine Lizenzgebühr verlangt? 10 ja 1 MKS erfordert eine hohe Lizenzgebühr. Wird die Software schon bei der GIP mbh eingesetzt? Entsteht ein Schulungsaufwand der Mitarbeiter beim Einsatz dieser Software? 10 ja 10 9 ja 4 MKS wird für die Versionskontrolle eingesetzt, aber nicht im PView-Umfeld. Entwickler müssen in die MKS-Umgebung umgeschult werden. Ist die Installation aufwändig? 9 nein 7 Die Installation an sich ist nicht aufwändig, aber die Konfiguration erhöht den Aufwand. Ist der Einsatz dieser Software zusätzlich an externe Werkzeuge gebunden? 9 nein 5 Wenn auf die integrierte Datenbank (zusätzliche Lizenzkosten) verzichtet wird, muss eine externe Datenbank verwendet werden. Sind die Werkzeuge untereinander kompatibel? 9 nein 5 Es werden nur bestimmte Datenbanken unterstützt. Ist die Anwendung selbst benutzerfreundlich? 8 ja 8 Es ist zwar gewöhnungsbedürftig, aber recht komfortabel. Existiert eine grafische Oberfläche? 8 ja 10 Der MKS Integrity Client ermöglicht eine leichte Handhabung. Können Entwicklungsumgebungen eingebunden werden? Können mehrere Repositories verwaltet werden? Ist das Tool in der Lage, einen Vergleich zwischen zwei Quelltexten herzustellen? 8 ja 10 8 ja 10 7 ja 10 MKS Integrity bietet die Möglichkeit, viele Entwicklungsumgebungen einzubinden. Der MKS Integrity Client bietet einen direkten Vergleich und viele andere Zusatzfunktionen an. Gesamtsumme

53 7.6 Anforderungen an das Continuous Integration System Das Continuous Integration System (CIS) hat die Aufgabe, Änderungen im Repository zu überprüfen. Die Überprüfung erfolgt in selbst definierbaren Zeitabständen. Wird eine Modifikation festgestellt, so wird diese kompiliert und somit auf Integrationsfehler hin getestet. In unserem Fall sind es mehrere Projekte, die auf Änderungen überwacht werden sollen. Die erfolgreich kompilierten Projekte liefern DLL- oder EXE-Dateien, die in einer bestimmten Verzeichnisstruktur abgelegt werden. Damit diese Anforderungen auch funktionieren, muss das Versionskontrollsystem mit dem CIS kompatibel sein Analyse von Continuous Integration Systemen Es ist zwar nicht so, dass der Markt im Bereich von Continuous Integration Systemen boomt, aber dennoch sind einige Tools zu begutachten. CruiseControl und AnthillPro sind zwei der führenden Werkzeuge in diesem Segment. Aber auch andere Systeme sind im Markt gut vertreten, wie z.b. folgende: Apache Gump: Luntbuild: Bamboo: ist ein in Python geschriebenes Werkzeug für die kontinuierliche Integration der Apache Software Foundation. Es wird unter der Open Source License vertrieben und unterstützt Apache Ant, Apache Maven (1.x and 2.x). Luntbuild ist ein automatisiertes Build- und Management-Werkzeug. Neben der freien Variante gibt es auch eine kostenpflichtige Version. Die Konfiguration erfolgt nicht über eine Konfigurationsdatei, sondern über ein web inerface. ist ein Produkt der Firma Atlassian. Es ist ein CI System und wird auch als Build Server bezeichnet. Bamboo ist ein kommerzielles Werkzeug Continuous Integration mit AnthillPro AnthillPro ist ein Continuous Integration System, welches von der Firma Urbancode erstmals im Jahre 2001 veröffentlicht wurde. Die erste kommerzielle Version der Software wurde aber 2002 veröffentlicht. Derzeit 32 befindet sich die dritte Generation von AnthillPro auf dem Markt. Es unterstützt sowohl hierarchische als auch plattformunabhängige Bauten, wie z.b..net, C/C++, Java und viele andere Sprachen. Die Anwendung läuft mit einem grafischen Frontend und ist im Gegensatz zu den anderen Continuous Integration Systemen recht komfortabel zu bedienen. Denn die gesamten Einstellungen werden über die grafische Oberfläche gehandhabt, wie z.b. das Editieren der Konfigurationsdatei bis hin zur Kommunikation zwischen dem Repository und AnthillPro. Das Tool veranschaulicht auch die ganzen Ereignisse mit tabellarischen Ansichten. Eine Vielzahl von Build Scripts wie Ant, Maven, Make, MSBuild und NAnt sowie auch die Zusammenarbeit mit vielen Versionskontrollsystemen werden unterstützt. 32 Stand: November

54 Folgende Versionskontrollsysteme werden nach Angaben von AnthillPro unterstützt: AccuRev Mercurical CVS ClearCase Base Dynamic View Perforce Harvest Team Foundation Server PVCS Dimensions Visual SourceSafe StarTeam MKS Source Integrity Synergy Das Konzept von AnthillPro Das Konzept von AnthillPro ist mit allen anderen Continuous Integration Systemen bis auf einen Arbeitsablauf identisch. Der einzige Unterschied besteht in der Vergabe von Build-Nummern (siehe P. 3 und 4). 1. Regelmäßiges Prüfen des Repositories. Quelltexte, die sich im Repository befinden, werden in bestimmten Zeitabständen auf Änderungen hin überprüft. Falls keine Änderungen festgestellt werden, werden alle weiteren Abläufe eingestellt und das System überprüft erneut nach Ablauf der der bestimmten Zeit auf Änderungen. Wird eine Änderung festgestellt, so beginnt das System mit dem zweiten Schritt. 2. Aktualisieren des Arbeitsbereiches: Die Änderungen bzw. die neue Version und die Änderungshistorie werden aus dem Repository geholt. 3. Inkrementieren der Build-Nummer: Um diesen Build identifizieren zu können, erhält dieser eine Nummer. 4. Identifikation der Quelltexte: Die Build-Nummer wird in dem Repository unter der letzten Änderung vermerkt. Dadurch können alle Build-Vorgänge, die jemals produziert wurden, jederzeit wieder rekonstruiert werden. 5. Build: Erst in diesem Schritt werden die Änderungen mit einer ausgewählten Scriptsprache übersetzt. Falls ein Modultest eingebaut wurde, wird dieser nach der Übersetzung getestet. 6. Freigabe: Falls das Übersetzen bzw. der Modultest erfolgreich war, wird eine Freigabe erteilt, um die Dateien an einem definierten zentralen Punkt ablegen zu können. 7. Information: Es wird eine an registrierte Benutzer verschickt, ob die Übersetzung bzw. der Modultest erfolgreich oder nicht erfolgreich gelaufen ist. 54

55 7.6.4 Continuous Integration mit CruiseControl CruiseControl ist ein Java-basiertes Framework 33 für das Erstellen eines kontinuierlichen Build-Prozesses. Das Tool wurde von den Angestellten der Firma ThoughtWorks entwickelt, welches später zu einem eigenständigen Framework weiterentwickelt wurde. CruiseControl steht unter freier Lizenz zur Verfügung. Mit den erweiterbaren Plugins zur Nutzung von Ant können auch automatische Benachrichtigungen per Mail an die Entwickler verschickt werden, um Informationen über den Build-Prozess zu vermitteln. Zusätzlich gibt es auch Schnittstellen, um weitere Programmierwerkzeuge einzubinden. Da CruiseControl ein Java-basiertes Framework ist, unterstützt es auch nur die Entwicklungsplattform J2EE. Deshalb wurde CruiseControl für zwei weitere Plattformen erweitert, CruiseControl.NET für.net-plattformen und CruiseControl.rb für Ruby/Rails- Plattformen. Die Entwicklungsplattform.NET von Microsoft kann anders als J2EE 34 von der Laufzeitumgebung unterstützte Programmiersprachen ausführen, z.b. C/C++, Visual Basic oder VisualJ. Ruby dagegen ist eine höhere Programmiersprache und unterstützt mehrere Programmierparadigmen Das Konzept von CruiseControl CruiseControl besteht hauptsächlich aus zwei Kernmodulen, einer so genannten Build Loop und einem Legacy Reporting (auch Build Results JSP genannt). Die Build Loop ist für die Überwachung der Änderungen, die im Repository enthalten sind, zuständig. Wird eine Änderung entdeckt, werden die entsprechenden Builds durchgeführt und die dazugehörigen Informationen per Mail an die entsprechenden Personen übermittelt. Die Build Loop wird bei CruiseControl über eine XML-Datei (config.xml) konfiguriert. Bei CruiseControl.NET dagegen heißt die Datei ccnet.config. Zusätzlich zu der - Benachrichtigung wird eine log-datei generiert, die einsehbar ist und von der Build Results 33 Ein Framework wird in der Softwaretechnik verwendet. Es stellt nur ein Programmiergerüst dar und kein fertiges Programm. Der Entwickler benutzt dieses und entwickelt innerhalb dieses Rahmens eine Anwendung. 34 Java Platform, Enterprise Edition. 35 Ist das zugrunde liegende Prinzip einer Programmiersprache. 55

56 JPS verwendet wird. Die Build Results JPS wurde für die Visualisierung der Ergebnisse der Build Loop entwickelt. Sie ist eine Webanwendung, welche die Anzeige der Build-Ergebnisse in einem Webbrowser wiedergeben soll. Sie ermöglicht damit eine komfortable Ansicht Probleme während der Installation Probleme und nicht geplante Ereignisse sind keine Seltenheit in der Informatik. Im Folgenden möchte ich diese Probleme näher erläutern, da sie auch ein Kriterium dafür sind, diese Tools nicht einzusetzen. Eines der größeren Probleme bestand darin, die Konfigurationsdatei von CruiseControl.NET (CC.NET) auf die jeweiligen Versionskontrollsysteme anzupassen. Denn die Konfigurationen sind mit jedem Versionskontrollsystem anders zu handhaben. Die Konfigurationsdatei befindet sich bei CC.NET unter dem Installationspfad (gewöhnlich C:\Programme\CruiseControl.NET) und ist darin unter dem Namen ccnet.config zu finden. In dieser Datei müssen Informationen über das Versionskontrollsystem angegeben werden. Die genaue Problematik entstand während der Einrichtung von Visual SourceSafe. Und zwar verlangt CC.NET in der ccnet.config-datei (nur für VSS) eine Angabe der Zeitzone des Repositories. Wird diese nicht angegeben, so werden auch Änderungen im Repository von CC.NET nicht erkannt. Wenn keine Angaben über die Zeitzone gemacht werden, wird auch keine Fehlermeldung ausgegeben, wodurch sich die Fehlersuche erschwerte. Ein anderes Problem ergab sich während der Apache2 Server-Installation für Subversion. Subversion unterstützt nicht alle Apache-Versionen, sondern nur bestimmte. Somit müssen unter Umständen auch ältere Versionen von Subversion verwendet werden. Aber nach Angaben von Subversion gibt es Versionen, die die Installation des Apache2 Servers erkennen und sich automatisch einrichten. Leider hat diese Option in meinen Tests nicht funktioniert und ich musste die Konfigurationen selbst manuell in der Konfigurationsdatei des Apache2 Servers durchführen. In der Konfigurationsdatei müssen bestimmte Module von Subversion 36 Stand November [18] 56

57 eingebunden und die Pfadangabe vom Subversion Repository angegeben werden. Um die Kompatibilität der Tools untereinander zu gewährleisten, ist es somit unumgänglich, die verschiedenen Versionen zu installieren und zu testen. 7.8 Fazit der Anforderungsanalyse Das Ergebnis der gestellten Anforderungen für die verschiedenen Versionskontrollsysteme ist recht eindeutig ausgefallen. Dieses ist jedoch nicht zu verallgemeinern, denn die Anforderungen waren GIP mbh-spezifisch. Subversion und das MKS Integrity Suite sind sehr umfangreiche Versionskontrollsysteme im Gegensatz zu VSS. Sie bieten viele Funktionen, die das VSS nicht unterstützt. Fakt ist aber, dass diese Funktionen in diesem Umfang nicht benötigt werden und damit auch überflüssig sind. Ein großer Nachteil von MKS Integrity ist, dass die Lizenzgebühren sehr hoch sind. Subversion dagegen ist zwar frei verfügbar, aber um es umfassend zu betreiben, müssen externe Tools wie RapidSVN oder tortoisesvn (GUI) und ein Apache2 Server installiert werden. Auch wenn diese Werkzeuge für das Arbeiten mit Subversion optimiert wurden, existieren dennoch Kompatibilitätsprobleme zwischen den verschiedenen Versionen. Damit steigt auch der Konfigurationsaufwand. Ein großer Vorteil von VSS ist, dass es momentan von der Entwicklung (PView) genutzt wird und dadurch der Schulungsaufwand wegfällt. Als Continuous Integration Systeme wurden nur zwei Tools in die engere Auswahl genommen, AnthillPro und CC.NET. Aus Zeitmangel konnte ich AnthillPro nicht so ausführlich wie das CC.NET mit jedem einzelnen Versionskontrollsystem testen. Trotz größerer Probleme während der Konfiguration von CC.NET ist das Tool hinsichtlich seiner Funktionen sehr ausgereift. Offensichtlich ist aber auch, dass AnthillPro mehr Funktionen bietet als CC.NET. Aber wenn man das Preisleistungsverhältnis betrachtet, erfüllt CC.NET die Anforderungen der GIP auch ohne eine Lizenzgebühr im Vergleich zu AnthillPro. Nach einer umfangreichen Konfiguration von CC.NET läuft es recht stabil und benötigt keine weiteren manuellen Eingriffe. 57

58 8 Feinkonzept 8.1 Aufbau des Feinkonzepts Mit dem Grobkonzept wurde ein Fundament erstellt, auf dem aufgebaut werden kann. In Bezug darauf wurde die Anforderungsanalyse erstellt, welche die Baumaterialien bestimmen soll. Letztendlich fehlt nur noch der Bauplan, dass mit dem Feinkonzept erstellt werden soll. Um das Ganze einfacher und verständlicher zu gestalten, wird der Bauplan (Feinkonzept) in einzelne Bereiche aufgeteilt. Zuerst wird die Verbindung zwischen Cluj und Offenbach geschildert, dann das Continuous Integration System bzw. die Zusammenarbeit zwischen dem Repository und dem Continuous Integration System und schließlich das Deployment. Da das Feinkonzept einen Prototyp darstellen soll, werden die technischen Details erst im nächsten Schritt, im achten Kapitel Implementierung, beleuchtet. 8.2 Verbindung zwischen Cluj und Offenbach Da die PView-Entwicklung auf Nearshoring basiert, sitzen die Entwickler in Rumänien. Es muss also eine Möglichkeit geschaffen werden, das System so aufzubauen, dass die Entwickler uneingeschränkt arbeiten können, als würden sie in Offenbach bei der GIP sitzen. Die Idee aus dem Grobkonzept bestand darin, die Verbindung zwischen Cluj und Offenbach über eine VPN-Verbindung zu ermöglichen. Eine VPN wird sehr häufig zum Verbinden von externen Rechnern mit dem lokalen Netzwerk verwendet. Die Voraussetzung ist lediglich eine Internetverbindung, denn das Internet dient als ein Transportmedium. Dabei müssen nicht einmal hardwaretechnische Eingriffe erfolgen, denn eine VPN-Verbindung ist rein Softwaretechnisch zu lösen. Heute gibt es viele Software-Produkte, die sogar solch eine Leistung kostenlos bereitstellen. Der Hintergrund einer VPN-Verbindung ist natürlich, die Datenvertraulichkeit aufrechtzuerhalten, auch wenn zwischen den beiden Standpunkten eine weite Entfernung liegt. Die Entwickler sollen aus Cluj auf lokale Ressourcen im GIP- Netzwerk zugreifen können, ohne den Dateninhalt während der Kommunikation preiszugeben. Der Vorteil hierbei ist, dass solch eine Verbindung zwischen Cluj und Offenbach bereits existiert und sehr stabil läuft. Es wird also keine neue VPN-Verbindung aufgebaut, sondern die vorhandene benutzt. Die VPN-Verbindung wird über eine Vertrauensbasis zwischen den Domain Controllern 37 in Cluj und Offenbach gebildet. Somit haben die Benutzer aus Cluj Zugriff auf freigegebene Laufwerke und können auf Verzeichnisse bzw. Dateien zugreifen. Mit der Anforderungsanalyse wurde festegelegt, mit welchem Versionskontrollsystem gearbeitet wird. Visual SourceSafe, für welches ich mich auf Grund der Anforderungsanalyse entschieden habe, arbeitet auf Dateisystemebene. Diese Arbeitsweise erleichtert die Einstellungen der Zugriffsrechte über die VPN-Verbindung. Das Repository wird als ein Verzeichnis dargestellt. Damit kann dieses Verzeichnis über die Windows-Freigabe für die jeweiligen Entwickler freigegeben und über die Zugriffsrechte können entsprechende Rechte 37 Der Domain Controller ist ein Server im Netzwerk, welcher für die Authentifizierung von Computern und Usern steht. 58

59 vergeben werden. Somit ist sichergestellt, dass unbefugte netzinterne Benutzer keinen Zugriff auf das Repository haben. Das Repository wird auf einem Netzlaufwerk mit Visual SourceSafe erstellt. Alle Netzlaufwerke werden täglich gesichert; damit ist es nicht notwendig, das Repository zusätzlich zu sichern. Die Erstellung eines Repositories wird im achten Kapitel Implementierung erläutert. 8.3 Continuous Integration mit CruiseControl.NET Mit dem Erstellen des Repositories muss der gesamte Quellcode eingepflegt werden. Der Inhalt des Repositories bzw. der Quellcode von PView besteht aus elf Projekten, die untereinander gewisse Abhängigkeiten aufweisen. Jedes Projekt wird im Repository als ein Ordner abgebildet, so wie es auch bei vielen Entwicklungsumgebungen der Fall ist. Wie das Repository zu befüllen ist, wird ebenfalls im Kapitel Implementierung erläutert. Nachdem das Repository erstellt und mit dem Source Code belebt worden ist, können die Entwickler ihre Änderungen ein- und auschecken. Damit beginnt auch die Aufgabe des Continuous Integration Systems CruiseControl.NET. Die Anwendung CC.NET soll auf einem Server im GIP-Netzwerk installiert werden, auf dem auch später das Deployment durchgeführt wird. Der Server muss sich im Netzwerk befinden, da dieses einen permanenten Zugriff auf das Repository benötigt. Nach der Installation muss CC.NET über die Konfigurationsdatei anhand eines Build Scripts konfiguriert werden, denn die gesamte Steuerung erfolgt über die Konfigurationsdatei. Die Installation und Konfiguration werden ebenfalls im achten Kapitel Implementierung detaillierter erläutert. Das System soll das Repository stündlich auf Änderungen hin durchsuchen. Falls Änderungen festgestellt werden, soll der Source Code neu kompiliert werden. Es macht auch nur Sinn, funktionale Blöcke in das Repository einzuchecken. Falls aber trotzdem Fehler während des Kompilierens entdeckt werden, sollten die Entwickler per benachrichtigt werden. 59

60 8.4 Deployment Der Begriff Deployment stammt aus dem Englischen und wird in der Informatik mit dem Begriff Softwareverteilung gleichgesetzt. Unter Softwareverteilung stellt man sich lediglich einen Prozess vor, bei dem eine Software auf einem PC oder Server installiert wird. Generell ist es aber so, dass die normalen Anwender nicht das Fachwissen haben oder überhaupt nicht befugt sind, die Software zu installieren. In den meisten Firmen wird diese Aufgabe z.b. von den Administratoren übernommen. Steigt aber die Anzahl der Installationen, so wird auch der Aufwand immer größer. Also ist es sinnvoll, ab einer gewissen Anzahl von PCs, die Tätigkeit der Softwareverteilung zu automatisieren. Eine automatische Softwareverteilung bringt z.b. folgende Vorteile mit sich. Die Anwender werden während den Installationen weniger bei ihrer Arbeit gestört, weil die Arbeitsunterbrechungen damit reduziert werden. Die Verteilung der Software erfolgt viel schneller, so erhalten auch z.b. PCs oder Server schneller ihre kritischen Updates. Durch die einheitlichen Softwareinstallationen werden die Supportaufkommen auch weniger beansprucht. Der Zeitaufwand für die Installationen wird deutlich reduziert, da das Installationsverfahren automatisch und von einem zentralen Punkt aus ausgeführt wird. In diesem Kapitel wird der automatische Deploy-Mechanismus in Bezug auf die jeweilige Test- bzw. Entwicklungsumgebung hin erläutert. Das Continuous Integration System hat bisher den Quellcode im Repository in bestimmten Zeitabständen auf Änderungen hin überprüft. Falls Änderungen festgestellt wurden, wurde der Quellcode kompiliert und Binärdateien in Form von dlls- oder exe-dateien erzeugt. Die generierten Dateien wurden schließlich in einer bestimmten Verzeichnisstruktur abgelegt. Das Deployment bzw. Update bezieht sich lediglich auf die Weiterverarbeitung der kompilierten Binärdateien. Diese neuen Binärdateien stellen letztendlich das nächste Update oder Service Pack dar. Da aber PView in Verbindung mit einer Kunden- und System-Datenbank steht, wird nicht nur PView aktualisiert, sondern auch in bestimmten Situationen die Kunden- und System-Datenbank. Somit sind drei mögliche Update-Varianten möglich. Client Update Datenbank-Update Client und Datenbank-Update Ein Client Update bezieht sich nur auf Änderungen in der Anwendung selbst. Der Grund für ein Client Update könnte z.b. sein, dass Fehlerkorrekturen in der Anwendung nötig sind, dass eine Funktion in der Businesslogik erweitert oder neu hinzugefügt wird. Client Updates werden nur mit dll-dateien durchgeführt. D.h., die alten dll-dateien werden mit neuen überschrieben. Alle durchgeführten Änderungen sind damit in diesen dll-dateien vorhanden. Sind aber jetzt keine Änderungen in der Anwendung nötig, sondern nur an der Datenbank, so wird das mit einem Datenbank-Update behoben. Es kann auch Situationen geben, wo nur ein Datenbank-Update durchgeführt werden muss. Ein mögliches Datenbank-Update könnte z.b. eine einfache Änderung des Feldtyps sein. 60

61 8.4.1 Update der Test- bzw. Entwicklungsumgebung Der automatische Deploy-Mechanismus erfolgt über eine selbst (GIP-intern, zum großen Teil im Rahmen der Diplomarbeit) entwickelte Anwendung. Die Anwendung wurde mit der Programmiersprache C# 38 auf der.net-softwareplattform entwickelt. Die Anwendung arbeitet die erforderlichen Arbeitsschritte in einer bestimmten Reihenfolge ab und installiert damit die aktuellen Binärdateien auf die jeweilige Umgebung bzw. Datenbank. Die Arbeitsschritte bestehen aus dreizehn verschiedenen Arbeitsabläufen, die je nach Update- Variante in unterschiedlicher Konstellation abgearbeitet werden müssen. 1. Endsprechende isolierte Umgebung (Test- bzw. Entwicklungsumgebung) sperren. 2. User, die in der Umgebung noch aktiv sind, abmelden. 3. Deregistrieren der dlls. 4. Aktuelle dlls sichern. 5. Kopieren der neuen dlls in das entsprechende Verzeichnis. 6. Registrieren der dlls. 7. System- und Kundendatenbank sichern und evtl. auch zippen. 8. Updateprogramm ( pbvupdate.exe ) kopieren und starten (Test- bzw. Entwicklungsumgebung). 9. Updateprogramm mittels ini-datei in der entsprechenden isolierten Umgebung starten. 10. Updateprotokoll in das entsprechende Verzeichnis kopieren und umbenennen. 11. Anwendungsbeschreibung der entsprechenden (Test- bzw. Entwicklungsumgebung) anpassen. 12. Gesperrte isolierte Umgebung wieder freigeben. 13. Benutzer per benachrichtigen, dass die entsprechende Umgebung wieder genutzt werden kann. Wird z.b. nur ein Client Update durchgeführt, so werden nur die Schritte von eins bis sechs und elf bis dreizehn durchgeführt. In der nachfolgenden Tabelle sind die Arbeitsabläufe für die verschiedenen Update-Varianten aufgelistet. Nr. Arbeitsabläufe Client Update DB- Update Client und DB- Update 1. Endsprechende isolierte Umgebung sperren X X X User, die in der Umgebung noch aktiv sind, 2. abmelden X X X 3. Deregistrieren der dlls X X 4. Aktuelle dlls sichern X X Kopieren der neuen dlls in das entsprechende 5. Verzeichnis X X 38 C# greift Konzepte der Programmiersprachen Java, C++, SQL, C sowie Delphi auf. C# zählt zu den objektorientierten Programmiersprachen und unterstützt sowohl die Entwicklung von sprachunabhängigen.net-komponenten als auch COM-Komponenten für den Gebrauch mit Win32-Applikationen. Quelle: Stand Januar [19] 61

62 6. Registrieren der dlls X X System- und Kundendatenbank sichern und evtl. 7. auch zippen X X 8. Updateprogramm ( pbvupdate.exe ) kopieren und starten X X 9. Updateprogramm mittels ini-datei in der entsprechenden isolierten Umgebung starten X X 10. Updateprotokoll in das entsprechende Verzeichnis kopieren und umbenennen X X 11. Anwendungsbeschreibung der entsprechenden Umgebung anpassen X X X 12. Gesperrte isolierte Umgebung wieder freigeben X X X Benutzer per benachrichtigen, dass die 13. entsprechen Umgebung wieder genutzt werden kann X X X Erläuterung der Arbeitsschritte Schritt 1 und 2: Wie bereits erwähnt, ist PView auf zwei isolierten Umgebungen (Citrix Presentation Server) installiert. Die Anwender, die PView in Anspruch nehmen, arbeiten auf einer dieser isolierten Umgebungen. Zusätzlich existiert auf einem PView-Testrechner (PView-demo-01) eine lokale Installation von PView. Diese lokale Installation hat mit den Installationen auf der Citrix- Umgebung nichts zu tun. Um das Update auf der isolierten Umgebung erfolgreich durchführen zu können, dürfen keine Benutzer aktiv an dieser Umgebung tätig sein. Dafür muss zuerst die jeweilige Umgebung für weitere Anmeldungen gesperrt werden. Damit soll sichergestellt werden, dass sich während des Updates keine weiteren Benutzer anmelden können. Weiterhin müssen sich alle Benutzer, die noch aktiv sind, abmelden. Dazu werden alle noch angemeldeten Benutzer über die Citrix-Umgebung per Sofortnachricht angeschrieben und aufgefordert, sich umgehend abzumelden. Falls sich die Benutzer nach einer bestimmten Zeit nicht abgemeldet haben, werden diese durch eine Zwangsabmeldung abgemeldet. Der Grund, warum sich die Benutzer während eines Updates abmelden müssen, hängt mit den Zugriffen auf die PView-Komponenten zusammen. Wenn die Komponenten durch den Benutzer in Verwendung sind und in der gleichen Zeit das Update darauf zugreifen will, wird der Zugriff verweigert. Damit wird das Update unterbrochen. Also dürfen während eines Updates keine gleichzeitigen Zugriffe auf PView- oder Datenbank-Komponenten erlaubt werden, sondern nur exklusive Zugriffe. Aus diesem Grund ist es zwingend erforderlich, alle angemeldeten User abzumelden und keine weiteren Anmeldungen während des Updates zu gestatten. 62

63 Schritt 3 und 6: PView COM-Komponenten 39 (dll-dateien) müssen im System registriert sein. Die Registrierung erfolgt eigentlich automatisch mit der Installation von PView. Mit einem Update ändern sich aber die dlls von PView. Um jetzt dem System die geänderten COM- Informationen und Interfaces bekannt zu geben, müssen die alten dlls erst einmal deregistriert werden. Anschließend werden die alten dlls durch die neuen ersetzt (Schritt 5) und müssen danach wieder dem System bekannt gegeben werden bzw. registriert werden. Schritt 4 und 5: In diesen beiden Schritten werden die deregistrierten (Windows registry) dlls, bevor sie mit den neuen überschrieben werden, gesichert. Falls die neuen dlls fehlerhaft sind, kann der alte Stand wieder hergestellt werden. Schritt 7: Die Daten von PView befinden sich in zwei Datenbanken, in der System- und der Kundendatenbank. Werden jetzt nicht nur Programmkomponenten, sondern auch Teile der Datenbank aktualisiert (Datenbank-Update), so müssen diese auch vor dem Aktualisieren gesichert werden. Schritt 8: Das Updateprogramm ist für die Aktualisierung der entsprechenden Datenbank notwendig und wird auch nur durchgeführt, falls ein Datenbank-Update bzw. Client und Datenbank- Update vorliegt. Das Updateprogramm wird explizit zusätzlich zu den Binärdateien mitgeliefert und ist eine ausführbare Windows-Datei, welche die Bezeichnung pbvupdate.exe hat. Um ein Datenbank-Update durchführen zu können, muss die Datei pbvupdate.exe in das Installationsverzeichnis von PView kopiert werden, was sich in der Regel unter C:\Programme\KIDICAP\PView befindet. Vor dem Ausführen des Updates ( pbvupdate.exe ) wir durch das Registrieren der entsprechenden Umgebung die jeweilige Datenbank aktualisiert. Für die Registrierung (lokal) der Testumgebung wird die Datei register_test_current.reg 40 und für die Registrierung der Entwicklungsumgebung wird die Datei register_dev_current.reg ausgeführt. Mit der Registrierung werden die SQL- und Datenbankinformationen der jeweiligen Datenbank in die registry 41 geschrieben. Das Updateprogramm holt sich wiederum diese Informationen aus der registry und weiß somit, welche Datenbank upgedatet werden soll. Schritt 9: Im fünften Schritt wurden die Programmkomponenten von PView für die lokale Installation aktualisiert. In diesem Schritt erfolgt dieselbe Aktion mit den isolierten Umgebungen von 39 Das Component Object Model ist eine von Microsoft entwickelte Plattform-Technologie, um unter dem Betriebssystem Windows Interprozesskommunikation und dynamische Objekterzeugung zu ermöglichen. COMfähige Objekte sind sprachunabhängig und können sowohl DLLs als auch ausführbare Programme sein. Jede COM-Komponente bietet ein Interface an, welches nach erfolgreicher Instanzierung dazu verwendet werden kann, die angebotenen Funktionen der COM-Komponente einzusetzen. Somit soll COM eine leichte Wiederverwendung von bereits geschriebenem Programmcode, auch über (Windows-)Betriebssystemgrenzen hinweg, möglich machen. Stand März [20] 40 *.reg-dateien sind Windows-spezifische, ausführbare Dateien, die Einträge in die registry vornehmen können. 41 Ist eine Windows-Registrierungsdatenbank, in der Informationen von Windows und auch Informationen von anderen installierten Programmen gespeichert werden. 63

64 PView auf dem Citrix Presentation Server. Wie bei einer lokalen Installation gibt es auch bei einer isolierten Installation ein Installationsverzeichnis. Auch hier werden die jeweiligen Komponenten erstmals deregistriert; die alten Komponenten werden gesichert, durch die neuen ersetzt und schließlich wieder registriert. Dieser Vorgang wird einmal für die isolierte Testumgebung und einmal für die isolierte Entwicklungsumgebung durchgeführt. Schritt 10: Das Updateprogramm erzeugt während des Datenbank-Updates ein Ereignisprotokoll. Dieses wird vom Fachbereich ausgewertet. Das Ereignisprotokoll wird in einem Temp-Ordner im tiefen Windowsverzeichnis erzeugt. Aufgrund der einfachen Handhabung mit dem Dokument wird das Ereignisprotokoll in eine zentrale Verzeichnisstruktur verschoben und mit folgender Benennung abgelegt: update_[umgebung]_[version].txt Schritt 11: Jede isolierte Umgebung hat eine Anwendungsbeschreibung, welche ein einfaches Textfeld ist und zur Beschreibung der jeweiligen Anwendung dient. Darin sind Informationen wie die Version, der Datenbank-Updatestand und das Datum des letzten Updates enthalten. Mit jedem Update verändern sich selbstverständlich auch die Informationen und sie müssen immer manuell eingepflegt werden. Mit dem automatischen Deploy-Mechanismus soll in diesem Schritt die manuelle Änderung an der Anwendungsbeschreibung automatisiert werden. Schritt 12: Nach einem erfolgereichen Update auf die jeweilige Umgebung wird diese auch wieder für die Anwender freigegeben. 64

65 Schritt 13: So wie alle anderen Schritte 1 bis 12 wurde auch die Benachrichtigung der Mitarbeiter, dass das Update erfolgreich abgeschlossen wurde, manuell erledigt. Mit dem Deployment soll auch die Benachrichtigung über die entwickelte C#-Anwendung erfolgen. 65

66 9 Implementierung 9.1 Aufbau der Implementierung Dieses Kapitel ist die Fortsetzung bzw. die Umsetzung des vorherigen Kapitels Feinkonzept. Im Folgenden soll die Implementierung dieses Projektes wiedergeben werden. Dabei werden die Anwendungen und Tools aus der Anforderungsanalyse verwendet und das Gesamtsystem mit dem Bauplan aus dem Feinkonzept aufgebaut. Zu der Implementierung gehören sowohl die Installation als auch die Konfiguration der einzelnen Anwendungen und Tools. 9.2 Installation und Konfiguration von Visual SourceSafe 2005 Die Installation lässt sich über die Ausführungsdatei setup.exe starten. Unmittelbar nach dem Ausführen der Setup-Datei erscheint folgende Abbildung. Auf der linken Seite wird angezeigt, welche Programme VSS benötigt, ggf. sind diese schon vorinstalliert oder werden mit diesem Setup installiert. Auf der rechten Seite dagegen steht der Lizenzvertrag, welcher akzeptiert werden muss. Dadrunter sind fünf Felder um den Product Key einzutragen. Die Installation kann schließlich durch Eingabe eines Namens weitergeführt werden. Als Nächstes erscheint folgende Abbildung. 66

67 In diesem Schritt stehen drei auswählbare Installationsfunktionen zur Verfügung. Wir wählen die Standard -Installation aus, da in gewünschten Situationen die zusätzlichen Funktionen nachinstalliert werden können. Auf dem rechten Abschnitt kann der Installationspfad ausgewählt werden und im unteren Feld wird der erforderliche Festplattenspeicher angezeigt. Durch das Klicken auf den Button Installieren beginnt die Installation. Wie die Abbildung zeigt, wird hier nur der Installationsstand angezeigt. Nach erfolgreicher Installation wird die Installation endgültig abgeschlossen. 67

68 9.2.1 Erstellen eines Repositories mit Visual SourceSafe 2005 Das Repository wird in der VSS-Umgebung als Datenbank bezeichnet, da die Struktur einer Datenbank ähnelt. Ich werde auf Grund der Übersichtlichkeit weiterhin den Begriff Repository verwenden. Um ein Repository zu erstellen, wird das Administrationstool von VSS benötigt, was standardmäßig mit installiert wird. Das Repository wird im Administrationstool und im Menü-Punkt Datei Neue Datenbank erstellt. Es startet einen Assistenten, der die Erstellung eines Repositories Schritt für Schritt durchführt. Als Erstes wird der Speicherort des Repositories festgelegt. Wichtig ist hier, dass der Speicherort eine Windowsfreigabe enthält. Der angegebene Pfad kann entweder ein lokaler Pfad oder ein UNC-Pfad 42 sein. Als nächster Schritt wird ein Anzeigename für das Repository benötigt. Es sollte ein schlüssiger und aussagekräftiger Name verwendet werden. 42 Ein UNC-Pfad ist eine Netzwerkfreigabe bzw. ein Netzwerkpfad und wird folgendermaßen angesprochen: \\Servername\Freigabename\Pfad 68

69 Schließlich wird die Arbeitslogik bestimmt, in der Änderungen in das Repository eingecheckt werden. Auswählbar sind Sperren-Ändern-Entsperren und Kopieren-Ändern- Zusammenführen. Wir wählen aufgrund der Anforderung Sperren-Ändern-Entsperren. Damit wird auch schon das Erstellen eines Repositories abgeschlossen. 69

70 Bei einem freigegebenen Repository müssen die Freigabeberechtigungen unbedingt noch nachgesetzt werden. Dazu muss das Verzeichnis, in dem sich das Repository befindet, freigegeben werden, damit die Entwickler auch über das Netzwerk darauf zugreifen können. Die Lese- und Schreib-Berechtigungen für dieses Verzeichnis dürfen nur explizit für die Entwickler, das Konfigurationsmanagement und für den Fachbereich gesetzt werden. Die Benutzergruppe Everyone, welche standardmäßig dazu berechtigt ist, muss entfernt werden. Zum Schluss müssen noch die Benutzer erzeugt werden, die mit VSS auf das Repository zugreifen dürfen. VSS erzeugt standardmäßig einen Gastuser, Administrator und den aktuellen Windowsuser, der als Lese- und Schreibberechtigter fungiert. Über den Menüpunkt Benutzer Benutzer hinzufügen können beliebig viele Benutzer bzw. Entwickler angelegt werden. Zum Anlegen eines Benutzers werden lediglich der Benutzername und ein Kennwort benötigt. Die Zugriffsrechte werden über den Menüpunkt Extras Benutzerrechte für Benutzer geändert. Somit wurden ein leeres Repository sowie Benutzter, die mit bestimmten Zugriffsrechten auf dem Repository abreiten dürfen, angelegt. Nun muss das Repository mit Inhalt gefüllt werden. Dazu muss man zum VSS Explorer wechseln. Der Explorer besteht aus drei geteilten Arbeitsfeldern. Die linke Seite des Explorers zeigt die Verzeichnisstruktur und die rechte Seite dagegen gibt den Inhalt der Verzeichnisse an, wie im normalen Windows Explorer. Nur das dritte Arbeitsfeld ist nicht wie im gewohnten Windows Explorer-Umfeld gestaltet. Dieses gibt nur die durchgeführten Aktionen wieder und dient ausschließlich zur Einsicht der durchgeführten Arbeitsschritte während einer Sitzung. Bevor das Repository mit dem Quellcode gefüllt werden kann, sollte aufgrund der Übersicht ein neues Projekt erzeugt werden. Mit dieser Vorkehrung ist es möglich, mehrere Projekte parallel in einem Repository zu verwalten. Ein Projekt wird im Explorer gewöhnlich über den Menüpunkt Datei Projekt erstellen konzipiert. Der Projektordner kann jetzt per drop & drag mit dem Quellcode gefüllt werden. 70

71 Schließlich ist das Repository erstellt, mit dem Quellcode bestückt und die einzelnen Benutzer angelegt worden. Nun fehlt nur noch die Konfiguration der Arbeitsplätze der einzelnen Entwickler. Nach erfolgreicher Installation von VSS muss das erstellte Repository auf den Arbeitsrechner der jeweiligen Entwickler hinzugefügt werden. Und zwar wird direkt nach dem ersten Start des VSS Explorers nachgefragt, mit welchem User und mit welchem Repository verbunden werden soll. Da die Benutzer in unserem Fall angelegt und entsprechend berechtigt wurden, kann der Zugriff auf das Repository erfolgen. Eine wichtige Konfiguration auf den Entwickler-Arbeitsplätzen stellt noch die Einrichtung einer lokalen Arbeitskopie dar. Diese wird mehr oder weniger auch automatisch von VSS erzeugt, da beim ersten Auschecken nach einem lokalen Arbeitsordner gefragt wird und diese direkt im Anschluss danach erstellt werden kann. Mann muss hier zwischen dem Bestand auf dem Repository und dem Bestand der lokalen Arbeitskopie unterscheiden. Denn Änderungen können nur auf der lokalen Arbeitskopie durchgeführt werden. 71

72 9.3 Installation und Konfiguration von CruiseControl.NET Die Installation von CC.NET ist recht komfortabel. Das Tool wird als eine ausführbare Windowsapplikation geliefert. Mit Hilfe eines Installationsassistenten wird die Installation schrittweise durchgeführt. Der Installationspfad befindet sich in der Regel unter C:\Programme\CruiseControl.NET. Dieses Verzeichnis enthält den Ordner Server, in dem sich die Konfigurationsdatei ccnet.config befindet. Die Konfigurationsdatei soll so konfiguriert werden, dass jedem Stunde im Projektordner (welche sich im Repository befinden) nach Modifikationen gesucht wird. Falls Änderungen in einem Projekt festgestellt werden, soll dieses kompiliert werden. Mit folgendem Flussdiagramm soll die Funktionsweise von CruiseControl.NET veranschaulicht werden. Die ccnet.config ist eine in XML geschriebene Konfigurationsdatei. Die Datei muss zumindest Angaben über das Repository, Projekt, Kompilierinformationen und den Überprüfungszyklus enthalten. Die gesamte Konfiguration findet innerhalb eines XML- Wurzelelements statt, so wie es ein wohlgeformtes XML-Dokument vorweist. Folglich wird ein Teil der Konfigurationsdatei abgebildet, anhand der Datei die Konfiguration erläutert werden soll. 1. <cruisecontrol> 2. <project name="ccustom.project" applylabel="false" autogetsource="true" > 3. <sourcecontrol type="vss"> 4. <executable>c:\programme\microsoft Visual SourceSafe\SS.EXE</executable> 5. <project>$/businessobjects/ccustom</project> 6. <username>oemer</username> 7. <password>123</password> 8. <ssdir>d:\repository\</ssdir> 9. <workingdirectory>d:\workingfolder\pview Version _31050\821_31050\BusinessObjects\CCustom</workingDirectory> 11. <culture>en-us</culture> 12. <cleancopy>true</cleancopy> 13. <timeout units="minutes">10</timeout> 14. </sourcecontrol> 72

73 15. <triggers> 16. <intervaltrigger seconds='3600' /> 17. </triggers> <tasks> 20. <nant> 21. <executable>c:\programme\nant-0.85\bin\nant.exe</executable> 22. <buildfile>d:\workingfolder\pviewbuild\default.build</buildfile> 23. <targetlist> 24. <target>build.ccustom.project</target> 25. </targetlist> 26. </nant> 27. </tasks> 28. </project> 29. </cruisecontrol> Da mehrere Projekte im Repository überwacht werden sollen, muss für jedes Projekt eine Bezeichnung der Tags 43 angegeben werden. Im Beispiel wird das Projekt ccustom.projekt beschrieben. Da elf Projekte überwacht werden, muss auch der project -Block elfmal erstellt werden. In der zweiten Zeile wird diesem Projekt der Name ccustum.projekt zugewiesen. Damit können mehrere Projekte innerhalb eines Wurzelelements erzeugt werden. Die dritte Zeile gibt an, um welches Versionskontrollsystem es sich hierbei handelt. In diesem Fall ist es Visual SourceSafe. Als Nächstes wird die Angabe des Pfads der ausführbaren Programmkomponente von VSS benötigt. Der Tag project gibt an, in welcher Hierarchie sich das Projekt im VSS befindet. In der sechsten Zeile wird ein username für VSS benötigt. Dieser sollte Lese- und Schreibrechte besitzen, da es zu Problemen bezüglich der Zugriffsrechte kommen könnte. Da üblicherweise jeder Anmeldename auch ein Passwort erfordert, wird hier auch eines angefordert. Der Tag ssdir benötigt die Pfadangabe der srcsafe.ini-datei, welche sich immer im Verzeichnis des Repositories befindet. Diese Datei gibt z.b. Auskunft darüber, wo sich die Daten befinden, wo die Benutzer hinterlegt sind etc. Als Nächstes wird der Arbeitsordner von VSS bestimmt. Die Angabe ist aber optional, denn falls dieser nicht angegeben wird, wird das Arbeitsverzeichnis automatisch erzeugt. Der nächste Tag ist aber eine Pflichtangabe; er soll darüber Auskunft geben, in welcher Sprache VSS installiert ist. Der triggers Tag bestimmt den Zyklus, in dem das CC.NET die Überprüfung durchführt. Der Wert wird in Sekunden angegeben. Die Zeilen 19 bis 27 sind für das Kompilieren des Projektes zuständig. Die Kompilierung wird anhand eines Build Scripts durchgeführt, welches durch das Tool NAnt 44 angestoßen wird. Dazu wird lediglich der Pfad zur ausführbaren NAnt-Datei angegeben. Die eigentliche Logik befindet sich im Build Script. Der Verweis zur NAnt steht in der 21. Zeile, zum Build Script dagegen in der 22. Zeile. In der 24. Zeile wird dem Build Script eine Funktion übergeben, die ausgeführt werden soll. Die komplette Konfiguration von CC.NET ist im Anhang 45 zu finden Konfiguration des Build Scripts Der Name deutet bereits auf die Tätigkeit des Bauens hin. Mit einem Build Script werden die einzelnen PView-Komponenten aus den Projekten für das Deployment gebaut und die erzeugten dll-dateien in einem Ausgabeverzeichnis ablegt. Das Script wird ebenfalls in XML erfasst. Anhand der XML Datei werden Informationen an NAnt übergeben, welches die 43 Mit einem Tag wird hier ein Block in einer XML-Datei bezeichnet. Z.B. <password>123</password> 44 NAnt ist ein Freeware Tool, das zur Automatisierung von Software Build-Prozessen dient. Es ist ein recht neues Produkt und basiert auf der.net-plattform. 45 Anhang 3: CCNET.config 73

74 Informationen wiederum ausführt. Deshalb ist es z.b. auch nicht richtig zu sagen, dass die Kompilierung vom Build Script durchgeführt wird. Denn die eigentliche Kompilierung nimmt der Compiler vor. Den Auftrag dazu bekommt der Compiler von NAnt. Das Build Script liefert nur die notwendigen Informationen an NAnt, z.b. was kompiliert wird und wo es liegt. Die vollständige Konfiguration des Build Scripts ist ebenfalls im Anhang 46 hinterlegt. Nachfolgend werden nur die wichtigsten Zeilen aus dem Build Script erläutert. 1. <target name="build.ccustom.project"> 2. <vb6 errorfile="${build.dir}/build.log" outdir="${build.dir}" 3. project="${ccustom.project}" /> 4. <call target="clean.temp.compile.files" /> 5. </target> In diesem Tag wird das Projekt ccustom gebaut. Der Name dieses Tags buil.ccustom.projekt ist identisch mit dem Tag aus der ccnet.config -Datei, denn die Aufrufe erfolgen aus der Konfigurationsdatei von CruiseControle.NET. Mit der zweiten Zeile beginnt die Kompilierung. vb6 bedeutet, dass ein Visual Basic Compiler zum Einsatz kommt und die Kompilierung durch einen VB Compiler erfolgt. Als Nächstes wird ein errorfile erzeugt, in dem die Kompilierfehler erfasst werden. Die Datei build.log wird generiert und in einer vordefinierten Verzeichnisstruktur abgelegt. Nach erfolgreicher Kompilierung wird bekanntlich eine dll-datei erzeugt, welche im selben Pfad (Ausgabeverzeichnis) wie die log-datei abgelegt wird. Mit project="${ccustom.project}" wird angegeben, um welches Projekt es sich handelt. Schließlich wird das call Tag aufgerufen, welches lediglich alle Dateien im Ausgabeverzeichnis bis auf die log-, dll- und exe-dateien löscht. 1. <target name="clean.temp.compile.files" description="loescht das Ausgabeverzeichnis der 2. Binaerdateien" > 3. <delete> 4. <fileset basedir="${build.dir}"> 5. <include name="*.*" /> 6. <exclude name="build.log" /> 7. <exclude name="*.dll" /> 8. <exclude name="*.exe" /> 9. </fileset> 10. </delete> 11. </target> Das $-Zeichen, welches hier immer wieder erscheint, ist eine Variable + Term für vordefinierte Pfade, in denen sich die Projekte oder bestimmte Ablageverzeichnisse befinden, um das Build Script übersichtlicher zu gestalten. Im Folgenden werden alle Objekte (property) aufgelistet. Verzeichnisse: <property name="main.project.dir" value="d:/projects/projekte/pview/entwicklung_aktuell"/> <property name="db.manager.project.dir" value="${main.project.dir}/dbmanager"/> <property name="kidicap.bv.project.dir" value="${main.project.dir}/kidicapbv"/> <property name="object.designer.project.dir" value="${main.project.dir}/objectdesigner"/> <property name="object.dictionary.project.dir" value="${main.project.dir}/objectdictionary"/> <property name="pbv.update.project.dir" value="${main.project.dir}/pbvupdate"/> <property name="pi.project.dir" value="${main.project.dir}/pi"/> <property name="business.objects.project.dir" value="${main.project.dir}/businessobjects"/> <property name="ccustom.project.dir" value="${business.objects.project.dir}/ccustom" /> <property name="ccustom.gip.project.dir" value="${business.objects.project.dir}/ccustom GIP"/> <property name="cdistrib.project.dir" value="${business.objects.project.dir}/cdistrib"/> <property name="cglobal.project.dir" value="${business.objects.project.dir}/cglobal"/> <property name="iface.project.dir" value="${business.objects.project.dir}/iface"/> Projekte: 46 Anhang 4: PView_default.build 74

75 <property name="db.manager.project" value="${db.manager.project.dir}/pbvdbmgr.vbp"/> <property name="kidicap.bv.project" value="${kidicap.bv.project.dir}/kidicapbv.vbp"/> <property name="object.designer.project" value="${object.designer.project.dir}/pbvdesign.vbp"/> <property name="object.dictionary.project" value="${object.dictionary.project.dir}/pbvobjdi.vbp"/> <property name="pbv.update.project" value="${pbv.update.project.dir}/pbvupdate.vbp"/> <property name="pi.project" value="${pi.project.dir}/pbviews.vbp"/> <property name="ccustom.project" value="${ccustom.project.dir}/pbvccust.vbp"/> <property name="ccustom.gip.project" value="${ccustom.gip.project.dir}/pbvccust.vbp"/> <property name="cdistrib.project" value="${cdistrib.project.dir}/pbvcdist.vbp"/> <property name="cglobal.project" value="${cglobal.project.dir}/pbvcglob.vbp"/> <property name="iface.project" value="${iface.project.dir}/pbviface.vbp"/> Bevor das Deployment beginnen kann, werden alle Projekte in einer bestimmten Reihenfolge gebaut, um die Kompatibilität untereinander zu testen. Da alle Tags für die einzelnen Projekte bereits geschrieben wurden, reicht es jetzt, alle Tags nur in der vorgeschriebenen Reihenfolge aufzurufen. <target name="build.all" description="baut alle Komponenten neu" > <call target="build.db.manager.project" /> <call target="build.iface.project" /> <call target="build.object.dictionary.project" /> <call target="build.cglobal.project" /> <call target="build.kidicap.bv.project" /> <call target="build.ccustom.project" /> <call target="build.ccustom.gip.project" /> <call target="build.cdistrib.project" /> <call target="build.pi.project" /> <call target="build.object.designer.project" /> <call target="build.pbv.update.project" /> </target> 9.4 Automatisiertes Deployment mit der C#-Anwendung Wie bereits im Feinkonzept erwähnt, wird das Deployment mit einer C#-Anwendung automatisiert. Eigentlich war es geplant, das Deployment mit einer Webapplikation zu steuern. Aufgrund einiger Tests wurde schnell klar, dass die Zugriffsrechte in zwei benachbarten Netzwerken wesentlich komplexer zu realisieren sind als mit einer lokalen Anwendung. Die Webapplikation war für die Benutzer aufgrund ihrer einfachen Handhabung und vor allem dadurch, dass sie als eine vertrauliche Umgebung empfunden wird, interessant. Um das Deployment zu automatisieren, müssen die im Feinkonzept erläuterten dreizehn Arbeitsschritte mit C# jeweils für die ausgewählte Umgebung, je nachdem welches Update durchgeführt wird, abgearbeitet werden. Die C#-Anwendung ist eine ausführbare Windowsapplikation bzw. exe-datei. Da die zu durchlaufenen Arbeitsschritte mehr oder weniger parallel zueinander bzw. dieselben Schritte sind, aber in unterschiedlicher Reihenfolge durchzuführen wären, werden alle dreizehn Schritte nacheinander erläutert. Welche Arbeitsabläufe mit welchen Updates abzuarbeiten sind, kann aus der Tabelle im Feinkonzept im Punkt entnommen werden. Die Anwendung existiert zweimal und sieht lediglich wie ein Formular mit drei Buttons aus. Sie unterscheiden sich nur in Bezug auf die Umgebung. Die eine Anwendung wurde für die Entwicklungs- und die andere für die Testumgebung entwickelt. Jeder Button steht für eine der Update-Varianten (Client Update, Datenbank-Update und Client & Datenbank-Update). In den folgenden Abschnitten werden nur Codeauszüge aus der C#-Anwendung zur Erläuterung mit abgebildet. Ein vollständiger Auszug der Anwendung kann aufgrund der enthaltenen Passwörter, Servernamen und Verzeichnisse nicht abgebildet werden. 75

76 9.4.1 Isolierte Umgebung sperren und Benutzer abmelden Der Citrix Presentation Server bietet eine MFCOM-Schnittstelle an, was im eigentlichen Sinne ein COM Server ist, der bestimmte Kontroll- und Monitoring-Funktionen des Citrix Presentation Servers mit einigen Script- und Programmiersprachen steuern kann. MFCOM ist eine COM-basierte Management-Schnittstelle, welche auf jedem Citrix Presentation Server lauffähig ist. Ein Entscheidungskriterium für C# war auch, dass diese Programmiersprache die COM-Programmierung unterstützt. Die Kommunikation zwischen der Anwendung und der MFCOM-Schnittstelle erfolgt über ein MetaFarm-Objekt bzw. eine vorhandene Klasse in C#. Um die jeweilige isolierte Umgebung zu sperren, muss erst einmal die Anwendung ermittelt werden. Dazu werden alle auf dem CPS installierten Anwendungen in die jeweiligen Applikationen geladen. Erst im nächsten Schritt wird die PView Test- bzw. Entwicklungsumgebung aus diesen geladenen Applikationen gefiltert. Da jetzt die Umgebung bekannt ist, können die angemeldeten User ermittelt werden. Nach Abschluss dieser Vorarbeiten dürfen die gewünschten Aktionen durchgeführt werden. Erst wird die Umgebung gesperrt und schließlich die jeweiligen Benutzer abgemeldet. // MetaFarm-Objekt erstellen IMetaFrameFarm Farm = new MetaFrameFarm(); Farm.Initialize(MetaFrameObjectType.MetaFrameWinFarmObject); // Anwendungen ermitteln IMetaFrameApplications Apps = Farm.Applications; foreach (IMetaFrameApplication App in Apps) { // Properties der jeweiligen Applikation laden App.LoadData(0); Console.WriteLine("Application: {0}", App.AppName // Gewünschte Umgebung finden if (App.AppName == "PView Testumgebung") { // App sperren App.EnableApp = 0; // 0=sperren 76

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

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

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

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

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

Permanente Integration Einstellung und Prozess versus Werkzeuge

Permanente Integration Einstellung und Prozess versus Werkzeuge Consulting Guild AG Methodenberatung für Projekte im 21. Jahrhundert Permanente Integration Einstellung und Prozess versus Werkzeuge Inhalt: Einleitung 1 Worum geht's hier überhaupt? 2 Überblick 2 Permanente

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

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

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

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

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

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services Wir schützen Ihre Investitionen Qualitätssicherung nach Maß IT Quality Services Sicherheit, die senkt Mit den IT Quality Services schützen Sie Ihre Investitionen Ohne Qualitätssicherung Mit Qualitätssicherung

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

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

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

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Automated Deployment Services Setup

Automated Deployment Services Setup visionapp Platform Management Suite Automated Deployment Services Setup Version 5.1.5.0 Installation Guide Copyright visionapp GmbH, 2002-2006. Alle Rechte vorbehalten. Die in diesem Dokument enthaltenen

Mehr

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt Inhalt 1 Einführungsveranstaltung 1.1 Ziel der Veranstaltung Warum Qualität? Inhalt der Veranstaltung 1.2 Formaler Ablauf der Veranstaltung 1.3 Übungs- und Gruppeneinteilung 1.4 Bewertungskriterien mittels

Mehr

Informatikkaufmann/-frau

Informatikkaufmann/-frau Die ECKD GmbH und ECKD Service GmbH zählt seit mehr als 25 Jahren zu den führenden IT-Dienstleistungsunternehmen für Informationsverarbeitung im kirchlichen Umfeld. Fokus unserer Aktivitäten ist die Bereitstellung

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

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth

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

visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation

visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation Copyright visionapp GmbH, 2002-2006. Alle Rechte vorbehalten. Die in diesem Dokument enthaltenen Informationen, Konzepte

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

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

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008 Traceability-Modell als Erfolgsfaktor für Process Enactment Einführung Referent Paul-Roux Wentzel Unternehmen method park Software AG 2008 method park Software AG Slide 2 Leistungsportfolio Training &

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

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Uwe Hehn TAV Februar 2005 Hochschule Bremen Uwe.Hehn@methodpark.de Abnahmetest: Warum brauchen wir denn so etwas? Projektabnahme

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

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

Konfigurationsmanagement

Konfigurationsmanagement Konfigurationsmanagement Universität zu Köln Historisch-Kulturwissenschaftliche Informationsverarbeitung Re-usable Content in 3D und Simulationssystemen Dozent: Prof. Dr. Manfred Thaller Referent: Jannes

Mehr

Das Online-Portal für ein modernes Personalmanagement mit KIDICAP

Das Online-Portal für ein modernes Personalmanagement mit KIDICAP Das Online-Portal für ein modernes Personalmanagement mit KIDICAP Ihre IT-Lösungen für Gesundheit und Soziales PERSONALMANAGEMENT WIE ICH ES WILL Das Portalangebot von myrzvpers.on bietet mir alle Optionen

Mehr

esec der sichere Weg zum ganzheitlichen Information-Security-Management-System (ISMS) nach ISO 27001 Version: 2.9 / 29.09.2008

esec der sichere Weg zum ganzheitlichen Information-Security-Management-System (ISMS) nach ISO 27001 Version: 2.9 / 29.09.2008 esec der sichere Weg zum ganzheitlichen Information-Security-Management-System (ISMS) nach ISO 27001 Version: 2.9 / 29.09.2008 WMC Wüpper Management Consulting GmbH Vertriebs-/Projektbüros Unternehmenssitz

Mehr

Testautomatisierung. Schritthalten mit agiler Software-Entwicklung. Matthias Hölzer-Klüpfel

Testautomatisierung. Schritthalten mit agiler Software-Entwicklung. Matthias Hölzer-Klüpfel Testautomatisierung Schritthalten mit agiler Software-Entwicklung Matthias Hölzer-Klüpfel Aufgabenstellung Entwicklung eines innovativen Medizinprodukts in einem Startup-Unternehmen bis zur CE-Kennzeichnung

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr

Grundlagen des Software Engineering

Grundlagen des Software Engineering Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Einleitung Historie des Konfigurationsmanagements:

Mehr

1. Zweckdes Dokuments

1. Zweckdes Dokuments Testplanung Testplanung 1.Zweck des Dokuments 2.Testziele 3.Teststrategie 4. Inkrementeller Test 5. Dokumentation der Tests 6. Performance Test 7. Literaturreferenzen 1. Zweckdes Dokuments Dokumentation

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Prozessmanagement mit ViFlow in der RWE Systems Sparte IT

Prozessmanagement mit ViFlow in der RWE Systems Sparte IT Prozessmanagement mit ViFlow in der RWE Systems Sparte IT RWE Systems AG Erfolgreiche Unternehmen arbeiten nach einem grundlegenden Prinzip: "Wir machen nur das, wovon wir wirklich etwas verstehen. Dort,

Mehr

Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen

Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen Tutorium auf der KSFE 2015 in Hannover, 25.03.2015 Qualität kommt von Qual. Wissen aus Daten gewusst wie ist IT-Dienstleister

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

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

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

Mehr

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

6 Zusammenfassende Bewertung und Ausblick

6 Zusammenfassende Bewertung und Ausblick 437 6 Zusammenfassende Bewertung und Ausblick Immer wieder scheitern Projekte zur Software-Gestaltung im Öffentlichen Dienst bzw. sie laufen nicht wie geplant ab. Dies ist für sich genommen nicht weiter

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

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

tisoware.projekt tisoware.projekt Die Software für Ihr Projektcontrolling

tisoware.projekt tisoware.projekt Die Software für Ihr Projektcontrolling tisoware.projekt tisoware.projekt Die Software für Ihr Projektcontrolling Projekterfolge nicht dem Zufall überlassen dank tisoware.projekt Ergänzende Module lassen sich jederzeit einbinden, etwa zur Personaleinsatzplanung

Mehr

Compliance Monitoring mit PROTECHT.ERM

Compliance Monitoring mit PROTECHT.ERM covalgo consulting GmbH Operngasse 17-21 1040 Wien, Austria www.covalgo.at Compliance Monitoring mit PROTECHT.ERM Autor: DI Mag. Martin Lachkovics, Dr. Gerd Nanz Datum: 20. Oktober 2014, 29. April 2015

Mehr

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung 2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer Beitrag von Peter Küsters Formen des Datentransfers bei der Erfassung von Websites Im folgenden werden Methoden und Software zur Erfassung vorgestellt.

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

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

ENDLICH ZEIT FÜR KREATIVE STRATEGIEN HR SERVICES & SOLUTIONS

ENDLICH ZEIT FÜR KREATIVE STRATEGIEN HR SERVICES & SOLUTIONS ENDLICH ZEIT FÜR KREATIVE STRATEGIEN HR SERVICES & SOLUTIONS >> Delegieren Sie Ihre Personalarbeit an die Software, die alle Routineaufgaben im Personalwesen erledigt. Flexibel. Zuverlässig. Sicher. DIE

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

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

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

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Automated Deployment Services. visionapp Platform Management Suite. Technische Dokumentation

Automated Deployment Services. visionapp Platform Management Suite. Technische Dokumentation Automated Deployment Services visionapp Platform Management Suite Technische Dokumentation Version 5.2 www.visionapp.com Inhalt 1 Voraussetzungen... 2 1.1 Systemvoraussetzungen... 2 2 Hintergrund... 3

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

IT-Development & Consulting

IT-Development & Consulting IT-Development & Consulting it-people it-solutions Wir sind seit 1988 führender IT-Dienstleister im Großraum München und unterstützen Sie in den Bereichen IT-Resourcing, IT-Consulting, IT-Development und

Mehr

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1 V-Modell Dipl. Wirtsch. Ing. Alexander Werth Software Engineering 11-1 Was ist das V-Modell? Das V im V-Modell steht für Vorgehensmodell. Umfangreiches Dokument. Softwaretool zur Unterstützung. Vorgabe

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

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH Thomas Freitag achelos GmbH SmartCard-Workshop 2012 1 2012 achelos GmbH Übersicht 1. 2. 3. 4. 5. 6. 7. Einführung / Motivation Historie des Testens Schnittstellen im Testbereich Eclipse Plugins Automatisierung,

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

Software Engineering Vorlesung für Medieninformatik

Software Engineering Vorlesung für Medieninformatik Software Engineering Vorlesung für Medieninformatik Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung

Mehr

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. K.-P. Fähnrich, Prof. H.-G. Gräbe, T. Riechert Institut für Informatik Sommersemester 2012 Allgemeine Bemerkungen

Mehr

IT-Organisation Superuser und Local Support

IT-Organisation Superuser und Local Support IT-Organisation Superuser und Local Support Inhalt VORWORT... 2 DEFINITION DER VORAUSSETZUNGEN... 3 ORGANISATION... 4 DEFINITION DES SUPERUSERS... 5 KOMPETENZABGRENZUNG... 6 AUFGABEN DES SUPERUSERS...

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

6 Systematisches Testen von Programmen

6 Systematisches Testen von Programmen 6 Systematisches Testen von Programmen Testen Untersuchung des Source-Codes nach Fehlern und Anomalien Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 6 p.1/24 Untersuchung des Source-Codes

Mehr

Standardisiert aber flexibel

Standardisiert aber flexibel AFCEA e.v. Mittagsforum 24.10.2008 Godesburg, Bonn-Bad Godesberg Standardisiert aber flexibel Prozessmodelle im Übergang von der Theorie in die Praxis. Brian Rosenberger Die Theorie Der entwickelt Verfahren

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

aconso HR-Information-Processing

aconso HR-Information-Processing Der neue HR-Mega-Trend - HR-Information-Processing HR-Prozessoptimierung ermöglicht Personalsachbearbeitern Konzentration auf die wesentlichen Aufgaben in der Personalabteilung Informationen sind die Grundlage

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

WinStation Security Manager

WinStation Security Manager visionapp Platform Management Suite WinStation Security Manager Version 1.0 Technische Dokumentation Copyright visionapp GmbH, 2002-2006. Alle Rechte vorbehalten. Die in diesem Dokument enthaltenen Informationen,

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

Migration von Subversion nach Mercurial und Einsatz dezentraler Versionskontrolle in Unternehmen

Migration von Subversion nach Mercurial und Einsatz dezentraler Versionskontrolle in Unternehmen Migration von Subversion nach Mercurial und Einsatz dezentraler Versionskontrolle in Unternehmen Christoph Mewes Otto-von-Guericke-Universität Magdeburg 17. August 2011 Christoph Mewes (OvGU) Migration

Mehr

Testen im Software- Entwicklungsprozess

Testen im Software- Entwicklungsprozess Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von

Mehr

Corporate WLAN. Testprotokoll

Corporate WLAN. Testprotokoll Corporate WLAN Verfasser: Nico Lamberti Email: nico.lamberti@leuchterag.ch Version: 1.1 Status: in Arbeit Datum: 18.03.2005 Änderungskontrolle Version Datum Ausführende Stelle Bemerkung / Art der Änderung

Mehr

1 Einleitung. 2 Formale Grundlagen. 3 Leistungen der Vertragspartner. 1.1 Zweck, Abgrenzung. 1.2 Projektübersicht, Motivation. 3.

1 Einleitung. 2 Formale Grundlagen. 3 Leistungen der Vertragspartner. 1.1 Zweck, Abgrenzung. 1.2 Projektübersicht, Motivation. 3. Projektplan Hive Version: 1.1 Autoren: Robin Goldberg (2453516) Hansjörg Schmauder (2531506) Benjamin Schmidt(2443953) Erstellt am: 15.02.2010 Letzte Änderung: 24.06.10 Inhaltsverzeichnis 1 Einleitung...

Mehr

I T I L. ITIL ein systematisches und professionelles Vorgehen für. das Management von IT Dienstleistungen. Andreas Henniger.

I T I L. ITIL ein systematisches und professionelles Vorgehen für. das Management von IT Dienstleistungen. Andreas Henniger. I T I L ITIL ein systematisches und professionelles Vorgehen für das Management von IT Dienstleistungen. 1 ITIL Was ist ITIL? ITIL wurde von der Central Computing and Telecommunications Agency (CCTA) entwickelt,

Mehr

Qualitätsmanagement - Umweltmanagement - Arbeitssicherheit - TQM

Qualitätsmanagement - Umweltmanagement - Arbeitssicherheit - TQM Qualitätsmanagement - Umweltmanagement - Arbeitssicherheit - TQM Besteht bei Ihnen ein Bewusstsein für Die hohe Bedeutung der Prozessbeherrschung? Die laufende Verbesserung Ihrer Kernprozesse? Die Kompatibilität

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

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

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von:

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Normfall 7.2 Whitepaper Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Microsoft SQL Server 2008 R2/2012/2014 2014 Normfall GmbH Alle Rechte vorbehalten. Vorbemerkungen

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

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann Extreme Programming Referat von Viktoria Schwarzhaupt und Andrea Schuhmann 1. Was ist XP - Prozessmodell für die objektorientierte Softwareentwicklung - leichter Softwareentwicklungsprozess Analyse Design

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

Mehr

Verfahrens-Verzeichnisse Kapitel III.2.3.1

Verfahrens-Verzeichnisse Kapitel III.2.3.1 III.2.3.1 Verfahrens-Verzeichnisse Prozesse oder Verfahren? Verfahrensverzeichnisse Wenn ich ein Verfahrensverzeichnis bearbeite, erinnere ich mich oft an meine ersten Versuche, herauszubekommen, was alles

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

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

Effiziente Personalentwicklung SOFTWARE FÜR PERSONALMANAGEMENT

Effiziente Personalentwicklung SOFTWARE FÜR PERSONALMANAGEMENT HR4YOU-HCM Effiziente Personalentwicklung SOFTWARE FÜR PERSONALMANAGEMENT HUMAN RELATIONSHIP MANAGEMENT SYSTEMS WARUM HR4YOU? Die Softwarelösungen von HR4YOU sind webbasiert und mehrsprachig verfügbar.

Mehr

Qualitätssicherung in der Praxis der Softwareerstellung

Qualitätssicherung in der Praxis der Softwareerstellung Thomas Kugel Qualitätssicherung in der Praxis der Softwareerstellung Dresden 18.10.2001 Quality Quality for for Success Success Inhalt Die SQS AG Einführung / Motivation Aufwandsschätzung Testorganisation

Mehr