Kabelmanagement am DESY.

Agenda Projektziel Projekthistorie Projektablauf Produktivbetrieb Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung) Systemeinführung Produktivbetrieb Ausblick und Randbedingungen Erfahrungen

Projektziel “Das KDS soll als Werkzeug der elektronischen Datenverarbeitung zur Unterstützung von Kabelinstallationen, Wartungsarbeiten, Reparaturen und deren Dokumentation dienen.“ D.h. es soll Informationen über Kabel, Kabeltrassen, Verbindungen, verbundene Geräte, Auslastungen halten, z.B. Engpässe oder Störungen verfolgen, bei der Planung neuer Trassen und Schaltungen (Patchaufträge, Wegesuche etc.) unterstützen, . . .

Lebenszyklus eines Beschleunigerprojektes und Einsatz eines Kabelmanagement-Systems Produktion Planung Entwurf Betrieb Planung Störungen Schaltaufträge Patchungen Neuverkabelung in Gebäuden Dokumentation Berichte I t

Projekthistorie Ergebnis: Juli 2006: Neuaufnahme des Projekts bis Nov. 2006: Erstellung des Lastenhefts Parallel: Marktstudie (Long-IT) Ergebnis: *Es gibt mehrere Anbieter, die die DESY-Muss-Anforderungen erfüllen können, d.h. die Systemauswahl muss(te) über eine Ausschreibung erfolgen. *Es ist Anpassungsaufwand am System zu erwarten, um DESY-Anforderungen umzusetzen, daher ist die Auswahl eines geeigneten Systemanbieters mitentscheidend für den Erfolg des Projekts. *System und Anbieter werden getestet im Benchmark.

Projekthistorie Juli 2006: Neuaufnahme des Projekts bis Nov. 2006: Erstellung des Lastenhefts Parallel: Marktstudie (Long-IT) Nov. 2006: Ausschreibung (Bekanntmachung des Vorhabens; EU-Verf.; Verhandlungsverfahren m. vorheriger Bekanntmachung) Mrz. 2007: Systemtests mit 3 Firmen -> Funktionstest Empfehlung: Weiter geht´s! Systemtechnik Anpassungsaufwand Mitarbeiter FNT + Firma II - Firma III

Projekthistorie Juli 2006: Neuaufnahme des Projekts bis Nov. 2006: Erstellung des Lastenhefts Parallel: Marktstudie (Long-IT) Nov. 2006: Ausschreibung (Bekanntmachung des Vorhabens; EU-Verf.; Verhandlungsverfahren m. vorheriger Bekanntmachung) Mrz. 2007: Systemtests mit 3 Firmen -> Funktionstest Nov./Dez. 2007: Pilotphase (Pilot-Feinspezifikation I und Pilotinstallation) -> Handhabungstest Feb.2008: Freischaltung der OOTB-KDS-Version für DESY und parallel Schulungen Juli 2008: Fertigstellung der Feinspezifikation und Aufwandsschätzung Bis Dez.2008: Erstellung eines Systementwurfs (FNT) und Umsetzung Nov. 2008 - Januar 2009: Überprüfung der Umsetzung von DESY-Anforderungen am Testsystem (iteratives Vorgehen) Feb. 2009: Freigabe eines an DESY-Anforderungen angepasstes KDS

Agenda Projektziel Projekthistorie Projektablauf Produktivbetrieb Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung) Systemeinführung Produktivbetrieb Ausblick und Randbedingungen Erfahrungen

Zunächst wird ein (Schalt-) Auftrag geschrieben... Von den Aufgaben... Zunächst wird ein (Schalt-) Auftrag geschrieben... ...dann zugewiesen...

...über deren Abfolge... Der (Schalt-)Auftrag wird angelegt... ...auf Vollständigkeit geprüft... ...angenommen, umgesetzt... ...und zum Schluss abgenommen.

... bis zur beschriebenen Systemoberfläche Welche Randbedingungen gibt es? Wie genau stellen wir uns den Vorgang „Auftrag anlegen“ vor?

Spezifikationen Erstellung von Lastenheften durch „Verbalisierung“ des Modells mit Forderungen an z.B. Arbeitsabläufe Datenbankinhalte Masken und Berichte Funktionsumfang der Systemkomponenten Systemkonfiguration und -administration oder durch betriebliche Randbedingungen Arbeitsgrundlage für alle Projektmitarbeiter

Leistungszusicherungskataloge Tabellarische Auflistung aller Anforderungen aus dem Pflichtenheft Erfüllungsgrad durch gelieferte Systemsoftware ist vom Lieferanten vorab schriftlich zu fixieren Standardumfang, im nächsten Release enthalten, zu realisieren binnen x Tagen, nicht realisierbar, ... Der Leistungszusicherungskatalog wird Vertragsbestandteil !

