Dieses Dokument behandelt das Thema "Integration eines datenschutzkonformen Imageservers". Der Schwerpunkt liegt bei der Beschreibung wie das Projekt nach DIN 69901 (Durcharbeiten der üblichen Projektphasen) abgewickelt wurde. Das Dokument wird anonymisiert hochgeladen. (Titelblatt verändert, Unternehmen anonymisiert, Autor anonymisiert)
Folgendes ist in diese PDF enthalten:
Dokumentation der Projektarbeit ca. 35 Seiten.
22 Anlagen (Riskmanagement, Phaseplan inkl. Meilensteine, Stakeholderanalyse, , Kommunikationsplanung, Kostenplanung, Change Management, Nutzwertanalyse usw.)
Die Projektarbeit soll Orientierung geben und bestmöglich durch die Projektphase begleiten. Es dient als Hilfestellung bzgl. der Darstellung und Gliederung der einzelnen Phasen und ist ein einwandfreies Beispiel dafür, wie ein Thema als Vehikel genutzt wird um zu verdeutlichen, dass die Projektarbeit verstanden wurde.
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1. Projektinitialisierung
1.1 Beschreibung Projektumfeld: Firma XYZ GmbH
1.2 Projektbeschreibung
1.3 Lastenheft
1.4 Machbarkeitsanalyse
1.5 Projektteam
1.6 Risikomanagement
1.6.1 Risikoanalyse
1.6.2 Durchführung Risikomanagement
1.7 Stakeholderanalyse
1.8 Changemanagement
1.9 Projekt-Modell
1.10 Freigabe für Projektplanung
2. Projektplanung
2.1 Ist Analyse
2.2 Konzeptplanung
2.2.1 Definition Ziele
2.2.2 Grobplanung Soll-Konzept
2.2.3 FeinplanungSollkonzept
2.3 Lösungsalternativen
2.4 Kommunikationsplanung
2.5 Projektorganisation
2.6 Zeitplanung
2.7 Ressourcenplanung
2.8 Kostenplanung
2.8.1 Materialkosten TJ
2.8.2 Personalkosten TJ
2.9 Testplanung
2.10 Controlling
2.11 Pflichtenheft
3. Projektdurchführung
3.1 Kick-off Meeting
3.2 Umsetzung der Planung
3.3 Controlling
4. Abschluss
4.1 Abnahmetest
4.2 Übergabe
4.3 Soll-Ist-Vergleich
4.4 Lessons Learned
4.5 Offene Punkte
Literaturverzeichnis
Abkürzungsverzeichnis
Anhangsverzeichnis
I. Vorwort
Diese Projektdokumentation mit dem Titel „Integration eines datenschutzkonformen Imageservers“ beschreibt die Anwendung von Projektmanagementmethoden zur Integration eines neuen Systems und Verbesserung eines bestehenden Geschäftsprozesses eines kleinen mittelständigen Unternehmens.
Innerhalb des Projektes nahm der Verfasser dieser Dokumentation die Rolle des Entwicklungsleiters ein.
Datenschutz
Um der Wahrung von persönlichen Daten nach dem BDSG nF, der DSGVO und den internen Vorgaben des Unternehmens gerecht zu werden, wurden in dieser Dokumentation alle personenbezogenen Daten sowie alle Daten die zur Identifizierung einer natürlichen Person ausreichen im Sinne der DSGVO verändert oder unkenntlich gemacht.
Außerdem wurden die Kalkulationssätze für Dienstleistungen aus Datenschutzgründen in diesem Projekt verhältnismäßig abgeändert.
Allgemeine Informationen und Verweise
Aus Gründen der besseren Lesbarkeit wird in dieser Projektarbeit ausschließlich die männliche Form für Rollenbezeichnungen verwendet, wobei die weibliche Form implizit miteingeschlossen ist.
Abbildunqsverzeichnis
Abbildung 1- Entscheidungsprozess
Abbildung 2- Aufbau Projektteam
Abbildung 3- Risikoanalyse
Abbildung 4 - Stakeholder Strategien
Abbildung 5 - Changemanagement_EPK
Abbildung 6 - Wasserfallmodell
Abbildung 7 - Ist-Analyse
Abbildung 8 - Schnittstellen Ist Analyse
Abbildung 9 - Top Down Strategie
Abbildung 10- Projektstrukturplan
Abbildung 11 - Phasen Brainstorming
Abbildung 12 - Ist-Soll-Vergleichsdiagramm
Abbildung 13 - Schnittstellen Soll-Konzept
Abbildungl4 - Schutzziele IT-Sicherheit
Abbildung 15 - Schutzzonen
Abbildung 16 - Nutzwertanalyse
Abbildung 17 - Kommunikationsorganisation
Abbildung 18 - Matrixorganisation
Abbildung 19 - Gantt Diagramm
Abbildung 20 - Netzplan
Abbildung 21 - Implementierung Testphase
Abbildung 22 - Magisches Dreieck
Abbildung 23 - Meilensteintrendanalyse
Abbildung 24 - PDCA Zyklus
Abbildung 25 - PDCA Fehlerzyklus
Abbildung 26 - Fehlerstatusmodell 33
Tabellenverzeichnis
Tabelle 1 - Einflussfaktoren
Tabelle 2 - Feinzieldefiniton
Tabelle 3 - Mindestanforderung Beschaffung
Tabelle 4 - Risikoklassen
Tabelle 5 - Aufzählung Stakeholder
Tabelle 6 - Möglichkeiten IT-Schutz
Tabelle 7 - RACI-Modell
Tabelle 8 - Materialkosten
Tabelle 9 - Personalkosten Entwicklungsleiter
Tabelle 10- Kosten Projektteam
Tabelle 11 - Fehlerkategorien
Tabelle 12 - Abgleich mit Lastenheft 34
1. Projektinitialisierunq
1.1 Beschreibung Projektumfeld: FirmaXYZGmbH
Die Firma XYZ GmbH ist ein mittelständiges IT-Unternehmen welches 2003 gegründet wurde und sich als Anbieter von IT Lösungen für Großveranstaltungen etablieren konnte. Das Unternehmen beschäftigt 9 festangestellte MA und ist europaweit tätig. Die auf den Veranstaltungen genutzte hauseigene Software ePMS wurde durch Firma XYZ entwickelt und wird ständig verbessert und angepasst.
Die benötigte Hardware, welche als ausführende Elemente der Software dienen, wurde eigens entwickelt. Die sogenannten Gates sind ca. 1,8m hohe Säulen, an denen sich ein Besucher authentifizieren muss um Zutritt zu bestimmten Arealen zu erhalten.
Die RFID Chips der Besucher werden mit einem Datensatz auf einer Veranstaltungsspezifischen Datenbank verglichen. Da größtenteils mit personenbezogenen Daten gearbeitet wird liegt die Priorität auf dem Schutz dieser.
Die beschriebenen Datenbanken werden vor jeder Veranstaltung in ePMS beschrieben und angepasst. Die Veranstaltungsspezifische Hardware wird von Firma XYZ aufgebaut, betrieben und durch einen vor Ort Support unterstützt.
Das Unternehmen hat seinen Sitz in Bonn. Eine Außenstelle in Berlin ist für alle Veranstaltungen im Osten Deutschlands verantwortlich.
Das Projekt wurde hauptsächlich innerhalb der Geschäftsräume in Bonn realisiert. Die Faktoren des Projektumfeldes wurden durch den Entwicklungsleiter analysiert und in Tabelle 1 zusammengeführt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1 - Einflussfaktoren
Die sachlichen Faktoren zu beachten kann im Vergleich mit den Sozialen Faktoren einfacher sein. Die Sozialen Faktoren wurden im Zuge der ersten Phase analysiert und werden unter Punkt 1.6 Stakeholderanalyse beschrieben.
1.2 Projektbeschreibung
Die Firma XYZ GmbH plante schon seit einiger Zeit einen neuen Image-Server aufzubauen um das alte Image-System durch einen modernen und effizienteren Server zu ersetzen. Durch zurückliegende Ereignisse, Aufträge und MA-Abgänge wurde dieses Projekt immerwiederverschoben.
Das in Kraft treten der DSGVO am 25.Mai 2018 war, neben der Optimierung etablierter Geschäftsprozesse, ein weitere Initialfunke für das Projekt.
Die Zieldefinition lautete:
Ziel soll sein, bis zum 30.10.2018 einen Imageserver zu installieren und alle
Komponenten zu konfigurieren um mobile Geräte, die auf Events/Messen ausgeteilt werden, mit Master-Images neu zu bespielen. Zusätzlich soll dem Datenschutz gemäß DSGVO und BDSG nF gerecht zu werden.
1.3 Lastenheft
Um Verstöße gegen die Verordnung zu vermeiden, wurden Schwachstellen in der IT- Sicherheit gesucht um diese schnellst möglich schließen zu können. Eine gegen die Firma XYZ GmbH gerichtete Sanktion hätte das wirtschaftliche Ende der Gesellschaft bedeutet, da diese in ihrer Höhe vergleichbar mit denen des Kartellgesetzes sind.
Beim alten Image-Server waren es die veraltete Hardware und die unzuverlässigen OpenSource Komponenten die in der Datenschutz-Risikoanalyse als kritisch betrachtet wurden. Eine Analyse der Schwachstellen wurde durch den Entwicklungsleiter unter Punkt 2.1 IstAnalyse beschrieben.
Der Geschäftsführer definierte im Vorfeld was der Server leisten soll
- Automatisierte Konfiguration der ein- und ausgehenden Hardware
- MDM
- diverse Technische Spezifikationen
- Datenschutzkonformität
AufGrundlage dieserVorgaben und diverserVorgespräche mit verschiedenen Stakeholdern wurde ein Lastenheft erstellt um die Richtung, in die das Projekt gehen sollte, festzuhalten. Dieses wurde dem Geschäftsführer am Ende der Initialisierungsphase vorgelegt.
Mit dem Lastenheft wurden Ziele durch den Entwicklungsleiter definiert und in einem Phasenplan, Anhang 05 - Phasenplan, zusammengefasst. Die Ziele wurden nach SMART definiert, also:
- Spezifisch
- Messbar
- Akzeptiert
- Realistisch
- Terminierbar
Auf Grundlage dieser Ziele wurden folgende Feinziele definiert und in Muss / Soll / Kann Ziele kategorisiert.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2 - Feinzieldefiniton
Die angestrebte DSGVO und BDSG nF konforme Konzeption wurde vom
Entwicklungsleiter entwickelt und wird unter Punkt 2.2 Sollkonzept beschrieben.
Mindestens zu migrierenden Komponenten
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3 - Mindestanforderung Beschaffung
Basierend auf den beschrieben Soll-Kriterien und den vorgegebenen Zielen oblag es dem Entwicklungsleiter eine grobe Kostenkalkulation für Soft- und Hardwarekomponenten zu akquirieren und eine Machbarkeitsanalyse durchzuführen.
Zusätzlich sollten alternative Lösungen entwickelt und vorgestellt werden. Ein Budget wurde nicht definiert.
Erst nach Vorlage der Kalkulation und den alternativen Lösungen, beschrieben unter Punkt 2.3 Lösungsalternativen, sollte entschieden werden ob das Projekt durchgeführt wird.
1.4 Machbarkeitsanalyse
Nach dem nennen der projektrelevanten Ziele durch den Geschäftsführer erfolgte eine Machbarkeitsanalyse überdie Umsetzung des Projektes. Die
Machbarkeitsanalyse hatte zum Ziel, die Projektziele auf ihre Umsetzbarkeit zu überprüfen und ob das Vorhaben realistisch ist.
Im Anschluss sollte das weitere Vorgehen des Projektes gedanklich vorweggenommen werden.
Die Machbarkeitsanalyse betrachtete sowohl die technische und wirtschaftliche als auch die organisatorische Umsetzbarkeit. Im folgenden Flussdiagramm sind die grundlegenden Fragen veranschaulicht:
Folgendes ergab sich aus derAnalyse:
Technische Machbarkeit
Bei der Suche nach geeigneten Lösungen wurden Geräte und Softwareprodukte evaluiert. Die damit einhergehenden Kenntnisse zeigten, dass die technischen Anforderungen der Umsetzung erfüllbar sind. Die dem Projekt angehörigen Administratoren verfügten über weitreichendes Wissen in diesem Segment. Die technischen Anforderungen und deren Umsetzung des BDSG nF in Verbindung mit der DSGVO stellte keine große Herausforderung dar.
Mit Hilfe der definierten Projektziele konnte durch die gewonnenen Informationen und vorbehaltlich nachträglicher Änderungen die technische Machbarkeit positiv bewertet werden.
Organisatorische Machbarkeit
Dieses Projekt benötigte die vorhanden knappen Ressourcen, für einen kurzen Zeitraum, in der Durchführungsphase. Das benötigte Fachwissen war bei allen Projektangehörigen vorhanden. Die personelle Durchführbarkeit war somit gewähreistet.
Um die terminliche Machbarkeitfestzustellen, wurden die Planungen andere Projekte geprüft. Es ergaben sich keine Überschneidungen, welche durch gesteuerten Personaleinsatz nicht zu bewältigen waren.
Wirtschaftliche Machbarkeit
Das vorläufige Budget wurde wie folgt festgelegt „so viel wie nötig, so wenig wie möglich“. Daraus ließ sich ableiten, dass für das Projekt nur ein geringes Budget zur Verfügung stand. Klar war, dass im Anschluss an das Projekt keine weiteren finanziellen Kostenblöcke entstehen sollten. Davon ausgenommen waren die Betriebskosten für die neue Serverumgebung.
Das größte wirtschaftliche Risiko stellten Probleme in der Komptabilität der einzelnen Softwarekomponenten des neuen Servers dar.
Unter der Betrachtung der Anforderungen waren wirtschaftliche Einschränkungen in der Machbarkeit zu erwarten.
1.5 Projektteam
In jedem Projekt ist der Faktor Mensch entscheidend. Die einen verfügen über hohe Fachkompetenzen und die anderen wiederrum über hohe Methodenkompetenz. Das richtige Zusammenspiel der verschiedenen Charaktere ist Aufgabe des Projektleiters.
Aufgrund der Größe von Firma XYZ ergaben sich die verschiedenen Rollen fast von selbst. Die Rolle des Projektleiters übernahm der Geschäftsführer und der Autor die des Entwicklungsleiters.
Die Kommunikation war stark vereinfacht, dargestellt unter Punkt 2.4 Kommunikationsplanung, da der PL gleichzeitig GF war und für alle Projektspezifischen Angelegenheiten den SPOC darstellte. Zur Unterstützung wurden noch zwei MA aus dem Administrationsbereich zugeteilt.
Diese sollten, den Terminen entsprechend, beim Projekt unterstützen und die Konfiguration sowie Tests übernehmen um das Know-how im Unternehmen zu halten.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2- Aufbau Projektteam
Ein Projektausschuss wurde nicht etatbliert.
1.6 Risikomanagement
Für dieses Projekt wurde entschieden, das Risikomanagement schon sehr früh zu
Konzeptionieren.
Im Rahmen des geplanten Projekts mussten neben Qualität, Kosten und Zeit auch Risiken beachtet werden.
Die Risiken sollten erkannt, analysiert und nach Eintrittswahrscheinlichkeit sowie Schadengröße bewertet werden.
Um ein Scheitern des Projektes zu vermeiden bzw. im Eventualfall eine schnelle Lösung zur Hand zu haben, wurde die Risikoanalyse erstellt und als Anlage 01 Risikoanalyse dieser Dokumentation beigefügt.
1.6.1 Risikoanalyse
Gerade im Bereich der IT gibt es viele kleine Ursachen die schnell zu einem kritischen Problem führen können. Die Risikoanalyse diente zudem, vielleicht auftretende, Kostenblöcke in der Kostenplanung zu beachten.
Die Risiken wurden in Risikoklassen eingeteilt um den Überblick zu vereinfachen.
Um eine Risikobewertung durchführen zu können, wurde jedes Risiko um einen Wahrscheinlichkeits- und Auswirkungswert ergänzt.
Die Summe derWahrscheinlichkeit und derAuswirkung ergab den Risikofaktor
Für die Visualisierung der Tabelle wurde ein Risikoprofil erstellt, welche die einzelnen Risiken verglich und verdeutlichte welche Risiken am kritischsten zu betrachten waren.
Folgende Abbildung 03 - Risikoanalyse aus dem Anhang 01 - Risikoanalyse verdeutlicht das beschriebene vorgehen.
1.6.2 Durchführung Risikomanagement
Das Risikomanagementwurde in jeder Phase des Projektes aktiv betrieben. Eine ständige Überwachung der Risiken war erforderlich um rechtzeitig agieren zu können, also noch vor Eintritt des anzunehmenden Schadens.
Wie in vielen Bereichen des Lebens ist es auch in einem Projekt von Vorteil in gewissen Situationen zu agieren statt zu reagieren gemäß dem Zitat „Angriff ist die beste Verteidigung“.
Darüber hinaus gilt es dem sich permanent ändernden Umfeld anzupassen und Risiken immerwiederzu bewerten sowie neue zu identifizieren.
1.7 Stakeholderanalyse
Die Definition nach ISO 10006 lautet:
„Stakeholder eines Projektes sind alle Personen, die ein Interesse am Projekt haben odervom Projekt in irgendeinerWeise betroffen sind.“
Leider ist es nicht in jedem Projekt klar zu erkennen, wer welchen Einfluss hat und wie groß dieser Einfluss ist. Bei dieser Stakeholderanalyse wurden die verschiedensten Einflussnehmer identifiziert und hinsichtlich einiger Faktoren bewertet.
Zunächst wurden anhand einer einfachen Aufzählung alle möglichen Stakeholder, die in irgendeiner Form Einfluss nehmen könnten, festgehalten.
Es wurde darauf geachtet die Auflistung nicht zu detailliert zu gestalten um den Überblick zu wahren und die wichtigen Stakeholder im Fokus zu behalten.
Abbildung in dieser Leseprobe nicht enthalten
Zum Beispiel hätte man noch die Familien oderdie einzelnen Familienmitglieder aufzählen können.
Im nächsten Schrittwurden die Stakeholderanhand von Faktoren bewertet. Das Ergebnis der Bewertung ist im Anhang 02 - Stakeholderanalyse dargestellt.
Die Bewertung der einzelnen Stakeholder und die darauf basierenden grafischen Darstellungen verhalfen in den verschiedenen Phasen des Projektes die richtigen Strategien zur Beeinflussung der Stakeholder anzuwenden.
Die Anwendung von nur einer Strategie führt selten zum Erfolg. So musste die Strategie ständig der Lage angepasst werden.
In Projekten spricht man von 4 möglichen Strategien:
Abbildung 4 - StakeholderStrategien
Trotz umfangreicher Interviews innerhalb der Stakeholderanalyse, war das Risiko, dass versteckte Stakeholder nicht gefunden wurden, wahrscheinlich. Dies hätte, je nach Einflussgrad der Person, für das Projekt gravierende Folgen haben können.
1.8 Changemanagement
Es ist nicht die stärkste Spezies, die überlebt, auch nicht die intelligenteste, es ist diejenige, die sich am ehesten dem Wandel anpassen kann
IT-Projekte unterstehen ständigen Änderungen. Dabei ist es unerheblich wie sorgfältig eine Planung durchgeführt wurde. Um bei Änderungen Handlungssicherheit zu schaffen wurde ein Changemanagement-Prozess entwickelt.
Das entwickelte Changemanagement sollte alle Änderungen abfangen und in einen standardisierten Ablauf lenken. So sollte verhindert werden, dass Änderungen ohne Kenntnis des Projektleiters und der Stakeholder „mal ebenso“ eingefügt wurden.
Mit Eingang eines Änderungswunsches wurde der Ablaufprozess des Changemanagements gestartet. Der Änderungswunsch wurde in Form eines Änderungsantrags an das Change Request Team geleitet.
Das CRT setzte sich zusammen aus dem PL und dem EL, da alle Änderungen sowohl aus technischer als auch aus der Sicht des Projektmanagements betrachtet werden musste. Der weitere Prozess ist auszugsweise in Abbildung 5 - Changemanagement_EPK und vollständig in Anlage 03 Changemanagement_EPK beschrieben.
Das gesamte Konstrukt diente zur Prüfung, ob ein Change Request angenommen, abgelehnt oder in veränderter Form genehmigt wurde. Am Ende sollte die Entscheidung dokumentiert werden um das Projektcontrolling zu unterstützen.
Alle eingereichten Changes sind im Anhang 04 - Changemanagement festgehalten.
1.9 Projekt-Modell
Für das Projekt wurde das Wasserfallmodel mit Rückschritt gewählt, wobei angelehnt an das V-Modell, Teile der Testphase bereits in der Durchführungsphase durchgeführt werden.
Das Wasserfallmodell, beschrieben in Abbildung 06 Wasserfallmodell, ist an sich ein klassisches Projektmodell und eignet sich hervorragend um einen Standardprozess in Form eines kleinen Projektes zu implementieren. Per Definition ist es ein lineares und nicht iteratives Modell. Das heißt das jede Phase erst mit Abschluss der vorangegangenen Phase begonnen werden kann. Probleme, welche in einer Phase nicht bemerkt werden, schleppen sich durch das Projekt und verursachen erheblichen Mehraufwand.
Um die beschriebene Problematik der Fehlerverschleppung verringern zu können wird das Wasserfallmodell um iterative Prozesse erweitert. Dies erlaubte einen Rücklauf in Teilschritten.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6 - Wasserfallmodell
Eines der Merkmale, dass die Planungsphase umfangreich ist, sollte vor dem Hintergrund des Projektes als Vorteil genutzt werden. Anhand der sorgfältigen Planung konnte das Controlling genauer definiert werden. Durch die Definition der Meilensteine und der Zuweisung der Arbeitspakete an die einzelnen Teammitglieder steigerte sich die Führbarkeit deutlich.
Die unflexible Form des Projektes versuchte man durch ein geeignetes Changemanagementzu beeinflussen.
Jedes Ende einer Phase wurde als Meilenstein definiert.
Die geplanten Phasen inklusive Meilensteine befinden sich im Anhang - 05 Phasenplan.
1.10 Freigabe für Projektplanung
Die Präsentation der validierten Informationen, den entwickelten Lösungen und des erstellten Lastenheftes erfolgte anhand eines kurzen Meetings. Dieses Meeting diente dazu, die Projektverantwortlichen auf den gleichen Stand zu bringen, mögliche Probleme zu besprechen sowie die Freigabe für die nächste Phase zu erhalten. Im Anschluss an die Freigabe erfolgte derfließende Übergang in die Phase „System und Software Entwurf“.
2. Projektplanunq
Der Vergleich eines Projektes mit der Chaostheorie ist naheliegend. Vereinfacht gesagt beschreibt die Theorie das, obwohl alle Faktoren eines fortschreitenden Prozesses bekannt sind, es unmöglich ist zu sagen was als Nächstes passiert. Man kann die Prognosen lediglich eingrenzen.
So ist es auch mit der Projektplanung, obwohl alles sorgfältig geplant, alle Risiken analysiert und jegliche Daten bewertet sowie strukturiert wurden, kann ein kleiner Flügelschlag alles beenden.
Dennoch ist eine je nach Projektmodell detaillierte Planung zwingend notwendig und hilft dem Projektleiter und allen Projektangehörigen das Projekt zu einem mehr oder weniger erfolgreichen Abschluss zu bringen
Die folgende Planungsphase ist geprägt nach „Festina Lente“ - Eile mit Weile. Ein Erfolgsrezept welches auch in stürmischen Phasen zum Erfolg führen kann. Die Kernessenz von diesem Leitspruch bedeutet, mit Bedachtsamkeit und sorgfältiger Abwägung, Pläne zu entwickeln und Entscheidungen zu treffen .
2.1 IstAnalyse
Die Ist-Analyse dieses Projektes versuchte den vorhandenen Zustand zu erfassen und Problemfelder zu identifizieren, damit diese im Soll-Konzept beachtet werden konnten.
Der Ist-Analyse stehen in der Regel verschiedene Methoden zur Verfügung um den aktuellen Zustand ermitteln zu können. Der Wahl der richtigen Methoden stehen viele Faktoren gegenüber, wie in Abbildung 07 - Ist-Analyse skizziert.
Die Vielzahl an verschiedenen Hardwaregeräten machte es zeitlich sehr aufwendig alle Geräte neu zu bespielen. Pro Event wurden mindesten 10 Geräte an Dritte übergeben. Jedes Gerät musste im Vorfeld konfiguriert und bereinigt werden.
Zum Zeitpunkt der IST-Aufnahme dauerte dies pro Gerät 15 min und war kaum bis gar nicht automatisiert. Pro Event wurden somit mindesten 2,5 Stunden allein fürs konfigurieren durch einen Mitarbeiter benötigt.
Die Vielzahl an vorhanden Software-Lizenzen beeinträchtigte den Überblick. Die Dokumentationen einzelner Bereiche (Netzwerkplan, Firewall System, Einbruchmeldeanlage) waren teilweise vorhanden. Gravierend war das Fehlen eines Datenschutzkonzeptes.
Abbildung in dieser Leseprobe nicht enthalten
Es war bereits ein Imageserver vorhanden. Dieser lief auf alter Hardware und schloss somit eine Erweiterung des vorhandenen Systems aus. Die genutzte Imagesoftware war ein Open Source Produkt.
Der Prozess „Image laden“ erfolgte manuell und war unübersichtlich. Neu zu beladene mobile IT Systeme mussten an das Firmennetz angeschlossen werden.
Das anbinden von mobiler IT in das Firmennetz, vor Bereinigung dieser, wurde als Sicherheitsmangel identifiziert, da auf Veranstaltungen eine Manipulation der Geräte nicht ausgeschlossen werden konnte.
Die Schnittstellen waren, wie in Abbildung 08 - Schnittstellen Ist Analyse dargestellt, realisiert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8 - Schnittstellen Ist Analyse
Verteilung Hardware
Es gab 6 Büroräume und einen Empfang. Hardware befand sich wie folgt aufgeschlüsselt in den Büroräumen. Aufgrund des Datenschutzes wird an dieser Stelle auf einen Raumplan verzichtet.
IT-Administration 2PC/1 Switch
Geschäftsführung 1 PC/1 Switch
Empfang 1 PC/1 Switch
Softwareentwickler 3PC/1 Switch
Der Serverschrank befand sich im Lagerraum, in dem die mobile IT der Events gelagert wurden.
Folgende nutzbare Serverkomponenten waren vorhanden
a. Unterbrechungsfreien Stromversorgungen
b. 19“ Serverschrank - abschließbar
Zusätzlich zur Ist-Analyse wurde ein Datenschutz-Audit erstellt. Dieses sollte neben technischen auch allgemeine Datenschutzregelungen dokumentieren.
Das Audit wurde anhand eines Fragenkatalogs erstellt. Der ausgefüllte
Fragenkatalog befindet sich in Auszügen im Anhang - 06 Datenschutzaudit.
2.2 Konzeptplanung
Das Soll-Konzept wurde erstellt um eine grobe Richtung zu definieren, welche die gesamte Planungsphase beeinflussen sollte. Gleichzeitig musste schon zu Beginn der Planung, das Verständnis der Zielsetzung bei allen Projektverantwortlichen nahezu identisch sein um Missverständnisse basierend auf Kommunikationsproblemen (Eisberg-Prinzip) zu vermindern.
Um eine Planung bezüglich Zeit und Ressourcen mit validen Werten erstellen zu können, war vorab eine Grobplanung der Projektabläufe notwendig.
Um von der Ist-Ausgangslage zur Soll-Lösung zu gelangen wurden die gewonnenen Informationen für die Top-Down Vorgehensstrategie genutzt.
Diese Vorgehensart beschreibt das Vorgehen vom Abstrakten zum Konkreten bzw. vom groben zum feinen. Die Top-Down Strategie wird durch analysierendes Denken geprägt. Das heißt, ein Gesamtsystem wird fortschreitend in Teilsysteme zerlegt und die aufkeimenden Probleme gelöst. Siehe dazu Abbildung 09 Top-Down Strategie
Abbildung in dieser Leseprobe nicht enthalten
[...]
- Citar trabajo
- Anónimo,, 2018, Integration eines datenschutzkonformen Imageservers. Projektdokumentation Certified Systems Manager, Múnich, GRIN Verlag, https://www.grin.com/document/1176285
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.