Hausarbeit zur Diplomprüfung an der HOCHSCHULE FÜR ANGEWANDTE WISSENSCHAFTEN HAMBURG Fakultät Design Medien Information Studiendepartment Information

Transkript

1 Entwurf, Entwicklung und Erprbung einer Kmpnente zur Erweiterung des Facility-Management-Systems (FMS) am Deutschen Elektrnen-Synchrtrn (DESY) um Funktinalitäten zur Unterstützung der Schlüsselverwaltungsprzesse Hausarbeit zur Diplmprüfung an der HOCHSCHULE FÜR ANGEWANDTE WISSENSCHAFTEN HAMBURG Fakultät Design Medien Infrmatin Studiendepartment Infrmatin vrgelegt vn Melanie Wessel Hamburg, August Prüfer: Prf. Dr. Franziskus Geeb 2. Prüfer: Prf. Dr. Martin Gennis

2 Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis...iv Tabellenverzeichnis... v Abkürzungsverzeichnis... v 1 Einleitung Prjekt Grundlagen Anlass... 2 Ziel und Nutzen des Prjektes... 3 Prjektablauf... 4 Prjektbeteiligte... 5 DESY... 6 Przessunterstützung durch Infrmatinssysteme... 7 Facility Management... 9 CAFM-Systeme GIS/FMS das CAFM-System am DESY Schlüsselverwaltung Werkzeuge und Methden Anfrderungserhebung und -management Was ist eine Anfrderung? Phasen der Anfrderungsentwicklung Anfrderungserhebung mit der Metaplan-Technik Analyse Geschäftsprzessanalyse mit der Unified Mdelling Language Was ist UML? Diagrammtypen der UML Systementwurf (Design) Benchmarking Funktinspunktanalyse i

3 Inhaltsverzeichnis 5 Analyse Ist-Zustand Geschäftsprzessanalyse Die Geschäftsprzesse der Schlüsselverwaltung im Überblick Analyse des Schlüsselausgabeprzesses Systemumfang des SVS Sll-Zustand Systemlösung Systementwurf Implementierungsphase Systemvrstellung: Das DESY-SVS Der Schlüsselausgabe-Wizard Benchmark-Test Durchführung des Benchmark-Tests Ergebnisanalyse Gesamtergebnis...57 Bewertung der einzelnen Testanwender...58 Bewertung in den Aufgabenblöcken...59 Bewertung in den Szenarien Zusammenfassung der Ergebnisse Ksten- und Aufwandsschätzung für die SVS-Entwicklung Durchführung der Aufwandsschätzung Aufwandsschätzung für die Realisierung der Schlüsselausgabefunktinen Aufwandsschätzung für die Realisierung der Schlüsselrückgabefunktinen Aufwandsschätzung der gesamten SVS-Entwicklung Ergebnisse der Kstenschätzung Ausblick Fazit und Prjektergebnisse Quellen Eidesstattliche Versicherung ii

4 Inhaltsverzeichnis Anhang 1 Einleitung...I 2 Przessanfrderungen...I 2.1 Przessbeteiligte... I 2.2 Funktinale Przessanfrderungen... I Allgemeine Przessanfrderungen... II Anfrderungen an den Schlüsselausgabeprzess... II 2.3 Randbedingungen... III 2.4 Anfrderungen an die Beteiligten zur Przessumsetzung... III 3 Systemanfrderungen... III 3.1 Anwenderanfrderungen an das Schlüsselverwaltungssystem... IV 3.2 Funktinale Systemanfrderungen...V Allgemeine Systemanfrderungen... V Anfrderungen an den Schlüsselausgabe-Wizard... V 3.3 Nicht-funktinale Systemanfrderungen...VII iii

5 Abbildungsverzeichnis Abbildungsverzeichnis Abb. 1: Prjektablauf (eigene Darstellung)... 4 Abb. 2: Luftbild des DESY-Geländes (Quelle: DESY 2006)... 6 Abb. 3: Blick in den Hera-Tunnel (Quelle: DESY 20052)... 7 Abb. 4: Umsetzungsmöglichkeiten vn Aktivitäten (eigene Darstellung)... 8 Abb. 5: Lebensphasen einer Sachressurce (nach Nävy 2003, S. 72)... 9 Abb. 6: Aspekte des Facility Managements (nach Nävy 2003, S. 4) Abb. 7: Kmpnenten eines CAFM-Systems (nach Nävy 2003, S. 111) Abb. 8: GIS/FMS-Architektur (nach Eucker 2005, S. 15; Rbben 2004, S. 14) Abb. 9: DESY-Knzept der Schlüsselverwaltung (eigene Darstellung) Abb. 10: Phasen der Anfrderungsentwicklung (nach Smmerville 2005, S. 17) Abb. 11: Anfrderungsschablne (nach Rupp 2002, S. 471) Abb. 12: Anfrderungsschablne mit Bedingung (nach Rupp 2002, S. 472) Abb. 13: Schritte der Analysephase (eigene Darstellung) Abb. 14: Anwendungsfalldiagramm (eigene Darstellung) Abb. 15: Aktivitätsdiagramm (eigene Darstellung) Abb. 16: Aktivitätsdiagramm mit Objektfluss (eigene Darstellung) Abb. 17: Klassendiagramm (eigene Darstellung) Abb. 18: Beispiel einer Systemarchitektur (nach Oestereich 2001, S. 146) Abb. 19: Vrgehensweise beim Benchmarking (eigene Darstellung) Abb. 20: Ablauf einer Funktinspunktanalyse (eigene Darstellung) Abb. 21: Ergebnis der Kartenabfrage Abb. 22: Auslösender Akteur des Przesses Schlüssel ausgeben (eigene Darstellung) Abb. 23: Ablauf des Schlüsselausgabeprzesses (eigene Darstellung) Abb. 24: Umsetzungsmöglichkeiten der Verwaltungsaktinen (eigene Darstellung) Abb. 25: Ablauf des Schlüsselausgabeprzesses mit IS (eigene Darstellung) Abb. 26: Systemumfang und externe Akteure (eigene Darstellung) Abb. 27: Identifikatin der Funktinsklassen (eigene Darstellung) Abb. 28: Systemstruktur der Schlüsselausgabekmpnente (eigene Darstellung) Abb. 29: Gebäude- und Raumauswahl des Schlüsselausgabe-Wizards (Screensht) Abb. 30: Schlüsselauswahl-Liste des Ausgabe-Wizards (Screensht) Abb. 31: Ergebnis der Besitzer-Suche (Screensht) Abb. 32: Übersicht der Vrgangsdaten vr Transaktinsspeicherung (Screensht) Abb. 33: Druckvrschau des Belegs zur Schlüsselausgabe (Screensht) Abb. 34: Gesamtergebnis des Benchmark-Tests (eigene Darstellung) Abb. 35: Gesamtergebnis unterteilt nach Testanwendern (eigene Darstellung) Abb. 36: Systembewertung in den Aufgabenblöcken (eigene Darstellung) Abb. 37: Systembewertung in den Szenarien (Teil I, eigene Darstellung) Abb. 38: Systembewertung in den Szenarien (Teil II, eigene Darstellung) Abb. 39: Beispielhafte Eingabemaske (Screensht) Abb. 40: Beispielhafte Ausgabemaske (Screensht) Abb. 41: Systemstruktur der Schlüsselausgabekmpnente (eigene Darstellung) Abb. 42: Systemstruktur der Schlüsselrückgabekmpnente (eigene Darstellung) Abb. 43: Systemstruktur der Schlüsselstammdatenerfassungskmpnente (eigene Darstellung) iv

6 Tabellenverzeichnis Tabellenverzeichnis Tabelle 1: Matrix zur Ermittlung der Funktinspunkte Tabelle 2: Aktinen des Schlüsselausgabeprzesses Tabelle 3: Aktinen des Schlüsselausgabeprzesses mit IS Tabelle 4: Funktinsklassen der Schlüsselausgabekmpnente Tabelle 5: Matrix zur Ermittlung der Funktinspunkte Tabelle 6: Funktinsklassen der Schlüsselrückgabekmpnente Tabelle 7: Funktinsklassen der Stammdatenerfassungskmpnente Abkürzungsverzeichnis A AF Ages ASA ASA_SR ASA_SR* ASA_SR_Diff ASA_SR_Real ASD ASpez ASR ASStD ATest AV AV_F_SD_ZD_ZR AZA AZA_ZR AZA_ZR_Diff AZA_ZR_Real AZD Aufwand Aufwand zur Realisierung der Schlüsselfundkmpnente Gesamtaufwand zur Realisierung des SVS Aufwand zur Realisierung der Schlüsselausgabekmpnente Aufwand zur Realisierung der Schlüsselausgabe- und Schlüsselrückgabekmpnente Aufwand zur Realisierung der Schlüsselausgabe- und Schlüsselrückgabekmpnente hne Spezifikatin und Systemtest Differenz zwischen geschätztem und tatsächlichem Aufwand zur Realisierung der Schlüsselausgabe- und Schlüsselrückgabekmpnente tatsächlicher Aufwand zur Realisierung der Schlüsselausgabeund Schlüsselrückgabekmpnente Aufwand zur Realisierung der Schlüsseldefektkmpnente Aufwand zur Spezifikatinserstellung Aufwand zur Realisierung der Schlüsselrückgabekmpnente Aufwand zur Realisierung der Schlüsselstammdatenerfassungskmpnente Aufwand für die Durchführung eines Systemtests Aufwand zur Realisierung der Schlüsselverlustkmpnente Aufwand zur Realisierung der Kmpnenten für den Schlüsselverlust, Schlüsselfund, Schlüsseldefekt, Zylinderdefekt und die Zylinderrückgabe Aufwand zur Realisierung der Zylinderausgabekmpnente Aufwand zur Realisierung der Zylinderausgabe- und Zylinderrückgabekmpnente Differenz zwischen geschätztem und tatsächlichem Aufwand zur Realisierung der Zylinderausgabe- und Zylinderrückgabekmpnente tatsächlicher Aufwand zur Realisierung der Zylinderausgabeund Zylinderrückgabekmpnente Aufwand zur Realisierung der Zylinderdefektkmpnente v

7 Abkürzungsverzeichnis AZR AZStD CAD CAFM DESY FLASH FM FMS FP GEFMA GIS/FMS HERA ILC IPP IS K KSA_SR_Diff KTag KZA_ZR_Diff OMG PETRA REP SVS TDI TP UFP UFPSA UFPSR UFPSStD UML V1 VAF XFEL Aufwand zur Realisierung der Zylinderrückgabekmpnente Aufwand zur Realisierung der Zylinderstammdatenerfassungskmpnente Cmputer Aided Design Cmputer Aided Facility Management Deutsches Elektrnen-Synchrtrn Freier Elektrnen Laser Hamburg Facility Management Facility-Management-System Funktinspunkt German Facility Management Assciatin Geinfrmatinssystem / Facility-Management-System Hadrn-Elektrn-Ring-Anlage Internatinal Linear Cllider Infrmatinsmanagement, Przesse, Prjekte Infrmatinssystem Entwicklungsksten Differenz zwischen geschätzten und tatsächlichen Ksten für die Realisierung der Schlüsselausgabe- und Schlüsselrückgabekmpnente Entwicklungsksten pr Tag Differenz zwischen geschätzten und tatsächlichen Ksten für die Realisierung der Zylinderausgabe- und Zylinderrückgabekmpnente Object Management Grup Psitrn-Elektrn-Tandem-Ring-Anlage Requirements Engineering Prcess Schlüsselverwaltungssystem Ttal Degree f Influence Team Perfrmance Unadjusted Functin Pint Unadjusted Functin Pint der Schlüsselausgabe Unadjusted Functin Pint der Schlüsselrückgabe Unadjusted Functin Pint der Schlüsselstammdatenerfassung Unified Mdelling Language Verwaltungsabteilung 1 Value added Factr X-ray free-electrn laser vi

8 1 Einleitung 1 Einleitung Die vrliegende Diplmarbeit wurde innerhalb eines Prjektes am Deutschen Elektrnen-Synchrtrn (DESY) in Hamburg erstellt. Ziel dieses Prjektes ist die Einführung eines Infrmatinssystems zur Unterstützung der Schlüsselverwaltungsprzesse am DESY. Bis zur Beendigung des Prjektes erflgte die Organisatin vn Gebäude- und Raumschlüsseln mit Hilfe eines Systems, das nicht über eine Anbindung an aktuelle Persnen-, Gebäude- und Raumdaten verfügt. Zylinderinfrmatinen wurden separat auf analgen Gebäudeplänen gepflegt. Diese mangelnde Vernetzung der relevanten Infrmatinen zur Schlüsselverwaltung erschwerte unter anderem das Ermitteln zutrittsberechtigter Persnen zu einem bestimmten Raum. Dieser Zustand sllte durch die Entwicklung einer neuen Systemkmpnente und durch ihre Integratin in ein existierendes DESY-System, welches zur Verwaltung vn Persnen-, Gebäude- und Raumdatenbeständen verwendet wird, behben werden. Die Infrmatinen zu den Mitarbeitern swie die Gebäude- und Raumdaten werden bei DESY in einem Geinfrmatins- und Facility-Management-System (GIS/FMS) dkumentiert und gepflegt. Die Aktualität der Datensätze und der technische Reifegrad des Systems ermöglichten es, eine Kmpnente zur Verwaltung vn Schlüsseln und Schließzylindern in das GIS/FMS zu integrieren. Das Schlüsselverwaltungssystem (SVS) wurde durch ein externes Entwicklerteam realisiert, dem zur technischen Umsetzung ein Anfrderungsdkument angefertigt im Hause DESY vrlag. Die Analyse der Schlüsselverwaltungsprzesse ist Inhalt der vrliegenden Diplmarbeit. Sie ist in zehn Kapitel unterteilt. Im Anschluss an die Einleitung wird der Prjektrahmen beschrieben. Begnnen wird hierbei mit der Schilderung des Anlasses, welcher die Durchführung des Prjektes rechtfertigt. Es flgen Ziel und Nutzen des Prjektes swie die Vrstellung der Prjektbeteiligten. Den dritten Abschnitt der Arbeit bildet das Grundlagenkapitel. Hier wird der Auftraggeber, das Deutsche Elektrnen-Synchrtrn, skizziert. Außerdem werden die Grundlagen zur Przessunterstützung mit Hilfe vn Infrmatinssystemen erläutert. Ebenfalls Bestandteil des Grundlagenkapitels sind eine Einführung in das Facility Management (FM) swie eine Vrstellung des GIS/FMS am DESY, welches für FMAufgaben eingesetzt wird. Des Weiteren wird der Bereich der Schlüsselverwaltung eine Teilaufgabe vn FM abgesteckt. Werkzeuge und Methden, die innerhalb des Diplmprjektes eingesetzt und angewandt wurden, werden im vierten Kapitel vrgestellt. Hier wird insbesndere auf die Prjektphasen Anfrderungserhebung, Analyse und Systementwurf eingegangen. Als Hilfsmittel zur Anfrderungserhebung fand die Metaplan-Technik Anwendung. Diese swie die Grundlagen zur Unified Mdelling Language (UML), mit Hilfe derer die Analyse der Schlüsselverwaltungsprzesse erflgte, werden innerhalb dieses Kapitels vrgestellt. Weiterhin werden Methden zur Durchführung eines Systemleistungs1

9 2 Prjekt vergleichs (Benchmarking) und einer Aufwands- und Kstenschätzung für die Entwicklung des SVS (Funktinspunktanalyse) beschrieben. Das flgende Analysekapitel setzt sich mit der Identifikatin des Ist-Zustandes der Schlüsselverwaltung swie der Analyse der Schlüsselverwaltungsprzesse auseinander. Im Hinblick auf das Ziel dieses Prjektes wird ferner der Sll-Zustand skizziert, der in Frm einer Spezifikatin dkumentiert wird. Die Präsentatin des Systementwurfes ist Gegenstand des sechsten Kapitels. Weiterhin flgen innerhalb dieses Arbeitsabschnittes die Schilderung der Implementierungsphase und die Vrstellung der Systemlösung. Kapitel sieben und acht befassen sich mit einem Leistungsvergleich zwischen dem DESY-SVS und einer Kaufsftware swie einer Aufwands- und Kstenschätzung für die vllständige Entwicklung einer Systemkmpnente zur Verwaltung des Schlüssel- und Zylinderbestandes. Es flgt in Abschnitt neun das Ausblickkapitel, welches Möglichkeiten zur Weiterentwicklung des SVS aufzeigt und die weiteren Schritte nach Beendigung des Prjektes benennt. Den Abschluss dieser Diplmarbeit bildet das Fazit, welches das Prjekt und seine Ergebnisse zusammenfasst und bewertet. Ein Ausschnitt der Spezifikatin, welche vn der Autrin der Diplmarbeit erstellt wurde und einem Entwicklerteam als Basis für die technische Umsetzung der Systemkmpnente diente, ist der vrliegenden Diplmarbeit als Anhang beigefügt. 2 Prjekt Die flgenden Abschnitte dieses Kapitels bieten einen Überblick über das Prjekt zur Entwicklung einer Systemkmpnente zur Unterstützung der Schlüsselverwaltungsprzesse am DESY, innerhalb dessen die vrliegende Diplmarbeit entstand. Zunächst wird der Anlass, welcher die Durchführung des Prjektes begründet, erläutert. Im Weiteren werden Ziele und Nutzen des Prjektes festgesteckt swie dessen Ablauf skizziert. Zur Kmplettierung des Überblicks werden abschließend die Beteiligten und ihre Rllen innerhalb des Prjektes vrgestellt. 2.1 Anlass Auf dem DESY-Campus in Hamburg-Bahrenfeld arbeiten zu Beginn des Prjektes ca DESYaner. Hinzu kmmen mehr als Gastfrscher swie mehrere hundert Auszubildende, Diplmanden, Dktranden und Nachwuchswissenschaftler 2