Systemauswahl - Methode Benchmark (bzw. Benchmarking (= Maßstäbe setzen)) als formalisiertes Konzept, nach der komplexe Leistungen von vergleichbaren Programmen gemessen und nach bestimmten Kriterien verglichen und bewertet werden…und zwar VOR Software-Kauf Ausgeführt durch repräsentatives Anwenderteam Voraussetzung für Projektplanung und -aufwandsschätzung Ergebnis: Technische Fähigkeiten und Grenzen des KDS ermitteln, Konfigurationsaufwand und Erfüllungsgrad des Lastenhefts abschätzen, Projektrisiken ermitteln Ablauf: Im Vorwege erhielt der Anbieter ein BM-Vorbereitungsexemplar (mit Themen) und Testdaten. Am BM-Tag wurden Aufgaben live am KDS vorgeführt. Basis war das BM-Durchführungsexemplar und mitgebrachte Daten. Das BM-Team bewertete vor Ort die vorgeführten Aufgaben.

Systemauswahl ... und Benchmarkszenarien point-to-point-connection Verbindung von Geb. 16 nach Geb. 50 finde mögliche Verbindungen generiere alle Patches erstelle mehraderige Verb. identifiziere angeschlossene Endgeräte Spezialfälle erkenne HV-Verbindungen durch Transformatoren usw. verwalte Telefone und Tel.-Nr. ... Building #50 Building #16 Cable 1 + IN SPS1 monitor L1 1a 1b L2 R16 - 1 R 50 L 2 Gebäude #50 Gebäude DW sensor Szenario „Point-to-Point-Connection“ Bldg. #16 HV - cable 10 kV source transormer switchboard MK 2806D consumer Geb. transformer Spezialisierte Funktionalität

...einige Eindrücke von den Benchmarks Benchmarktest mit Kandidatensystemen Evaluierungsteam aus 10 künftigen Anwendern Idee: Test-Szenarien auf allen Kandidatensystemen ausführen zuvor Kriterien definieren, Zeitlimits setzen, Szenarien beobachten und Leistung bewerten Ergebnisse nach Themen, Anwendern etc. aggregieren

Lizenz- u. Dienstleistungsverträge Vertragsmodell, das den Anbieter früh einbezieht (suspensiv verkettete Verträge) Dienstleistungs-vertrag (20% des ges. Volumens f. Pilot) Feinspezifikation m.Leistungszusicherungs- Katalog (LZK) Dienstleistungs- vertrag Wartungs- und Lizenzvertrag Dienstleistungsvertrag beschreibt geplanten Projektumfang erstes Projektergebnis: abgestimmte Feinspezifikation gemeinsam mit Systemanbieter erstellt Lizenzvertrag basiert auf Feinspezifikation und tritt erst mit deren Abschluss und Umsetzung in Kraft Hauptteil des Budgets wird erst nach Lizenzlieferung freigegeben

Vorgehen bei der Systemeinführung Phase 1 (Pilotinstallation) Dokumentation der Verkabelung von DESY-Gebäuden (insbes. PETRA) Meilensteine: Lauffähiges KDS in der DESY-Softwareumgebung (OOTB) Geschulte Anwender (begrenzter Anwenderkreis) Dokumentierte Verkabelung (begrenzter Datenumfang) Bewertete Pilotphase Phase 2 (Feinspezifikation) Erstellung einer Feinspezifikation (Pflichtenheft) gemeinsam mit dem Systemanbieter Ausgearbeitetes und abgestimmtes Pflichtenheft Definierter Umfang des Betriebs- und Wartungskonzepts Definierter Umfang der Systemanpassungen gem. Spezifikation Phase 3 (Umsetzung) Bereitstellung eines DESY-spezifischen KDS Betriebsbereites DESY-weit verfügbares KDS gem. Pflichtenheft Geschulte Anwender

Durchführung der Pilotphase (Phase 1) Pilotteam: Mitarbeiter der Fachgruppen MDI, MKK, IT, IT-TK, IPP Vorbereitung: 3 Tage Schulung in der Handhabung des KDS von FNT (Command) Durchführung: 10 Tage intensives Arbeiten am KDS unter fachlicher Betreuung sowie detaillierte Einweisung in weitere Themen durch Fa. FNT. Abschluss: Bewertung zur Handhabung und Komfortabilität des KDS durch jeden Pilotteam-Mitarbeiter Fachliche Kompetenz der FNT-Mitarbeiter Zugriffsrechte, Benutzereinrichtung Import von Stamm- und Bewegungsdaten Berichte, Protokolle, Abfragen, Suche Gruppenübergreifende Fremdverkabelung Systemdokumentation System-Handhabung System-Vollständigkeit (FNT-Standard) Visio

