Kabelmanagement am desy
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Kabelmanagement am DESY . PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Kabelmanagement am DESY .

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Kabelmanagement am desy

Kabelmanagement am DESY.


Agenda

Agenda

  • Projektziel

  • Projekthistorie

  • Projektablauf

    • Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung)

    • Systemeinführung

  • Produktivbetrieb

  • Ausblick und Randbedingungen

  • Erfahrungen


Projektziel

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

Betrieb

Produktion

Planung

Entwurf

Lebenszyklus eines Beschleunigerprojektes und Einsatz eines Kabelmanagement-Systems

Planung

Störungen

Schaltaufträge

Patchungen

Berichte

Neuverkabelung

in Gebäuden

Dokumentation

I

t


Projekthistorie

Projekthistorie

  • 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.


Projekthistorie1

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!


Projekthistorie2

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


Agenda1

Agenda

  • Projektziel

  • Projekthistorie

  • Projektablauf

    • Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung)

    • Systemeinführung

  • Produktivbetrieb

  • Ausblick und Randbedingungen

  • Erfahrungen


Von den aufgaben

Von den Aufgaben...

Zunächst wird ein (Schalt-) Auftrag geschrieben...

...dann zugewiesen...


Ber deren abfolge

...über deren Abfolge...

Der (Schalt-)Auftrag wird angelegt...

...auf Vollständigkeit geprüft...

...angenommen, umgesetzt...

...und zum Schluss abgenommen.


Bis zur beschriebenen systemoberfl che

... 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

Spezifikationen


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 !

Leistungszusicherungskataloge


Systemauswahl methode

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

Szenario „Point-to-Point-Connection“

Gebäude

Building

#16

#16

Gebäude #50

Building #50

R16

R16

R16

-

-

-

1

1

1

R

R

R

50

50

50

-

-

-

1

1

1

L1

L1

L1

L2

L2

L2

L

L

L

2

2

2

L

L

L

1

1

1

1a

1a

1a

1a

1a

1a

1a

1a

1a

1a

1a

1a

Cable 1

Cable 1

+

+

+

SPS1

SPS1

SPS1

DW

-

1

1b

1b

1b

1b

1b

1b

1b

1b

1b

1b

1b

1b

monitor

monitor

monitor

sensor

IN

IN

IN

Spezialisierte Funktionalität

Bldg.

Geb.

#16

#16

transormer

transformer

switchboard

transormer

transormer

switchboard

10 kV

10 kV

source

source

HV

HV

-

-

cable

cable

10 kV

MK

MK

MK

-

-

-

2806D

2806D

2806D

source

consumer

consumer

consumer

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.

    • ...


Kabelmanagement am desy

...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

Lizenz- u. Dienstleistungsverträge

  • 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

  • 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


Vorgehen bei der systemeinf hrung

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

  • Meilensteine:

    • Ausgearbeitetes und abgestimmtes Pflichtenheft

    • Definierter Umfang des Betriebs- und Wartungskonzepts

    • Definierter Umfang der Systemanpassungen gem. Spezifikation

      Phase 3 (Umsetzung) Bereitstellung eines DESY-spezifischen KDS

  • Meilensteine:

    • Betriebsbereites DESY-weit verfügbares KDS gem. Pflichtenheft

    • Geschulte Anwender


Durchf hrung der pilotphase phase 1

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

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

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

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

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.


Agenda2

Agenda

  • Projektziel

  • Projekthistorie

  • Projektablauf

    • Methodik (Spezifikation, Vertragsmodell, Auswahlkriterien und Entscheidung)

    • Systemeinführung

  • Produktivbetrieb

  • Ausblick und Randbedingungen

  • Erfahrungen


Zahlen

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äreAufgaben eingesetzt, teilweise über die Grenzen des Systems hinaus.

  • Read-Zugriff: 50

  • Davon Voll-Zugriff: 39

  • Davon KDS-Gruppenadmins: 19


Weitere aufgaben

Weitere Aufgaben

  • Schnittstellen-Umsetzung

  • Bestandsdaten-Erfassung (in Arbeit)

  • Update-Schulungen (geplant)

  • (Später auch Inhouse-Schulungen)

  • Anwendertreffen

  • Etc.


Umsetzung eines anwendungsfalls im geoinformations und facility management system gis fms

Umsetzung eines Anwendungsfalls im Geoinformations- und Facility Management System (GIS/FMS)

Such-Maske

Karte

Stückliste/TGA-Bericht

Raumnutzungs-Bericht

Raumnutzungs-Anzeige


Weitere aufgaben1

Weitere Aufgaben

  • Schnittstellen-Umsetzung

  • Bestandsdaten-Erfassung (in Arbeit)

  • Update-Schulungen (geplant)

  • (Später auch Inhouse-Schulungen)

  • Anwendertreffen

  • Etc.


Risiken und abh ngigkeiten

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

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


Erfahrungen1

GIS/FMS

andere

KDS

User + Systeminterfaces

Kernel

Repository

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.

  • 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 


Kabelmanagement am desy

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

[email protected]


  • Login