10 2 Prjekt (vgl. DESY 20051). Die Zahl der Beschäftigten steigt stetig, ebens wie die der Gebäude. In den nächsten Jahren werden unter anderem die neuen Experimentieranlagen PETRA III (Psitrn-Elektrn-Tandem-Ring-Anlage III) und XFEL (X-ray freeelectrn laser) entstehen, für die aus sicherheitstechnischen Gründen besndere Zutrittsregelungen gelten werden. Aus all diesen Faktren werden in Zukunft erhöhte Anfrderungen an die Verwaltung der Gebäude- und Raumschlüssel swie der Schließanlage resultieren Anfrderungen, die mit Hilfe der Methden und Werkzeuge, die zu Beginn des Prjektes angewendet wurden, nicht erfüllt werden könnten. Bisher griffen die Verantwrtlichen der DESY-Schließanlage und des Schlüssel- und Zylinderbestandes nicht auf zentrale Mitarbeiter- und Gebäude-/Raumdaten zurück, sndern führten diese in einem separaten Schlüsselverwaltungssystem. Gepflegt wurden diese Infrmatinen auf Grund des hhen Aufwandes und da ihre Verwaltung außerhalb des Schlüsselverwaltungsbereiches liegt, nicht. Die Zuständigkeit für die Dkumentatin und Pflege der Mitarbeiter- und Gebäudedaten liegt bei einer der Verwaltungsabteilungen. Der Datenbestand, auf den bei der Schlüsselverwaltung zurückgegriffen wurde, war smit inaktuell. Hinzu kmmt, dass das Schlüsselverwaltungssystem keine Schnittstelle zu dem Geinfrmatins- und Facilty-ManagementSystem, mit Hilfe dessen die Pflege der Persnal- und Gebäudedaten erflgt, besaß. Dies erschwerte die Erfüllung der Anfrderungen an die Schlüsselverwaltung. Das GIS/FMS wurde vr einigen Jahren am DESY eingeführt. Die darin gespeicherten Infrmatinen sind aktuell und der technische Reifegrad des Systems ermöglicht es, in Zukunft eine Kmpnente zur Verwaltung des Schlüssel- und Zylinderbestandes zu integrieren. 2.2 Ziel und Nutzen des Prjektes Das Ziel des Prjektes ist die Entwicklung und Einführung einer neuen Systemkmpnente für das GIS/FMS, die Funktinalitäten zur Unterstützung der Schlüsselverwaltungsprzesse bietet und einen Zugriff auf die zentralen Persnal- und Gebäudedaten erlaubt. Mit der Erweiterung des GIS/FMS sll eine Unterstützung der Verwaltungsprzesse und eine Optimierung des Schlüsselmanagements erreicht werden. Die Spezifikatin, welche die Anfrderungen an die Schlüsselverwaltungsprzesse swie die GIS/FMS-Erweiterung definiert und einem externen Entwicklerteam als Basis für die technische Umsetzung diente, wurde vn der Autrin der vrliegenden Diplmarbeit entwickelt und ist dieser Arbeit in Auszügen beigefügt. Die Arbeit selbst verflgt das Ziel, den Weg vm Beginn des Prjektes bis hin zur Vrstellung einer Systemlösung zu dkumentieren. Als Datenbasis für die künftige Verwaltung des Schlüssel- und Zylinderbestandes sllen die im GIS/FMS bereits vrhandenen Raum- und Persnendaten dienen. Dies wird gegenüber der bisherigen Methde zu einer Verbesserung der Qualität der Verwaltungsdaten führen. Infrmatinen zu Schlüssel- und Zylinderverbleib, bisher getrennt verwaltet, werden mit dem neuen SVS gepflegt und zentral einsehbar sein. 3

11 2 Prjekt Durch die Integratin der Schlüsselverwaltungsdaten in das GIS/FMS wird die Unterdisziplin des Facility Managements swhl technisch als auch lgisch in den FMBereich integriert. Gebäude-, Raum-, Persnen-, Zylinder- und Schlüsselinfrmatinen werden innerhalb des GIS/FMS miteinander verknüpft und ermöglichen einen schnellen und vllständigen Datenüberblick. Weiterhin sll durch die Zusammenfassung aller verwaltungsrelevanten Daten in einem Infrmatinssystem gewährleistet werden, dass Mitarbeiter, schnell und unkmpliziert in den Bereich der Schlüsselverwaltung eingeführt und im Umgang mit dem SVS geschult werden können, s dass für den Schlüsselverwalter, z.b. im Urlaubsfall, Ersatz bereit steht. 2.3 Prjektablauf Das Prjekt wurde nach einem systematischen Ablaufplan durchgeführt (siehe Abb. 1). Das aus sechs Schritten bestehende Schema wird im Flgenden kurz vrgestellt. Eine detailliertere Erläuterung der einzelnen Prjektphasen erflgt in den jeweiligen Kapiteln dieser Diplmarbeit. Abb. 1: Prjektablauf (eigene Darstellung) 1) Anfrderungserhebung In der ersten Phase des Prjektes werden Anfrderungen an den Sll-Zustand der Schlüsselverwaltung und die zu entwickelnde Systemkmpnente erhben. Die Anfrderungen definieren die Ziele des Prjektes und werden in einer Spezifikatin kmprimiert. 2) Analyse Im zweiten Schritt flgt die Analysephase. Hier werden die Przesse der Schlüsselverwaltung in ihre Aktinen zerlegt und eingehend betrachtet. Diese Aufschlüsselung dient als Basis für die nachflgende Prjektphase den Systementwurf. 4

12 2 Prjekt 3) Systementwurf Innerhalb dieses Abschnittes wird die Architektur des zu entwickelnden Teilsystems ausgearbeitet. Das Ergebnis dieser Entwurfsphase stellt die Vrlage für den vierten Prjektschritt die technische Umsetzung dar. 4) Technische Umsetzung In dieser Phase des Prjektes wird an Hand der Spezifikatin aus Schritt eins und des Systementwurfs aus Schritt drei die Kmpnente zur Verwaltung des Schlüssel- und Zylinderbestandes technisch durch ein externes Entwicklerteam realisiert. 5) Systemtest Im Anschluss an die Entwicklung der Systemkmpnente hat ein Systemtest zu erflgen. Hier werden die Funktinalitäten des Prduktes überprüft und gegebenenfalls Krrekturen und Anpassungen vrgenmmen. 6) Inbetriebnahme Nach einer ausführlichen Testphase kann die Systemkmpnente in Betrieb genmmen werden. Diese Prjektphase ist jedch kein Bestandteil der vrliegenden Diplmarbeit mehr und wird daher in der erläuternden Grafik in Abb. 1 ausgegraut. 2.4 Prjektbeteiligte Das Prjekt wurde vn der Abteilung V1 (Verwaltung 1) des Deutschen ElektrnenSynchrtrns in Auftrag gegeben und unter der Leitung der Autrin dieser Diplmarbeit durchgeführt. Unterstützend standen der Diplmandin in allen Prjektphasen Mitglieder der Gruppe IPP (Infrmatinsmanagement, Przesse, Prjekte) zur Seite. Mitarbeiter der Firma Hrstick waren als externe Entwickler für die technische Umsetzung der FMS-Erweiterung verantwrtlich. Die Abteilungsmitglieder vn V1 infrmierten die Auftragnehmer der Gruppe IPP über die Abläufe der Schlüsselverwaltung am DESY und entwickelten Anfrderungen an das zu realisierende Schlüsselverwaltungssystem. Die Erhebung der Anfrderungen erflgte durch die Autrin der Diplmarbeit, die vn den Prjektmitgliedern der Gruppe IPP darin unterstützt wurde. Ebenfalls in dieser Knstellatin wurde in der Analyse- und Entwurfsphase zusammengearbeitet. Die Entwickler der Firma Hrstick setzten die Systemkmpnente zur Verwaltung des Schlüssel- und Zylinderbestandes technisch auf Basis der DESY-Spezifikatin, erstellt vn der Autrin der vrliegenden Diplmarbeit, um. Das Entwicklerteam stellte dem DESYPrjektteam eine Testversin des SVS bereit, welche vn der Diplmandin und Mitgliedern der Gruppe IPP auf ihre Funktinalitäten geprüft wurde. Daten zur Durch5

13 3 Grundlagen führung des Systemtests stellten die prjektbeteiligten Mitglieder vn V1 zur Verfügung. 3 Grundlagen Das nachflgende Kapitel beschreibt die Grundlagen derjenigen Themenbereiche, die einen Bestandteil der vrliegenden Diplmarbeit darstellen. Zunächst werden das Deutsche Elektrnen-Synchrtrn und seine Kerntätigkeiten skizziert. Im Weiteren wird erläutert, inwiefern Przess durch den Einsatz vn Infrmatinssystemen unterstützt werden können. Es flgt eine Definitin und Beschreibung des Facility Managements. Eng mit diesem Thema ist die Ntwendigkeit vn Infrmatinssystemen CAFM-Systemen zur Durchführung vn FM-Aufgaben verbunden. Das Teilkapitel zum GIS/FMS am DESY liefert hierzu ein Praxisbeispiel. Abschließend flgt eine Definitin zum Thema Schlüsselverwaltung. 3.1 DESY Das Deutsche Elektrnen-Synchrtrn ist ein Frschungszentrum der HelmhltzGemeinschaft mit Standrten in Hamburg und Zeuthen (Brandenburg). Es wurde 1959 gegründet und entwickelt und baut Beschleunigeranlagen, die für die Frschung im Bereich der Teilchenphysik und für die Frschung mit Phtnen in Betrieb genmmen werden. Wissenschaftler aus aller Welt jährlich ca Gastfrscher aus 45 Natinen arbeiten mit DESY zusammen. Des Weiteren beteiligt sich das deutsche Frschungszentrum an internatinalen Prjekten, wie z.b. dem eurpäischen Röntgenlaser XFEL der dem Internatinalen Linearcllider ILC (vgl. DESY 2007). Abb. 2: Luftbild des DESY-Geländes (Quelle: DESY 2006) Frschung wird bei DESY vr Ort betrieben. Unter dem Werksgelände befindet sich neben Experimentieranlagen wie PETRA und FLASH (Freier Elektrnen Laser Hamburg) unter anderem ein Teil des sechs Kilmeter langen Beschleunigerrings HERA (Hadrn-Elektrn-Ring-Anlage) (siehe Abb. 2), der im Juni 2007 abgeschaltet wurde. Hier wurden seit 1992 Experimente aus dem Bereich der Teilchenphysik 6

14 3 Grundlagen durchgeführt. Die Auswertung der Ergebnisse wird über das Jahr 2010 hinaus andauern (vgl. DESY 2007). Abb. 3: Blick in den Hera-Tunnel (Quelle: DESY 20052) Bis 2013 werden unter dem DESY-Werksgelände zwei weitere Experimentieranlagen entstehen PETRA III (Inbetriebnahme 2009) und der XFEL (Inbetriebnahme 2013). Die Anlage des XFEL wird mit einer geplanten Länge vn ca. drei Kilmetern unterirdisch vn Hamburg bis nach Schleswig-Hlstein reichen und den Wissenschaftlern bei DESY neben PETRA III zur Frschung mit Phtnen dienen (vgl. DESY 2007). 3.2 Przessunterstützung durch Infrmatinssysteme Das Ziel dieses Prjektes ist die Einführung eines Infrmatinssystems zur Unterstützung der Schlüsselverwaltungsprzesse am DESY. Mit dieser Zieldefinitin wird gleichzeitig die These aufgestellt, dass Infrmatinssysteme in der Lage sind, die Durchführung vn Przessen zu unterstützen. Bevr im Flgenden diese These auf ihre Belegbarkeit geprüft wird, müssen zunächst einige Grundlagen erklärt werden. Przess Ein Przess besteht aus einer Menge vn Aktivitäten, die parallel der nacheinander ablaufen, um ein definiertes Ziel zu erreichen (vgl. Grässle/Baumann/Baumann 2007, S. 45 ff). Jeder Przess hat einen Beteiligten bzw. Akteur der mehr, welcher diese Aktivitäten durchführt (vgl. Jacbsn/Bch/Rumbaugh 2001, S. 25). Die Aktivitäten eines Przesses können swhl durch Menschen als auch durch Infrmatinssysteme umgesetzt werden (siehe Abb. 4). 7

15 3 Grundlagen Abb. 4: Umsetzungsmöglichkeiten vn Aktivitäten (eigene Darstellung) Infrmatinssystem Ein Infrmatinssystem ist ein System zur Speicherung, Wiedergewinnung, Verknüpfung und Auswertung vn Infrmatinen (zit. Grässle/Baumann/Baumann 2007, S. 277). Es wird eingesetzt, um statt eines Menschen Aktivitäten auszuführen und um smit die Abwicklung eines Przesses zu unterstützen. Die Aktinen, die ein Infrmatinssystem durchführt, werden Anwendungsfälle genannt. Anwendungsfall Bch, Jacbsn und Rumbaugh definieren einen Anwendungsfall als: A descriptin f a set f sequence actins, including variants, that a system perfrms that yields an bservable result f value t a particular actr (zit. Bch/Jacbsn/Rumbaugh 2001, S. 432). Ein Anwendungsfall ist demnach eine Abflge vn Aktinen, die ein System durchführt, um einem Anwender ein wahrnehmbares Resultat zu liefern. Eine spezifische Abflge der Aktinen innerhalb eines Anwendungsfalls wird als Szenari bezeichnet (vgl. Grässle/Baumann/Baumann 2007, S. 286). Infrmatinssysteme werden demnach eingesetzt, um Akteure bei der Durchführung vn Przessen zu unterstützen und an ihrer statt Aktinen auszuführen. Dieser Autmatismus kann in einem Unternehmen dazu führen, dass Mitarbeiter überflüssig und letztendlich vn einem Infrmatinssystem verdrängt werden. Diese Einsparung an Persnal kann im Endeffekt einen psitiven Einfluss auf die Wirtschaftlichkeit ausüben und zu einer Kstenreduktin führen. Infrmatinssysteme können für unterschiedliche Zwecke betrieben werden. Bei DESY wird z.b. das GIS/FMS zur Dkumentatin vn Geinfrmatinen und FM-Daten 8

16 3 Grundlagen eingesetzt, während SAP bei der Abwicklung betriebswirtschaftlicher Aufgaben Anwendung findet. 3.3 Facility Management Facility Management ist eine Management-Disziplin, die eine strategische Bewirtschaftung, Verwaltung und Organisatin aller Sachressurcen innerhalb eines Unternehmens zum Ziel hat (zit. Nävy 2003, S. 3). Ohne FM werden diese Sachressurcen (z.b. Grundstücke, Gebäude, Maschinen) ft unter Ausschluss der für sie verantwrtlichen Abteilungen betreut. Facility Management hingegen srgt dafür, dass die Ressurcen zu einer ganzheitlichen Betreuung zusammengeführt werden, was einen zentralen Zugriff auf alle FM-relevanten Infrmatinen innerhalb einer Organisatin ermöglicht (vgl. Nävy 2003, S. 3 ff). Diese Transparenz spielt im Facility Management eine entscheidende Rlle. Indem alle Infrmatinen zentral verfügbar und stets aktuell sind, wird erst die Bewirtschaftung, Verwaltung und Organisatin der Sachressurcen möglich (vgl. Nävy 2003, S. 6). Sachressurcen durchlaufen während ihres Lebenszyklus verschiedene Phasen (siehe Abb. 5). Facility Management findet hierbei in jeder einzelnen Lebensphase statt vn der Idee über die Planung, Erstellung, Nutzung bis hin zur Entsrgung der Ressurce (vgl. Nävy 2003, S. 5). Abb. 5: Lebensphasen einer Sachressurce (nach Nävy 2003, S. 72) Das Knzept des Facility Managements wurde Mitte der 50er Jahre gebren und seitdem stets weiterentwickelt. Ende der 70er Jahre kam FM erstmals in den USA aktiv zum Einsatz. Nach Deutschland gelangte die Management-Disziplin Ende der 80er Jahre mit der Gründung der GEFMA (German Facility Management Assciatin). Sie hat das Ziel, die Praktizierung des Facility Managements in den Unternehmen der Bundesrepublik zu fördern (vgl. Nävy 2003, S. 40 ff). Unterteilt man Facility Management in seine Unterdisziplinen, ergibt sich ein vielfältiges Bild an Aufgaben. S umfasst FM nicht nur das Management vn Gebäuden und Flächen, sndern auch der Kmmunikatinsanlagen. Abb. 6 stellt diese und weitere Aspekte des Facility Managements grafisch dar. 9

17 3 Grundlagen Abb. 6: Aspekte des Facility Managements (nach Nävy 2003, S. 4) 3.4 CAFM-Systeme Um Facility Manager bei der Erfüllung der in Abb. 6 dargestellten Aufgaben zu unterstützen, werden Infrmatinssysteme eingesetzt. Diese Aufgabenbewältigung mit Hilfe vn Cmputern verleiht FM auch den Namen Cmputer Aided Facility Management (CAFM). Abgeleitet hiervn werden die FM-unterstützenden Infrmatinssysteme auch CAFM-Systeme genannt. Diese begleiten die Sachressurcen durch alle Phasen ihres Lebenszyklus und ermöglichen allen Beteiligten durch die zentrale Speicherung aller FM-relevanten Infrmatinen einen zeitgleichen Zugriff auf redundanzfreie Daten (vgl. Nävy 2003, S. 67 ff). CAFM-Systeme setzen sich hauptsächlich aus zwei Kmpnenten zusammen: auf der einen Seite aus einer Datenbank, die alphanumerische Daten speichert und auf der anderen Seite aus dem Cmputer Aided Design (CAD), welches für die Verarbeitung vn grafischen Elementen verantwrtlich ist (siehe Abb. 7). 10

18 3 Grundlagen Abb. 7: Kmpnenten eines CAFM-Systems (nach Nävy 2003, S. 111) Beide Kmpnenten sind miteinander verknüpft, s dass eine Änderung der grafischen Daten im CAD gleichzeitig eine Aktualisierung der alphanumerischen in der Datenbank nach sich zieht. Dies garantiert ein Arbeiten mit redundanzfreien Daten und reduziert das Fehleraufkmmen (vgl. Nävy 2003, S. 69 ff). 3.5 GIS/FMS das CAFM-System am DESY Bei DESY werden die Aufgaben des Facility Managements in Unterstützung mit dem GIS/FMS umgesetzt. Es ist ein kmbiniertes Geinfrmatins- und FacilityManagement-System und wird bei DESY vn verschiedenen Abteilungen für unterschiedliche Zwecke verwendet unter anderem zur Planung und Dkumentatin vn Gebäuden und Anlagen. Das GIS/FMS beherbergt Sachdaten swie Bauzeichnungen, Übersichtskarten und Landkarten. Alphanumerische und gegrafische Daten sind hierbei in getrennten Datenbanken abgelegt. Des Weiteren ist in dem GIS/FMS das sgenannte Raumbuch integriert, welches Flächenmanagement (z.b. Berechnung vn Reinigungsflächen der freier Flächen für die Aufstellung neuer Experimentierstände) ermöglicht (vgl. Eucker 2005, S. 14 ff). Den technischen Aufbau des GIS/FMS beschreibt Abb. 8. Sach- der gegrafische Daten werden durch die Fachanwender in die jeweilige Benutzerberfläche eingetragen. Zu den Systemnutzern gehören unter anderem die Bauabteilung der die Verwaltung. Gespeichert werden die Daten über das DESY-Intranet in der jeweiligen Datenbank. Auch der Abruf der im GIS/FMS dkumentierten Infrmatinen ist ausschließlich über das DESY-Intranet möglich. 11