Ergebnis der Pilotphase (Phase 1) Ziel: Test des KDS bzgl. Handhabung, Nutzbarkeit (Usability) und Anpassungsfähigkeit im Rahmen von fachgruppenspezifischen Arbeitsabläufen, d.h. schnelle und einfache Einarbeitung, Gute Zusammenarbeit mit der Fa. FNT effiziente, eingängige Anwendungsmöglichkeiten. Test einer KDS-Installation in der DESY-Systemumgebung Ergebnis: Ein zufriedenstellendes Arbeiten am DESY mit dem KDS wird erwartet Mehrwert für DESY durch das KDS Endlich eine gruppenübergreifende Dokumentation von Kabeln und Verbindungen, z.B. Pilotherme Das System erfüllt schon jetzt viele wesentliche DESY-Anforderungen Einige DESY-spezifische Anforderungen (existieren) müssen dringend noch umgesetzt werden (insbesondere grafische Anbindung). FNT erscheint als ein sehr kompetenter Partner, der in der Lage ist, diese Anforderungen zu erfüllen. Eine Durchschnittsnote von 2,34 für ein System „out of the box“ (bzw. commercial of the shelf COTS)

Abnahmeverfahren DESY-DEV DESY-TST DESY-Anforderungen wurden in der Feinspezifikation (FSII) beschrieben und dienen DESY als Testszenarien, um die Umsetzung zu prüfen. Die Projektleitung prüfte in einem Vorabtest, ob die Version zum Test für die Anwender geeignet ist. Ggf. werden gravierende Fehler umgehend von FNT behoben. Die Anwender testeten die Version. Eine Fehlerliste wurde erstellt. Die Abschlussprüfung erfolgt durch DESY. Ein Abnahme-Protokoll wird erstellt. vorab testen (DESY) gravierende Mängel [ nok ] beheben (FNT) [ ok ] Anwender testen (DESY) Fehlerliste erstellen Bugs fixen (FNT) [ ok ] Abschlussprüfung durch- führen und freigeben (DESY) Abnahmeprotokoll erstellen [ ok ] Freigegeben für Betrieb (DESY-PRD)

Fehlerliste Die Fehlerliste klassifiziert die Fehler hinsichtlich der weiteren Bearbeitung. Fehlerschwere/Severity: Kat. 1: Systemfunktion nicht nutzbar, nur durch Systemänderung behandelbar Kat. 2: Systemfunktion nicht nutzbar, durch Anleitung (Workaround) behebbar Kat. 3: Systemverhalten fehlerhaft/fehlerträchtig Kat. 4: Systemverhalten ergonomisch ungünstig Kat. 5: nicht direkt mit Geschäftsprozess verbunden Fehlerbehebung: QS : Der Fehler fällt unter Qualitätssicherung und wird umgehend behoben ignore : Der Fehler wird zur Zeit nicht weiter behandelt. Zusatz : Der Fehler soll behoben werden, die Kosten trägt der Auftraggeber.

Abnahmeprotokoll Wenn alle UseCases (oder Funktionen) mit „ok“ bewertet wurden, gilt die Programmversion als abgenommen. Eine definierte Anzahl von kleineren Fehlern kann nachträglich beseitigt werde und schließt die Abnahme nicht aus.

Agenda Projektziel Projekthistorie Projektablauf Produktivbetrieb Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung) Systemeinführung Produktivbetrieb Ausblick und Randbedingungen Erfahrungen

Zahlen... DESY-Gruppen im KDS und Anwender im Juni 09 MDI MKK IT IT-TK IPP MPS HASYLAB MHF-E MHF-P MKS MIN HASYLAB-SHT ZEUTHEN EMBL Immer mehr Anwendern aus unterschiedlichen Gruppen arbeiten mit command. -> command wird für zunehmend interdisziplinäre Aufgaben eingesetzt, teilweise über die Grenzen des Systems hinaus. Read-Zugriff: 50 Davon Voll-Zugriff: 39 Davon KDS-Gruppenadmins: 19

Weitere Aufgaben Schnittstellen-Umsetzung Bestandsdaten-Erfassung (in Arbeit) Update-Schulungen (geplant) (Später auch Inhouse-Schulungen) Anwendertreffen Etc.

Stückliste/TGA-Bericht Umsetzung eines Anwendungsfalls im Geoinformations- und Facility Management System (GIS/FMS) Such-Maske Karte Projektstruktur wählen Gebäude auswählen Karte anzeigen lassen Etage auswählen Bauzeichnung anzeigen lassen Raum auswählen in Bauzeichnung oder Strukturbaum Infos zum Raum anzeigen lassen Stückliste/TGA-Bericht Raumnutzungs-Bericht Raumnutzungs-Anzeige