19 3 Grundlagen Abb. 8: GIS/FMS-Architektur (nach Eucker 2005, S. 15; Rbben 2004, S. 14) Das GIS/FMS basiert auf Standardsystemkmpnenten, die im Auftrag vn DESY um Funktinen ergänzt wurden. Die technische Umsetzung der vn DESY spezifizierten Zusatzfunktinen erflgte unter anderem vn der Firma Hrstick (vgl. Eucker 2005, S. 16). 3.6 Schlüsselverwaltung Eine der Teilaufgaben des Facility Managements ist die Schlüsselverwaltung. Sie zählt zum Sicherheitsmanagement, ist jedch auch eng mit dem Gebäudemanagement verknüpft (vgl. Nävy 2003, S. 254). Der Bereich der Schlüsselverwaltung lässt sich wiederum in weitere Unteraufgaben teilen. Im Fall des Schlüsselmanagements bei DESY wurden in Absprache mit den Verantwrtlichen dieses Arbeitsbereiches sieben Hauptaufgaben zu seiner Erfüllung definiert (siehe Abb. 9). Dazu gehören unter anderem die Erfassung vn Schlüssel- und Zylinderstammdaten swie die Ausgabe und Rücknahme vn Schlüsseln und Zylindern. Um die Schlüsselverwalter in der Durchführung dieser Aufgaben zu unterstützen, werden auch in diesem Bereich des Facility Managements CAFM-Systeme eingesetzt (vgl. Nävy 2003, S. 256). Abb. 9 fasst den Bereich der Schlüsselverwaltung, wie DESY ihn definiert, grafisch zusammen. 12

20 3 Grundlagen Abb. 9: DESY-Knzept der Schlüsselverwaltung (eigene Darstellung) Die Aufgaben bzw. Vrgänge der Schlüsselverwaltung werden vn einem Systemnutzer durchgeführt. Dieser kann swhl ein Verwalter als auch ein Administratr sein. Ein Vrgang kann sich swhl auf Schlüssel- als auch auf Zylinderexemplare beziehen. Beide besitzen eine Seriennummer, einen Status swie eine Ausgabestelle Infrmatinen, die individuell für ein Exemplar gelten. Schlüsselexemplare können zu einem Schlüssel, Zylinderexemplare zu einem Zylinder zusammengefasst werden. Diese Gruppierung ermöglicht die Zusammenfassung gleichartiger Schlüssel und Zylinder zu einem Typen (z.b. Einzelschlüssel der Einzelzylinder). Je nach Bedarf können smit Hierarchien gebildet werden, bei denen der Elternschlüssel die Schließeigenschaften all seiner Kinderschlüssel vereint. Den Kpf der DESY-Hierarchie stellt der Generalschlüssel, der alle Zylinder der DESY-Anlage schließen kann. Unter ihm flgen Obergruppen-, Gruppen-, Einzel- und Zentralschlüssel, die vn ben nach unten innerhalb der Schließhierarchie einzelne, immer kleinere Schließkreise schließen. 13

21 4 Werkzeuge und Methden Diese Definitin setzt vraus, dass ein Schlüsselexemplar ein Zylinderexemplar der mehrere schließen kann. Weiterhin legt das DESY-Mdell der Schlüsselverwaltung fest, dass ein Nutzer ein Schlüsselexemplar der mehr besitzen kann und ein Zylinderexemplar zwei Räumen zugerdnet ist. Diese Verknüpfungen zwischen Schlüssel- und Zylinderexemplar, Zylinderexemplar und Raum swie Schlüsselexemplar und Nutzer sind ntwendig, um eine krrekte und umfassende Durchführung der Schlüsselverwaltungsaufgaben zu gewährleisten. Erst mit der Vernetzung dieser Infrmatinen ist z.b. eine Überwachung vn Zutrittsregelungen möglich (vgl. May 2004, S. 30). Neben der Organisatin vn Raumschlüsseln gehört zum Schlüsselmanagement auch die Verwaltung vn Schlüsseln für Spinde, Tre, Fenster, Alarmkästen etc. Im Fall des Prjektes am DESY einigte man sich jedch darauf, zunächst nur die Verwaltung vn Raumschlüsseln anzustreben. 4 Werkzeuge und Methden Um einen Lösungsansatz für die GIS/FMS-Erweiterung zu entwickeln, wurden innerhalb der ersten drei Prjektphasen (siehe Abb. 1, Kapitel 2.3) verschiedene Werkzeuge verwendet und Methden angewandt. Ziel dieses Kapitels ist es, diese vrzustellen und zu erläutern. Zur Bewältigung der ersten Prjektphase werden zunächst die Grundlagen zur Erhebung vn Anfrderungen und deren Management vrgestellt. Als Methde zur Anfrderungserhebung wurde die Metaplan-Technik angewandt, die ebenfalls innerhalb dieses Kapitels umrissen wird. Weiterhin werden das Vrgehen zur Durchführung einer Przessanalyse swie Grundlagen zur Entwicklung eines Systementwurfes geschildert. Als Werkzeug zur Analyse der Schlüsselverwaltungsprzesse fand die Unified Mdelling Language (UML) Anwendung. Der entsprechende Kapitelabschnitt definiert die UML und stellt einzelne ihrer Elemente vr. Ebenfalls Bestandteil dieses Kapitels ist eine Erläuterung zur BenchmarkingMethde, welche innerhalb des Prjektes zur Leistungsbewertung der entwickelten Schlüsselverwaltungskmpnente angewandt wurde. Außerdem wird die Funktinspunktanalyse ein Hilfsmittel zur Abschätzung des Arbeitsaufwandes swie der Ksten eines Prjektes vrgestellt. 4.1 Anfrderungserhebung und -management Um mit dem Ergebnis des Prjektes den Wünschen des Auftraggebers gerecht zu werden, müssen zu Beginn ihre Anfrderungen an das zu entwickelnde Prdukt erhben werden. Das flgende Unterkapitel geht zunächst näher auf den Begriff der Anfrderung ein. Anschließend werden die einzelnen Phasen der Anfrderungsentwicklung vrgestellt. 14

22 4 Werkzeuge und Methden Was ist eine Anfrderung? Bevr auf das Thema des Anfrderungsmanagements eingegangen wird, muss zunächst der Begriff Anfrderung erklärt werden. Nach Chris Rupp ist eine Anfrderung eine Aussage über eine zu erfüllende Eigenschaft der zu erbringende Leistung eines Prduktes, eines Przesses der der am Przess beteiligten Persnen (zit. Rupp 2002, S.13). Anfrderungen an ein Prdukt können sich zum Beispiel an ein Infrmatinssystem richten. Diese Systemanfrderungen sind wiederum in zwei weitere Kategrien zu unterteilen: funktinale Anfrderungen nicht-funktinale Anfrderungen Funktinale Anfrderungen beschreiben, welche Aktinen ein System durchführen sll (vgl. Rupp 2002, S. 173). Hierbei wird nicht darauf eingegangen, WIE ein System etwas leisten sll, sndern WAS das System zu leisten hat. Nicht-funktinale Anfrderungen hingegen machen eine Aussage bezüglich der Systemeigenschaften das WIE. Mit ihnen können Vrgaben hinsichtlich Entwicklungsumgebung der zu verwendender Prgrammiersprachen getrffen werden (vgl. Bch/Jacbsn/Rumbaugh 2001, S. 447). Den Prjektbeteiligten dienen Anfrderungen vr allem als Kmmunikatins- und Wissensgrundlage Phasen der Anfrderungsentwicklung Bevr mit der Entwicklung vn Anfrderungen begnnen werden kann, müssen dem Prjekt zunächst klare Ziele gesetzt werden. Erst mit definierten Prjektzielen vr Augen können Anfrderungen zwecksgerichtet erhben werden (vgl. Rupp 2002, S. 20). Der Przess der Anfrderungsentwicklung wird auch Requirements-EngineeringPrcess (REP) genannt. Dieses Verfahren kapselt eine Reihe vn Aktivitäten, die den Prjektbeteiligten dabei helfen, die zu erbringenden Leistungen eines Systems herauszukristallisieren und diese in einem Anfrderungsdkument zusammenzufassen (vgl. Smmerville 2005, S. 16). Der Przess der Anfrderungsentwicklung unterteilt sich nach Ian Smmerville in sechs Phasen (siehe Abb. 10): Anfrderungserhebung Analyse der Anfrderungen Bestätigung der Anfrderungen durch die Auftraggeber Verhandlung Frmulierung der Anfrderungen / Dkumentatinsphase Management der Anfrderungsänderungen (nach Smmerville 2005, S.16 ff) 15

23 4 Werkzeuge und Methden Abb. 10: Phasen der Anfrderungsentwicklung (nach Smmerville 2005, S. 17) Smmerville betnt, dass es sich bei der Entwicklung der Anfrderungen um einen iterativen Przess handelt, bei dem die einzelnen Phasen mehrmals durchlaufen werden (vgl. Smmerville 2005, S. 17). Die Darstellung des REP in Abb. 10 unterstreicht diese These. In den flgenden Abschnitten wird näher auf die einzelnen Phasen der Anfrderungsentwicklung eingegangen. Anfrderungserhebung Die Erhebung vn Anfrderungen kann auf unterschiedliche Arten und mit Hilfe verschiedener Methden erflgen. Welche hierbei die richtige bzw. effektivste ist, hängt vn Faktren wie Zeit, Geld und Mtivatin der Kunden ab (vgl. Rupp 2002, S. 92). Vn Interviews über Brainstrming-Verfahren bis hin zu Fragebögen der Feldbebachtungen ist hier vieles möglich. Je nach Prjektsituatin sllte eine geeignete Technik gewählt werden. Das angewandte Erhebungsverfahren innerhalb dieses Prjektes wird in Kapitel 4.2 erläutert. Analyse In der Analysephase werden die Zusammenhänge zwischen den erhbenen Anfrderungen hergestellt. Diese Betrachtung erflgt ftmals mit Hilfe einer grafischen Darstellung. Durch die Mdellierung der Anfrderungen ist es möglich, die Qualität der Spezifikatin aufzudecken. Die beiden Przesse Anfrderungserhebung und Mdellierung sllten daher parallel stattfinden (vgl. Rupp 2002, S. 68 ff). Damit bei Änderungen im Laufe des Prjektes swhl die Anfrderungen als auch die entsprechenden Punkte im Mdell angepasst werden, muss eine bidirektinale Verbindung zwischen beiden bestehen. Widersprüchen und Redundanzen kann s entgegengesteuert werden (vgl. Rupp 2002, S. 70). 16

24 4 Werkzeuge und Methden Bestätigung und Verhandlung In der Bestätigungsphase werden die Anfrderungen den Auftraggebern präsentiert, um sich ihrer Krrektheit, Verständlichkeit und Vllständigkeit zu vergewissern. Dies stellt sicher, dass Analytiker und Auftraggeber die selben Ziele verflgen und dass Missverständnisse zwischen beiden Parteien ausgeräumt werden (vgl. Rupp 2002, S. 120; S. 122). In der Verhandlungsphase geht es darum, aus den unterschiedlichen Ansichten und Ansprüchen der Auftraggeber eine gemeinsame Linie zu bilden (vgl. Smmerville 2005, S. 17). Dkumentatin Die Menge der Anfrderungen, die auf diesem Wege innerhalb eines Prjektes frmuliert werden, bilden ein Anfrderungsdkument bzw. eine Spezifikatin. Diese dient während des Prjektes unter anderem für eine abschließende Prduktabnahme, z.b. für einen Systemtest. Verhält sich das System gemäß einer Anfrderung, kann diese als erfüllt festgehalten werden. Die Spezifikatin dient jedch nicht nur als Anleitung für einen Systemtest. Auch Systemänderungen erflgen ausschließlich auf Basis einer abgeänderten Spezifikatin (vgl. Rupp 2002, S. 14). Um zu gewährleisten, dass der Anfrderungskatalg qualitativ hchwertig ist, sind an jede Anfrderung Qualitätsansprüche zu stellen. Einige dieser Kriterien sind im Flgenden aufgelistet: Vllständigkeit Krrektheit Knsistenz Testbarkeit Gültigkeit Verstehbarkeit Umsetzbarkeit Ntwendigkeit Eindeutigkeit (vgl. Rupp 2002, S. 24) Anfrderungen haben allerdings nicht nur den ben aufgelisteten Qualitätskriterien zu genügen, sndern auch einer vrgeschriebenen Satzknstruktin zu entsprechen. Diese syntaktische Anfrderungsschablne, s Chris Rupp, reduziert Frmulierungsfehler und ermöglicht es, jeder Anfrderung eine ähnliche Struktur aufzuprägen (zit. Rupp 2002, S. 232). Abb. 11 stellt ein Muster zur Frmulierung vn Anfrderungen dar. Hierbei wird deutlich, dass eine Anfrderung verschiedene Verbindlichkeitsgrade aufweisen kann. Eine Pflicht wird durch MUSS, ein Wunsch durch SOLL und eine Absicht durch WIRD ausgedrückt. Des Weiteren kann eine Anfrderung nutzer- bzw. systemrientiert sein. 17

25 4 Werkzeuge und Methden Abb. 11: Anfrderungsschablne (nach Rupp 2002, S. 471) Vllständige Anfrderungen gemäß der Schablne in Abb. 11 können flgendermaßen aussehen: Das Schlüsselverwaltungssystem muss dem Nutzer die Möglichkeit bieten, verfügbare Schlüsselexemplare zu identifizieren. Das Schlüsselverwaltungssystem sll in der Lage sein, Daten zu imprtieren. Anfrderungen können außerdem unter Einbeziehung vn Bedingungen frmuliert werden. Eine entsprechende Schablne findet sich in Abb. 12. Abb. 12: Anfrderungsschablne mit Bedingung (nach Rupp 2002, S. 472) Flgende Anfrderungen dienen als Beispiel für eine Frmulierung mit Hilfe der Anfrderungsschablne in Abb. 12: Nach der Speicherung der Przessdaten sll der Schlüsselausgabe-Wizard dem Systemnutzer die Möglichkeit bieten, sich eine Übersicht des durchgeführten Vrgangs anzeigen zu lassen. Wurde ein Przess erflgreich durchgeführt, sll das System eine Übersicht des durchgeführten Vrgangs ausdrucken. Beide Schablnen gelten nur für die Frmulierung vn funktinalen und nichtfunktinalen Anfrderungen. Für das Ausfrmulieren vn Anfrderungen an Przes18

26 4 Werkzeuge und Methden se der für an einem Przess beteiligte Persnen müssen andere Muster herangezgen werden. Management Da während eines Prjektes ftmals grße Mengen an Anfrderungen entwickelt werden, ist ein definiertes Verfahren ntwendig, um diese beherrschbar zu machen. An diesem Punkt setzt das Anfrderungsmanagement an. [...] es ermöglicht, die ftmals unüberschaubare Anzahl an Anfrderungen kmplexer Prjekte zu beherrschen (zit. Rupp 2002, S. 15). Anfrderungsmanagement dient zur Vermeidung vn Fehlern in der Analysephase eines Prjektes und erhöht die Qualität der Anfrderungen (vgl. Rupp 2002, S. 12 ff). Die Vraussetzung für eine hhe Qualität der Anfrderungen setzt jedch vraus, dass auch dessen Änderungen gerade in kmplexen Prjekten bewältigt werden. Hierzu bedient man sich Requirements-ManagementTechniken. Die richtige Herangehensweise ist hierbei entscheidend darüber, b die Prjektbeteiligten trtz frtlaufender Änderungen an dem Anfrderungsdkument stets auf die selbe Arbeitsgrundlage zurückgreifen. Anfrderungsmanagement ermöglicht ein paralleles Arbeiten aller Prjektbeteiligten mit der Spezifikatin und garantiert einen einheitlichen Infrmatinsstand (vgl. Rupp 2002, S. 15). Prfessinelles Anfrderungsmanagement kann demnach maßgeblich zu einem erflgreichen Prjektabschluss beitragen (vgl. Rupp 2002, S. 12 ff). 4.2 Anfrderungserhebung mit der Metaplan-Technik Innerhalb des DESY-Prjektes zur Einführung eines SVS wurde zur Anfrderungserhebung die Metaplan-Technik angewandt. Sie ist jedch nicht nur für die Erhebung vn Anfrderungen geeignet, sndern als mderierte Gruppenarbeitsmethde vielfältig einsetzbar. Mit Hilfe einer Kartenabfrage werden Ideen und Aspekte zu einem vrgegebenen Thema gesammelt. Den Teilnehmern der Arbeitsgruppe werden Aufgaben bzw. Fragen präsentiert, die in einem festgesteckten Zeitrahmen zu bearbeiten sind. Jedes Gruppenmitglied ntiert seine Ideen auf Karten. Dabei ist zu beachten, dass auf jeder Karte stets nur ein Gedanke festgehalten wird. Am Ende der Bearbeitungszeit werden die einzelnen Ideen vrgelesen und zur Gruppendiskussin freigegeben. Ist ein Gedanke nicht für alle Arbeitsgruppenteilnehmer nachvllziehbar, wird er vn dem Verfasser erläutert. Die Karten werden an eine Pinwand gesteckt und unter Einbeziehung aller Teilnehmer thematisch srtiert. Der kmplette Verlauf des Wrkshps wird vn einem Mderatr krdiniert und begleitet. Diese Arbeitsmethde dient dazu, alle Gruppenmitglieder in die Ideenfindung zu invlvieren und ein möglichst breites Spektrum an Ideen und Meinungen zu erzielen (vgl. Dnnert/Sterzenbach 1999, S ). 19

27 4 Werkzeuge und Methden 4.3 Analyse Im Anschluss an die Anfrderungserhebung flgt die Analyse. In dieser Prjektphase findet eine tiefere Auseinandersetzung mit den Anfrderungen statt, was dabei hilft, einen detaillierteren Blick auf den Prblembereich zu erhalten und diesen zu verstehen (vgl. Bch/Jacbsn/Rumbaugh 2001, S. 174; Hitz/Kappel 1999, S. 178). Die Analyse ist Vraussetzung, um später ein Design bzw. einen Systementwurf anfertigen zu können. Außerdem können Fehler in den Anfrderungen durch ihre genaue Betrachtung innerhalb dieser Prjektphase frühzeitig erkannt und behben werden, bevr sie bei der Erstellung der Systemarchitektur weiterverarbeitet werden. In der Erhebungsphase werden die Anfrderungen in natürlicher Sprache frmuliert, um den Bedürfnissen der Kunden gerecht zu werden. In der Analysephase kann auf andere, präzisere Ausdrucksmöglichkeiten z.b. die UML (siehe Kapitel 4.4) zurückgegriffen werden (vgl. Bch/Jacbsn/Rumbaugh 2001, S. 173 ff). Als Resultat steht ein Analyse-Mdell, welches sich durch einen gewissen Abstraktinsgrad auszeichnet und möglichst wenige Details aufweist. Zu diesem Zeitpunkt ist das Mdell nch frei vn jeglichen Umsetzungsmöglichkeiten. In der Design-Phase dient es als Grundlage für die Anfertigung eines Systementwurfs (vgl. Bch/Jacbsn/Rumbaugh 2001, S. 176 ff). Dem vllständigen Analyse-Mdell nähert man sich in mehreren Schritten. Man wandert hierbei vm Grben ins Feine (siehe Abb. 13). Abb. 13: Schritte der Analysephase (eigene Darstellung) 1) Identifikatin der Geschäftsanwendungsfälle Im ersten Schritt werden die Geschäftsanwendungsfälle des zu betrachtenden Prblembereiches identifiziert. Ein Geschäftsanwendungsfall ist ein Przess innerhalb einer betrieblichen Organisatinsstruktur, an dessen Ende das Erreichen eines betrieblichen Ziels steht (vgl. Grässle/Baumann/Baumann 2007, S. 46). Mit diesem Schritt wird ein Überblick zur Thematik geschaffen, während die flgenden Schritte auf eine nähere Betrachtung der einzelnen Geschäftsanwendungsfälle abzielen. 20

28 4 Werkzeuge und Methden 2) Auslösenden Akteur identifizieren Im zweiten Schritt flgt die Bestimmung des auslösenden Akteurs des betrachteten Geschäftsanwendungsfalls. Der auslösende Akteur repräsentiert eine Rlle für einen agierenden Teilnehmer innerhalb eines Przesses, der diesen aktiv einleitet. 3) Beteiligte Akteure identifizieren Neben dem auslösenden Akteur wird ein Geschäftsanwendungsfall durch weitere Przessteilnehmer durchgeführt. Diese Akteure werden innerhalb des dritten Schrittes bestimmt. 4) Ergebnis / Geschäftswert identifizieren Jeder Geschäftsanwendungsfall hat mit der Erbringung eines Geschäftswertes zu enden. Dieses Przessergebnis ist in Schritt vier zu ermitteln. Die Durchführung dieser vier Schritte gewährleistet, dass die Zusammenhänge des Prblembereiches erkannt wurden (vgl. Oestereich 2001, S. 96 ff; S. 129 ff). Eine Ausdifferenzierung der einzelnen Geschäftsanwendungsfälle erflgt mit Hilfe der flgenden beiden Schritte. 5) Ablaufbeschreibung In diesem Schritt wird der Ablauf eines Geschäftsanwendungsfalls dargestellt. Hierbei ist darauf zu achten, dass der Przess durch eine Aktin des auslösenden Akteurs begnnen wird. Des Weiteren muss berücksichtigt werden, dass Przessabläufe nicht immer linear sind, sndern durch Ausnahmen und Verzweigungen einen anderen Weg als den Standardablauf verflgen können. Um sich nicht in unnötige und sich möglicherweise verändernde Details zu verlieren, werden die Aktinen eines Geschäftsanwendungsfalls möglichst allgemein und abstrakt frmuliert (vgl. Oestereich 2001, S. 101 ff). In dieser Phase der Analyse wird zunächst vllständig lösungsfrei mdelliert. 6) Identifikatin der Systemanwendungsfälle Welche Aktinen eines Geschäftsanwendungsfalls letztendlich durch ein Infrmatinssystem unterstützt werden sllen, wird innerhalb dieses Schrittes durch die Identifikatin der Systemanwendungsfälle bestimmt (vgl. Oestereich 2001, S. 109 ff). Ebenfalls Teil der Analysephase ist die strukturelle Darstellung des Prblembereiches. Hierbei werden zunächst die Geschäftsklassen identifiziert und schließlich die Beziehungen zueinander bestimmt (vgl. Oestereich 2001, S. 120 ff). Ein Beispiel für eine derartige Darstellung findet sich in Abb. 9 in Kapitel

29 4 Werkzeuge und Methden 4.4 Geschäftsprzessanalyse mit der Unified Mdelling Language Zur Analyse der Geschäftsprzesse der Schlüsselverwaltung wurde innerhalb dieses Prjektes die Unified Mdelling Language verwendet. Der flgende Kapitelabschnitt klärt zunächst, was sich hinter der UML verbirgt. Anschließend flgt eine Vrstellung ausgewählter Diagrammtypen swie ihrer Elemente, die innerhalb dieses Prjektes Anwendung fanden. Im Einzelnen werden Anwendungsfall-, Aktivitäts- und Klassendiagramm vrgestellt Was ist UML? Die Unified Mdelling Language ist eine vn der Object Management Grup (OMG) standardisierte grafische Sprache. Ursprünglich wurde sie vn Grady Bch und James Rumbaugh, später auch vn Ivar Jacbsen, als Ntatin zur bjektrientierten Analyse entwickelt (vgl. Ose 2007). Die erste standardisierte Versin der UML wurde 1996 vn der OMG veröffentlicht (vgl. Grässle/Baumann/Baumann 2007, S. 19). Die UML ermöglicht es, die Artefakte eines Systems zu visualisieren, zu spezifizieren, zu knstruieren und zu dkumentieren. Weiterhin kann sie zur Mdellierung vn Geschäftsprzessen eingesetzt werden (vgl. ISO/IEC 2005, S. 2). Ein Prblembereich, seien es Geschäftsprzesse der Infrmatinssysteme, kann aus unterschiedlichen Sichten dargestellt werden. Für jede Sicht gibt es einen Diagrammtypen, um die hervrzuhebenden Aspekte darzustellen (vgl. Bch/Jacbsn/Rumbaugh 2001, S. 23 ff). Dabei müssen alle Diagramme der unterschiedlichen Sichten in Beziehung zueinander stehen, da sie den selben Prblembereich, jedch aus unterschiedlichen Perspektiven, darstellen (vgl. Hitz/Kappel 1999, S. 6). Seit Anfang des Jahres 2007 steht UML in der Versin zur Verfügung (vgl. OMG1 2007) Diagrammtypen der UML Wie in dem vrangegangen Kapitelabschnitt erwähnt, kennt die UML verschiedene Diagrammtypen insgesamt dreizehn an der Zahl,die jeweils einen anderen Fkus auf den dargestellten Sachverhalt legen (vgl. OMG2 2007). Im Flgenden werden diejenigen Diagramme und ihre Elemente, die zur Analyse des Schlüsselverwaltungsknzeptes innerhalb dieses Prjektes verwendet wurden, vrgestellt. Anwendungsfalldiagramm Anwendungsfalldiagramme zeigen Anwendungsfälle, Akteure und deren Beziehungen zueinander. Sie geben einen Überblick über die Aktinen, die vn einem Anwendungsfall umfasst werden, geben jedch keine Infrmatin darüber, in welcher zeitli22

30 4 Werkzeuge und Methden chen Reihenflge diese Aktinen ablaufen der welcher Akteur diese ausführt (vgl. Grässle/Baumann/Baumann 2007, S. 64; Oestereich 2001, S. 196). Akteure werden in Anwendungsfalldiagrammen durch Strichmännchen dargestellt. Jeder Akteur steht für eine Rlle, die vn einem Beteiligten eines Anwendungsfalls eingenmmen werden kann. Akteure lösen Anwendungsfälle, die durch Ellipsen dargestellt werden, aus (vgl. Grässle/Baumann/Baumann 2007, S. 65). Der Anwendungsfall Schlüssel ausgeben wird beispielsweise durch den Akteur Gebäudenutzer ausgelöst (siehe Abb. 14). Abb. 14: Anwendungsfalldiagramm (eigene Darstellung) Ein Anwendungsfall kann in einzelne Unteranwendungsfälle aufgegliedert werden. (vgl. Grässle/Baumann/Baumann 2007, S. 62). Diese werden dem Hauptanwendungsfall durch include- der extend-beziehungen zugerdnet (vgl. Oestereich 2001, S. 199 ff). Die include-beziehung sagt aus, dass einem Hauptanwendungsfall ein Unteranwendungsfall angehört (vgl. Oestereich 2001, S. 207). Hiermit kann demnach beschrieben werden, aus welchen Teilschritten sich ein Anwendungsfall zusammensetzt, was ein detaillierteres Bild über den betrachteten Bereich liefert. Der Anwendungsfall Schlüssel ausgeben umfasst beispielsweise die Anwendungsfälle Schlüssel anfrdern, Schlüssel anbieten etc. (siehe Abb. 14). Die extend-beziehung hingegen drückt aus, dass der Hauptanwendungsfall in einem speziellen Szenari um einen Anwendungsfall erweitert wird (vgl. Oestereich 2001, S. 207). In dem Beispieldiagramm in Abb. 14 wird der Anwendungsfall Schlüssel ausgeben durch den Unteranwendungsfall Exemplar beschaffen erweitert. Bei der Durchführung der Schlüsselausgabe muss demnach in einigen Fällen ein Schlüsselexemplar beschafft werden, um den Przess erflgreich beenden zu können. 23

31 4 Werkzeuge und Methden Aktivitätsdiagramm Ein Aktivitätsdiagramm stellt die zeitliche Abflge der Aktinen eines Przesses dar. Als Aktin ist hierbei ein einzelner Schritt innerhalb eines Przesses zu verstehen (vgl. Grässle/Baumann/Baumann 2007, S. 79 ff). Neben Arbeitsabläufen stellen Aktivitätsdiagramme Zuständigkeiten dar. Diese werden durch Partitinen der auch sgenannte Schwimmbahnen, denen Aktinen zugeteilt werden, verdeutlicht (vgl. Grässle/Baumann/Baumann 2007, S. 84). Im Flgenden werden die einzelnen Elemente eines Aktivitätsdiagramms vrgestellt. Eine entsprechende grafische Darstellung findet sich in Abb. 15. Start- und Endpunkt eines Przesses werden in einem Aktivitätsdiagramm durch entsprechende Kreissymble markiert (vgl. Hitz/Kappel 1999, S. 153). Aktinen werden durch Rechtecke mit abgerundeten Ecken dargestellt. Ist eine Aktin durchgeführt, wird mit einem vn ihr ausgehenden Pfeil eine weitere Aktin ausgelöst. Aktivitätsdiagramme sind weiterhin in der Lage, Alternativabläufe darzustellen. Dies ist möglich, indem der ausgehende Pfeil einer ausgeführten Aktin zu einem Entscheidungspunkt, dargestellt durch eine Raute, führt. Vn ihm aus kann ein Ablauf in unterschiedliche Richtungen frtgesetzt werden. Treffen zwei Abläufe an einem Punkt wieder zusammen, wird dies durch eine Raute mit mehreren eingehenden Pfeilen dargestellt (vgl. Oestereich 2001, S. 290). Abb. 15: Aktivitätsdiagramm (eigene Darstellung) Das Beispielaktivitätsdiagramm in Abb. 15 lässt sich wie flgt lesen: Besteht ein Bedarf, frdert ein Gebäudenutzer einen Schlüssel an. Ein Verwalter bietet Schlüssel an und der Gebäudenutzer wählt einen davn aus. Ist der ausgewählte Schlüssel nicht 24

32 4 Werkzeuge und Methden verfügbar, wird ein Exemplar durch den Verwalter beschafft. Wurde ein Exemplar beschafft der ist eines im Lager befindlich, händigt der Verwalter dieses aus. Przesse können bei Bedarf mit einem Objektfluss dargestellt werden (siehe Abb. 16). Hierunter sind ein- und ausgehende Infrmatinen bei der Durchführung vn Aktinen zu verstehen. Diese werden durch rechteckige Objekte dargestellt. Ein Objekt kann in einem Aktivitätsdiagramm mehrfach verarbeitet werden. In diesem Fall wird es durch seinen jeweiligen Zustand in eckigen Klammern dargestellt ergänzt. (vgl. Grässle/Baumann/Baumann 2007, S. 81 ff; Hitz/Kappel 1999, S. 158 ff). Abb. 16: Aktivitätsdiagramm mit Objektfluss (eigene Darstellung) Die Aussage des Aktivitätsdiagramms in Abb. 16 ist flgende: Besteht ein Bedarf, frdert ein Gebäudenutzer einen Schlüssel an und initiiert s eine Ausgabe. Ein Verwalter bietet Schlüssel an und übermittelt dem Gebäudenutzer ein Angebt. Dieser wählt einen Schlüssel aus. Ist der ausgewählte Schlüssel nicht verfügbar, beschafft der Verwalter ein Exemplar. Ist das Schlüsselexemplar beschafft, händigt der Verwalter dieses aus. Dasselbe geschieht bei Verfügbarkeit des Schlüssels. Wurde das Exemplar übergeben, gilt die Schlüsselausgabe als beendet. 25

33 4 Werkzeuge und Methden Klassendiagramm Klassendiagramme stellen Klassen und ihre Beziehungen zueinander dar (vgl. Oestereich 2001, S. 326). Mit ihnen können swhl die Strukturen eines Geschäftssystems als auch die eines Infrmatinssystems als ein Systementwurf verdeutlicht werden (vgl. Grässle/Baumann/Baumann 2007, S. 107; S. 160). Beide Diagramme stehen in Beziehung zueinander und zeigen die Infrmatinen des zu betrachtenden Bereiches aus unterschiedlichen Perspektiven (vgl. Grässle/Baumann/Baumann 2007, S. 255). Klassendiagramme werden weiterhin zur Begriffsklärung eingesetzt. Ein Klassendiagramm besteht wie der Name schn sagt zum einen aus Klassen. Diese stehen für ein Knzept, eine Menge vn Persnen der Dingen mit denselben Eigenschaften (vgl. Grässle/Baumann/Baumann 2007, S. 161). Klassen werden durch Rechtecke dargestellt. Jede Klasse besitzt einen Namen und wird zusätzlich durch Attribute und Operatinen ergänzt (vgl. Oestereich 2001, S. 209). Attribute beschreiben die Eigenschaften einer Klasse, während die Operatinen ihr Verhalten kennzeichnen (vgl. Oestereich 2001, S. 40). Klassen sind über Beziehungen verschiedenster Art miteinander verbunden. Die einfachste Beziehung zwischen zwei Klassen wird Assziatin genannt. Sie kann mit einem Zusatz versehen werden, der die Art der Beziehung näher beschreibt. Ohne eine Assziatin stehen zwei Klassen nicht in Verbindung zueinander und können smit auch nicht miteinander kmmunizieren (vgl. Oestereich 2001, S. 262). Die Generalisierung ist eine weitere Art der Beziehung. Sie drückt aus, dass Klassen mit den gleichen Merkmalen zu einer gemeinsamen Klasse zusammengefasst werden. Generalisierungen werden als Pfeile dargestellt und als ist-beziehung gelesen (vgl. Grässle/Baumann/Baumann 2007, S. 157). Z.B.: Eine Ausgabe ist ein Vrgang (siehe Abb. 17). Sind zwei Klassen durch eine Aggregatin miteinander verbunden, wird dadurch ausgedrückt, dass eine der beiden Klassen sich zum Teil aus der anderen zusammensetzt. Eine Aggregatin wird wie eine Assziatin dargestellt, jedch unter dem Zusatz einer Raute auf Seiten der übergerdneten Klasse. Diese Art der Beziehung wird als besteht aus gelesen (vgl. Oestereich 2001, S. 280). Z.B.: Eine Schließgruppe besteht aus mehreren Gruppen (siehe Abb. 17). Assziatinen und Aggregatinen können mit einem Zusatz versehen werden: der Multiplizitätsangabe. Sie sagt aus, wie viele Objekte miteinander in Beziehung stehen (vgl. Oestereich 2001, S. 262). Multiplizitätsangaben können mit unterschiedlichen Werten belegt werden: 0 1 Ein Objekt steht zu keinem der einem Objekt in Beziehung 1 Es besteht eine Verbindung zu genau einem Objekt einer Klasse 26

34 4 Werkzeuge und Methden * Es besteht eine Beziehung zwischen einem Objekt und vielen Objekten einer Klasse 1...* Ein Objekt kann mit einem Objekt der mehreren Objekten in Beziehung stehen Abb. 17: Klassendiagramm (eigene Darstellung) Abb. 17 zeigt ein Beispiel eines Klassendiagramms mit den ben angeführten Elementen und lässt sich flgendermaßen lesen: Ausgaben und Rückgaben sind Vrgänge. Ein Systemnutzer führt einen Vrgang der mehrere durch. Jeder Vrgang besitzt ein Datum und bezieht sich auf ein Schlüsselexemplar der mehr. Ein Schlüsselexemplar besitzt die Attribute Schlüsselseriennummer, Status und Ausgabestelle. Ein Schlüsselexemplar der mehr können zu einem Schlüssel gruppiert werden. Dieser besitzt das Attribut Typ. Schlüssel und Schließgruppen sind Gruppen. Eine Schließgruppe setzt sich aus mehreren Gruppen zusammen. Beide besitzen eine Bezeichnung. 27

35 4 Werkzeuge und Methden 4.5 Systementwurf (Design) Unter einem Design ist die Entwicklung eines Systemknzeptes zu verstehen, welches dazu dient, ein definiertes Prblem zu lösen. Die Entwicklung hat unter Einbeziehung erhbener nicht-funktinaler Anfrderungen und Rahmenbedingungen zu erflgen (vgl. Oestereich 2001, S. 145; Bch/Jacbsn/Rumbaugh 2001, S. 215). In der Design-Phase wird unter anderem entschieden, auf welcher Entwicklungsumgebung gearbeitet der welche Prgrammiersprache zur Umsetzung verwendet werden sll (vgl. Hitz/Kappel 1999, S. 180; S. 257). Das Design wird auf Basis des Analyse-Mdells entwickelt. Die Design-Phase stellt einen Übergang zwischen der Ausarbeitung und der Knstruktinsphase dar (vgl. Bch/Jacbsn/Rumbaugh 2001, S. 215 ff). Als Ergebnis entsteht ein DesignMdell, welches die Struktur bzw. Architektur des zu entwickelnden Systems darstellt und einen Entwurf für die letztendliche Implementierung liefert (vgl. Bch/Jacbsn/Rumbaugh 2001, S. 265). Es gibt verschiedene Arten vn Architekturen, die aus unterschiedlichen Elementen bestehen können (vgl. Oestereich 2001, S. 145). Im Flgenden werden einige Bespielbestandteilen genannt, die auch in dem System, welches innerhalb dieses Prjektes entwickelt wurde, wiederzufinden sind. Eine grafische Darstellung dieser beispielhaften Architektur findet sich in Abb. 18. Abb. 18: Beispiel einer Systemarchitektur (nach Oestereich 2001, S. 146) 28