Weitere Aufgaben Schnittstellen-Umsetzung Bestandsdaten-Erfassung (in Arbeit) Update-Schulungen (geplant) (Später auch Inhouse-Schulungen) Anwendertreffen Etc.

Risiken und Abhängigkeiten Verfügbarkeit der Projektmitarbeiter Bestandsdatenerfassung als Folge-/Parallelaufgabe zur Einführung des Systems ist Voraussetzung für die gruppenübergreifende Arbeit. Separates Projekt unter Leitung von MDI Erweiterung von command durch Schnittstellen zu bereits eingesetzten Systemen für den Einsatz bei interdisziplinären Aufgaben. Akzeptanz und Einhaltung der definierten Arbeitsabläufe Prozessorientierte Aktivitäten, (hierarchisches) Transaktionsmodell Kollaboratives Aktivitäten, „marketplace working“, Ad hoc- Prozesse, Netzwerkmodell

Erfahrungen Betrachtung aller geplanten Nutzungen und deren Zusammenspiel im Vorfeld hilft bei Definition des Projektumfangs bezieht zukünftige Anwender früh mit ein und fördert die System-Akzeptanz Rechtzeitige und intensive Einbeziehung der zukünftigen Anwender wichtig für Teambildung und Ausbildung Sicherheit und Systemstabilität durch den Einsatz mehrerer Systemumgebungen für Entwicklung, Test und Produktiv-Programmversionen Benchmarking als Systemauswahl-Methode gibt gute Einschätzung des Systemverhaltens im späteren Einsatz bereits vor Einführung eines Systems lässt Stärken und Schwachstellen des Systems frühzeitig erkennen hilft bei Abschätzung der zu erwartenden Anpassungs- und Entwicklungsaufwände Benchmark mit Testszenarien essenziell für Projektplanung, aber auch schwer durchsetzbar wegen (scheinbarer) Aufwände Vertragsmodell (suspensiv verkettete Verträge) bezieht Systemanbieter früh mit ein und schützt vor Spezifikation „am System vorbei“ LZK schützt Kunden vor Packaging-Willkür des Herstellers Etablierung eines GIS/FMS als zentrales Informationssystems durch Betrachtung aller geplanten Nutzungen und deren Zusammenspiel im Vorfeld D.h. nicht nur Konzentration auf bestimmte Anwendungsfelder, sondern frühzeitige Einbindung aller zukünftigen Systemanwender mit ihren Arbeitsprozessen und Anwendungsfällen in das Projekt Benchmarking als Systemauswahl-Methode gute Einschätzung des Systemverhaltens im späteren Einsatz bereits vor Einführung eines Systems Frühzeitiges Erkennen von Stärken und Schwachstellen des Systems Abschätzung der Anpassungs- und Entwicklungsaufwände als Grundlage für Projektplanung Schwer durchsetzbare Methode aufgrund scheinbarer Aufwände Suspensiv verkettete Verträge ermöglichen Kompromisse bei Lizenz- und Wartungsbedingungen LZK schützt Kunden vor Packaging-Willkür des Herstellers Einsatz eines Requirements Management System (RMS) Gute Unterstützung bei Projekten mit viele Beteiligten, Prozesse und Systemkomponenten während des ganzen Projekts. von der Erstellung der Systemspezifikationen bis zur Implementierung und Abnahme des Systems

User + Systeminterfaces Erfahrungen Betrachtung aller Anwendungsfälle zur Systemintegration in eine vorhandene Softwarelandschaft Integration: Der Anwender sieht nur das User-Interface und ist nicht daran interessiert, unterschiedliche Software zu nutzen. Die Integration muß sowohl auf Logik- und Datenebene (Datenimport und –austausch) als auch insbesondere auf der Oberfläche umgesetzt werden. Eine “schnelle” Lösung betrachtet meist nur eine dieser Ebenen und erfüllt damit häufig nur Anwendungsfälle geringer Komplexität. Eine umfangreiche Nutzung und gute Akzeptanz der Software wäre damit nicht gesichert. KDS andere GIS/FMS User + Systeminterfaces Kernel Repository Objektbezogene Umsetzung ggü. prozessbezogener Abnahme Abhängig von Erfahrung des Fertigers sind zusätzliche Testszenarien notwendig, die Verwendung der gefertigten (Teil-) Komponenten beschreiben (die ggf. nicht den def. Anwendungsfällen entsprechen) Fertiger lernen beim Kunden 

für Ihre Aufmerksamkeit! Vielen Dank für Ihre Aufmerksamkeit! Andrea Robben Deutsches Elektronen-Synchrotron (DESY) Informationsmanagement, Prozesse, Projekte (IPP) Notkestraße 85 22607 Hamburg Tel. 040/8998 4946 andrea.robben@desy.de