36 4 Werkzeuge und Methden Dialg Der Dialg ist eine Interface-Klasse und stellt eine Schnittstelle zum Systemnutzer (Client) dar. Über dieses Element erflgen Eingaben durch den Client swie die Darstellung vn Infrmatinen am Bildschirm. Der Dialg setzt sich jedch nicht nur aus Elementen zusammen, die für den Anwender am Mnitr sichtbar sind. Weiterhin kann eine Steuerungsklasse hinter dem Dialg stehen, die ihn krdiniert (vgl. Oestereich 2001, S. 146). Dialge können unterschiedliche Erscheinungsfrmen haben. Einige ermöglichen dem Nutzer eine freie Kmmunikatin. In anderen Fällen werden benutzerführende Dialge sgenannte Wizards eingesetzt (vgl. Oestereich 2001, S. 175). Dialg-Agent Der Dialg-Agent ist eine Steuerungsklasse und dient als Vermittler zwischen der Dialgsteuerung und den Steuerungselementen auf Seiten des Servers. Der DialgAgent ist auf einen bestimmten Dialg angepasst, nimmt Daten vn ihm entgegen und leitet diese weiter. Umgekehrt leitet der Dialg-Agent Daten an die Dialgsteuerung weiter (vgl. Oestereich 2001, S. 147). Anwendungsfallsteuerung Eine Anwendungsfallsteuerung ist ebenfalls eine Steuerungsklasse und für die Krdinierung vn reihenflglich festgelegten Abläufen eines Anwendungsfalls der mehrerer Anwendungsfälle verantwrtlich. Sie aktiviert bzw. deaktiviert Dialge und dient als weiterleitende Instanz zwischen Dialgsteuerung und Wrkflwsteuerung bzw. den fachlichen Kmpnenten (vgl. Oestereich 2001, S. 147). Als Anwendungsfallsteuerung im Bereich der Schlüsselverwaltung kann z.b. die IS-unterstützte Dkumentatin einer Schlüsselausgabe verstanden werden. Wrkflwsteuerung Eine weitere Steuerungsklasse innerhalb der beispielhaften Systemarchitektur aus Abb. 18 ist die Wrkflwsteuerung. Sie initiiert, überwacht und steuert die Abarbeitung eines Geschäftsvrfalls (zit. Oestereich 2001, S. 146). Falls zwischen den Anwendungsfällen eines Geschäftsvrfalls zeitliche Spannen liegen, srgt die Wrkflwsteuerung dafür, dass der aktuelle Zustand der Bearbeitung für die Zeit der Unterbrechung gespeichert wird (zit. Oestereich 2001, S. 148). Im Fall der Schlüsselverwaltung kann als Wrkflwkmpnente ein Ausgabe- der Rückgabe-Wizard verstanden werden. Fachklassen Die fachlichen Kmpnenten stehen für die Fachklassen inklusive der Attribute und Operatinen eines Geschäftsbereiches. Fachlich zusammengehörende Klassen werden in der Design-Phase zu fachlichen Kmpnenten zusammengefasst (vgl. Oestereich 2001, S ). Im Bespiel der Schlüsselverwaltung würde aus den Fach29

37 4 Werkzeuge und Methden klassen Schlüssel und Schlüsselexemplar die fachliche Kmpnente Schlüsselbestand werden. Diese Kmpnente kann der Anwendungsfallsteuerung Daten wie Schlüsselseriennummer, Schlüsseltyp, Status der Ausgabestelle liefern. Die fachlichen Kmpnenten werden auch als Infrmatinsbjekte bezeichnet. 4.6 Benchmarking Benchmarking ist ein Instrument der Wettbewerbsanalyse, welches dazu dient, Prdukte, Przesse, Organisatinsstrukturen und Strategien des eigenen Unternehmens mit denen der marktführenden Knkurrenz zu vergleichen. Es ermöglicht, Stärken und Schwächen gegenüber Spitzenunternehmen zu identifizieren, um Leistungslücken systematisch zu schließen (vgl. 4managers; Sabisch/Tintelnt 1997, S. V). Benchmarking erflgt üblicherweise in einem fünfstufigen Verfahren (siehe auch Abb. 19): 1) 2) 3) 4) 5) Auswahl des zu untersuchenden Objektes (Prdukt, Przess...) Auswahl des Vergleichsunternehmens bzw. Vergleichsbjektes Datengewinnung Infrmatinsanalyse: Feststellung vn Leistungslücken und ihrer Ursachen Umsetzung der Erkenntnisse (nach Karlöf/Östblm 1994, S. 86; 4managers) Abb. 19: Vrgehensweise beim Benchmarking (eigene Darstellung) 1) Untersuchungsbjekt wählen Zunächst muss entschieden werden, was benchmarked werden sll. Hierbei kann es sich um ein spezielles Prdukt, einen Przess, eine Strategie, eine Prjekt- der Organisatinsstruktur handeln. 2) Vergleichsbjekt wählen Im zweiten Schritt ist ein Vergleichsbjekt zu wählen. Dies kann ein Objekt innerhalb des Unternehmens sein (internes Benchmarking), ein Objekt eines branchenähnlichen Unternehmens (externes Benchmarking) der ein Objekt eines Unternehmens jeder Branche (funktinales Benchmarking) (vgl. Karlöf/Östblm 1994, S ). 30

38 4 Werkzeuge und Methden 3) Daten erheben Es flgt die Phase der Infrmatinsbeschaffung. Dies kann auf unterschiedlichen Wegen erflgen: über Fragebögen, Interviews, Recherche nach allgemeinen Wirtschaftsinfrmatinen etc. Wichtig ist, dass hier swhl zum Knkurrenzunternehmen als auch zur eigenen Organisatin Infrmatinen gesammelt werden (vgl. Karlöf/Östblm 1994, S. 139; S ). 4) Ergebnisanalyse In diesem Schritt werden die Infrmatinen analysiert, Leistungslücken identifiziert und interpretiert. Oft kann es sein, dass die Gesamtergebnisse der beiden verglichenen Objekte wegen unterschiedlicher betrieblicher Vraussetzungen stark vneinander abweichen. Diese unterschiedlichen Bedingungen müssen identifiziert und in die Bewertung des Ergebnisses einbezgen werden (vgl. Karlöf/Östblm 1994, S. 166 ff). 5) Erkenntnisumsetzung Im letzten Schritt des Benchmarking sllen die identifizierten Lücken mit dem Ziel einer Leistungssteigerung geschlssen werden (vgl. Karlöf/Östblm 1994, S. 185 ff). 4.7 Funktinspunktanalyse Die Funktinspunktanalyse wurde Ende der 70er Jahre vn dem IBM-Mitarbeiter Alan Albrecht entwickelt (vgl. Hürten 1999, S. 12). Sie ist eine Methde, um den Aufwand für ein zu realisierendes Infrmatinssystem vr dessen Entwicklung abzuschätzen (vgl. Bundschuh/Peetz/Siska 1991, S. 28). Bei dieser Aufwandsschätzung werden zwei Faktren betrachtet: Leistungsumfang und Kmplexität. Durchgeführt wird die Funktinspunktanalyse anhand vn sechs Einzelschritten (siehe Abb. 20). Abb. 20: Ablauf einer Funktinspunktanalyse (eigene Darstellung) 1) Funktinstypen identifizieren Im ersten Schritt werden die sgenannten Funktinstypen des zu entwickelnden Infrmatinssystems identifiziert. Hiervn gibt es fünf an der Zahl: 31

39 4 Werkzeuge und Methden Eingabe (Interface-Klasse) Ausgabe (Interface-Klasse) Speicher (Infrmatinsbjekt) Rechnung (Steuerungsklasse) Schnittstelle / Exprt (nach Bundschuh/Peetz/Siska 1991, S. 40) 2) Kmplexität bestimmen Im zweiten Schritt werden die identifizierten Funktinstypen hinsichtlich ihrer Kmplexität beurteilt. Der Schwierigkeitsgrad ist in drei Stufen aufgebaut: einfach mittel kmplex (vgl. Bundschuh/Peetz/Siska 1991, S.40) Aus flgender Matrix lassen sich für jeden Funktinstypen eines gewissen Schwierigkeitsgrades die entsprechenden Funktinspunkte ablesen. Eine einfache Eingabe weist beispielsweise 3 Funktinspunkte auf, während eine kmplexe Rechnung 15 Funktinspunkte umfasst. Tabelle 1: Matrix zur Ermittlung der Funktinspunkte Schwierigkeitsgrad Funktinstyp einfach mittel kmplex (-) () (+) Eingabe Ausgabe Speicher Rechnung Schnittstelle / Exprt (nach Bundschuh/Peetz/Siska 1991, S. 40) 3) UFP berechnen Addiert man die einzelnen Funktinspunkte, erhält man die Summe Unadjusted Functin Pints (UFP) eine nch nicht an das Entwicklungsumfeld angepasste Gesamtzahl der Funktinspunkte. Eine mittlere Eingabe (4) und ein kmplexer Speicher (6) ergeben zum Beispiel einen UFP-Wert vn

40 4 Werkzeuge und Methden 4) Krrekturwert berechnen Des Weiteren muss in die Aufwandsabschätzung der Einfluss des Entwicklungsumfeldes einbezgen werden. Hierbei werden 14 Merkmale betrachtet, die mit einem Einflussgrad vn 0-5 (0 = kein Einfluss; 5 = starker Einfluss) bewertet werden. Die Summe dieser Bewertungen ergibt den sgenannten Ttal Degree f Influence (TDI) eine Zahl, die den Gesamteinfluss des Entwicklungsumfeldes repräsentiert. Der TDI kann in flgende Frmel eingefügt werden, um einen Krrekturwert (VAF Value added Factr) für die Summe UFP zu bestimmen: VAF = (TDI * 0,01) + 0,65 (vgl. Hürten 1999, S. 25; Bundschuh/Peetz/Siska 1991, S. 40 ff). 5) Funktinspunkte berechnen Mit Hilfe des Krrekturwertes können die Funktinspunkte (FP) berechnet werden: FP = UFP * VAF (vgl. Hürten 1999, S. 40) 6) Aufwand berechnen Um den zeitlichen Aufwand zur Entwicklung eines Infrmatinssystems bestimmen zu können, muss der Realisierungsaufwand für einen Funktinspunkt bekannt sein. Dieser Aufwand kann jedch nicht pauschal gesetzt werden, sndern hängt vn vielen Faktren, z.b. Qualifikatin der Entwickler der Prgrammiersprache, ab. Außerdem ist zu definieren, b der festgelegte Aufwand zur Umsetzung eines Funktinspunktes Anfrderungsentwicklung und Systemtest inkludiert (vgl. Glinz 2004, S. 57). Die Anzahl der Funktinspunkte, die ein Entwickler an einem Tag umsetzt, wird im Flgenden als Team Perfrmance (TP = FP pr Tag) bezeichnet. Der zeitliche Aufwand (A) lässt sich durch flgende Frmel berechnen: A = FP / TP Um den Zwischenschritt der Funktinspunktberechnung [FP = UFP * VAF] zu sparen und gleich die Berechnung des Aufwandes vrnehmen zu können, werden diese und die Frmel zur Berechnung des Aufwandes kmbiniert: A = UFP * VAF / TP 33

41 5 Analyse Entsprechend dieser Verkürzung der Rechnung werden in Kapitel 8 zur Berechnung des Aufwandes und der Ksten des DESY-SVS die Schritte 5 und 6 zusammengefasst. 5 Analyse In den flgenden Kapitelabschnitten werden die einzelnen Schritte der Analysephase innerhalb des Prjektes vrgestellt. Begnnen wird mit der Schilderung des IstZustandes hinsichtlich der Durchführung der Schlüsselverwaltung am DESY. Zu diesem Zweck fand zu Beginn des Prjektes ein Meeting mit den Auftraggebern der Abteilung V1 statt. Im Weiteren werden die Geschäftsprzesse der Schlüsselverwaltung definiert und eine exemplarische Analyse an Hand des Schlüsselausgabeprzesses durchgeführt. 5.1 Ist-Zustand Zum Einstieg des Prjektes fand ein Meeting mit den Auftraggebern der Abteilung V1 statt. Anwesend waren der Abteilungsleiter, ein Facility Manager und der hauptverantwrtliche Schlüsselverwalter. Das Zusammentreffen diente vr allem zur Klärung der Prjektziele und des -umfangs. Außerdem wurde es genutzt, um den IstZustand der Schlüsselverwaltung am DESY zu umreißen und um einige Anfrderungen an den Sll-Zustand zu entwickeln. Als Hilfsmittel fand hierzu die in Kapitel 4.2 vrgestellte Metaplan-Technik Anwendung. Den Prjektbeteiligten der Abteilung V1 wurden flgende Leitfragen zur Erhebung des Ist-Zustandes und der Anfrderungen an den Sll-Zustand gestellt: 1) 2) 3) 4) Welche Aufgaben zum Thema Schlüsselverwaltung fallen in Ihren Tätigkeitsbereich? Welche Infrmatinen sind für die Erfüllung dieser Aufgaben erfrderlich? Welche Infrmatinen erhalten Sie? Welche Infrmatinen geben Sie weiter? Welche psitiven Aspekte weist Ihre jetzige Arbeitsweise auf? Was würde Ihnen bei der Bearbeitung Ihrer Aufgaben helfen und was ist verbesserungswürdig? Den prjektbeteiligten Mitgliedern vn V1 stand eine vrdefinierte Bearbeitungszeit für das Ntieren ihrer Antwrten und Ideen zur Verfügung. Im Anschluss flgte eine thematische Gruppierung der Ergebnisse der Kartenabfrage im Plenum. Hieraus ergab sich flgendes Bild: 34

42 5 Analyse Abb. 21: Ergebnis der Kartenabfrage 1) + 2) Aufgaben der Schlüsselverwaltung und zu verarbeitende Infrmatinen Mit Hilfe der Metaplan-Technik knnten die Auftraggeber der Abteilung V1 den Prjektmitgliedern der Gruppe IPP einen ersten Überblick zu den Aufgaben der Schlüsselverwaltung darbieten. Während der Gruppendiskussin erflgte eine Erläuterung der Aufgaben und der dazugehörigen Infrmatinen. Hierbei knnten einige der Aufgaben zu einer übergerdneten Tätigkeit zusammengefasst werden. S umfasst die Ausgabe vn Schlüsseln beispielsweise auch eine entsprechende Eingabe im System. Die Aufgaben und Infrmatinen der Schlüsselausgabe und -rückgabe beispielsweise, die lgisch und thematisch zusammengehören, wurden in Abb. 21 entsprechend angerdnet und mit einem fettgedruckten Rahmen versehen. Andere Aufgaben sind ebenfalls übergerdneten Tätigkeiten zuzurdnen, werden jedch nur in Ausnahmefällen ausgeführt. S werden z.b. Schlüsselbestellungen nur dann getätigt, wenn entsprechende Schlüssel nicht mehr im Lager befindlich sind. Entsprechende Punkte innerhalb des Schlüsselausgabeprzesses wurden in Abb. 21 mit einem gestrichelten Rahmen versehen. Weiterhin ist als Ergebnis der Gruppenarbeit festzustellen, dass einige Aspekte der Schlüsselverwaltung ausreichend umrissen wurden, andere hingegen recht spärlich. Im Falle der Schlüsselausgabe knnte mit Hilfe der Metaplan-Technik ein Bild der 35

43 5 Analyse Aufgaben und der zu verarbeitenden Infrmatinen abgedeckt werden. Als Gegenbeispiel knnte das Feld der Schlüsselrückgabe nch nicht ausreichend abgesteckt werden. Um ein vllständiges Bild der Schlüsselverwaltung am DESY zu erhalten, waren im weiteren Prjektverlauf Einzelgespräche mit dem hauptverantwrtlichen Schlüsselverwalter erfrderlich. Weiterhin ist auffällig, dass einige Aufgaben, wie beispielsweise das Anfrdern vn Schlüsseln der der Ein- und Rückbau vn Zylindern, nicht in den Bereich des Schlüsselverwalters fallen, sndern innerhalb eines entsprechenden Przesses vn anderen Akteuren durchgeführt werden. Wiederum andere Aufgaben, wie das Verwalten des Bestandes, beziehen sich auf den gesamten Themenbereich und können daher nicht als Kerntätigkeiten bezeichnet werden. Der angeführte Przess neues Schließsystem planen kann wiederum nicht als essentielle Schlüsselverwaltungsaufgabe bezeichnet werden und findet lediglich bei Umzugsaktivitäten der Baumaßnahmen Anwendung. In der weiteren Phase der SVS-Entwicklung wurde daher auch dieser Przess nicht weiter berücksichtigt. Als Hauptaufgaben können gemäß des Ergebnisses der Auftraggeberbefragung zunächst flgende festgehalten werden: Schlüssel ausgeben Schlüssel zurücknehmen Verlust vn Schlüsseln registrieren Zylindereinbau dkumentieren Rückbau (bzw. Rücknahme) vn Zylindern 3) + 4) Psitive Aspekte des Ist-Zustandes und Verbesserungswünsche Als ein weiteres auffälliges Ergebnis der Kartenabfrage ist festzustellen, dass die Abteilungsmitglieder vn V1 keine psitiven Aspekte bezüglich ihrer derzeitigen Arbeitsweise zu bemerken hatten. Dies lässt auf einen erheblichen Verbesserungsbedarf schließen. Gleichzeitig zeigten sich die Auftraggeber vn V1 bezüglich ihrer Verbesserungswünsche recht verhalten. Es wurden wenig knkrete Ansätze für den SllZustand geschaffen die meisten Aspekte kamen in der Plenumdiskussin auf, die bei der Ideenfindung eine förderliche Wirkung hatte. Einige dieser Verbesserungswünsche überschnitten sich jedch nicht mit den Zielen des Prjektes. S können eine neue Schließsystematik der eine Optimierung der Schließhierarchie durch die Einführung einer Systemkmpnente, welche auf die Unterstützung der Schlüsselverwaltungsprzesse abzielt, nicht verwirklicht werden. Flgende Verbesserungswünsche knnten dagegen innerhalb des Prjektes berücksichtigt werden: Infrmatinen nicht mehr auf mehreren Quellen verteilt IS Schließsystem / -hierarchie abbilden Zugangsauswertung Zusammenspiel mit DESY-Ausweisen klären Hinsichtlich des Ist-Zustandes ergab sich aus einer ffenen Gesprächsrunde mit den Auftraggebern vn V1 flgende Skizze: 36

44 5 Analyse Die Gebäudepläne liegen dem Verwalter in Papierfrm vr und beinhalten relativ genaue Infrmatinen über die in den Türen eingebauten Zylinder. Die Pflege der Pläne erflgt händisch. Die Gebäudepläne werden vm Schlüsselverwalter teils selbst erstellt, teils liegen Kpien der Abteilung Zbau vr. Für die Schlüsselausgabe wird das System Big Key verwendet. Die Zylinderausgabe wird nicht über Big Key verwaltet, sndern in den Gebäudeplänen festgehalten. Es werden nur Gebäudeschlüssel verwaltet keine Tr-, Schrankschlüssel usw. Dies wird in Zukunft auch nicht angestrebt. Um die verfügbare Schlüsselstückzahl herauszufinden, zählt der Verwalter im Schlüsselschrank nach. Der DESY-Bestand weist Schlüssel und Zylinder auf (bei Mitarbeitern). Zusammenfassung der Ergebnisse Die Ergebnisse des Brainstrmings und der anschließenden Diskussin innerhalb des ersten Meetings mit den Auftraggebern stellten einen ersten Prjektansatz dar, der jedch keinen Anspruch auf Vllständigkeit hat. Er bt allerdings einen Anhaltspunkt, mit dem sich weiter arbeiten und das grbmaschige Bild der Ansprüche an die Schlüsselverwaltung am DESY verdichten ließ. Dies erflgte, wie bereits erwähnt, in Einzelgesprächen mit dem hauptverantwrtlichen Schlüsselverwalter. Weiterhin war auffällig, dass die Metaplan-Technik vn den Auftraggebern wenig begeistert angenmmen wurde und das erhffte Aufkmmen an Ideen und Anregungen ausblieb. Dies ist vr allem darauf zurückzuführen, dass die Interessenslage unter den Auftraggebern stark vneinander abwich. Das Prjekt wurde durch eine Auftragserteilung Seitens der Abteilungsleitung initiiert, während der hauptverantwrtliche Schlüsselverwalter wenig überzeugt vn der Ntwendigkeit zur Entwicklung einer GIS/FMS-Erweiterung für die Schlüsselverwaltung und der Abschaffung des derzeitigen SVS im selben Zug war. An dieser Stelle musste im weiteren Prjektverlauf Überzeugungsarbeit durch die Diplmandin und die Prjektmitglieder der Gruppe IPP geleistet werden. Dies wurde ebenfalls durch Einzelgespräche, bei denen die Abteilungsleitung nicht anwesend war, erreicht und indem besnders intensiv auf die Anfrderungen des hauptverantwrtlichen Schlüsselverwalters eingegangen und mit ihm gemeinsam das DESY-Knzept der Schlüsselverwaltung definiert wurde. 5.2 Geschäftsprzessanalyse Wie in Kapitel 4.3 dargestellt, beginnt die Analysephase im ersten Schritt mit der Identifikatin der Geschäftsprzesse. Als ein Geschäftsprzess wird ein Przess innerhalb einer betrieblichen Organisatinsstruktur definiert, der ein betriebliches Ziel zum Zweck hat (vgl. Grässle/Baumann/Baumann 2007, S. 46). In den flgenden Unterkapiteln wird zunächst ein Überblick der zu analysierenden Geschäftsprzesse der 37

45 5 Analyse Schlüsselverwaltung dargebten und eine exemplarische Analyse an Hand des Schlüsselausgabeprzesses vrgenmmen. Dabei wird die in Kapitel 4.3 vrgestellte Vrgehensweise verwendet. Abschließend werden der Umfang des zu entwickelnden SVS und der Sll-Zustand dargestellt Die Geschäftsprzesse der Schlüsselverwaltung im Überblick Ein Teil der Schlüsselverwaltungsprzesse knnte bereits aus den Ergebnissen der Kartenabfrage herausgefiltert werden (siehe Kapitel 5.1). Andere wurden durch Einzelgespräche mit dem hauptverantwrtlichen Schlüsselverwalter ergänzt. Insgesamt lassen sich unter dem Begriff der Schlüsselverwaltung aus DESY-Sicht flgende elf Geschäftsprzesse zusammenfassen: Schlüssel erfassen Schlüssel ausgeben Schlüssel zurückgeben Schlüsselverlust melden Schlüsselfund melden Schlüsseldefekt melden Zylinder erfassen Zylinder ausgeben Zylinder zurückgeben Zylinderdefekt melden Bericht erstellen Da die ben aufgelisteten Geschäftsprzesse in dieser grben Frm nicht analysierbar sind, wird im Flgenden der Geschäftsprzess Schlüssel ausgeben exemplarisch weiter aufgegliedert. Auf die Analyse der übrigen zehn Przesse der Schlüsselverwaltung wird in dieser Diplmarbeit nicht näher eingegangen. Sie erflgte jedch nach demselben hier an dem Geschäftsprzess Schlüssel ausgeben vrgestellten Muster Analyse des Schlüsselausgabeprzesses Im Flgenden wird der Przess der Schlüsselausgabe gemäß der Vrgehensweise aus Kapitel 4.3 aufgegliedert und analysiert. 1) Identifikatin der Geschäftsanwendungsfälle Zunächst hat eine Identifikatin der Geschäftsanwendungsfälle zu erflgen. Dies geschah bereits in Kapitel Der im Flgenden betrachtete Geschäftsanwendungsfall ist dementsprechend der Przess Schlüssel ausgeben. 38

46 5 Analyse 2) Auslösenden Akteur identifizieren Wurden die Geschäftsprzesse identifiziert, ist der auslösende Akteur zu bestimmen. Dieser repräsentiert eine Rlle für einen agierenden Teilnehmer innerhalb eines Przesses, der diesen aktiv einleitet. Der Schlüsselausgabeprzess wird vn einem Akteur namens Gebäudenutzer ausgelöst (siehe Abb. 22). Abb. 22: Auslösender Akteur des Przesses Schlüssel ausgeben (eigene Darstellung) 3) Beteiligte Akteure identifizieren Ein weiterer beteiligter Akteur bei der Durchführung des zu betrachtenden Geschäftsprzesses ist der Verwalter. Er reagiert auf die Einleitung des Przesses durch den Gebäudenutzer. 4) Ergebnis / Geschäftswert identifizieren Für den Gebäudenutzer als auslösenden Akteur hat sich bei Abschluss des Przesses ein Geschäftswert zu ergeben. Im Fall der Schlüsselausgabe wäre dies der Erhalt eines Schlüsselexemplars, das seinen Anfrderungen entspricht. 5) Ablaufbeschreibung In diesem Schritt flgt die Aufgliederung des Geschäftsprzesses Schlüssel ausgeben. Hierbei ist auf einen angemessenen Detaillierungsgrad zu achten. Weiterhin sllen die Aktinen nch keine Schlussflgerung auf die Umsetzung zulassen sie sllen lösungsfrei sein. Des Weiteren ist es erfrderlich, den Przess durch eine Aktin des auslösenden Akteurs hier des Gebäudenutzers beginnen zu lassen. Im Einzelnen umfasst der Przess flgende Aktinen: 39

47 5 Analyse Tabelle 2: Aktinen des Schlüsselausgabeprzesses Nr. Akteur 1 Gebäudenutzer 2 Verwalter 3 Gebäudenutzer 4 Verwalter 5 Gebäudenutzer 6 Verwalter 7 Gebäudenutzer Ausnahmen Aktin Schlüssel anfrdern Schlüssel anbieten Schlüssel auswählen Exemplar aushändigen Exemplar entgegennehmen Ausgabe dkumentieren Ausgabe bestätigen Schlüssel nicht verfügbar / beschaffen 3a Verwalter Exemplar beschaffen (weiter mit 4.) Schlüssel nicht verfügbar / nicht beschaffen 3b Gebäudenutzer Auswahl ändern (weiter mit 3.) Grafisch wird der Przess in einem Aktivitätsdiagramm in Abb. 23 dargestellt. Es macht Zuständigkeiten durch Partitinen deutlich und zeigt ein- und ausgehende Infrmatinen, die bei der Durchführung vn Aktinen übertragen werden. Abb. 23: Ablauf des Schlüsselausgabeprzesses (eigene Darstellung) 40

48 5 Analyse 6) Systemanwendungsfälle identifizieren Bei der Bestimmung des Ablaufs des Geschäftsprzesses Schlüssel ausgeben wurde zunächst auf die Einbeziehung vn Umsetzungsmöglichkeiten verzichtet. Im flgenden Analyseschritt erflgt nun eine Betrachtung der Aktinen auf Verwalterseite hinsichtlich ihrer Ausführbarkeit durch ein Infrmatinssystem. Hierbei ist festzustellen, dass die Aktinen Schlüssel anbieten und Ausgabe dkumentieren vn einem IS durchgeführt werden können. Abb. 24 fasst diesen Sachverhalt grafisch zusammen. Abb. 24: Umsetzungsmöglichkeiten der Verwaltungsaktinen (eigene Darstellung) Das in Abb. 23 dargestellte Szenari ist unter Einbeziehung der Umsetzungsmöglichkeit der Przessaktinen durch ein IS um einen weiteren Akteur ein Infrmatinssystem zu erweitern. Aus diesem Schritt ergibt sich flgendes abgeändertes Szenari: 41

49 5 Analyse Tabelle 3: Aktinen des Schlüsselausgabeprzesses mit IS Nr. Akteur Aktin 1 Gebäudenutzer Schlüssel anfrdern 2 Verwalter Anfrderung weiterleiten 3 IS Schlüssel anbieten 4 Verwalter Angebt weiterleiten 5 Gebäudenutzer Schlüssel auswählen 6 Verwalter Exemplar aushändigen 7 Gebäudenutzer Exemplar entgegennehmen 8 Verwalter Dkumentatin einleiten 9 IS Ausgabe dkumentieren 10 Verwalter Beleg weiterleiten 11 Gebäudenutzer Ausgabe bestätigen Ausnahmen Schlüssel nicht verfügbar / beschaffen 5a Verwalter Exemplar beschaffen (weiter mit 6.) Schlüssel nicht verfügbar / nicht beschaffen 5b Gebäudenutzer Auswahl ändern (weiter mit 5.) Die grafische Darstellung des Szenaris unter Einbeziehung des IS erflgt in Abb. 25: Abb. 25: Ablauf des Schlüsselausgabeprzesses mit IS (eigene Darstellung) 42

50 5 Analyse Abbildung 24 zeigt, dass die Aktinen Schlüssel anbieten und Ausgabe dkumentieren mit Hilfe eines IS umgesetzt werden können, während die Aktinen Schlüssel beschaffen und Exemplar aushändigen weiterhin vn Mitarbeitern durchzuführen sind. Auffällig bei der grafischen Darstellung des abgeänderten Szenaris in Abb. 25 ist, dass es bei der Erweiterung um das IS auch um Aktinen auf Seiten des Verwalters zu erweitern ist. Dies ist ntwendig, da der Verwalter als Vermittler zwischen Gebäudenutzer und Infrmatinssystem fungieren sll. Im Flgenden sllen unter dem Hauptanwendungsfall Schlüssel ausgeben ausschließlich die IS-umgesetzten Aktinen verstanden werden Systemumfang des SVS Im Eingang dieses Kapitels wurde erwähnt, dass sich der Begriff der Schlüsselverwaltung neben der Schlüsselausgabe aus weiteren Przessen zusammensetzt. Der vrherige Abschnitt zeigt, dass einige Aufgaben innerhalb des Schlüsselausgabeprzesses durch ein Infrmatinssystem übernmmen werden können. Die übrigen Schlüsselverwaltungsprzesse wurden innerhalb des Prjektes auf dieselbe Art und Weise analysiert mit dem Ergebnis, dass ausnahmsls für jeden einzelnen entsprechende Funktinen innerhalb des SVS zu entwickeln sind. Ausgehend davn, dass unter den eingangs definierten Przessen ausschließlich die Aktinen, welche ISunterstützt umzusetzen sind, verstanden werden, ergibt sich flgender Systemumfang: Abb. 26: Systemumfang und externe Akteure (eigene Darstellung) 43

51 5 Analyse Abb. 26 stellt den Umfang der zu entwickelnden Systemkmpnente dar und verdeutlicht, dass sie bei der Durchführung aller Schlüsselverwaltungsprzesse dienlich sein sll. Entsprechende Funktinen sind durch ein Entwicklerteam zu realisieren. Die Anwendungsfälle der Schlüsselverwaltung werden vn einem Administratr, Systemnutzer und Verwalter, die als externe Akteure außerhalb der Systemgrenze liegen, mit Hilfe des SVS durchgeführt. Systemnutzer im Allgemeinen können Berichte erstellen. Abbildung 9 in Kapitel 3.6 zeigt, dass swhl Administratr als auch Verwalter Systemnutzer sein können. Abb. 16 zeigt, dass beide in der Lage sind, Berichte anzufertigen. Allerdings ist es nur Administratren erlaubt, Schlüssel und Zylinder zu erfassen, während Verwalter Przesse wie Ausgaben, Rückgaben und Verlustmeldungen mit Hilfe des Systems verarbeiten dürfen. Das System führt die Aktinen nicht alleine aus, sndern auf Veranlassung und in Kmmunikatin mit den externen Akteuren. 5.3 Sll-Zustand Der Sll-Zustand der Schlüsselverwaltung ergab sich innerhalb des Prjektes zum einen aus Gesprächen mit den Auftraggebern der Abteilung V1 und zum anderen aus der Analyse der Schlüsselverwaltungsprzesse. Das Erreichen des Sll-Zustandes stellt das letztendliche Ziel dieses Prjektes dar. Damit dies gelingt, wurden Anfrderungen an die Schlüsselverwaltung und die zu entwickelnde Systemkmpnente frmuliert und in einer Spezifikatin gebündelt. Hierfür wurden die in Kapitel vrgestellten Anfrderungsschablnen verwendet. Da die Prjektmitglieder mit frtschreitender Prjektdauer stets neue Erkenntnisse im Hinblick auf das zu entwickelnde Schlüsselverwaltungssystem gewannen, wurde die Spezifikatin über den Prjektverlauf hinweg stetig gepflegt und erweitert. Es waren nicht nur Anfrderungen hinzuzufügen, sndern auch zu verfeinern, zu ändern der sgar zu entfernen. Die hierbei entstandene Spezifikatin lieferte den externen Entwicklern der Firma Hrstick eine detaillierte Anfrderungsliste, welche ihnen als Basis für die technische Umsetzung und die Realisierung der FMS-Erweiterung diente. Neben ihrer Funktin als Anfrderungsdkument stellte die Spezifikatin eine einheitliche Wissensbasis zum Thema Schlüsselverwaltung für alle Prjektbeteiligten dar. Dazu wurde ihr eine Definitin der FM-Disziplin beigefügt. Die gesamte Spezifikatin unterteilt sich in fünf Kapitel: 1) 2) 3) 4) 5) Knzept der Schlüsselverwaltung Przessüberblick Przessdefinitinen Przessanfrderungen Systemanfrderungen Das erste Kapitel definiert ein einheitliches Verständnis zum Thema Schlüsselverwaltung und beinhaltet unter anderem das Klassendiagramm aus Kapitel 3.6. Im zweiten Kapitel wird kurz umrissen, welche Przesse innerhalb der Schlüsselverwaltung anfallen und vn welchen Akteuren diese ausgeführt werden. Zur grafischen Erklärung 44

52 5 Analyse ist das Systemkntextdiagramm (Abb. 26) aus Kapitel 5.2 diesem Abschnitt der Spezifikatin beigefügt. Kapitel drei geht näher auf die einzelnen Przesse ein. Die Abläufe werden Anhand vn Aktivitätsdiagrammen und Szenaritabellen wie in Kapitel dargestellt. Auch Ausnahmen und Erweiterungen innerhalb der Przesse werden hier erläutert. Das daraufflgende Kapitel definiert die Anfrderungen an die Przesse. Jeder einzelne wird hier hinsichtlich vierer Punkte aufgeschlüsselt: Przessbeteiligte Funktinale Przessanfrderungen Randbedingungen Anfrderungen an die Beteiligten zur Przessumsetzung Zunächst werden die beteiligten Akteure und ihre Rllen innerhalb des jeweiligen Przesses genannt. Es flgt eine Auflistung der funktinalen Anfrderungen an die Przesse. Hierin wird definiert, welche Ergebnisse ein frmulierter Przess zu leisten hat, was seine Ziele und diejenigen einzelner Aktinen innerhalb des Przesses sind. Die Randbedingungen beschreiben, welche Maßgaben erfüllt sein müssen, damit die Przesse ausgeführt werden können. Sie gelten innerhalb dieses Prjektes für alle Przesse und werden nicht für jeden einzelnen angepasst. Die Anfrderungen an die Beteiligten zur Umsetzung eines Przesses spezifizieren die zu erbringenden Leistungen der Akteure, um einen Przess erflgreich durchführen zu können und smit wiederum den Anfrderungen an den Przess gerecht zu werden. Das Kapitel der Systemanfrderungen unterteilt sich ebenfalls in einzelne Unterabschnitte: Anwenderanfrderungen Funktinale Systemanfrderungen Nicht-funktinale Systemanfrderungen Die Anwenderanfrderungen definieren, welche Leistungen die Systemlösung seinen Nutzern bieten sll, damit diese einen Przess erflgreich durchführen können. Hier wird ganz speziell der Dialg zwischen Anwender und System angesprchen, während die funktinalen Anfrderungen ausschließlich auf die zu erbringenden Leistungen und Fähigkeiten des Systems anspielen. Unter den nicht-funktinalen Systemanfrderungen werden Maßgaben zur inneren Beschaffenheit des Systems zusammengefasst (siehe auch Kapitel 4.1.1). Die Spezifikatin ist auszugsweise dieser Diplmarbeit angehängt. Da die ersten drei Kapitel Knzept der Schlüsselverwaltung, Przessüberblick und Przessdefinitin bereits in den vrherigen Kapiteln dieser Diplmarbeit ihre Erwähnung fanden, wurde darauf verzichtet, sie ihr ein weiteres Mal im Anhang hinzuzufügen. Die beigefügte Spezifikatin beschränkt sich auf die beiden Kapitel Przessanfrderungen und Systemanfrderungen. Allerdings beziehen sich diese nicht auf alle elf Schlüsselverwaltungsprzesse, sndern nur auf denjenigen der Schlüsselausgabe, da ausschließlich dieser als Referenz innerhalb dieser Diplmarbeit dient. 45

53 6 Systemlösung 6 Systemlösung Das flgende Kapitel stellt die Systemlösung zur Unterstützung der Schlüsselverwaltungsprzesse am DESY vr. Zunächst wird der Entwurf einer Systemarchitektur für die Schlüsselausgabe vrgestellt. Weiterhin werden die Zusammenarbeit mit den Entwicklern erläutert und schrittweise die Systemfunktinen zur Unterstützung des Schlüsselausgabeprzesses präsentiert. 6.1 Systementwurf Bevr mit der technischen Umsetzung der Anfrderungen und der Entwicklung begnnen werden knnte, hatte eine Ausarbeitung der Systemarchitektur zu erflgen. Als Basis wurde hierfür auf die nicht-funktinalen Systemanfrderungen und auf das aus der Analysephase resultierende Mdell zurückgegriffen. Im Fall des Schlüsselausgabeprzesses erflgte die Entwicklung der Systemarchitektur ausgehend vn dem Aktivitätsdiagramm (Abb. 25) aus Kapitel Abbildung 27 zeigt schrittweise die Erhebung der Systemelemente, die später in einem Klassendiagramm zusammenzufassen sind. Abb. 27: Identifikatin der Funktinsklassen (eigene Darstellung) 46

54 6 Systemlösung 1) Ermittlung der Interface-Klassen Zunächst werden die auf der Partitinsgrenze zwischen Verwalter und IS liegenden Klassen betrachtet. Sie stellen eine Schnittstelle zwischen den beiden Akteuren dar und bilden die Interface-Klassen. Klassen dieses Typs können zwischen Eingabe- der Ausgabeklasse differenziert werden. Die drei flgenden Klassen stellen Eingabemasken dar: Anfrderung_A Angebt_A Dkumentatin_A Demgegenüber bilden die drei flgenden Klassen jeweils eine Ausgabemaske: Angebt_A Dkumentatin_A Beleg Es ist auffällig, dass die beiden Klassen Angebt_A und Dkumentatin_A swhl Eingabe- als auch Ausgabemasken sind. Im Flgenden ist diese Kmbinatin aus Eingabe und Ausgabe getrennt und als zwei unterschiedliche Elemente zu behandeln. In der Regel lässt sich aus dem Aktivitätsdiagramm an der Richtung des Infrmatinsflusses erkennen, b es sich bei den Interface-Klassen um Ausgabe- der Eingabemasken handelt. Geht die Infrmatin vm Verwalter zum Infrmatinssystem, muss es sich unweigerlich um eine Eingabeklasse handeln. In diesem Fall ist die Mdellierung allerdings nicht detailliert genug, um zu erkennen, dass es sich bei den Klassen Angebt_A und Dkumentatin_A um eine Kmbinatin aus Eingabe und Ausgabe handelt. Andernfalls wäre die Ablaufübersicht auch nicht mehr nachvllziehbar, sndern vn zu vielen Details überschwemmt. Bei Bedarf können jedch einige Ausschnitte mit größerer Feinheit mdelliert werden, um eben diese Details zu verdeutlichen. 2) Ermittlung der Steuerungsklassen In diesem Schritt werden die Klassen identifiziert, welche die Interface-Klassen steuern. Um diese ausfindig zu machen, rientiert man sich an den IS-umgesetzten Przessen Schlüssel anbieten und Ausgabe dkumentieren. Ausgehend hiervn können flgende Steuerungsklassen bestimmt werden: Schlüsselanbieter_A Dkumentar Die beiden Steuerungsklassen rufen die Eingabe- bzw. Ausgabemasken auf und lassen sie am Bildschirm erscheinen. 47

55 6 Systemlösung Die Klasse Schlüsselanbieter_A benötigt Daten, um diese an die Interface-Klassen weiterleiten zu können. Die Klasse Dkumentar hingegen sll Infrmatinen zur Speicherung weitergeben. An dieser Stelle sind daher zwei weitere Steuerungsklassen ntwendig: Schlüsselsuche Vrgangsspeicher Die Schlüsselsuche frdert Infrmatinen zu Schlüsselexemplaren vn einer Datenbank an und leitet diese an den Schlüsselanbieter_A weiter. Der Vrgangsspeicher nimmt die Vrgangsdaten vm Dkumentar entgegen und srgt dafür, dass diese in einer entsprechenden Datenbank abgelegt werden. 3) Ermittlung der Speicherklassen Die Steuerungsklasse Schlüsselsuche muss auf eine Datenbank mit Infrmatinen zum Schlüsselbestand zugreifen, um ihre Aufgabe zu erfüllen. Zu diesem Zweck wird eine Speicherklasse eingeführt. Ebens sll der Vrgangsspeicher auf eine Datenbank zugreifen und in ihr entsprechende Daten ablegen. Auch hierfür wird eine Speicherklasse eingeführt. Insgesamt sind flgende Datenbankklassen ntwendig: Schlüsselbestand Vrgangsbestand Die Speicherklasse Schlüsselbestand beherbergt die Stammdaten aller DESYSchlüssel, während mit Hilfe der Speicherklasse Vrgangsbestand Infrmatinen zu durchgeführten Transaktinen dkumentiert werden. 4) Ermittlung der Hauptsteuerungsklasse Des Weiteren muss es eine Steuerungsklasse geben, welche den kmpletten Ablauf der Schlüsselausgabe innerhalb des Infrmatinssystems krdiniert und die Steuerungsklassen Schlüsselanbieter_A und Dkumentar aufruft: Ausgabe-Wizard Aus dieser Analyse heraus ergibt sich flgende Systemstruktur: 48

56 6 Systemlösung Abb. 28: Systemstruktur der Schlüsselausgabekmpnente (eigene Darstellung) Das Diagramm lässt sich wie flgt interpretieren: Ein Verwalter greift auf die Interface-Klassen Anfrderung_A, Angebt_A, Dkumentatin_A und Beleg zu. Über Eingabeklassen gibt er Daten ein bzw. bekmmt Infrmatinen durch Ausgabeklassen angezeigt. Die Interface-Klassen werden vn den Steuerungsklassen Schlüsselanbieter_A und Dkumentar kntrlliert. Diese wiederum krdiniert die Steuerungsklasse Ausgabe-Wizard. Der Schlüsselanbieter_A aktiviert die Interface-Klasse Anfrderung_A, welche am Bildschirm erscheint. Um eine Suchanfrage nach Schlüsseln abzugeben, trägt der Verwalter die Daten des Zugangswunsches (Gebäude und Raum) in die Interface-Klasse Anfrderung_A ein. Sie gibt die Infrmatinen weiter an den Schlüsselanbieter_A. Dieser ruft die Schlüsselsuche auf und übergibt ihr die entgegengenmmenen Daten. Die Schlüsselsuche greift auf Grund der Gebäude- und Raumdaten auf entsprechende Infrmatinen aus dem Schlüsselbestand zu und leitet passende Schlüsselexemplare weiter an die Steuerungsklasse Schlüsselanbieter_A, welche die Interface-Klasse Angebt_A aktiviert. Diese zeigt dem Verwalter die Infrmatinen der ermittelten Schlüsselexemplare an. Angebt_A stellt gleichzeitig eine Eingabemaske dar und nimmt die Auswahl eines Schlüsselexemplars vm Verwalter entgegen. Diese Infrmatin wird an den Schlüsselanbieter_A weitergeleitet, welcher dem Ausgabe-Wizard die Erfüllung seiner Aufgaben meldet. Der Ausgabe-Wizard ruft im nächsten Schritt den Dkumentar auf, welcher die Interface-Klasse Dkumentatin_A aktiviert. Über die Eingabemaske Dkumentatin_A tätigt der Verwalter eine Dateneingabe, indem er den Empfänger des ausgewählten Schlüsselexemplars angibt. Die Infrmatinen werden an die Steuerungsklasse Dkumentar weitergeleitet, welche die Klasse Vrgangsspeicher aktiviert und ihr die Daten übergibt. Der Vrgangsspeicher legt diese im Vrgangsbestand ab. Der Vrgangsspeicher bestätigt dem Dkumentar die Erfüllung seiner Aufgabe, wraufhin dieser die Interface-Klasse Dkumentatin_A zur Bestätigung der Durchführung für den Verwalter aufruft. Abschließend aktiviert der Dkumentar die Interface-Klasse Beleg, die dem Verwalter abschließend die Infrmatinen des durchgeführten Przesses anzeigt. Da sich die in Abb. 28 dargestellte Systemarchitektur ausschließlich auf den Schlüsselausgabeprzess bezieht, wurde hier lediglich ein Systemausschnitt mdelliert. Um ein umfassendes Design zu erhalten, waren für die übrigen Schlüsselverwaltungsprzesse nach dem gleichen Schema Systemelemente und -struktur zu mdellieren. Der 49

57 6 Systemlösung Grundaufbau variiert hierbei nicht, lediglich die Systemklassen waren entsprechend der Przesse anzupassen, wbei einige durchaus wiederverwendet werden knnten. 6.2 Implementierungsphase Die Erweiterung des FMS fand nicht innerhalb DESYs statt, sndern wurde an eine externe Firma Hrstick vergeben, die für den Betrieb und die Anpassungen des GIS/FMS verantwrtlich ist. Da es sich bei dem SVS um eine Kmpnente handelt, die in das GIS/FMS integriert werden und dieses erweitern sll, wurde Hrstick flglicherweise mit der technischen Realisierung betraut. Die Implementierung der Kmpnente zur Verwaltung des Schlüssel- und Zylinderbestandes erflgte auf Basis einer vn DESY erstellten Spezifikatin. Zu Beginn des Prjektes fand ein Meeting mit den zuständigen Entwicklern der Firma Hrstick statt, um Prjektumfang und -zeitplan swie die technischen Rahmenbedingungen zu klären. Außerdem wurde das Meeting mit dem Entwicklerteam zu Anfang der Prjektphase genutzt, um ein einheitliches Verständnis zum Thema Schlüsselverwaltung swhl auf DESY- als auch auf Entwicklerseite zu schaffen. Weiterhin wurde der Ist-Zustand vrgestellt und im Gegenzug erläutert, wie DESY sich die Zukunft im Hinblick auf die Schlüsselverwaltung vrstellt. Um den Entwicklern der Firma Hrstick zusätzlich einen Eindruck vn den Nutzerwünschen und der erwarteten Perfrmance im Hinblick auf das SVS zu ermöglichen, wurde ihnen eine Systemsimulatin auf Micrsft-Pwerpint-Basis präsentiert. In einer anschließenden Diskussin wurde entschieden, dass es am sinnvllsten ist, die Funktinalitäten jedes Verwaltungsprzesses in einem benutzerführenden Wizard zu kapseln. Dies sll zum einen verhindern, dass im SVS Gebäude- der Persnendaten geändert werden der dass der Verwalter bei der Durchführung eines Przesses die Angabe ntwendiger Daten vergisst. Insgesamt sllen die einzelnen Wizards zur Fehlervermeidung beitragen, die Datenknsistenz fördern und den Schlüsselverwalter schrittweise durch den jeweiligen Przess führen. Es flgte die Entwicklungsphase auf Basis der vn DESY erstellten Spezifikatin. Für Testzwecke wurden jedch nicht alle Funktinalitäten umgesetzt, sndern zunächst nur diejenigen zur Unterstützung der Schlüsselausgabe und -rückgabe. Diese wurden den Prjektmitgliedern DESYs vn den Entwicklern der Firma Hrstick in einem Wrkshp vrgestellt und diskutiert. Änderungswünsche der DESYPrjektmitglieder knnten aufgenmmen und im weiteren Prjektverlauf umgesetzt werden. Des Weiteren wurden Unstimmigkeiten und Missverständnisse zwischen den Prjektmitgliedern, die sich möglicherweise auf das ganze Prjekt erstreckt und ein Risik für einen erflgreichen Abschluss dargestellt hätten, durch die anfängliche Entwicklung zweier Przesse vermieden bzw. knnten rechtzeitig beseitigt werden. Außerdem knnten ffene Fragen zur Schlüsselverwaltung während des Wrkshps unter den Prjektmitgliedern der durch Rückmeldung mit den zuständigen Schlüsselverwaltern der Abteilung V1 geklärt werden. 50

58 6 Systemlösung Für die Prjektmitglieder auf DESY-Seite stellte der Wrkshp eine erste technische Einführung im Umgang mit dem SVS dar. Auf dieser Wissensbasis war es ihnen später möglich, das SVS mit Testdaten zu befüllen und den Schlüsselausgabe- und rückgabeprzess zu erprben. Schrittweise erhielten die Entwickler der Firma Hrstick die Spezifikatinen für die weiteren Schlüsselverwaltungsprzesse und setzten diese technisch um. Alle Funktinalitäten wurden vn den Prjektteilnehmern DESYs hinsichtlich der spezifizierten Anfrderungen überprüft und auf etwaige Entwicklungsfehler getestet und vn den Entwicklern entsprechend überarbeitet. Die Prjektmitglieder näherten sich smit schrittweise dem fertigen Prdukt. 6.3 Systemvrstellung: Das DESY-SVS Aus der Implementierungsphase entstand als Ergebnis eine Systemlösung entsprechend der DESY-Spezifikatin. Das SVS wurde als neue Kmpnente in das bestehende GIS/FMS integriert. Da das System zur Verwaltung des Schlüssel- und Zylinderbestandes sensible Infrmatinen enthält, die nur durch autrisierte Systemnutzer einsehbar und änderbar sein sllen, war die Einrichtung einer Benutzeranmeldung erfrderlich. Jeder Schlüsselverwalter des Deutschen Elektrnen-Synchrtrns besitzt entsprechend ein Nutzerknt für das SVS mit einer bestimmten Rechtzuweisung. Hierdurch kann z.b. entschieden werden, dass ein Systemnutzer zwar Schlüsselexemplare zurücknehmen, jedch keine ausgeben darf. Des Weiteren werden ihm durch die Zurdnung seiner Ausgabestelle Transaktinsrechte für Schlüsselexemplare seines Verantwrtungsbereiches eingeräumt. Die Durchführung vn Vrgängen mit Exemplaren einer anderen Ausgabestelle wird das System dem Verwalter smit unterbinden. Im Flgenden werden das SVS und seine Funktinalitäten genauer vrgestellt. Da diese Diplmarbeit als Referenz-Przess stets auf die Schlüsselausgabe zurückgreift, steht flgerichtig der Schlüsselausgabe-Wizard im Fkus der nachstehenden Systemvrstellung Der Schlüsselausgabe-Wizard Bevr einer der Wizards aktiviert und genutzt werden kann, ist zunächst das SVS zu starten. Nach erflgreicher Benutzeranmeldung hat der Systemnutzer die Möglichkeit, für die Durchführung eines Przesses aus der linken Navigatinsleiste einen entsprechenden Wizard aufzurufen. Ein Klick auf den Schlüsselausgabe-Buttn öffnet den Wizard, welcher den Schlüsselverwalter durch den Schlüsselausgabeprzess leitet. Jeder Wizard setzt sich aus mehreren Eingabe- und Ausgabemasken zusammen. Im Fall des Schlüsselausgabe-Wizards ist dies an den Reiterkarten Suchen, Auswahl, Besitzer und Speichern zu erkennen (siehe Abb. 29). Auf diesem Weg hat der Systemnutzer die Möglichkeit, innerhalb einer Schlüsselausgabe zurückzuspringen, um ge51

59 6 Systemlösung gebenenfalls seine Angaben zu ändern. Das Vrspringen auf eine Reiterkarte ist jedch nicht möglich und wurde vn den Entwicklern der Firma Hrstick entsprechend umgesetzt. Dies verhindert, dass der Schlüsselverwalter einige Schritte innerhalb eines Przesses überspringt und s die Angabe ntwendiger Daten vergisst. Bei der Durchführung einer Schlüsselausgabe startet der Wizard auf der Reiterkarte Suchen. Der Verwalter hat im ersten Schritt vn dem Gebäudenutzer einen Zugangswunsch zu erfragen. Vn dieser Infrmatin ausgehend, kann der Verwalter mit Hilfe des SVS ermitteln, welcher Schlüssel den Zugangswunsch des Klienten befriedigt. Hierfür sind in der Suchmaske des Schlüsselausgabe-Wizards die Infrmatinen Gebäudenummer, Etage, Raum 1, alternativ Raum 2 und ebenfalls alternativ Schlüsseltyp anzugeben (siehe Abb. 29). Durch die Angabe des Schlüsseltypen kann die Suche gleich zu Beginn der Schlüsselermittlung eingegrenzt werden, denn sllte der Gebäudenutzer keine Berechtigung für den Besitz eines Generalschlüssels haben, ist ein entsprechendes Angebt überflüssig. Als Variante können die Suchfelder auch mittels Markierung eines Punktes in dem Navigatinsbaum autmatisch ausgefüllt werden. Per Mausklick auf den Buttn Suchen wird die Anfrage an das Infrmatinssystem übergeben, um passende Schlüssel zu ermitteln. Abb. 29: Gebäude- und Raumauswahl des Schlüsselausgabe-Wizards (Screensht) Wurde die Suchanfrage abgeschickt, zeigt der Schlüsselausgabe-Wizard im nächsten Schritt auf der Reiterkarte Auswahl ein entsprechendes Suchergebnis an. Dem Verwalter wird eine Liste verfügbarer Schlüssel angebten. Als zusätzliche Infrmatinen liefert ihm das System die Schlüsselseriennummer, die Typangabe und die Ausgabestelle. Auf der rechten Seite des Fensters erhält der Schlüsselverwalter eine Übersicht mit der Anzahl nch verfügbarer Schlüsseltypen. In dem Beispiel aus Abb. 30 sind zur Suchanfrage vier Einzelschlüssel, jedch weder Generalhauptschlüssel, Obergruppenschlüssel, Gruppenschlüssel der Zentralschlüssel vrhanden. Diese An52

60 6 Systemlösung zeige ermöglicht dem Verwalter das rechtzeitige Erkennen einer ntwendigen Schlüsselnachbestellung. Hat der Gebäudenutzer einen der mehrere Schlüssel ausgewählt, kann der Verwalter ein entsprechendes Exemplar der mehrere markieren und gelangt per Mausklick auf den Buttn auswählen zum nächsten Ausgabe-Schritt. Wählt der Schlüsselverwalter ein Exemplar aus, das nicht zu seiner Ausgabestelle gehört, erscheint eine Meldung, welche ihm mitteilt, dass für diese Aktin keine Benutzerrechte bestehen. Abb. 30: Schlüsselauswahl-Liste des Ausgabe-Wizards (Screensht) Hat der Verwalter ein Schlüsselexemplar der mehrere zur Ausgabe ausgewählt, kann er diese an den Empfänger übergeben. Zur Dkumentatin des Vrgangs ist eben dieser Empfänger im nächsten Schritt auf der Reiterkarte Besitzer anzugeben (siehe Abb. 31). Um den zukünftigen Besitzer zu finden, ist die Durchführung einer Suche ntwendig. Diese kann in den Kategrien Name, Vrname und Gruppe vrgenmmen werden. Gibt der Schlüsselverwalter wie in dem Beispiel in Abb. 31 unter Vrname Anna ein und aktiviert die Filterfunktin, wird ihm eine Liste mit gespeicherten Persnen, die den Vrnamen Anna besitzen, angezeigt. Im flgenden Schritt ist der Empfänger aus der Suchergebnisliste zu markieren. Per Mausklick auf den Buttn auswählen gelangt der Schlüsselverwalter zur nächsten Maske des SchlüsselausgabeWizards. Abb. 31: Ergebnis der Besitzer-Suche (Screensht) 53

61 7 Benchmark-Test Auf der Maske in Abb. 32 werden dem Schlüsselverwalter vr der Durchführung der Transaktin abschließend die Daten des Vrgangs angezeigt. Dazu gehören zum einen die Schlüsselinfrmatinen wie Seriennummer, Typ und Ausgabestelle. Zum anderen wird dem Verwalter eine Übersicht der Empfängerdaten gebten. Aktiviert der Verwalter den Buttn speichern, wird die Transaktin abgeschlssen und der Vrgang in der Datenbank gespeichert. Der Status des Schlüsselexemplars wird hierbei in ausgegeben geändert, damit es nicht für eine weitere Ausgabe angebten wird. Abb. 32: Übersicht der Vrgangsdaten vr Transaktinsspeicherung (Screensht) Eine vllständige Übersicht des Vrgangs lässt sich auf Wunsch als Beleg für den Schlüsselempfänger ausdrucken. Unter Angabe des Datums werden hier Schlüsselseriennummer, Art des Vrgangs, Schlüsseltyp, Gebäude- und Raumdaten swie Name und Gruppe des Empfängers aufgelistet (siehe Abb. 33). Abb. 33: Druckvrschau des Belegs zur Schlüsselausgabe (Screensht) Durch eine Unterschrift kann der Empfänger die Krrektheit der Angaben bestätigen. Diese Anerkennung des durchgeführten Vrgangs ist die Vraussetzung für die erflgreiche Beendigung des Przesses. Der Verwalter hat nun die Möglichkeit, einen weiteren Przess durchzuführen und hierfür einen entsprechenden Wizard zu starten. 7 Benchmark-Test Inhalt des flgenden Kapitels ist ein Leistungsvergleich zwischen dem DESY-SVS und einer Kaufsftware. Ziel hierbei ist die Erkenntnis darüber, mit welchem der beiden Systeme die Prjektziele erfüllt werden können und welches vn ihnen den Ansprüchen DESYs genügen kann. Hierbei wurde gemäß des fünfstufigen Verfahrens 54

62 7 Benchmark-Test vn Karlöf und Östblm (siehe Kapitel 4.6) vrgegangen. Der erste Kapitelabschnitt schildert die Herangehensweise bei der Durchführung des Benchmark-Tests. Anschließend flgen eine Analyse der Ergebnisse des Leistungsvergleichs swie eine Zusammenfassung derselbigen. 7.1 Durchführung des Benchmark-Tests Das ausschnittweise in Kapitel 6.3 vrgestellte SVS wurde auf Basis eines ausgearbeiteten Anfrderungskatalgs vn der Firma Hrstick entwickelt und als Erweiterung in ein bestehendes Facility-Management-System integriert. Im Vrfelde war ein entsprechender Aufwand zur Anfrderungserhebung, Analyse der Schlüsselverwaltungsprzesse und zur Entwicklung der Spezifikatin zu leisten. Stellt sich die Frage, b eine kundenspezifische Systementwicklung Aufwand und Ksten rechtfertigt der b der Erwerb einer Kaufsftware ebens ausreicht, um die Kundenwünsche zu befriedigen. Zur Beantwrtung dieser Frage wurde ein Leistungsvergleich mit Hilfe der Benchmarking-Methde durchgeführt. Hiermit ist der erste Punkt nach Karlöf und Östblm geklärt: 1) Untersuchungsbjekt wählen Untersucht werden sll das maßgeschneiderte Schlüsselverwaltungssystem des Deutschen Elektrnen-Synchrtrns. 2) Vergleichsbjekt wählen Als Vergleichsbjekt wurde das System Key Organizer der Firma AIDeX Sftware ausgewählt. Der Key Organizer steht interessierten Kunden als Demversin mit vllständiger Funktinalität, jedch in der Anzahl der Datensätze auf 20 Schlüssel und 20 Persnen begrenzt, zur Verfügung (vgl. AIDeX1). Je nach Bedarf kann der Key Organizer mit unterschiedlicher Datensatzkapazität für einen Preis vn ca. 80 bis ca. 550 erwrben werden. Sllten Größe des Unternehmens der des Schlüsselbestandes zunehmen, ist der Erwerb eines Sftware-Upgrades möglich (vgl. AIDeX2). AIDeX zählt mehr als 500 Unternehmen, Behörden und Organisatinen in Deutschland, Österreich und der Schweiz zu seinen Kunden, darunter den Landesverband der Betriebskrankenkassen Baden-Württemberg BKK, den Arbeiter-SamariterBund in Offenbach, das Kaufhaus Saturn und Reader s Digest Deutschland (vgl. AIDeX3). 3) Daten erheben Die Datengewinnung zu den beiden Prdukten erflgte über einen Fragenkatalg. Dieser deckte flgende vier Aufgabenbereiche und deren Unterpunkte ab: 55

63 7 Benchmark-Test Datenmdell Stammdaten Relatinen User Interface / Ergnmie Benutzerhilfe / Verständlichkeit Ergnmie Przesse Schlüssel ausgeben Schlüssel zurückgeben Systemarchitektur Rllen und Rechte Schnittstelle zu anderen Systemen / Imprt Berichte Der Katalg bestand aus 41 Aufgaben, die vn den Anfrderungen aus der Spezifikatin abgeleitet und hinsichtlich derer beide Systeme getestet wurden. Der Aufgabenkatalg diente als Anleitung, um die beiden Systeme Key Organizer und DESY-SVS einem Testpublikum vrzustellen. Nacheinander wurden alle Aufgaben vn einem Vertreter des Entwicklerteams zunächst mit dem einen, dann mit dem anderen System durchgeführt. Das Testpublikum mit einer Stärke vn vier Persnen vergab für die Erfüllung der Aufgaben Punkte vn 1 bis 4. Die Aufschlüsselung der Bewertung lautet wie flgt: 1 nicht erfüllt 2 erfüllt 3 gut erfüllt 4 sehr gut erfüllt Das Bewertungsspektrum wurde bewusst grbmaschig gehalten, um den Testanwendern bei ihrer Bewertung eine eindeutige Tendenz zu entlcken. In der Auswertung der einzelnen Bewertungen wurden den Punkten przentuale Werte zugerdnet. 1 0% 2 50 % 3 85 % % Dies ermöglichte bei der Zusammenfassung der einzelnen Bewertungen zu einer Gesamtbeurteilung eine bessere Einschätzung der Akzeptanz der beiden Systeme bei den Testanwendern. Da den Aufgabenblöcken, Unteraufgabenblöcken und Aufgaben nicht die gleiche Wichtigkeit zuzurdnen ist, wurde im Vrfeld der Systempräsentatin eine Gewichtung der einzelnen Aufgabenkatalg-Segmente vrgenmmen. Ziel dieser Vrge56

64 7 Benchmark-Test hensweise war, dass als weniger wichtig einzurdnende Aufgaben der Aufgabenblöcke einen geringeren und besnders wichtige einen höheren Anteil zum Gesamtergebnis beitragen. 4) Ergebnisanalyse Die Analyse der gewnnenen Daten aus Punkt 3 erflgt in Kapitel Ergebnisanalyse Im Zuge der Durchführung eines Leistungsvergleichs ist flglicherweise eine Analyse der Ergebnisse vrzunehmen. Die Resultate dieser Betrachtung werden in den nachstehenden Unterkapiteln vrgestellt. Zunächst wird auf das Gesamtergebnis des Leistungsvergleiches eingegangen. Es flgen differenzierte Betrachtungen hinsichtlich der Bewertungen der einzelnen Testanwender swie der Ergebnisse in den einzelnen Aufgabenblöcken und Szenarien Gesamtergebnis Als Ergebnis der Datengewinnung lag eine Leistungsbewertung der beiden Vergleichsbjekte Key Organizer und DESY-SVS durch vier Testanwender vr. Aus den einzelnen Bewertungsergebnissen wurde ein Gesamtergebnis errechnet, das sich in Grafik 34 widerspiegelt. 100 Nutzwert (in %) % % Gesamtnutzwert Key Organizer DESY-SVS Abb. 34: Gesamtergebnis des Benchmark-Tests (eigene Darstellung) 57

65 7 Benchmark-Test Es ist zu erkennen, dass die Kaufsftware Key Organizer bei den Testanwendern eine Akzeptanz vn 58 % erreicht, während das nach DESY-Wünschen entwickelte SVS der Firma Hrstick 75 % Anwenderakzeptanz erzielen kann. Smit liegt die Bewertung beider Systeme über der 50-%-Grenze, was ein entscheidender Indikatr dafür ist, dass die Prjektziele mit beiden Prdukten erreicht werden könnten und ein Scheitern des Prjektes ausgeschlssen werden kann. Dennch es darf nicht übersehen werden, dass das Prdukt Key Organizer die 50-%-Schwelle nur mit knappen 8 % übersteigt und ein Erreichen der Prjektziele mit dem SVS der Firma Hrstick bei 75 % leistungsmäßiger Bewertung eher gewährleistet werden kann Bewertung der einzelnen Testanwender Eine Gesamtbeurteilung der Systeme fasst die Bewertungen der einzelnen Testanwender zusammen. Eine Betrachtung der Einzelergebnisse ermöglicht, Differenzen in der Bewertung unter den Testanwendern zu erkennen. Die Aufspaltung des Gesamtergebnisses gibt Aufschluss darüber, b es sich in den einzelnen Bewertungen der Testanwender widerspiegelt der einen Mittelwert darstellt, der völlig unterschiedliche Anwenderbewertungen zu einer vereinigt. Abbildung 35 stellt das Ergebnis der Einzelbewertungen der vier Testanwender grafisch dar. Abb. 35: Gesamtergebnis unterteilt nach Testanwendern (eigene Darstellung) Ein Vergleich der Werte aus den Abbildungen 34 und 35 ergibt, dass die Bewertungen der Testanwender alle relativ nahe am Gesamtergebnis liegen und die Streuung 58

66 7 Benchmark-Test der Bewertungen recht gering ist. Die Key-Organizer-Bewertungen der Anwender weichen mit maximal 7 % nach ben und 6 % nach unten ab. Bei der Bewertung des DESY-SVS liegt die maximale Abweichung nach ben und unten bei 4 %. Das Gesamtergebnis kann die Bewertung jedes einzelnen Testanwenders gut repräsentieren Bewertung in den Aufgabenblöcken Zur Feststellung vn Defiziten (Punkt 4 nach Karlöf und Östblm, siehe Kapitel 4.6) wird eine Betrachtung der Nutzwerte unterteilt nach Aufgabenblöcken vrgenmmen. Ausgehend hiervn können Schwachstellen und Stärken der beiden Systeme identifiziert und genauer untersucht werden. Um die zu beseitigenden Leistungslücken besser eingrenzen zu können, erflgt im nächsten Schritt eine entsprechende Analyse (siehe Abb. 36). Dies kann bis auf die unterste Ebene eine Betrachtung der einzelnen Aufgaben geführt werden. Eine derart feingliedrige Analyse wurde in dieser Arbeit jedch nicht vrgenmmen. Abb. 36: Systembewertung in den Aufgabenblöcken (eigene Darstellung) Der Grafik in Abbildung 36 ist zu entnehmen, dass das SVS der Firma Hrstick in allen Bereichen eine um ca. 20 % höhere Akzeptanz bei den Testanwendern erzielen kann. Lediglich im Aufgabenblck Systemarchitektur wurde der Key Organizer um 1 % besser als das DESY-SVS bewertet. Gleichzeitig ist zu bemerken, dass das SVS der Hrstick-Entwickler in allen Bereichen über der 50-%-Grenze liegt und ein Scheitern des Prjektes smit ausgeschlssen werden kann. Anders hingegen sieht es bei der Kaufsftware Key Organizer aus. Das Schlüsselverwaltungssystem kann die Testanwender mit seiner Leistung in den Aufgabenblöcken Datenmdell (49 %) und 59

67 7 Benchmark-Test Przesse (53 %) nicht überzeugen und verfehlt die 50-%-Grenze bzw. überschreitet sie nur knapp. Bei dem DESY-SVS ist davn auszugehen, dass die Leistungsfähigkeit im Laufe des Prjektes nch steigerungsfähig ist, da einige Punkte aus dem Anfrderungskatalg zum Zeitpunkt des Benchmarkings nch nicht umgesetzt waren Bewertung in den Szenarien In den Grafiken 37 und 38 werden die Nutzwerte durch eine Analyse der einzelnen Szenarien einer nch detaillierteren Betrachtungsweise unterzgen. Hier lassen sich Schwachstellen gezielter identifizieren Nutzwert (in %) Stammdaten Relatinen Benutzerhilfe / Ergnmie Verständlichkeit Szenari Key Organizer DESY-SVS Abb. 37: Systembewertung in den Szenarien (Teil I, eigene Darstellung) Aus Grafik 37 lässt sich ablesen, dass beide Systeme die Punkte Relatinen und Benutzerhilfe / Verständlichkeit aus Sicht der Testanwender nicht erfüllen können. Hier muss es bei dem DESY-SVS innerhalb des weiteren Prjektverlaufes zu Nachbesserungen kmmen, whingegen dies bei der Kaufsftware nicht möglich ist. Die Prjektziele könnten mit dem Key Organizer in diesen Szenarien swie bei den Stammdaten nicht erfüllt werden. In den Kategrien Stammdaten und Ergnmie kann das DESY-SVS die Testanwender überzeugen. Die Akzeptanz dieser Szenarien erreicht über 90 % und liegt mit 40 % (Stammdaten) bzw. 20 % (Ergnmie) deutlich vr der Kaufsftware Key Organizer. Dieser Leistungsvrsprung kann dahingehend begründet werden, dass das DESY-SVS auf Kundenwünsche angepasst wurde und smit den Anfrderungen eher gerecht werden kann, als die universell verwendbare Sftware Key Organizer. 60

68 7 Benchmark-Test Nutzwert (in %) Schlüssel ausgeben Schlüssel zurückgeben Rllen und Schnittstelle zu Berichte Rechte anderen Systemen / Imprt Szenari Key Organizer DESY-SVS Abb. 38: Systembewertung in den Szenarien (Teil II, eigene Darstellung) Abbildung 38 zeigt, dass das Prdukt der Firma Hrstick in den Szenarien Schlüssel ausgeben und Schlüssel zurückgeben bei den Testanwendern eine Akzeptanz vn über 70 % erreicht und das Testpublikum in den Kategrien Rllen und Rechte swie Schnittstelle zu anderen Systemen / Imprt nahezu kmplett zufrieden stellen kann. Eine deutliche Schwachstelle ist jedch in der Kategrie Berichte zu erkennen. Allerdings ist hierzu zu bemerken, dass dieser Aufgabenbereich der Firma Hrstick zum Zeitpunkt des Benchmarkings nch nicht als Spezifikatin vrlag und smit nch nicht umgesetzt war. 7.3 Zusammenfassung der Ergebnisse Abschließend kann zusammengefasst werden, dass das maßgeschneiderte SVS bereits in einem frühen Entwicklungsstadium durchaus mit einer Kaufsftware mithalten und es in seiner Leistung sgar überbieten kann. In der Gesamtbetrachtung wird deutlich, dass das DESY-SVS die Prjektziele in jedem Fall, die Kaufsftware jedch nur minimal erreichen kann. Eine differenziertere Leistungsbetrachtung ermöglicht die Identifizierung vn Schwachstellen in den einzelnen Aufgabenblöcken und Szenarien. Im Falle des DESY-SVS können Mängel erkannt und in der weiteren Systementwicklung behben werden. 61

69 8 Ksten- und Aufwandsschätzung für die SVS-Entwicklung Die Ergebnisse des Benchmark-Tests müssen dennch kritisch betrachtet werden. Bei den Testanwendern handelt es sich zwar um unvreingenmmene Persnen, die jedch nur geringes Fachwissen im Bezug auf den Bereich der Schlüsselverwaltung besitzen. Sie sind nicht ausreichend mit der Materie vertraut, um die Leistungen der Systeme wirklich beurteilen zu können. Hinzu kmmt, dass die Gewichtung der Aufgabenblöcke und Szenarien vn Prjektteilnehmern der Gruppe IPP vergeben wurde, die zwar ein gewisses Beurteilungsvermögen zum Thema Schlüsselverwaltung besitzen, letztendlich aber keine Facility-Management-Experten der Schlüsselverwalter sind. 8 Ksten- und Aufwandsschätzung für die SVS-Entwicklung Entscheidet man sich für den Erwerb und den Einsatz einer Kaufsftware, können die Ksten im Vrfeld mühels eingehlt werden. Bei einer maßgeschneiderten Entwicklung auf Basis einer Spezifikatin ist entweder ein Pauschalpreis festzulegen der die Entwickler sind nach Aufwand zu vergüten. In diesem Fall entschied sich DESY für eine aufwandsbezgene Entlhnung. Um einen genauen Kstenüberblick zu erhalten und das zugestandene Prjektbudget nicht zu überschreiten, war im Vrwege eine Abschätzung der Entwicklungsksten ntwendig. Dies erflgte auf Basis einer Funktinspunktanalyse. Die Durchführung einer entsprechenden Aufwands- und Kstenschätzung stellt den Inhalt dieses Kapitels dar. Es wird die Herangehensweise erläutert und eine Abschätzung des Aufwandes für die Entwicklung der Schlüsselausgabekmpnente durchgeführt. In den weiteren Kapitelabschnitten flgen eine Abschätzung zur Realisierung der Schlüsselrückgabefunktinalitäten swie der gesamten SVS-Entwicklung. Abschließend wird eine Ergebnisbetrachtung zur Ksten- und Aufwandsschätzung vrgenmmen. 8.1 Durchführung der Aufwandsschätzung Entsprechend der in Kapitel 4.7 beschriebenen Herangehensweise wird in diesem Kapitel eine Aufwandsschätzung für die Entwicklung der Schlüsselausgabefunktinen vrgenmmen. Zunächst sll die zu erwartende Team Perfrmance die Anzahl der Funktinspunkte, die der Entwickler der Firma Hrstick vraussichtlich an einem Tag umsetzen kann abgeschätzt werden. In der Praxis können ftmals Erfahrungswerte verwendet werden. Da diese jedch nicht vrlagen, wurde die Team Perfrmance mit Hilfe eines praktischen Beispiels ermittelt. Als Basis dienten hierfür eine Eingabe- (Abb. 39) und eine Ausgabemaske (Abb. 40). Die Beispiel-Eingabe besitzt zwei Eingabefelder. Sie kann smit als einfach eingestuft und gemäß der Matrix in Kapitel 4.7 mit 3 Funktinspunkten versehen werden. 62

70 8 Ksten- und Aufwandsschätzung für die SVS-Entwicklung Abb. 39: Beispielhafte Eingabemaske (Screensht) Die Ausgabemaske liefert fünf Datensätze mit je drei Feldern. Sie kann ebenfalls als einfach eingestuft werden und erhält gemäß der Matrix in Kapitel Funktinspunkte. Abb. 40: Beispielhafte Ausgabemaske (Screensht) Mit einer einfachen Eingabe- (3 FP) und einer einfachen Ausgabemaske (4 FP) ergibt sich flgende Rechnung für den Wert UFP: 63