Pflichtenheft Basissystem - MISTRA Public

ASTRA • OFROU 

Managementinformationssystem 

Strasse und Strassenverkehr 

Code B SE 

Teilprojekt Basissystem 

Pflichtenheft Basissystem 

Version 4.1 

Datum 30. September 2005 

Techdata AG 

Projekt- und Baumanagement 

D:\Daten\Aufträge\MISTRA\Basissystem\Pflichtenheft\R 2005 09 30 B Pflichtenheft Basissystem V4.1.doc / 19.10.2005 

Effingerstrasse 13, Postfach, 3001 Bern 

Tel. 031 384 07 07, Fax 031 384 07 17 

E-Mail: bern@techdata.net

MISTRA -Pflichtenheft Basissystem 

Impressum 

Erstelldatum 29. August 2003 

Ausgabedatum 19.10.2005 16:02:00 

Autor(en)/Autorin(nen) Th. Mahrer, Chr. Kaeser, E. Bernard, J. Landolt, A. Peyinghaus, M. Cremosnik 

Verzeichnis/Dateiname R 2005 09 30 B Pflichtenheft Basissystem V4.1.doc 

Anzahl Seiten 126 

Dokumentenverwaltung 

Version Datum Autor Bemerkungen 

1.0 29.01.04 EB Ergänzungen nach internem Review 

2.0 30.08.04 EB Überarbeitung nach Review ELCA + Erweiterungen 

2.01 06.09.04 EB Korrekturmarkierung entfernt 

3.01 03.03.05 EB Entwurf Version 3 

3.02 18.04.05 EB Überarbeitung aufgrund Review ELCA und DWH 

3.03 22.04.05 EB Diverse Anpassungen nach internem Review 

3.04 29.04.05 EB Änderungen nach Steuerungssitzung eingebaut 

3.05 02.05.05 EB Korrekturen und Ergänzungen von Korrekturlesungen 

3.1 03.05.05 EB Freigegeben für Offertstellung Basissystem und DWH 

3.11 23.05.05 EB Korrekturmarkierung entfernt 

3.2 15.08.05 EB Begriffe mit Dokument Geschäftsprozesse abgeglichen 

4.0 30.09.05 EB Neuer Inhalt Projektauftrag in Kap 2 bis 5 eingearbeitet, Bemerkungen 

EBP eingebaut, Kap 7 Datenintegration ergänzt, weitere geringfügige 

Korrekturen. 

4.1 30.09.05 rbo Korrekturmarkierung entfernt

MISTRA - Pflichtenheft Basissystem 

Inhaltsverzeichnis 

Seite 

0 ALLGEMEINES...........................................................................................................................................1 

0.1 Einleitung ..........................................................................................................................................1 

0.2 Grundlagen .......................................................................................................................................1 

0.3 Literaturhinweise...............................................................................................................................2 

1 ZWECK DES DOKUMENTS.......................................................................................................................3 

2 AUSGANGSLAGE ......................................................................................................................................4 

2.1 Auftrag ..............................................................................................................................................4 

2.2 Abgrenzung ......................................................................................................................................6 

2.3 Organisation .....................................................................................................................................7 

2.4 Marktanalyse ....................................................................................................................................7 

2.5 GIS, Web-Technologie, Standards...................................................................................................8 

3 IST-ZUSTAND ............................................................................................................................................9 

3.1.1 Neugestaltung des Finanzausgleiches und der Aufgabenteilung (NFA).............................9 

3.1.2 Geschäftsprozesse ..............................................................................................................9 

3.1.3 ISA, KOFINAS, Projektkosten-Controlling.........................................................................10 

3.1.4 STRADA-DB, KUBA-DB, UH-PERI ...................................................................................10 

3.1.5 Verkehrsunfälle..................................................................................................................11 

3.1.6 Verkehrsmonitoring............................................................................................................11 

3.1.7 Langsamverkehr, GIS-LV, DM-LV.....................................................................................12 

3.1.8 Inventar der historischen Verkehrswege der Schweiz (IVS) .............................................12 

3.1.9 Sonderbewilligungen .........................................................................................................13 

3.1.10 Erhaltungsmanagement.....................................................................................................13 

4 ZIELE UND LÖSUNGEN..........................................................................................................................14 

4.1 Vision ..............................................................................................................................................14 

4.1.1 Unterhaltsstrategie.............................................................................................................14 

4.1.2 Ausbauprojekte..................................................................................................................15 

4.1.3 Ausnahmetransporte .........................................................................................................15 

4.1.4 Verkehrssicherheitspolitik (Via Sicura) ..............................................................................16 

4.2 Systemziele ....................................................................................................................................17 

4.2.1 Übergeordnete Ziele ..........................................................................................................17 

4.2.2 Oberziele............................................................................................................................17 

4.3 Hauptziele.......................................................................................................................................17 

4.3.1 Systembezogene Ziele ......................................................................................................18 

5 ANFORDERUNGEN MUSSKRITERIEN ..................................................................................................22 

6 SYSTEMANFORDERUNGEN BASISSYSTEM .......................................................................................23 

6.1 Basissystem - Anforderungen Realisierung ..................................................................................23 

6.1.1 Systemaufbau und -grenzen..............................................................................................23 

6.1.2 Systemarchitektur MISTRA ...............................................................................................26 

6.1.3 Systemarchitektur Basissystem.........................................................................................28 

6.1.4 Basisprodukte und -technologien ......................................................................................31 

6.1.5 Modularer Systemaufbau...................................................................................................32 

6.1.6 Anbindung von MISTRA-Fachapplikationen......................................................................33 

6.1.7 Unterstützende Funktionen Basissystem für Fachapplikationen.......................................35 

6.1.8 Grundanforderungen an die Fachapplikationen ................................................................37 

6.1.9 Anbindung von Fremdapplikationen ..................................................................................37 

6.1.10 Verteilung der MISTRA-Instanzen, typische Systemkonfigurationen................................39 

6.1.11 Authentisierung und Rechte ..............................................................................................43 

6.1.12 Mehrbenutzerbetrieb, Bearbeitungseinheiten....................................................................44 

6.1.13 Service-Interface................................................................................................................45 

Version 4.1, 30.09.2005 

a


6.1.14 Standardisierte Schnittstelle (Interlis2) ..............................................................................47 

6.1.15 Export WebGIS KOGIS .....................................................................................................49 

6.1.16 Import Daten Beteiligter .....................................................................................................50 

6.1.17 Import Daten zu Dokumenten............................................................................................50 

6.1.18 Import Daten Verkehrsnavigation ......................................................................................50 

6.1.19 Import Daten Verkehrsinformation.....................................................................................51 

6.1.20 Export Metadaten KOGIS ..................................................................................................51 

6.1.21 Weitere Schnittstellen ........................................................................................................51 

6.1.22 Selektionswerkzeug...........................................................................................................52 

6.1.23 Clients / Benutzeroberfläche..............................................................................................52 

6.1.24 Anwendungsfälle (UseCases) ...........................................................................................54 

6.1.25 GIS-Basisapplikation .........................................................................................................63 

6.1.26 Administrationsapplikation .................................................................................................68 

6.1.27 Applikation Achsband ........................................................................................................69 

6.1.28 Mehrsprachigkeit................................................................................................................71 

6.1.29 Sicherheit 71 

6.1.30 Dokumentation...................................................................................................................73 

6.1.31 Leistungsanforderungen, Antwortzeiten ............................................................................74 

6.2 Basissystem – Anforderungen Einführung ASTRA........................................................................75 

6.2.1 Einführungskonzept ...........................................................................................................75 

6.2.2 Systemabnahme................................................................................................................75 

6.2.3 Installation..........................................................................................................................76 

6.2.4 Schulung ............................................................................................................................76 

6.3 Basissytem - Anforderungen Betrieb..............................................................................................76 

6.3.1 Konfigurationsmanagement...............................................................................................76 

6.3.2 Wartung .............................................................................................................................77 

6.3.3 Release Management........................................................................................................78 

6.3.4 Support (Problem Management) .......................................................................................78 

7 DATENINTEGRATION .............................................................................................................................80 

7.1 Basisdatenintegration .....................................................................................................................80 

7.1.1 Schnittstelle STRADA........................................................................................................80 

7.1.2 Schnittstelle UH-PERI........................................................................................................82 

7.1.3 Datenübernahme ...............................................................................................................82 

7.1.4 Datenaufbereitung .............................................................................................................82 

7.2 Integration weiterer Basisdaten ......................................................................................................83 

7.2.1 Integration Daten Verkehrsnavigation ...............................................................................83 

7.2.2 Integration Daten Verkehrsinformation..............................................................................83 

7.3 Integration Generalistendaten ........................................................................................................83 

7.3.1 Schnittstelle Trassen .........................................................................................................83 

7.3.2 Integration Kunstbauten mit Kennzahlen...........................................................................83 

7.3.3 Integration Unfalldaten.......................................................................................................83 

7.3.4 Integration Verkehrsdaten .................................................................................................84 

7.3.5 Integration Langsamverkehr ..............................................................................................84 

7.3.6 Integration Daten historische Verkehrswege.....................................................................84 

7.3.7 Integration Betriebsbuchhaltung........................................................................................85 

8 SYSTEMANFORDERUNGEN DATA WAREHOUSE ..............................................................................86 

8.1 Data Warehouse – Anforderungen Realisierung............................................................................86 

8.1.1 Einleitung ...........................................................................................................................86 

8.1.2 Architektur..........................................................................................................................87 

8.1.3 Konzeptionelle Anforderungen ..........................................................................................92 

8.1.4 Abfragen und Reports........................................................................................................94 

8.1.5 Funktionale Anforderungen ...............................................................................................99 

8.1.6 Anwendungsfälle (UseCases) .........................................................................................100 

8.1.7 Software/Tool Anforderungen..........................................................................................102 

8.1.8 Datenschutz und Datensicherheit....................................................................................104 

8.1.9 Technische Anforderungen..............................................................................................106 

Version 4.1, 30.09.2005 

b

TU9UT TUPLANUNG 

................................................................................................................119 

...................................................................................................119 


TU8.1.10UT TUMengengerüstUT..................................................................................................................108 

TU8.1.11UT TUDokumentationUT.................................................................................................................109 

TU8.1.12UT TUProjektplanungUT.................................................................................................................111 

TU8.2UT TUData Warehouse – Anforderungen Einführung ASTRAUT ...............................................................113 

TU8.2.1UT TUEinführungskonzeptUT .........................................................................................................113 

TU8.2.2UT TUSystemabnahmeUT..............................................................................................................113 

TU8.2.3UT 

TUInstallationUT........................................................................................................................113 

TU8.2.4UT TUSchulungUT..........................................................................................................................114 

TU8.3UT TUData Warehouse - Anforderungen BetriebUT...................................................................................114 

TU8.3.1UT 

TUKonfigurationsmanagementUT.............................................................................................114 

TU8.3.2UT TUWartungUT ...........................................................................................................................114 

TU8.3.3UT TUSupport (Problem Management)UT .....................................................................................115 

UND ORGANISATIONUT .........................................................................................................116 

TU9.1UT 

TUProjektmanagementUT......................................................................................................................116 

TU9.1.1UT 

TUProjekthandbuch, ProjektplanUT..........................................................................................116 

TU9.1.2UT TUGrobterminplanUT ................................................................................................................117 

TU9.2UT 

TUQualitätssicherung QSUT..................................................................................................................118 

TU9.3UT TURisikomanagement RMUT 

TU9.4UT TUKonfigurationsmanagement KMUT 

Abbildungsverzeichnis 

TUAbbildung 1: Systemabgrenzung MISTRAUT...................................................................................................... 7 

TUAbbildung 2: Systemaufbau und -grenzenUT .................................................................................................... 23 

TUAbbildung 3: Konzeptionelle Systemarchitektur Gesamtsystem MISTRAUT .................................................... 26 

TUAbbildung 4: Logische SystemarchitekturUT ..................................................................................................... 28 

TUAbbildung 5: Varianten modularer SystemaufbauUT......................................................................................... 32 

TUAbbildung 6: Anbindung Fachapplikation Online / OfflineUT ............................................................................. 33 

TUAbbildung 7: Anbindung von FremdapplikationenUT......................................................................................... 38 

TUAbbildung 8: Varianten Systemkonfiguration UT ............................................................................................... 39 

TUAbbildung 9: Bildschirmlayout GIS-ClientsUT.................................................................................................... 53 

TUAbbildung 10: Prozesslandkarte Basissystem (Makro-Ebene)UT ..................................................................... 54 

TUAbbildung 11: Modelltransformation STRADA MISTRAUT........................................................................... 80 

TUAbbildung 12: DWH - Einbettung in logische SystemarchitekturUT .................................................................. 87 

TUAbbildung 13: DWH - interne ArchitekturUT ...................................................................................................... 88 

TUAbbildung 14. DWH - Iterative ImplementierungsprozessUT............................................................................. 91 

TUAbbildung 15: DWH - Veränderung von Raum-/Zeit-BeziehungenUT............................................................... 93 

TUAbbildung 16: DWH - Beispiel kombinierter ReportUT ...................................................................................... 97 

TUAbbildung 17: DWH - VerfügbarkeitUT ............................................................................................................ 106 

TUAbbildung 18: Terminplan Realisierung und EinführungUT............................................................................. 118 

Tabellenverzeichnis 

TUTabelle 1: Kerneigenschaften MISTRAUT ........................................................................................................... 5 

TUTabelle 2: Basisprodukte und TechnologienUT ................................................................................................. 31 

TUTabelle 3: Unterstützende Funktionen Basissystem für FachapplikationUT...................................................... 36 

TUTabelle 4: Mengengerüst grosse InstallationenUT............................................................................................. 41 

TUTabelle 5: Mengengrüst kleine bis mittelgrosse InstallationenUT...................................................................... 42 

TUTabelle 6: Client-TypenUT ................................................................................................................................. 52 

Version 4.1, 30.09.2005 

c


Tabelle 7: UseCases und Zuordnung zu den Clients.................................................................................... 62 

Tabelle 8: Schnittstelle STRADA................................................................................................................... 81 

Tabelle 9: DWH - Abfragen ........................................................................................................................... 95 

Tabelle 10: DWH - Standardreports .............................................................................................................. 97 

Tabelle 11: DWH - Funktionale Anforderungen ............................................................................................ 99 

Tabelle 12: DWH - UseCases und Zuordnung zu den Clients.................................................................... 101 

Tabelle 13: DWH – Benutzertypen (* gemäss [2]) ...................................................................................... 105 

Tabelle 14: DWH - Häufigkeit der Zugriffe .................................................................................................. 107 

Tabelle 15: DWH - Mengengerüst............................................................................................................... 108 

Tabelle 16: DWH - Zeitplan Integrationsmodule ......................................................................................... 111 

Tabelle 17: DWH - Detailtermine Modul Sockeldaten ................................................................................. 112 

Tabelle 18: DWH - Termine Module Spezialistendaten .............................................................................. 112 

Version 4.1, 30.09.2005 

d

MISTRA – Pflichtenheft Basissystem 

0 Allgemeines 

0.1 Einleitung 

Das vorliegende Dokument beinhaltet das Pflichtenheft für die Realisierung, die Einführung und 

den Betrieb des Basissystems MISTRA. 

Das Basissystem bildet die Informations- und Kommunikationsplattform aller Beteiligten für die 

Unterstützung der Steuerung der Aufgaben des ASTRA und umfasst folgende Teile: 

• Sockeldatenbank mit Basis- und Generalistendaten 

• GIS-Basisapplikation zur Bearbeitung von Basisdaten, Bau- und Erhaltungsprojekten, Fachnetzen, 

Bauwerken u.a.m. 

• Schnittstellen für den Datenaustausch mit Fach- und Fremdapplikationen 

• Data Warehouse für Auswertungen (Fachanalysen und Fachreports, Managementinformationen) 

• Achsbandapplikation für grafische Auswertung auf der Abwicklung von Achsen 

• Werkzeuge zur Administration der Daten 

• Migrationstools für die Übernahme von Daten aus STRADA, UH-PERI, VECTOR25 u.v.a.m. 

Die Spezialistendaten, welche meist in aggregierter Form von weiteren Fachapplikationen benötigt 

werden, stehen als Generalistendaten im Basissystem zur Verfügung, werden aber i.d.R. in 

der Fachapplikation verwaltet. Es gibt einzelne Fachbereiche, für welche das Basissystem temporär 

und im Sinne einer Übergangslösung bis zur Fertigstellung entsprechender Fachapplikationen 

Funktionalität zur Verwaltung von Generalistendaten zur Verfügung stellt. Dies betrifft: Streifen, 

Schichteinbau Deckschicht, Langsamverkehr, Rapportstrecken, Kosten, Bauwerke, Projekte, ev. 

weitere. 

0.2 Grundlagen 

[1] HERMES, Führen und Abwickeln von Projekten der Informations- und Kommunikationstechnik", 

Ausgabe 2003 

[2] ASTRA, "Geschäftsprozesse Basissystem", Version 4.3 

[3] ASTRA, "Datenkatalog Sockeldaten", Version 4.0 

[4] ASTRA, "MISTRA Basissystem, UseCase-Diagramm", Version 1.0 

[5] ASTRA, "Beschreibung der Testdaten", 03.05.2004 

[6] ASTRA, "MISTRA Teilprojekt Daten, Vorgehen Datenintegration", Version 1.0 

[7] Ecole Polytechnique Lausanne, Projet SYRROU, Rapport final 

HTUhttp://topo.epfl.ch/siroute/syrrou/documents.htmlUTH 

[8] VSS-Normen gemäss Ausschreibung zur Teilnehmerauswahl, Absatz 7.2, in der jeweils 

Version 4.1, 30.09.2005 

1


gültigen Version 

[9] STRADA: Leitfaden für den Aufbau und Betrieb, Version 1.0 vom 10.01.2002 

http://www.strada-gs.ch/download/Leitfaden2002.pdf 

[10] "INTERLIS 2 – Referenzhandbuch", 13.05.2003 

http://www.interlis.ch/interlis2/download_d.php bzw. download_f.php 

[11] KOGIS "geocat.ch: Metadatenkatalog für Geodaten", August 2002 

http://www.kogis.ch/docs/geocat.ch/geocat_sik_de.pdf 

[12] KOGIS "Metadatenmodell GM03", Version 2.0 

http://www.kogis.ch/frameset/gm03-d.htm 

[13] ISB Informatikstrategieorgan Bund, I007 – Basisstandards Interoperabilität 

http://www.isb.admin.ch/internet/informatikstandards/standardindex/00760 

[14] ISB Informatikstrategieorgan Bund, I013 – Interoperabilitätsstandards für Web Services 

http://www.isb.admin.ch/internet/informatikstandards/standardindex/01549 

[15] Open GIS Consortium Inc. "Catalog Services Specification", Version 2.0 

http://www.opengis.org/specs/?page=specs 

[16] Open GIS Consortium Inc. "Simple Features Specification for SQL", Version 1.1 

http://www.opengis.org/docs/99-049.pdf 

[17] Open GIS Consortium Inc. "Simple Features Specification for OLE/COM", Version 1.1 


[18] ISO/TC211 ISO/DIS 19128 "Geographic Information – Web map server interface", 

http://www.opengis.org/specs/?page=specs 

[19] Open GIS Consortium Inc. "Web Feature Service Implementation Specification", V 1.0 


[20] http://www-106.ibm.com/developerworks/library/specifications/ws-add/ 

[21] http://www-106.ibm.com/developerworks/library/specifications/ws-secure/ 

[22] http://www-106.ibm.com/developerworks/library/specifications/ws-tx/ 

0.3 Literaturhinweise 

[23] Open GIS Consortium Inc. "OpenGIS Reference Model" OGC 03-040, Version 0.1.2 

http://www.opengis.org/info/orm/03-040.pdf 

[24] ESRI "Linear Referencing and Dynamic Segmentation in ArcGIS", Mai 2001 

http://www.esri.com/library/whitepapers/pdfs/lrds_arcgis.pdf 

[25] ESRI "Modeling and Using History in ArcGIS", Technical Paper, Mai 2002 

http://arconline.esri.com/arconline/whitepapers/ao_/Modeling_and_Using_History_in_ArcGIS.pdf 

[26] MISTRA, Teilprojekt Verkehrsunfälle, Bericht Voranalyse Version 1.1 vom 27.01.2005 

Version 4.1, 30.09.2005 

2


1 Zweck des Dokuments 

Das Pflichtenheft beschreibt die Ziele und Anforderungen an das zukünftige System, die mit der 

angestrebten Lösung zu erreichen sind. Es bildet die Grundlage für Preisangebot und Realisierung 

des Basissystems MISTRA entsprechend den Vorgaben von Hermes 2003. 

Der Bericht Geschäftsprozesse Basissystem [2] bildet die zentrale Grundlage für das Projekt, 

indem es Rollen, Aktivitätenreihenfolgen und Ergebnisse unmissverständlich darlegt. Der Datenkatalog 

Sockeldaten [3], das Use-Case-Diagramm [4] und die Testdaten [5] sind Bestandteile 

dieses Pflichtenhefts. 

Das Pflichtenheft dient als Grundlage für die Realisierung. 

Gleichzeitig dient das vorliegende Pflichtenheft als Rahmen für Integrationsarbeiten, welche es 

bei der Realisierung von MISTRA-Fachappliaktionen und Fremdapplikationen des ASTRA zu 

leisten gilt. 

Version 4.1, 30.09.2005 

3


2 Ausgangslage 

2.1 Auftrag 

Die Geschäftsleitung des ASTRA erteilt der Projektleitung MISTRA folgenden Auftrag: 

Das ASTRA erstellt ein Management-Informations-System Strasse und Strassenverkehr 

(MISTRA) zur Unterstützung der strategischen, konzeptionellen und operativen Steuerung der 

ASTRA-Aufgabenbereiche Netzkonzipierung, Netzbereitstellung (Planung, Bau, Ausbau, Unterhalt, 

Betrieb) und Netznutzung sowie sinngemässer Aufgaben professioneller Strasseneigentümer 

und strassenbezogener Netzbetreiber. Dieses geographische Informations- und Kommunikations-System 

(IKS) wird in Zusammenarbeit mit Kantonen, Agglomerationen und verschiedenen 

Bundesämtern sowie einschlägigen Fachorganisationen erstellt. 

MISTRA zeichnet sich durch folgende Kerneigenschaften aus: 

betriebswirtschaftlich 

effizient 

• Ermöglicht einfache, kundenorientierte Auswertungen zu generieren, 

wie Fachanalysen und -reports und möglichst automatisches 

Generieren von Netzkennziffern im Sinne von Management- 

Informationen für das ASTRA. 

• Unterstützung der georeferenzierten ASTRA-Geschäftsprozesse. 

• Abschöpfung des erheblichen Nutzen-Potenzials für das ASTRA 

durch den breiten Integrationsansatz. 

schweizweit 

• Für alle professionellen, öffentlichen Strasseneigentümer und 

strassenbezogenen Netzbetreiber. 

• Für alle Belange der Strasseninfrastruktur und des Strassenverkehrs, 

welche direkt oder indirekt von nationaler Bedeutung sind. 

objektorientiert 

kundenorientiert 

• Flächendeckende, durchgängige Applikationen und Webservices. 

Beinhaltet Daten, Strassen-Objekte und Netze als statische, räumliche 

Infrastrukturinformationen, die zugewiesen werden können für: 

• Nationalstrassen 

• Hauptstrassen 

• Kantonsstrassen 

• Gemeindestrassen 

• Übrige Strassen 

• Velowege (national, regional) 

• Fuss- und Wanderwege (national, regional, lokal) 

• Historische Verkehrswege (national, regional, lokal) 

Ausrichtung der Wertschöpfung des ASTRA auf die Bedürfnisse der 

Zielgruppen: 

• Öffentlichkeit und Mobilitätsteilnehmende 

• Kantone und kantonale Organisationen 

• Agglomerationen, Städte, Gemeinden 

Version 4.1, 30.09.2005 

4


• Professionals 

• Fachdienstleister 

• Bund, ASTRA, diverse Bundesämter 

integriert • Standardisierung gemäss Vorgaben des Bundes und der strategischen 

IT-Vorgaben des ASTRA. 

• Wiederverwendung bestehender Datensätze. 

• Einfache Wiederverwendung von Webservices und Applikationen. 

• Mitbenutzung der Geodienste von swisstopo und KOGIS. 

• Berücksichtigung der VSS-Normen soweit möglich und sinnvoll. 

volkswirtschaftlich 

effizient 

• Leistungserstellung erfolgt auf der Wertschöpfungskette im Sinne 

der NFA und im Rahmen des FLAG-Amtes ASTRA (Lieferant 

ASTRA Kunde) weitgehend ohne Medienbrüche. 

• Offene, erweiterbare, flexible IKS-Lösung, welche stark von der 

Weiterentwicklung von Standard-Software profitieren kann. 

• Die zur Verfügungstellung von Informationen, Daten, Webservices 

und Applikationen des MISTRA-Basissystems hat für die Kunden 

keine Kostenfolgen. 

• Einfache und breite Daten- und Applikationsnutzung. 

• Optimierung der Aufgaben-Zuständigkeiten nach Massgabe des 

volkswirtschaftlichen Aufwands (z.B. Entwicklung von Applikationen 

durch den Bund oder freien Markt). 

effektiv 

• Geschäftsprozesse, Applikationen, Web-Services und Daten sind 

gut und klar spezifiziert sowie auf die Zielgruppen von MISTRA 

ausgerichtet. 

• MISTRA-Lösung funktioniert mit grosser Kontinuität, hoher Stabilität 

und Zuverlässigkeit. 

• Das Kosten-Nutzen-Verhältnis ist angemessen. 

Tabelle 1: Kerneigenschaften MISTRA 

Mit der Aufbauphase (2004 - 2006) von MISTRA werden folgende Ergebnisse angestrebt: 

1. Voranalyse und Konzept des Gesamtsystems mit zeitlicher Priorisierung der Fachapplikationen 

2. Aufbau des MISTRA-Basissystems 

3. Integration der Sockeldaten aus STRADA, UH-PERI, KUBA-DB und weiteren Datenbanken 

4. Realisierung der für den Systembetrieb erforderlichen Basisapplikationen mit den Webservices 

5. Sicherstellung einer ausbaufähigen IT-Funktion mit klarem Service Level Agreement des 

ASTRA mit dem Systembetreiber. 

6. Definition der zentralen Geschäftsprozesse des ASTRA 

Version 4.1, 30.09.2005 

5


Mit der Betriebsphase I (2007 - 2009) von MISTRA werden folgende Ergebnisse angestrebt: 

1. Bedarfsgerechter Ausbau des Datenmodells und des Datenkatalogs 

2. Weiterentwicklung des Basissystems aufgrund der ersten Erfahrungen der Benutzer 

3. Starkes Vorantreiben der Webservices auf einer Web-browser-basierten Technologie 

Mit der Betriebsphase II (2010 - 2012) von MISTRA werden folgende Ergebnisse angestrebt: 

1. Definition weiterer Geschäftsprozesse für die Fach- und Fremdapplikationen des ASTRA 

2. ansonsten dito Betriebsphase I 

Normalbetrieb von MISTRA (ab 2012): 

Inkrementelle Anpassung und Weiterentwicklung des Informations- und Kommunikationssystems 

MISTRA bezüglich allen Belangen nach Vorgaben der oben stehenden Kerneigenschaften des 

Systems. 

Stufenweise Ablösung STRADA-DB (ab 2007): 

Sobald die Daten aus STRADA-DB migriert sind und der einwandfreie Betrieb von MISTRA sichergestellt 

und gewährleistet ist, kann STRADA-DB stufenweise in das neue System von 

MISTRA überführt werden. Im Rahmen der Überführung ist ein Parallelbetrieb vorgesehen. Die 

definitive Abschaltung, d.h. die Sistierung der Finanzierung der Wartungs- und Supportleistungen, 

erfolgt nach Abschluss der Datenübergabe der Kantone an das ASTRA im Zuge der NFA, voraussichtlich 

per 01.01.2008. 

2.2 Abgrenzung 

Gemäss den Kerneigenschaften behandelt MISTRA ausschliesslich statische Infrastrukturdaten. 

Diese Daten können maximal tagesaktuell gehandhabt und mutiert werden. Die Anwendungen 

der Finanz- und Betriebsbuchhaltung (Kostenmanagement), der Strassenverkehrstelematik sowie 

Applikationen zu NFA wie z.B. Immobilienmanagement oder Landerwerb sind deshalb nicht Bestandteil 

von MISTRA. MISTRA wird hingegen so offen konzipiert, dass diese Applikationen über 

klar spezifizierte Standardschnittstellen angebunden werden und Sockeldaten beziehen bzw. liefern 

können. 

Die folgende Grafik stellt explizit die Abgrenzung der verschiedenen Systeme nochmals vereinfacht 

dar. Sie gilt in diesem Sinne auch für weitere Fremdsysteme (Fremdapplikationen) wie IDM, 

Verkehrsnavigation, Verkehrsinformation, etc. 

Version 4.1, 30.09.2005 

6


Abbildung 1: Systemabgrenzung MISTRA 

2.3 Organisation 

Die Organisation und der Rollenbeschrieb sind in [2] , Dokumente Nr. 211 und 220 detailliert 

beschrieben. 

2.4 Marktanalyse 

Die Ausschreibung MISTRA-Studienauftrag hat ergeben, dass keine Standardlösung auf dem 

Markt existiert, welche die Systemziele befriedigend erfüllen kann. Deshalb wird sich die Lösung 

auf die Entwicklung eines neuen Softwaresystems auf der Basis eines GIS und weiterer Fertigprodukte 

konzentrieren. Nur in Ausnahmefällen und bei gutem Kosten-Nutzen-Verhältnis können 

zusätzlich vollständige Eigenentwicklungen veranlasst werden. 

Version 4.1, 30.09.2005 

7


2.5 GIS, Web-Technologie, Standards 

Die Verbreitung von geografischen Informationssystemen GIS hat in den vergangenen Jahren 

stark zugenommen und ist bei den Verwaltungen zu einem wichtigen Bestandteil der IT-Infrastruktur 

geworden. Mit der Verbreitung der Hilfsmittel hat sich auch die Datenlage stark verbessert. 

Diese Entwicklung hat die Nachfrage nach einem integralen Ansatz bei der Verwaltung 

raumbezogener Daten stark erhöht. 

Eine weitere sehr bedeutende Entwicklung stellt das Aufkommen von WebGIS-Anwendungen 

auf der Basis von Web-Services dar. Diese Technologie ermöglicht eine sehr einfache und kostengünstige 

Verbreitung von Geodaten. Während die Web-Technologie heute primär noch als 

eine Grundlage für Betrachter-Werkzeuge angesehen wird, zeichnet sich ein starker Trend hin zu 

Nachführungsfunktionen via Web (Web Feature Services) ab. Es ist anzunehmen, dass in den 

nächsten 2 bis 3 Jahren auch die Nachführung von Daten verstärkt über Web-Technologien (im 

Intranet) aktuell wird. Kapitel 6.1.2 beschreibt inwiefern diese Entwicklung beim Aufbau des Basissystems 

zu berücksichtigen ist. 

Durch intensive Standardisierungsbemühungen insbesondere durch das Open GIS Consortium, 

in Zusammenarbeit mit den GIS-Herstellern, sind die Systeme zur Verarbeitung von Geodaten 

sehr viel offener geworden. Hierdurch hat sich die Interoperabilität der Systeme, d.h. die Verwendung 

eines einheitlichen Datenbestands durch verschiedene Systeme, bereits heute verbessert. 

Die Benutzung einstmals komplexer GIS-Werkzeuge ist ebenfalls wesentlich einfacher geworden 

und hat sich an einen quasi-Standard angeglichen. Die früher oft intensiv diskutierte Frage nach 

dem strategischen GIS-Werkzeug hat dadurch an Bedeutung verloren. 

Die Koordinationsstelle GIS des Bundes KOGIS hat mit ihren Standardisierungen in den Bereichen 

Metadaten [11] und Datenaustausch über Interlis2 [10] wichtige Grundlagen für die effiziente 

und verbesserte Nutzung vorhandener Daten beigetragen. Diese Grundlagen sind beim Aufbau 

des Basissystems MISTRA zu berücksichtigen. 

Version 4.1, 30.09.2005 

8


3 Ist-Zustand 

3.1.1 Neugestaltung des Finanzausgleiches und der Aufgabenteilung (NFA) 

Die Neugestaltung des Finanzausgleichs und der Aufgabenteilung zwischen Bund und Kantonen 

(NFA) ist eine zentrale Umfeldentwicklung für MISTRA. Die Landschaft der Zuständigkeiten wird 

sich entsprechend dem NFA-Ansatz erheblich verändern. Grob lassen sich folgende Aussagen 

machen: 

• Nationalstrassennetz fertig stellen in Zusammenarbeit mit Bund und Kantonen 

• Ausbau und Erweiterung Nationalstrassennetz als Bundesaufgabe 

• Unterhalt und Betrieb Nationalstrassennetz als Bundesaufgabe 

• Ausbau Agglomerationsverkehrsnetze als Verbundaufgabe 

• Verkehrsmanagement auf Nationalstrassen und Transitachsen (VM-CH) als Verbundaufgabe 

• Teilentflechtung im Subventionsbereich Hauptstrassennetz 

• Bau und Unterhalt übrige Strassennetze als Kantonsaufgabe 

• Nationale Velo- und Wanderwege als Verbundaufgabe; übrige Wege als Kantonsaufgabe 

• Historische Verkehrswege nationaler Bedeutung als Verbundaufgabe; übrige als Kantonsaufgabe 

MISTRA ist so aufzubauen, dass die neue Zuständigkeitsordnung in jedem Falle ohne Neugestaltung 

der Geschäftsprozesse und der dementsprechenden Fachapplikationen durch die Betroffenen 

und Beteiligten wahrgenommen werden kann. 

3.1.2 Geschäftsprozesse 

Die ASTRA-Geschäftsprozesse (= Vorgehen zur Leistungserstellung) dienen als zentrale Grundlage 

für die weiteren Arbeiten. MISTRA wird so aufgebaut, dass künftig die mit den Geschäftsprozessen 

definierte Leistungserstellung im Führungsrahmen des FLAG-Amtes ASTRA erbracht 

werden kann. Dementsprechend ist bei der Realisierungsphase des MISTRA-Basissystems eine 

vollständige Kongruenz der Geschäftsprozesse durch Abgleich mit den Arbeiten zum FLAG-Amt 

ASTRA und zur NFA zu erzielen. 

Die Geschäftsprozesse für das Basissystem wurden bis auf die Mikroebene und Gebrauchsfälle 

definiert und bilden die Grundlage für die Realisierung, Einführung und den Betrieb des Basissystems 

sowie des Data Warehouses. 

Die Geschäftsprozesse der Fachapplikationen Fahrbahn und Nebenanlagen, Kunstbauten und 

Tunnel, Verkehrsunfälle, Verkehrsmonitoring, Langsamverkehr und Historische Verkehrswege 

werden zurzeit erarbeitet. Gleichzeitig werden die Grundsätze für die entsprechenden Fachprozesse 

definiert und mit dem aktuellen Führungssystem des ASTRA abgeglichen. 

Version 4.1, 30.09.2005 

9


3.1.3 ISA, KOFINAS, Projektkosten-Controlling 

Die Verwaltung der Finanzdaten zur Strasseninfrastruktur ist heute im ASTRA mit dem System 

ISA (Informatiksystem Amt), gelöst. Dank der ständig vorgenommenen Weiterentwicklungen erfüllt 

dieses System von der Technik und der Leistungsfähigkeit her die gestellten Anforderungen. 

Einzig die Benutzeroberfläche entspricht nicht mehr dem heutigen Bürostandard und sollte angepasst 

werden. 

Für einen Teil des ISA-Systemes wurde im Projekt KOFINAS (Kosten- /Finanzmanagement 

ASTRA) seit Anfang 2003 ein entsprechendes Ablösungskonzept erarbeitet. Da mit KOFINAS die 

erwünschten Ergebnisse nicht erzielt werden konnten, wurde das Projekt abgebrochen. Es wurde 

deshalb eine neue Voranalyse für ein Investitionscontrolling-Tool erstellt. 

3.1.4 STRADA-DB, KUBA-DB, UH-PERI 

STRADA-DB wird in ca. 17 Kantonen und im ASTRA für die Erhaltungsplanung der Strassen 

eingesetzt. Es werden keine weiteren Entwicklungsarbeiten mehr, sondern nur noch die betriebsnotwendigen 

Massnahmen ausgeführt (Wartung, Support). 

Als Basis für die Unterhaltsprojekte der Nationalstrassen wurde das Projekt UH-PERI NS erstellt. 

Es stellt ein vollständiges Verzeichnis der Nationalstrassenobjekte dar. Die entsprechende, integrative 

Informatikanwendung wird vollständig in das Basissystem integriert und zweckmässig 

weiterentwickelt. Des weiteren ist die Integration der betrieblichen Abschnittsverzeichnisse (Rapportstrecken) 

vorgesehen. Dank der Zusammenarbeit mit swisstopo/KOGIS werden die Objektverzeichnisse 

über den WEB-GISServer von KOGIS breit zur Verfügung gestellt. 

Basissystem 

Die Basisdaten aus STRADA-DB und die Daten von UH-PERI werden ins Basissystem integriert. 

Für die Konzeption und Realisation des Basissystems wurden 2003 aus 30 Teilnahmeanträgen 

5 Kandidaten für die Ausarbeitung der Voranalyse, des Konzeptes, eines Prototypen und Preisangebotes, 

im Rahmen eines Studienauftrages, ausgewählt. Dieser wurde Anfang 2004 gestartet. 

Im Frühjahr 2004 präsentierten die Kandidaten ihre Voranalysen und einen ersten Prototypen. 

Im November 2004 wurden die Konzepte und weiterentwickelten Prototypen vorgestellt. Diese 

wurden evaluiert und bewertet. Im Juni 2005 erfolgte die Gesamtbewertung für die Vergabe. Der 

Realisierungsbeginn ist für Oktober 2005 geplant. Das System soll Anfang 2007 im ASTRA eingeführt 

und betriebsbereit sein. 

Fahrbahn und Nebenanlagen 

Fachdaten über den Strassenaufbau und die Erhaltungsplanung wurden bis heute mit STRADA- 

DB bewirtschaftet. Für die Ablösung muss eine entsprechende Fachapplikation verfügbar sein. 

Dies kann sowohl mit einer bestehenden, an MISTRA angekoppelten Fachapplikation erfolgen 

oder, falls die Anforderungen nicht erfüllt werden, durch eine Neuentwicklung. 

Version 4.1, 30.09.2005 

10


Heute liegen die ersten Ergebnisse der Voranalyse (Situationsanalyse und Zielsystem) vor. Im 

Dezember 2005 soll der vollständige Voranalysebericht vorliegen. 

Kunstbauten und Tunnel 

Im Rahmen der neusten Entwicklung, wird KUBA-DB, in enger Abstimmung mit MISTRA, bis 

Ende 2006 um ein Modul Managementsystem für die Unterhaltsplanung und ein Modul zur Verwaltung 

der Substanzdaten bergmännischer Tunnel ergänzt werden. 

Die Konzeptphase für die Erweiterung von KUBA-DB mit dem Managementsystem (KUBA-MS) 

ist abgeschlossen. Die Realisierungsarbeiten und Wartungsleistungen wurden im Frühjahr öffentlich 

ausgeschrieben und vergeben. Die Realisierung von KUBA 4.0 ist im August 2005 gestartet 

und soll Ende 2007 in allen Kantonen eingeführt sein. KUBA 4.0 beinhaltet die Erweiterung mit 

den Funktionen für das Management der Kunstbauten (BMS). 

Die Arbeiten für das IT-Konzept von KUBA 4.1 für die Erweiterung mit den bergmännischen Tunnels 

und die vollständige Anbindung an das Basissystem MISTRA ist in Arbeit. Das Konzept wird 

im Herbst 2005 vorliegen. 

3.1.5 Verkehrsunfälle 

In Zusammenarbeit mit bfu, BFS und den Polizeiorganen der Kantone wurde das neue Unfallerhebungsprotokoll 

festgelegt. Unter anderem wird dabei zwingend die Georeferenzierung der Unfallstelle 

verlangt. Das neue Unfallerhebungsprotokoll wurde 2004 getestet und nach positiven 

Erfahrungen eingeführt. Auf dem Markt existieren bereits verschiedene Applikationen zur Unfallerhebung 

und Auswertung. 

Die Massnahmen aus dem Projekt Verkehrssicherheitspolitik des Bundes (VESIPO) sollen im 

Handlungsprogramm Via Sicura umgesetzt werden. Die Fachapplikation Verkehrsunfälle kann als 

eine vorgezogene Massnahme davon betrachtet werden. Der Konzeptbericht soll im Frühling 

2006 vorliegen, sodass die Realisierung eines Werkzeuges für die Erfassung und Auswertung 

der Unfalldaten ausgeschrieben werden kann. 

3.1.6 Verkehrsmonitoring 

Mit dem Teilprojekt Verkehrsmonitoring sind primär Grundlagen quantitativer und qualitativer Art 

über den Verkehrsfluss zu erfassen und bereitzustellen. Später ist auch vermehrt das Monitoring 

der Umweltbereiche (Lärm, Luft, Staub, Gewässer) durchzuführen und die erhobenen Daten mit 

dem Aufkommen des motorisierten Individualverkehrs (MIV) zu verknüpfen. 

Die bereits Anfangs 2005 abgeschlossenen Arbeiten für die Voranalyse betrafen nur einen Teil 

des Verkehrsmonitorings (AVZ), weshalb das Projekt auf Antrag der Gesamtprojektleitung hin 

neu aufgegleist wurde, mit dem Ziel einen erweiterten Ansatz für das Monitoring zu erarbeiten. 

Die Voranalyse und das Konzept werden entsprechend angepasst. Die ersten Module sollen im 

Frühling 2006 für die Realisierung ausgeschrieben werden. 

Version 4.1, 30.09.2005 

11


In der ersten Phase werden Module für die automatischen Verkehrszähler (AVZ), WIM (dynamische 

Achslasterfassungssysteme), Messstellenverwaltung, und Verkehrsmodell UVEK (in Zusammenarbeit 

mit dem ARE) umgesetzt. 

Die Rohdaten aus den einschlägigen Sensoren (Verkehrszähler, WIM-Anlagen u.a.m.), ausgewertete 

Verkehrsdaten und -informationen, z.B. DTV, LW-Anteil, Ganglinien sollen alle im 

MISTRA-Basissystem oder via Data Warehouse (DWH) zugänglich gemacht werden. Der spätere 

Ausbau in Richtung Verwaltung und Betreuung der Staudaten sowie der Auswirkungen des 

Strassenverkehrs bezüglich Lärm, Luft und Boden wird in die entsprechenden Arbeiten miteinbezogen. 

3.1.7 Langsamverkehr, GIS-LV, DM-LV 

Der Bereich Langsamverkehr hat eine Voranalyse GIS-Langsamverkehr (GIS-LV) und das entsprechende 

Datenmodell (DM-LV) erarbeitet. Eine wesentliche Erkenntnis war, dass zur Bearbeitung 

des Langsamverkehrs die entsprechenden Grundlagendaten zum Wandern und Velofahren, 

sowie IVS flächendeckend über die ganze Schweiz vorhanden sein müssen. Aus diesem Grund 

ist beabsichtigt die spezifischen LV-Grundinformationen auf den Referenzdaten der swisstopo 

(VECTOR25) aufzubauen. 

Das Teilprojekt Langsamverkehr wurde im Januar 2005 auf Antrag der Gesamtprojektleitung hin 

aufgesplittet in einen Teil Datenmodell und Datenkatalog Langsamverkehr und einen Teil IVS für 

die Webapplikation, welche die historischen Verkehrswege der Schweiz über Intranet/Extranet 

verfügbar machen sollen. 

Die Voranalysenphase ist abgeschlossen. Das Datenmodell wird noch an die Anforderungen von 

MISTRA angepasst. Die Fachapplikation selber wurde zurück gestellt, die Daten sollen jedoch im 

Basissystem mit den vorhandenen Basisfunktionen erfasst und verwaltet werden. Die Haupttätigkeiten 

konzentrieren sich ab 2006 auf die Datenerfassung. 

3.1.8 Inventar der historischen Verkehrswege der Schweiz (IVS) 

Um den enormen Papierberg bei der Publikation und Nachführung des IVS zu vermeiden, ist geplant, 

die Vernehmlassung der Verordnung zum IVS (VIVS) und das Bearbeiten/Nachführen des 

IVS selbst mit elektronischen Medien zu unterstützen. Aus diesem Grund ist im WEB-GIS-Projekt 

von KOGIS die Pilotapplikation WEB-IVS in Vorbereitung. Voraussichtlich gegen Ende 2005 wird 

der Entwurf des Inventars der historischen Verkehrswege für die ganze Schweiz über diesen digitalen 

Weg für alle Kundensegmente von MISTRA frei zugänglich sein. 

Das Inventar der historischen Wege der Schweiz (IVS) wird als eigenständige Fachapplikation 

geführt. Das Inventar der historischen Verkehrswege Schweiz (IVS) liegt heute im Entwurf vollständig 

digitalisiert vor und soll mit seinen Kurzbeschreibungen demnächst via Intranet/Internet 

veröffentlicht und behördenverbindlich werden, als Novum in der Bundesverwaltung. Die Webapplikation 

dient auch für die vorgesehene Vernehmlassung und als Basis für die Beurteilung von 

kantonalen Gesuchen um Finanzhilfen sowie für die Nachführung. 

Version 4.1, 30.09.2005 

12


3.1.9 Sonderbewilligungen 

Für die Ausstellung der Sonderbewilligungen wurde ein Informatikmittel ASTRA mit Bewilligungsformular, 

Rechnungsstellung, Verbuchung sowie Schnittstelle zu SAP gesucht. Eine Arbeitsgruppe 

sollte die Informationen zur Fahrstrecke inklusive der sich darauf befindlichen Hindernissen als 

Grundlage zur Erstellung der Sonderbewilligung eruieren. 

Die Befragung der Transportfirmen, kantonalen Stellen und der Polizeidienste hat ergeben, dass 

kein klarer Bedarf bezüglich den Sonderbewilligungen besteht. Das Teilprojekt wurde daraufhin 

im Januar 2005 auf Antrag der Gesamtprojektleitung sistiert. 

3.1.10 Erhaltungsmanagement 

Für das Erhaltungsmanagement wurden im Rahmen des Projektes UplaNS strategische Vorgaben 

festgelegt. Gleichzeitig wurde das Management des Gesamtsystems und diejenigen der Teilsysteme 

(Fahrbahn, Brücke, Elektromechanik) definiert und die Zusammenarbeit geregelt, damit 

eine Optimierung auf Stufe Gesamtsystem möglich wird. Die Unterstützung mit einem Informatik- 

Hilfsmittel wurde nicht realisiert. Die Kantone hingegen haben die strategischen Vorgaben in Unterhaltsabschnitte 

(Abschnitte UplaNS) umgesetzt. 

Das Teilprojekt wurde im Januar 2005 auf Antrag der Gesamtprojektleitung hin gestoppt und zurück 

gestellt. Grobe Überlegungen zum übergeordneten Erhaltungsmanagement werden im 

Rahmen des Erhaltungsmanagements der einzelnen Teilsysteme Fahrbahn und Kunstbauten 

angestellt. 

Version 4.1, 30.09.2005 

13


4 Ziele und Lösungen 

4.1 Vision 

Integrales, betriebs- und volkswirtschaftlich effektives und effizientes Informations- und Kommunikationssystem 

Strasse und Strassenverkehr für das ASTRA als Entscheidgrundlage bei Netzkonzipierung, 

Netzbereitstellung, Netznutzung und zur breiten Nutzung durch alle Partner (Bundesstellen, 

Kantone, Agglomerationen). 

Die Vision wird anhand einiger Beispiele in den folgenden Kapiteln umschrieben. 

4.1.1 Unterhaltsstrategie 

Herr X erhält als Mitarbeiter des ASTRA den Auftrag die umfassende Unterhaltsstrategie für die 

Nationalstrassen für die nächsten 5 Jahre zu entwickeln. Das heisst, dass er zunächst das gesamte 

Inventar mit dem Wiederbeschaffungswert der gesamten Nationalstrassen-Infrastruktur 

in Erfahrung bringt. Dann will er die aktuellsten Strassenzustandsindices der letzten Messkampagnen 

beiziehen. Mit Hilfe der aktuellsten Mehrjahres-Prognosen zum Verkehrsaufkommen 

lässt sich der jährliche Wertverlust der Strasse, also die Zustandsentwicklung, ermitteln. Die 

Zustandsentwicklung der Kunstbauten und der elektromechanischen Anlagen will er ebenfalls mit 

den Zustandswerten und jährlichem Wertverlust erheben. Anschliessend gilt es die über die 

nächsten 5 Jahre optimierten Erhaltungsabschnitte zu bilden. Zusätzlich ist dabei der Mindestabstand 

zwischen den Baustellen zu berücksichtigen. Zudem sind in den festgelegten Erhaltungsabschnitten 

vorgezogene Unterhaltsmassnahmen zu prüfen, die in den nächsten 5-10 

Jahren fällig werden könnten. Als Resultat will Herr X einerseits eine Gesamtübersicht der 

Schweiz mit den optimierten Unterhaltsabschnitten farblich unterschieden pro Jahr. Pro Unterhaltsabschnitt 

wird eine Kartenübersicht mit den verschiedenen Objekten und geplanten Massnahmen 

benötigt. Schliesslich sollen diese Auswertungen auch noch in Listenform mit den genauen 

Daten pro Unterhaltsabschnitt zusammengestellt werden. 

In Zukunft setzt sich Herr X an seinen Computer, startet den Internet Explorer und die MISTRA- 

Intranetseite. Er hat sofort die Gesamtübersicht der Schweiz mit dem Nationalstrassennetz vor 

sich. Über das Objektverzeichnis der Nationalstrassen-Infrastruktur lässt er sich eine Rangliste 

der zustandkritischen Objekte für das Jahr 2008 anzeigen und hält die 100 wichtigsten Objekte 

in einer Selektion fest. Nun erfolgt die Definition und Optimierung der Unterhaltsabschnitte 

für die ausgewählten Objekte. Über die mitgeführte Kostenliste wird die Einhaltung der Budgetvorgaben 

für 2008 kontrolliert und die endgültige Auswahl getroffen. Abschnitt für Abschnitt ü- 

berprüft Herr X am Bildschirm die getroffene Auswahl und bringt noch interaktiv Korrekturen an. 

Anschliessend speichert er bei den ausgewählten Objekten die vorgesehenen Unterhaltsmassnahmen 

für 2008. 

Die gleiche Prozedur wiederholt Herr X für das Jahr 2009, dann 2010 bis 2012 und erhält in Kürze 

die erwünschte Unterhaltstrategie. Bemerkenswert ist, dass bei der Definition und Optimie- 

Version 4.1, 30.09.2005 

14


rung der Unterhaltsabschnitte zum Beispiel im Jahr 2010 auch die vorgesehenen Unterhaltsmassnahmen 

für 2008 und 2009 korrekt berücksichtigt werden und nicht mehr als zustandkritische 

Objekte erscheinen. 

4.1.2 Ausbauprojekte 

Das ASTRA hat die Planunterlagen zum kantonalen Ausbauprojekt Kantonsstrasse Bern- 

Schwarzenburg erhalten. Bei der Dossierregistrierung schaut Frau M in die MISTRA- 

Intranetseite, ob das Projekt schon vom Kanton eingegeben wurde. Dazu gibt sie den Projekttitel 

"Ausbauprojekt Kantonsstrasse Bern-Schwarzenburg" als Suchkriterium ein. Tatsächlich wird 

dieses im grafischen Übersichtsfenster angezeigt. Als nächstes werden die zu begrüssenden 

Verantwortlichen im ASTRA definiert. Ein Standardmenu für die Vernehmlassungen mit einem 

Vorschlag der zu behandelnden Themen und Zuständigen erscheint dazu am Bildschirm. Das 

System prüft, ob die vorgeschlagenen Personen anwesend sind und in den nächsten Tagen das 

Dossier bearbeiten können. Nachdem Dossierbehandlung und Termine festgelegt sind, gibt Frau 

M es zur Bearbeitung frei. 

Die Themenverantwortlichen können über die MISTRA-Intranetseite gleichzeitig ihre Stellungnahmen 

erarbeiten und Änderungsvorschläge als Varianten im Dossier ablegen. Diese sind wiederum 

allen Themenverantwortlichen zugänglich und können entsprechend mitberücksichtigt 

werden. Sobald alle Stellungnahmen erarbeitet sind, meldet das System dies dem Dossierverantwortlichen 

per E-Mail. Dieser kann nun die Schlusskontrolle durchführen und allfällige vorhandene 

Widersprüchlichkeiten in den Stellungnahmen oder Unvollständigkeiten bearbeiten lassen. 

Sind auch diese Arbeiten erfolgreich abgeschlossen, geht das Ausbauprojekt zurück an den 

Kanton. Da alle Arbeiten im System MISTRA dokumentiert wurden, erhält der Kanton diese nicht 

nur in Papierform, sondern er kann direkt über das System MISTRA darauf zugreifen. Mit den 

entsprechenden Zugriffsberechtigungen kann im Kanton das Projekt weiterbearbeitet werden. 

4.1.3 Ausnahmetransporte 

Der Transporteur A aus Deutschland hat einen Transport von Stuttgart nach Gstaad durchzuführen. 

Sein Fahrzeug übertrifft das zulässige Gewicht in der Schweiz, folglich muss eine Sonderbewilligung 

beantragt werden. Der Transporteur A setzt sich an seinen Computer und gelangt über 

die Internetseite des ASTRA zum Bereich Sonderbewilligungen. Zunächst wird der Transporteur 

A seinen Ausgangsort und den Zielort eingeben. Anschliessend schlägt das System grenzüberschreitend 

die optimale Route vor, einerseits als Karte, andererseits als Beschrieb. Zusätzlich 

erstellt ihm das System auf dieser Grundlage die benötigte Sonderbewilligung aus. Alles ist nun 

für den Transport bereit. 

In Folge Unvorhergesehenem und im Einverständnis mit dem Warenempfänger verzögert sich 

der Transport. Die Fahrt verläuft reibungslos bis zur Schweizer Grenze. Nach der Kontrolle geht 

es weiter bis nach Bern, dort weist ihn das Verkehrsbeeinflussungssystem darauf hin, dass die 

Strasse nur bis Zweisimmen für LKWs befahrbar ist, da ein Steinschlag einen Teil der Strasse 

verschüttet hat und diese nun in Folge der Aufräum- und Unterhaltsarbeiten nur noch für den 

Version 4.1, 30.09.2005 

15


Personenwagenverkehr geöffnet ist. Der Fahrer setzt sich mit seinem Handy direkt mit dem 

Transporteur A in Verbindung und fragt nach einer alternativen Route. Der Transporteur A konsultiert 

nochmals die ASTRA-Internetseite Sonderbewilligungen, gibt den neuen Ausgangsort 

Bern und Gstaad als Zielort ein und lässt sich die neue Route berechnen. Das System schlägt 

ihm nun eine Route über Bern-Fribourg-Bulle-Gruyères vor. Die temporäre Strassensperrung 

Zweisimmen - Gstaad für den Schwerverkehr ist bereits im System nachgeführt. Nachdem er den 

Routenbeschrieb und die aktualisierte Sonderbewilligung als Textdateien vom System erhalten 

hat, sendet er diese an seinen Fahrer per SMS. Dieser kann seine Fahrt fortsetzen und die 

Ware noch am gleichen Tag in Gstaad abliefern. 

4.1.4 Verkehrssicherheitspolitik (Via Sicura) 

Frau S von der ASTRA-Verkehrssicherheitspolitik hat vom Direktor ASTRA den Auftrag den 

Erfolg der angeordneten Massnahmen seit der Einführung der neuen Politik vor 3 Jahren zu 

überprüfen. Sie geht dazu auf die MISTRA-Intranetseite und holt sich die jährlichen Strassenverkehrsunfälle 

mit Toten und Schwerverletzten der letzten 5 Jahre vor der Umsetzung von VESIPO 

als Referenzsituation aus dem System. Zusätzlich lässt sie sich die Unfallschwerpunkte grafisch 

am Bildschirm anzeigen und die wichtigsten Schwerpunkte festhalten. Sie lässt sich auch 

die von den Kantonen und Gemeinden getroffenen Massnahmen bei den Unfallschwerpunkten 

anzeigen. Danach erstellt sie die gleiche Auswertung über die letzten 3 Jahre. Nun hat sie die 

wesentlichen Grundlagen zur Erstellung des Evaluationsberichtes VESIPO, um erste Aussagen 

machen zu können. 

Version 4.1, 30.09.2005 

16


4.2 Systemziele 

4.2.1 Übergeordnete Ziele 

MISTRA hat folgende übergeordneten Ziele: 

1. Unterstützung strategischer Entscheide 

"Wo wirkt der eingesetzte Steuerfranken am meisten?" 

2. Unterstützung der täglichen Arbeit mit geografischen Daten 

3. Information der Öffentlichkeit 

Daraus abgeleitet lassen sich die nachfolgenden Ober- und Hauptziele definieren. 

4.2.2 Oberziele 

1. Aufbau MISTRA 

Das Management-Informations-System Strasse und Strassenverkehr unterstützt integral die 

strategische, konzeptionelle und operative Steuerung der Aufgabenbereiche Netzkonzipierung, 

Netzbereitstellung (Bau, Ausbau, Unterhalt, Betrieb) und Netznutzung des ASTRA sowie 

sinngemässer Aufgaben professioneller Strasseneigentümer und strassenbezogener 

Netzbetreiber. 

2. Ablösung technisch überholter Informatiklösungen 

Die Ablösung der Informatiklösung STRADA-DB erfolgt vollständig und unproblematisch mit 

Integration der entsprechenden Fachapplikation in MISTRA. Die vorhandenen Sachdaten 

werden migriert. 

4.3 Hauptziele 

1. ASTRA-Leistungserstellung 

Die Leistungserstellung des ASTRA wird im betriebs- und volkswirtschaftlichen Sinne effizienter. 

2. ASTRA-Wertschöpfung 

Die Wertschöpfung des ASTRA ist kundenorientiert, das heisst mit verbessertem Nutzen für 

den Kunden. 

3. Wiederkehrende Kosten 

Das Kosten/Nutzen-Verhältnis bei den wiederkehrenden Systemkosten für Betrieb, Wartung, 

Support, muss verbessert werden. 

Version 4.1, 30.09.2005 

17


Zur Erreichung dieser Hauptziele sind die folgenden Rahmenbedingungen zu berücksichtigen: 

• Die bestehenden Daten (Basis- und Fachdaten) sind ohne Verluste zu übernehmen. 

• Die Daten und Fachapplikationen werden Dritten zu den Grenzkosten angeboten. 

• Die internationalen Entwicklungen sind zu berücksichtigen. 

• Die Aufgabenzuständigkeiten sind gemäss dem volkswirtschaftlichen Aufwand zu optimieren. 

4.3.1 Systembezogene Ziele 

Aus den übergeordneten Zielen ergeben sich die systembezogenen Ziele sowie die Anforderungen 

an das System. 

Investitionsschutz 

1. Bedeutende Investitionen gut schützen und breiten Gebrauch sicherstellen 

Einhaltung der Standards von Bund (KOGIS, swisstopo, BIT) und ASTRA 

Produktestandards ASTRA (MS-Office, GIS usw.) 

VSS-Normen sind einzuhalten bzw. müssen in begründeten Fällen an MISTRA angepasst werden 

(z.B. Raumbezug, Topologie) [8]. 

Applikationen und Web-Services 

2. Stufengerecht einsetzbar (Politik, Leitung, Betrieb und Unterhalt) 

Einstieg, Bedienung und Funktionsumfang der Lösung müssen stufengerecht ausgeführt werden 

können. 

3. Praxisbezogene, einfache Lösung 

Für die Mehrheit der Anwender, die nur lesend zugreifen, muss die Bedienung einfach und intuitiv 

sein, möglichst über einen Web-Client. 

Für die Anwender, die für die Datenbewirtschaftung zuständig sind, muss sich die Benutzeroberfläche 

am Look & Feel von Windows-Anwendungen orientieren (Windows-Richtlinien) und in weitverbreitete 

GIS-Produkte integriert sein. 

4. Einfache Ausgabe von Daten&Informationen (Statistiken, Listen, Pläne, Achsband) 

Der Report Service muss direkt, d.h. ohne Zwischenschritte und Datentransfers möglich sein. Der 

Arbeitsfluss muss kurz und intuitiv für alle Kundensegmente von MISTRA sein. 

5. Mehrsprachig D / F / I / (E) 

Die Software muss sprachunabhängig konzipiert werden. Die verwendeten Texte für Oberfläche, 

Meldungen, Reports und Pläne müssen parametrisierbar sein. Die Texte werden in separaten Tabellen 

gehalten. Handbücher und Online-Hilfe werden mehrsprachig erstellt. 

6. Sowohl für grosse, als auch für kleine Strassennetze einsetzbar 

Die Lösung muss sowohl für den Betrieb grosser Strassennetze in Multi-User-Umgebungen, als 

auch bei kleinen Netzen im Single-User-Betrieb mit vertretbaren Kosten möglich sein. Dies hat 

insbesondere Konsequenzen auf die benötigten Lizenzen für Datenbank- und GIS-Software. 

7. Einfache und schnelle Ausbildung der BenutzerInnen 

Version 4.1, 30.09.2005 

18

TP 

PT Die 


 

 

Die Schulung für den Rich-GIS-Client muss in 3 bis 5 Tagen möglich sein, inkl. Einführung in die 

Benutzung der Fertigprodukte. 

Für die Web-Clients muss eine 1/2 –tägige Schulung ausreichen. 

8. Leistungserstellung ohne Medienbrüche 

Durchgehend digitale Arbeitsflüsse für die Haupttätigkeiten. Beizug von analogen Daten nur in 

Ausnahmefällen und bei sehr ungünstigem Kosten-Nutzen-Verhältnis der digitalen Verarbeitung. 

Die Daten innerhalb einer Organisation (= MISTRA-Instanz) werden in einer autonomen Datenbank 

gehalten. Das Schlüsselkonzept muss den Datenaustausch mit anderen Organisationen 

(z.B. Kantone) konfliktfrei und ohne Verletzung der Datenhoheit ermöglichen. 

Informatik-Komponenten 

9. Erweiterbare Lösung, d.h. zukünftige Bedürfnisse müssen integriert werden können 

Zu verwenden sind markgängige Datenbankprodukte (Oracle). Die Datenstrukturen müssen 

transparent und in 3. Normalform sein. Der Zugriff zu den Daten muss mit ANSI-SQL-Befehlen 

möglich sein. Die Verwendung von Stored Procedures ist zu minimieren und darf den Grundsatz 

der Datenbanksystemunabhängigkeit nicht verletzen. Die referentielle Integrität ist ohne Verwendung 

von Stored Procedures sicher zu stellen. 

Die Software ist in verschiedenen Applikationen gegliedert, welche nach Bedarf eingesetzt werden 

können (Skalierbarkeit). Durch die Verwendung von Standards (.NET, ANSI-SQL, ISO/TC211 / 

1 

openGIS TP PT, Interlis2) muss die Interoperabilität über verschiedene Plattformen so weitgehend wie 

heute möglich gewährleistet werden. 

10. Hohe Verfügbarkeit, Stabilität und Zuverlässigkeit 

Das System muss eine angemessene Verfügbarkeit, z.B. 6 x 18, zulassen (präzise Vorgaben sind 

in Kapitel 6.1.10 aufgeführt) 

Die Daten und Applikationen müssen kontinuierlich gesichert werden können, damit im Fehlerfall 

ein Systemneustart innert 4 Stunden möglich ist. 

11. Zusammenarbeit über verschiedene Plattformen und IT-Komponenten gewährleistet 

Durch die Einhaltung von Standards und den Einsatz von Web-Services wird die Interoperabilität 

mit allen Partnerorganisationen zu Strasse und Strassenverkehr weitgehend sichergestellt. 

12. Minimierung der Betriebskosten 

Die Datenbewirtschaftung muss über marktgängige GIS-Produkte möglich sein. Für die Ausgabe 

von Business-Reports sind einfache Werkzeuge einzusetzen (z.B. Excel, BI-Tools). 

Durch einen hohen Anteil von Fertigprodukten müssen die Kosten für die Wartung von Software 

möglichst tief gehalten werden. 

13. Einfache Installation von Datenbank und Applikationen (inkl. Updates) 

Für die Installation der Software sind Setup-Prozeduren bereit zu stellen. 

Insbesondere die Business Processes (siehe [2]) müssen möglichst für alle Kundensegmente von 

MISTRA ohne Installationsaufwand verwendbar sein. 

1 

relevanten ISO-Normen und OGC-Spezifikationen sind in [15] bis [19] aufgeführt. 

Version 4.1, 30.09.2005 

19


Daten und Informationen 

14. Bestehende Daten soweit wie nötig berücksichtigen 

Grundsätzlich wird bei der Erstellung der Sockeldatenbank versucht, mit den vorhandenen Daten 

aus STRADA, KUBA, Kartendaten wie VECTOR25 usw. zu arbeiten 

Neuerfassungen sind nur in begründeten Ausnahmefällen zulässig 

Verlustfreie Übernahme von Daten aus den heutigen Systemen 

15. Daten und Informationen schweizweit aktuell 

 

Der Datenbestand deckt grundsätzlich die gesamte Schweiz flächendeckend ab. Dabei kann die 

inhaltliche Tiefe der Objekte und Sachinformationen von den nationalen über kantonale zu den lokalen 

Stellen im definierten Rahmen variieren. 

16. Daten und Beziehungen objektorientiert und systemunabhängig beschrieben 

Erstellung des Datenmodelles als ER- oder UML-Klassendiagramm und Datenbeschreibung Interlis2. 

17. Die in MISTRA enthaltenen Daten sind gemäss dem Metadatenstandard von KOGIS beschrieben. 

Die Metadaten sind für Suchdienste zugänglich 

Bereitstellung der Metadaten gemäss ISO19115 (Profil GM03 gem. [12]) 

Publikation der Metadaten zu Handen von Suchdiensten, z.B. GeoCat [11] (s. auch Kap. 6.1) 

18. Einfacher Austausch von Daten zwischen Bund und Kantonen 

 

 

 

 

 

Die Daten müssen selektiv über Interlis2-Schnittstellen ausgetauscht werden können. 

Schlüsselverletzungen beim Import müssen in jedem Fall vermieden werden. 

Die zeitliche und räumliche Konsistenz der Daten muss überprüft werden. 

Das Eigentum an den Daten muss klar definiert sein. 

Die singuläre und eindeutige Datenherrschaft (Mutationsrecht) ist vom System sicher zu stellen. 

19. Die räumlichen Objekte sind in den gebräuchlichen Referenzsystemen georeferenziert 

 

 

Die Objekte sind in Landeskoordinaten (x, y, z) abgelegt 

Bei spezifischen Themen (z.B. Unterhalt, Betrieb) werden zusätzlich linear referenzierte 

Gebrauchskoordinaten (u, v) geführt 

20. Die Nachführung oder Historisierung sowohl der Basisgeometrie (z.B. VECTOR25) wie, sofern 

erforderlich, auch der Sachinformationen erfolgen einfach und ohne Verluste. Der Nachführungszyklus 

ist bedarfsabhängig pro Objektklasse geregelt. Er variiert zwischen täglich und 

mehrjährig. 

Organisatorische und finanzielle Gewährleistung der konsistenten Datennachführung über die verschiedenen 

autonomen Datenherren (ASTRA, Bundesämter, Kantone, Gemeinden) 

Verkehrszähldaten werden als aggregierte Tageswerte, als Ganglinien oder eventuell auch als 

Stundenwerte abgelegt. 

Die Zustandserhebungen der Strassenobjekte erfolgen in einem regelmässigen Mehrjahres- 

Turnus, welcher in Abstimmung mit den VSS-Normen oder anderen, einschlägigen Praxisleitfäden 

festgelegt wird. 

Veränderungen in der Realität werden innert Tagesfrist an den entsprechenden Daten aktualisiert. 

Version 4.1, 30.09.2005 

20


Projekt-Management 

21. Das Projekt ist akzeptiert, die Meilensteine sind eingehalten, die Risiken sind bekannt und 

minimiert, die Ablösung der bestehenden Systeme erfolgt problemlos 

Kleine überblickbare Einheiten (Module) mit geringem Realisierungsrisiko erstellen. 

Die Betroffenen (Benutzer, Kunden, insbesondere Kantone und Agglomerationen) werden zu allen 

wesentlichen Entwicklungsschritten einbezogen. 

Mittels einer bedarfsgerechten, klaren und offenen Kommunikation sind die Betroffenen gut über 

den jeweiligen Projektstand im Bilde 

Die stufenweise Ablösung der bestehenden IT-Systeme erfolgt erst, wenn die entsprechenden 

MISTRA-Applikationen funktionieren, so dass zumindest ein gleichwertiges Arbeiten für alle Benutzer 

möglich ist. 

Version 4.1, 30.09.2005 

21


5 Anforderungen Musskriterien 

1. Der Auftraggeber verlangt für die Realisierungsphase ein iteratives Vorgehen. Die Gründe für 

das iterative Vorgehen sind: 

• Einflussnahme des Auftraggebers und der mitwirkenden Kantone auf das System Design 

• Die frühzeitige Beherrschung der technischen Risiken 

• Die Möglichkeit der inkrementellen Inbetriebnahme 

Die Inhalte der Iterationen sind in Kap. 6.1.24 und die zeitliche Abwicklung in Kap. 9.1.2 beschrieben. 

2. Bei der Realisierung werden drei Pilotkantone (BE, VD, ZH) miteinbezogen. Es muss eine 

Testumgebung für das ASTRA und die Pilotkantone realisiert werden. 

3. Im Rahmen der Realisierung erarbeitet der Auftragnehmer eine Detailspezifikation (Systemdesign 

nach HERMES), welches die Vorgaben gemäss Datenkatalog [3] und diesem Pflichtenheft 

konkretisiert und verfeinert. Zum Systemdesign gehören: 

• Geschäftsprozesse des Basissystems gemäss Dokument [2] 

• Verfeinerung der Beschreibung der Use-Cases 

• Detailliertes Objekt- und Datenmodell auf der Grundlage des Datenkataloges [3] 

• Layout des GUI für Rich- und Browser-Client (nur Intranet) 

• Beschreibung der verwendeten Algorithmen und Berechnungsgrundlagen 

Die Detailspezifikation wird im Rahmen der Iterationen (möglichst strukturiert nach den klar 

spezifizierten Geschäftsprozessen in den Bereichen Integration Processes, Content Processes, 

Business Processes sowie IT Operation Processes, vgl. [2]) schrittweise erstellt. Jeder 

Schritt bedarf der Prüfung und Genehmigung / Freigabe durch den Auftraggeber. Mit der Codierung 

darf erst nach der jeweiligen Freigabe begonnen werden. 

4. Die Leistungen sind in diesem Pflichtenheft, im UseCase-Diagramm [4] und im Preis- / Leistungsverzeichnis 

beschrieben. 

Version 4.1, 30.09.2005 

22


6 Systemanforderungen Basissystem 

6.1 Basissystem - Anforderungen Realisierung 

6.1.1 Systemaufbau und -grenzen 

Schematisch dargestellt sieht die Systemgrenze von MISTRA in der Übersicht wie folgt aus: 

Lieferanten 

ASTRA, Bundesämter, Kantone, 

Agglomerationen und Städte, 

Fachdienstleister, Professionals 

New ASTRA 

Kunden 

Bund, ASTRA, Bundesämter, Kantone, 

Agglomerationen und Städte, Fachdienstleister, 

Professionals, Öffentlichkeit 

IKS 

B asissyste m 

Legende: 

FA 

BCI/IKS 

FA … 

FA Lärm 

FA Immobilien 

Basisapplikationen: (GIS-Basisapplikation, Administration, Analyse+Report, Achsband, Data Warehouse) 

Metadaten zu Basis- und Generalistendaten 

Generalistendaten Strassen und Strassenverkehr: Bauwerke, Streifen, Deckbelag, Verkehr, Unfälle, Kosten, Langsamverkehr 

Basisdaten Strassen und Strassenverkehr : Achsen, Achsgeometrien, Fachnetze, Topologie, Beteiligte, Inventarobjekte, usw. 

Übrige Basisdaten: Flächennetze, Pixelkarten, VECTOR25/200, Orthobilder, Höhenmodelle, Geografische Namen, usw. 

Geschäftsprozesse unterstützt durch 

spezifische Fachapplikation 

Systemgrenze MISTRA 

Business Collaboration Infrastructur / 

Informations- und Kommunikationssystem 

Kommunikation 

FA Landerwerb 

Webservices für Kunden 

Basisdaten swisstopo 

Basisdatens Navigation 

FA … 

FA Verkehrsunfälle 

FA Verkehrsmonitoring 

FA Fahrbahn + Nebenanlagen 

FA Kunstbauten + Tunnel 

IT-Systeme (HW, OS) / Datenbanken 

bestehende Fachapplikationen, Daten Dritter 

z.B. KUBA, STRADA, swisstopo,VM-CH. LKC, u.v.a.m. 

Detaildaten 

Kunstbauten 

Navigationsdaten 

Verkehrsinformationsdaten 

Daten 

Dritte 

FA Langsamverkehr 

FA Historische Verkehrswege 

Metadaten zu Spezialistendaten 

Detaildaten 

Fahrbahn 

Datenintegration 

FA Erhaltungsmanagement 

FA Betrieblicher Unterhalt 

/ GIS-Server Server / Internet / Intranet 

Detaildaten 

Elektromech. 

FA Verkehrsmanagement 

FA Entwässerung 

Spezialistendaten Strassen und Strassenverkehr 

Swisstopo 

KOGIS 

Stat. Daten 

VM-CH 

VM UVEK 

Daten Erhalt.- 

management 

Finanzdaten 

LKC 

u.a.m. 

FA … 

WEB-GIS: UH-PERI 

WEB-GIS: IVS 

Webservice … 

Datenkatalog 

+Datenmodell 

geocat.ch von KOGIS 

Webservice … 

Datenmodell 

Gestützt auf die erwarteten Ergebnisse 

werden die Beziehungen der Objekte 

festgelegt 

MISTRA-Phase I: 

1. ohne Betrieb 

2. ohne Verkehrsmanagement 

3. mit Focus Infrastruktur Nationalstrassen, 

Langsamverkehr, 

Verkehrsunfälle und -monitoring 

Abbildung 2: Systemaufbau und -grenzen 

Die obige Darstellung gibt eine grobe Übersicht über die Einbettung des Projektes MISTRA. Von 

zentraler Bedeutung ist dabei die Festlegung und Beschreibung der ASTRA-Leistungserstellung 

(und der dazugehörigen Geschäftsprozesse) unter Berücksichtigung der Lieferanten- und Kundenbedürfnisse 

/ -verhältnisse. Diese verschiedenen Bedürfnisse sind grob und noch nicht abschliessend 

in den unterschiedlichen Fachapplikationen, die zur Unterstützung der Geschäftsprozesse 

[2] mit den gewünschten Ergebnissen dienen, dargestellt. Für das ASTRA sind das beispielsweise 

die Schlüsse aus der Unfallentwicklung auf den Strassen, die Entwicklung des Verkehrsaufkommens 

mit spezifischer Ausweisung der Staustrecken mit Staudauern, die Beurteilung 

und Begleitung von Neu-/Ausbauprojekten, Erhaltung sowie der Erfolg von Lärmschutzmassnahmen 

oder die Förderung des Langsamverkehrs. Bei den Kunden stehen Ergebnisse wie 

Version 4.1, 30.09.2005 

23


Strassenkarten mit geplanten Erweiterungen, Unfallkarten mit Listen und geografischen Schwerpunkten, 

Wanderwegrouten oder Übersichten der aktuellen und geplanten Strassenunterhaltsstellen 

im Vordergrund. Die Lieferanten erstellen beispielsweise detaillierte Projekte zu spezifischen 

Unterhaltsobjekten oder führen die Erhebung der Unfalldaten oder Wanderwegnetzdaten 

durch. 

Damit die Fachapplikationen effektiv und effizient erstellt werden können, muss von allen Beteiligten 

auf ein gemeinsames Informations- und Kommunikationssystem, die Business Collaboration 

Infrastructure (BCI), zurückgegriffen werden. Das Basissystem von MISTRA stellt eine BCI dar 

und besteht aus den Teilen IT-Systeme, Datenbanken, Basis-Applikationen, Internet/Intranet und 

den Generalisten- und Basisdaten zu Strassen- und Strassenverkehr. 

Die Applikationen (Fach- und Fremdapplikationen von Spezialisten, Lieferanten und Kunden sowie 

Webservices als Service Public für Endkunden) greifen auf die Systeme und Daten über das 

Datennetz, also via BCI, zu. Die BCI bildet die Informatik- und Netzwerkumgebung der verschiedenen 

Beteiligten ab, so dass eine konstruktive und effiziente Zusammenarbeit mit allen ohne 

Medienbrüche ermöglicht wird. Das bedeutet, dass die BCI heterogen, teilweise zentral, teilweise 

dezentral aufgebaut wird. Dank der Einhaltung der vereinbarten Standards (Datenmodell, Datenkatalog 

[3], Web-Technologie, GIS-System, Datenbanken, IT-Netzwerk, usw.) können die EDV- 

Systeme mit den Applikationen und Daten zusammenarbeiten. 

Die Sockeldaten in der BCI umfassen alle Meta- und Basisdaten sowie alle diejenigen Daten aus 

den Fachapplikationen, welche für mehrere Fachbereiche von Interesse sind (Generalistendaten). 

Das Datenmodell der Sockeldatenbank wird fest vereinbart. Es muss aber erweiterbar sein, 

z.B. wenn Daten neuer Fachbereiche aufgenommen werden sollen. Änderungen und Erweiterungen 

an der Struktur der Sockeldaten müssen auf breiter Basis abgestimmt werden und bedürfen 

der Genehmigung durch eine noch zu definierende Instanz im oder ausserhalb des ASTRA. 

Die Basisapplikationen sind Bestandteil der BCI, des Basissystems MISTRA und dem Data Warehouse. 

Sie umfassen die Anwendungsfälle für die Ausführung der Geschäftsprozesse [2]: 

• Führungsprozesse FP für Lenkungsaufgaben (Zugriffe, Datenpublikation) 

• Leistungserstellungsprozessen LP für Auswertungen, Karten-, Report- und Achsbanderstellung 

sowie für die Datenbereitstellung 

• Datenbearbeitungsprozesse DP für die Bearbeitung der Basisdaten. Temporär werden auch 

Generalisten- und Spezialistendaten durch das Basissystem bearbeitet. 

• Integrationsprozesse IP für den Import von Basisdaten Dritter sowie den Generalistendaten 

von Fach- und Fremdapplikationen. 

• Systembetriebsprozessen SP für das Change Management, der Verwaltung der Rechte usw. 

Die Datenintegration ist Bestandteil der Realisierung. Die zugehörigen Leistungen wurde im 

Preis-/Leistungsverzeichnis für die Realisierung des Basissystems als Optionen ausgeschrieben. 

Sie werden entweder vom Auftragnehmer Basissystem oder von Dritten durchgeführt. Der Entscheid 

erfolgt später durch die PL MISTRA. 

Version 4.1, 30.09.2005 

24


Daten mit Raumbezug werden über eine GIS-Oberfläche bewirtschaftet. Hohe Priorität hat die 

rasche Bereitstellung einer Basisapplikation für den Rich-GIS-Client und Web-GIS-Client sowie 

eines Analysewerkzeugs (Data Warehouse). Weitere Basis-Applikationen sind für Achsbanddarstellungen 

und eine Anwendung zur Administration der Sockeldaten. Längerfristig werden mehrere 

Softwareanwendungen mit / ohne GIS in der Lage sein, die Sockeldaten MISTRA-konform zu 

verwalten. Die Basisapplikationen werden in einem einheitlichen Look & Feel erstellt. 

Mit Fachapplikationen sind nicht nur Werkzeuge zur Dokumentation des Bestands, sondern auch 

für das Erhaltungsmanagement, die Planung, die Durchführung von Simulationen usw. gemeint. 

Für Fachanwendungen werden Spezialistendaten benötigt. Sie werden nicht als Teil der BCI verwaltet. 

Diese Spezialistendaten werden meist in aggregierter Form von weiteren Fachapplikationen 

benötigt und sollen im Basissystem als Generalistendaten zur Verfügung gestellt werden. 

Damit der Einbezug dieser Daten in der BCI möglich ist, werden entsprechende Datenstandards 

(Datenkatalog [3], Datenmodell[4], Erfassungsregeln) auch für diese Daten behandelt. Die Fachapplikationen 

werden völlig autonom, d.h. unabhängig von der Sockeldatenbank funktionieren. 

Dementsprechend verfügen sie, unabhängig von MISTRA, über eine eigenständig verwaltete 

Datenablage. Sie kommen mit den Sockeldaten in Berührung, wenn sie: 

• Basisdaten oder Generalistendaten anderer Fachanwendungen beziehen oder 

• Generalistendaten aus der Fachanwendung in die Sockeldaten abspeichern. 

Die Sockeldatenbank bzw. die Basisapplikationen greifen grundsätzlich nicht auf die Datenablage 

der Fachanwendungen (Spezialistendaten) zu. Der Datenaustausch ist ausschliesslich Sache der 

Fachapplikationen. Das Basissystem stellt standardisierte Schnittstellen für den Datenzugriff zur 

Verfügung (s. oben). 

Der Zugriff auf die Sockeldatenbank erfolgt über standardisierte Schnittstellen (vgl. Kap 6.1.14). 

Die Schnittstellen werden primär für den Offline-Zugriff (Interlis2-Transfers) und auch für den Online-Zugriff 

als Web-Services realisiert. 

Die erfolgreiche und vollständige Datenintegration der bestehenden Datensammlungen 

(STRADA-DB, UH-PERI, usw.) schliesst die Arbeiten des Systemaufbaus MISTRA ab. 

Das applikatorische Konzept ermöglicht ein stufenweises (iteratives) Vorgehen bei der Realisierung, 

kurze Entwicklungszeiten für die einzelnen Komponenten sowie Flexibilität gegenüber dem 

Technologiewandel. Mit diesem Konzept lässt sich ein System aufbauen, das bedürfnisbezogen 

erweitert und angepasst werden kann. Müssen zwischen verschiedenen Fachapplikationen Daten 

ausgetauscht werden, welche nicht im Modell der Sockeldatenbank vorgesehen sind, ist eine 

Erweiterung dieses Modells zu prüfen. 

Alle Daten sind in Metadaten beschrieben und für Suchdienste wie geocat von KOGIS zugänglich. 

Das Metadatenmodell richtet sich nach der internationalen ISO-Norm ISO / DIS 19115 mit 

dem Metadatenmodell GM03 nach der KOGIS (vgl. [11] und [12]). Die MISTRA-spezifische 

Implementation des Modells GM03 sind im Datenkatalog [3] dokumentiert. Die Basisapplikationen 

sowie die Schnittstellen zur Sockeldatenbank müssen die Verwaltung von Metadaten sicherstellen. 

Die Metadatenbank wird als Bestandteil der Sockeldatenbank aufgebaut und betrieben. 

Version 4.1, 30.09.2005 

25


6.1.2 Systemarchitektur MISTRA 

Die entsprechende Vorstellung zur Systemarchitektur ist in Abbildung 3: Konzeptionelle Systemarchitektur 

Gesamtsystem MISTRA dargestellt. 

Abbildung 3: Konzeptionelle Systemarchitektur Gesamtsystem MISTRA 

Das Kernstück der Lösung ist das Basissystem mit der Sockeldatenbank (SDB). Das Basissystem 

ist Daten- und Informationsdrehscheibe zwischen den verschiedenen Anwendungen und 

Systemen, sowohl intern wie auch bei den Beziehungen mit den Lieferanten (Kantone, Agglomerationen, 

Fachdienstleiter) wie auch den Kunden. Je nach Applikation (Fach-, Webservice) wird 

entweder auf die SDB oder Fachdatenbank (KUBA, STRADA, Verkehr, LV, usw.) alleine oder in 

Kombination miteinander auf Informationen zugegriffen. Grundsätzlich befinden sich alle applikationsübergreifenden 

Daten in der SDB. 

Mit verschiedenen Bundesämtern, den Kantonen und Agglomerationen und gewissen Gemeinden 

(Agglomerationen) wird ein entsprechender Datenaustausch zwischen den verschiedenen 

Version 4.1, 30.09.2005 

26


Datenbanken stattfinden. Mit gewissen Stellen wird dies, sofern wirtschaftlich und technisch sinnvoll, 

direkt online erfolgen, ansonsten offline. 

Via Webservices und Web-Applikationen wird die breite Öffentlichkeit über das Internet auf aufbereitete 

Information zugreifen können. Diese Anwendungen und die entsprechenden Daten sollen 

mit der Web-GIS-Lösung von KOGIS realisiert werden. Dazu werden die Daten in die DMZ des 

Bundes repliziert. 

Version 4.1, 30.09.2005 

27


6.1.3 Systemarchitektur Basissystem 

ASTRA / Bund / Kantone Public Internet 

Client tier 

Rich-GIS, -Admin 

Web-GIS, -DWH, -Admin 

Web-GIS, -DWH 

Fach-Client 

GIS-Client 

Data tier Application tier 

Appl. Server 

FA 

Data-Access 

Fachdaten 

GIS-Server 

(Service-Interface) 

Data Access Layer 

Geodaten 

Map-Server 

Sach- und 

Metadaten 

Web-Server 

ETL 

ETL 

BI-Server 

Data Marts 

ETL 

ODS 

ETL DWH 

Firewall 

Geo Dienste 

Bund 

GIS-Server 

Data-Access 

GEO-Daten 

Web-Server 

Map-Server 

BI-Server 

Data Marts 

ETL Geodaten 

Internes DWH 

Externes DWH 

Produktionsumgebung 

Intranet (KOMBV) 

DMZ Bund 

Internet-Infrastruktur 

Abbildung 4: Logische Systemarchitektur 

Die Abbildung zeigt die logische Systemarchitektur von MISTRA. Die Kästchen repräsentieren die 

wichtigen SW-Komponenten. Hierbei handelt es sich nicht um eine strikte Komponentenaufteilung. 

Je nach Bedarf können diese weiter aufgeteilt werden. Bei kleinen und mittleren Installationen 

müssen die Komponenten hardwaremässig zusammengelegt werden können. Die Pfeile zeigen 

die Richtung des Datenflusses. 

Die einzelnen Bereiche umfassen: 

A. Umgebung für die Bewirtschaftung der Basisdaten, insbesondere der Geodaten an GIS- 

Arbeitsplätzen über Rich-Clients. 

B. Umgebung für die Bewirtschaftung von Sachdaten und einfacher Geodaten sowie für die Betrachter 

im Intranet. Die AnwenderInnen greifen auf die aktuelle, produktive Version der Sockeldaten 

(read/write) und auf das DWH (read-only) im Intranet. 

Version 4.1, 30.09.2005 

28


C. Umgebung für die Betrachter im Internet (read-only). Die Anwender und Anwenderinnen greifen 

auf einen replizierten Extrakt der Sockeldaten, das DWH und die Geo Services Bund der 

Bundesverwaltung (in der DMZ) zu. Eine Referenzpartnerschaft zwischen dem ASTRA und 

swisstopo regelt die Details dieser Zusammenarbeit. 

Die Erstellung der Komponenten in der Internet-Infrastruktur gehört nicht zum Leistungsumfang 

zur Realisierung des Basissystems. 

D. Umgebung für die Bewirtschaftung der Fachdaten über Fachapplikationen an Web- oder Rich- 

Clients (ausserhalb Leistungsumfang Basissystem) 

Die Bereiche A und B sind Gegenstand der Realisierung des Basissystems MISTRA. 

Bemerkungen zur Systemarchitektur: 

1. Die Systemarchitektur ist logisch als 3-tier-Architektur dargestellt. In vielen Anwendungsfällen 

ist eine Zusammenlegung von Data Access und Application Tier zu erwarten. Für den 

Low-End-Bereich muss auch eine Installation auf einem einzelnen Arbeitsplatz möglich sein. 

Nach den aktuellen Erkenntnissen ist keine Low-End-Version geplant. Die gewählte Systemarchitektur 

sollte jedoch die Möglichkeit einer späteren Realisierung einer Low-End-Version 

ermöglichen. Das heisst, dass nur eine Version entwickelt und gewartet werden muss. Es 

muss jedoch weiterhin möglich sein, die Softwarekomponenten auf einer einzigen Hardware 

zusammen zu führen. 

Siehe auch die drei typischen Systemkonfigurationen gemäss Kap. 6.1.10. 

2. Das Data Tier umfasst die Komponenten für den Zugriff zu den Daten. Diese beinhalten die 

Datenbanksoftware sowie allfällige zusätzliche Fertigprodukte (ArcSDE, ev. weitere) (s. Kap 

6.1.12). Als weitere Komponenten sind die Extrakt-Dienste (ETL) für das DWH und das 

WebGIS Internet dargestellt. 

3. Die Integrität der Daten muss gewährleistet sein. Es ist die relationale Datenbank Oracle zu 

verwenden. MISTRA muss sowohl im Mehrbenutzer- als auch im Einbenutzerbetrieb funktionieren. 

Im Mehrbenutzerbetrieb sind Zugriffskonflikte abzufangen; bei Fehlern muss der letzte 

konsistente Zustand der Daten wiederhergestellt werden können. 

Siehe auch die Anbindung von Fachapplikationen gemäss Kap 6.1.6. 

4. Der Datenbankzugriff zwischen dem Service-Interface und den Data-Access-Schichten der 

Fertigprodukte muss systemunabhängig erfolgen. Herstellerspezifische Elemente, insbesondere 

Stored Procedures sind zu minimieren und in allen Fällen mit dem Auftraggeber abzusprechen. 

Es muss möglich sein die einer Applikation zugrunde liegende Datenbank durch 

Produkte unterschiedlicher Hersteller auszuwechseln. Die referenzielle Integrität ist ohne 

Verwendung von Stored Procedures sicher zu stellen. 

5. Das Application Tier enthält die Funktionen für die Datenverarbeitung. In den herkömmlichen 

Rich-Client-Umgebungen sind diese Funktionen i.d.R. im Client-Tier enthalten. 

Das Application Tier enthält auch das Service-Interface für den Zugriff auf die Sockeldaten, 

siehe auch Kap. 6.1.6. 

Version 4.1, 30.09.2005 

29


6. Im Sinne der Entlastung der Clients, der Anbindung von portablen Clients und der Senkung 

von Lizenz-, Installations- und Betriebskosten strebt MISTRA eine Server-orientierte Lösung 

an. Die Funktionen im Service-Interface sind als Web-Services sowohl für den Rich- als auch 

für den Browser-Client zu realisieren. Viewing-, Analyse- und Auswertungsfunktionen sowie 

schreibende Funktionen müssen im Rahmen der heutigen technischen Möglichkeiten, z.B. 

für die Nachführung von Sachdaten sowie für einfache grafische Bearbeitungen, für Planerstellung 

usw. möglichst weitgehend über Web-Services abgedeckt werden. 

7. Die Fachapplikationen müssen standalone, d.h. ohne MISTRA funktionieren können. Für den 

Bezug von Sockeldaten und das Schreiben von Generalistendaten wird primär die Interlis2- 

Schnittstelle (offline) oder alternativ die Service-Interfaces (online) benutzt. 

Siehe auch die Anbindung von Fachapplikationen gemäss Kap 6.1.6. 

8. Aus sicherheitstechnischen Gründen wird für den Internet-Zugang in der Bundesverwaltung 

eine separate Infrastruktur betrieben. Die KOGIS hat die Aufgabe die Internet-Anwendungen 

des Bundes zu koordinieren. Den interessierten Bundesämtern steht eine zentral betriebene 

Intranet-/Internet-Infrastruktur zur Verfügung (Geo Services Bund). Diese Infrastruktur soll 

auch von MISTRA genutzt werden. Von den Geo Services Bund werden einerseits Basisdaten 

für MISTRA als WebMap-Services bezogen. Andererseits stellt MISTRA Daten für die Internet-Plattform 

als Kopie zur Verfügung (Extrakt-Funktion im Interlis2-Format). Die Zusammenarbeit 

ist in der Referenzpartnerschaft ASTRA swisstopo/KOGIS definiert und geregelt. 

9. Die heutige KOGIS-Plattform umfasst kein DWH für das Internet. Es ist zum heutigen Zeitpunkt 

noch offen, wie das Internet-DWH realisiert werden soll. Zum Leistungsumfang für die 

Realisierung des Basissystems gehören nur die ETL-Dienste gemäss Kap. 8. 

10. Die Systemarchitektur ist so auszulegen, dass sie den Anforderungen der verschiedenen 

Kundensegmenten gemäss den für das Basissystem spezifizierten Geschäftsprozessen 

verwendet werden kann. 

Siehe auch die drei typischen Systemkonfigurationen gemäss Kap. 6.1.10. 

11. Die Kantone sind über das KTV an das Intranet der Bundesverwaltung angebunden. Diese 

Verbindung erlaubt den Zugriff auf die Daten der MISTRA-Instanz des ASTRA. Es ist jedoch 

nicht vorgesehen, dass über diese Verbindung Daten in der MISTRA-Instanz durch die Kantone 

nachgeführt werden. Die Kantone und Agglomerationen werden für ihre Strassendaten 

eigene MISTRA-Instanzen betreiben. 

Version 4.1, 30.09.2005 

30


6.1.4 Basisprodukte und -technologien 

Dem Basissystem sind im Rahmen der ersten Realisierung folgende Basisprodukte und –technologien 

zu Grunde zu legen: 

Betriebssysteme Data Tier 

ab Windows 2003 oder Unix/Linux 

Betriebssysteme Application Tier ab Windows 2003 

Netzwerk 

Betriebssysteme Clients 

Datenbank für Sockeldatenbank 

und DWH 

GIS 

Server-Anschluss mit 1 GB/sec 

Client-Anschluss mit 100 Mbit/sec 

ab Windows XP 

ab Oracle 10g 

Browser ab MS Internet Explorer 6.0 

ab Netscape 7.0 

Büroanwendungen 

Entwicklungsplattform 

Tabelle 2: Basisprodukte und Technologien 

ab ESRI ArcGIS-Server 9.1, ArcSDE 9.1, ArcIMS 9.1, ArcEditor 

9.1 

ab MS Office XP 

.NET 

In der Betriebsphase sind immer der jeweils aktuelle aktuelle und letzte Major Release zu warten 

und unterstützen. 

Version 4.1, 30.09.2005 

31


6.1.5 Modularer Systemaufbau 

Die modulare Systemarchitektur muss je nach Grösse der Strassenbehörde sehr unterschiedliche 

Installationen zulassen. Die nachfolgende Abbildung zeigt drei Beispiele: 

Abbildung 5: Varianten modularer Systemaufbau 

• Paket 1 zeigt die umfassende Installation beim ASTRA mit dem Basissystem, allen Fachapplikationen 

und dem DWH. Die GIS-Oberfläche ist eine speziell für das Basissystem entwickelte 

Umgebung integriert in ESRI-Produkte und wird für die Bewirtschaftung der Basisdaten verwendet. 

Sie besteht aus einem RichGIS- und WebGIS-Client-Teil. 

• Paket 2 zeigt eine Installation bei einem Bundesamt oder einer kantonalen Behörde, bei welcher 

der Einsatz einzelner Fachapplikationen und die Datennutzung über das DWH im Vordergrund 

stehen. Das Basissystem wird ohne die GIS-Oberfläche des Basisystems eingesetzt, 

weil die raumbezogenen Basisdaten extern bewirtschaftet werden. Das Basissystem hat 

"nur" eine integrative Funktion. 

• Paket 3 zeigt eine Installation wie sie in einer Behörde oder in einem Ingenieurbüro zu finden 

ist, wo ausschliesslich Basisdaten, z.B. für den Raumbezug aufbereitet und dann an eine Behörde 

z.B. des Typs von Paket 2 weitergegeben werden. 

Version 4.1, 30.09.2005 

32


6.1.6 Anbindung von MISTRA-Fachapplikationen 

Fachapplikationen FA sollen unabhängig vom Basissystem BS betrieben funktionieren können. 

Demzufolge verfügen FA immer über eine eigene Datenablage, welche auch völlig unterschiedlich 

vom BS konzipiert sein kann. FA kommunizieren in folgenden Situationen mit dem BS: 

1. Beim Bezug von Basisdaten (mit den zugehörigen Metadaten). 

2. Beim Bezug von Generalistendaten anderer FA (mit den zugehörigen Metadaten). 

3. Bei der Bereitstellung eigener Generalistendaten für andere FA (mit den zugehörigen Metadaten) 

(Geschäftsprozess Basissystem IP2). 

Die Kommunikation erfolgt online oder offline: 

• Online (oder synchron), wenn FA und BS beide hochgefahren sind und eine direkte Verbindung 

möglich ist. Die Daten werden durch Direktzugriff der FA auf das BS ausgetauscht. Es 

entstehen keine Transferdateien. 

• Offline (oder asynchron), typischerweise wenn FA und BS in verschiedenen Systemumgebungen 

betrieben werden und ein Direktzugriff nicht möglich ist. Der Datenaustausch läuft 

über das Export/Import-Modul von FA und BS. Beim Export wird eine Interlis2-Transferdatei 

erzeugt. Diese Datei wird, z.B. per E-Mail oder auf einer CD-ROM an den Empfänger gesandt 

und dort importiert. Die Offline-Variante kann auch anstelle eines Online-Transfers angewandt 

werden. 

Beim Datenaustausch in beiden Richtungen ist immer die Fachapplikation und nie das Basissystem 

die aktive Komponente. 

Die beiden Varianten sind technisch gleichwertig. Weil die Offline-Variante universeller anwendbar 

ist, wird diese mit hoher Priorität im Rahmen der ersten Realisierungseinheit des Basissystems 

realisiert. Die nachfolgende Abbildung zeigt die typischen Systemkomponenten für jede 

dieser Methoden: 

Methode Online 

Fachapplikation 

BS-Interface 

Methode Offline 

Fachapplikation 

Import/Export-Modul 

Interlis2 

Transfer-Datei 

Service-Interface 


Import/Export-Modul 


Abbildung 6: Anbindung Fachapplikation Online / Offline 

Version 4.1, 30.09.2005 

33


Für das Online-Interface werden den Herstellern der Fachapplikationen Software-Komponenten 

als Web-Services für die Entwicklung der Schnittstelle zur Verfügung gestellt. Sie sind als Basis- 

Library dokumentiert (WSDL) zu paketieren und können auch im SourceCode bereitgestellt werden. 

Siehe hierzu auch die Liste der Services gem. Kap. 6.1.13. 

Der Offline-Datenaustausch mit den FA muss automatisierbar sein: 

• Für jede FA wird je ein Austauschverzeichnis für Import und Export angelegt 

• Exporte aus dem Basissystem müssen über einen Job-Scheduler automatisch gestartet werden 

können 

• Importe in das Basissystem müssen über ein "Polling" der Import-Verzeichnisse automatisiert 

werden. 

Importe erfolgen zwecks Validierung immer in einen temporären Importbereich ("Validierungszone") 

der Sockeldatenbank. 

Version 4.1, 30.09.2005 

34


6.1.7 Unterstützende Funktionen Basissystem für Fachapplikationen 

Fachapplikationen verfügen teilweise nicht über die für MISTRA notwendigen Strukturen zur 

Speicherung der Basisdaten und haben teilweise kein GIS-Interface für die Bearbeitung von Geometrien. 

Bei vielen FA stellt sich die Frage, welche Funktionen des Basissystems von den FA 

mitbenutzt werden können. Dies ist grundsätzlich auf zwei Arten möglich: 

1. Durch die Bearbeitung von Generalistendaten im Basissystem, statt in der FA. 

2. Durch den Aufruf der benötigten Services des Basissystem aus der FA heraus. 

Die nachfolgende Tabelle gibt einen Überblick der wichtigsten Funktionen, die zur Verfügung stehen. 

Bearbeitung von Generalistendaten im Basissystem (Rich oder Web), statt in der FA: 

Datenbearbeitungsprozess: 

Erstellen und Bearbeiten 

von Fachnetzen 



von Flächennetzen 



von Bauwerksarten 

Ein Fachnetz ist eine Ebene / Thema auf der Sachverhalte zur Strasse und 

zum Strassenverkehr abgelegt werden können, z.B. Geschwindigkeits-, 

Unterhaltsabschnitte 

Falls eine FA nicht über die GIS-Funktionalität zur Erstellung und Bearbeitung 

von Fachnetzen verfügt, können diese ausserhalb der FA im Basissystem 

bearbeitet werden. Dann ist das Vorgehen zur Einrichtung eines 

Fachnetzes folgendermassen: 

1. Configuration Management: Definition der Anforderungen durch den 

Fachbereich: Name, Netztyp, topologische Bedingungen, Kennzahlen 

(Attribute) des Netzes. 

2. Configuration Management: Netzdefinitionen in die Sockeldatenbank 

eingeben durch den CM Basissystem. 

3. Datenbearbeitungsprozess: Netzabschnitte erstellen durch den Operateur 

des Fachbereichs oder die Geschäftsstelle MISTRA. 

Beispiele für zusätzliche Fachnetze sind: Verkehrsabschnitte, Unfallabschnitte, 

Strassenabschnitte in Gefahrenzonen, TMC-Location-Codes 

Ein Flächennetz ist eine Ebene / Thema mit Flächenobjekten, z.B. Kantone, 

Gemeinden, Projektperimeter 

Das Vorgehen ist gleich wie bei Fachnetzen. 

Beispiele für zusätzliche Flächennetze sind: Administrative Gebietsaufteilungen, 

Zonen mit erhöhten Lärmschutzanforderungen. 

Eine Bauwerksart ist eine Ebene / Thema mit Bauwerken der gleichen Art, 

z.B. Brücken, Tunnel, Stützmauern. Die Bauwerke können dabei punkt-, 

linien- oder flächenförmig sein. 

Das Vorgehen zur Einrichtung einer Bauwerksart ist: 

1. Configuration Management: Definition der Anforderungen durch den 

Fachbereich: Name der Bauwerksart, Geometrietyp, Kennzahlen (Attribute) 

des Bauwerkes 

2. Configuration Management: Definition der Bauwerksart in die Sockeldatenbank 

eingeben durch den CM Basissystem. 

3. Datenbearbeitungsprozess: Bauwerke erstellen durch einen Operateur 

des Fachbereichs oder die Geschäftsstelle MISTRA. 

Beispiele für zusätzliche Bauwerksarten sind: Leitplanken, Wechseltextanlagen, 

Zählstellen 

Beispiele für den Aufruf eines Service-Interface des Basissystems aus der FA heraus: 

Datenbearbeitungsprozess 

Zuordnung von FA-Objekten 

Sind die XY-Koordinaten von FA-Objekten der Fachapplikation bekannt, 

können die entsprechenden RBBS-Koordinaten (Bezugspunktnummer, U, 

Version 4.1, 30.09.2005 

35


zum RBBS 

Leistungserstellungsprozess 

Zuordnung von Daten zu 

Fachnetzen 

Leistungserstellungsprozess 

Zuordnung von Daten zu 

Flächennetzen 

V) durch den Service ermittelt und zurückgegeben werden. 

Der Aufruf erfolgt pro FA-Objekt. Bei Punktobjekten wird 1 Koordinaten- 

Triple, bei Linien- und Flächenobjekten 2 Koordinaten-Triple, je ein für die 

minimale und maximale Projektion auf die RBBS-Achse, zurückgegeben. 

Da die Bestimmung nicht immer eindeutig ist, müssen u.U. mehrere 

RBBS-Koordinaten-Triple zur Auswahl zurückgegeben werden. 

Die Art und Weise wie die RBBS-Koordinaten gespeichert werden, z.B. 

als Attribute in der Objekttabelle, ist Sache der FA. 

Beispiele für FA-Objekte, deren RBBS-Bezug auf diese Weise erstellt 

werden kann sind: Zählstelle, Bauwerk, Unfallort. 

Für die universelle Nutzung der Daten aus den FA ist die Zuordnung von 

Informationsobjekten zu Fachnetzen erforderlich, z.B. die Aggregation 

von Unfalldaten auf Unfallabschnitte, von Verkehrsdaten auf Verkehrsabschnitte 

usw. 

Der Aufruf erfolgt pro FA-Objekt. Dabei wird pro FA-Objekt der Schlüssel 

des zugehörigen Netzabschnittes zurückgegeben. Voraussetzung ist, 

dass die RBBS-Koordinaten des FA-Objekts bekannt sind. 

Anwendungsbeispiele sind die Zuordnung von Verkehrszählern zu Verkehrsabschnitten, 

Zuordnung von Unfällen zu Unfallabschnitten, Zuordnung 

von Unfallabschnitten zum Fachnetz Strassenzustand usw. 

Statt der Zuordnung von FA-Objekten zu Flächen durch manuelle Bearbeitung, 

kann dies durch Aufruf des Service-Interface automatisch gemacht 

werden. 

Der Aufruf erfolgt pro Objekt. Dabei wird pro FA-Objekt der Schlüssel der 

zugehörigen Fläche zurückgegeben. Voraussetzung ist, dass die Landeskoordinaten 

des FA-Objekts bekannt sind. 

Anwendungsbeispiele sind die Zuordnung von Bauwerken zu Kantonen, 

Gemeinden usw. 

Tabelle 3: Unterstützende Funktionen Basissystem für Fachapplikation 

Weitere Dienste, welche das Basissystem den Fachapplikationen zur Verfügung stellt, sind in 

Kap. 6.1.13 aufgelistet. 

Im Sinne einer Übergangslösung werden im Basissystem Funktionen für die Verwaltung von Generalisten- 

und Spezialistendaten verschiedener Fachbereiche temporär zur Verfügung gestellt. 

Dies betrifft die Objektklassen: Streifen, Schichteinbau Deckschicht, Langsamverkehr, Rapportstrecken, 

Kosten, Bauwerke, Projekte. Nach der vollständigen Realisierung der FA werden diese 

Funktionen im Basissystem ausser Betrieb genommen. 

Version 4.1, 30.09.2005 

36


6.1.8 Grundanforderungen an die Fachapplikationen 

Damit Fachapplikationen, die im Auftrag des ASTRA entwickelt werden, optimal an das Basissystem 

angebunden werden können, müssen folgende Anforderungen erfüllt sein: 

1. Benutzer-, Gruppen- und Rechte-Verwaltung erfolgt über LDAP. Für jede FA werden im 

LDAP-Verzeichnis die notwendigen Gruppen mit den Zugriffsrechten auf die Sockeldatenbank 

sowie die Rollen mit den Ausführungsrechten der Web-Services definiert. 

2. Die FA muss über eine Interlis2-Schnittstelle verfügen, die Daten in beiden Richtungen entsprechend 

dem Datenmodell des Basissystems transferiert. Als Grundlage wird das Datenmodell 

in der Datenbeschreibungssprache Interlis an die FA abgegeben. 

3. Die Objekt-Identifikation des Basissystems (UUID) muss beim Datenaustausch in beiden 

Richtungen mitgenommen werden. 

4. Die Objektidentifikation der FA-Objekte darf nie verändert werden. 

6.1.9 Anbindung von Fremdapplikationen 

Es gibt Basis- und Generalistendaten, welche weder vom Basissystem, noch von MISTRA- 

Fachapplikationen sondern von Applikationen verwaltet werden, auf welche das ASTRA keinen 

Einfluss auf die Gestaltung von Daten und Schnittstellen hat. Hierzu gehören: 

• Daten von nicht-MISTRA-Fachapplikationen (z.B. ViaPMS) 

• Daten von Erfassungswerkzeugen (z.B. CAD-Systeme, Excel-Tabellen, mobile Geräte) 

• Daten über Beteiligte (Adressen) und Dokumente (IDM) 

• Daten aus Finanzapplikationen (z.B. Kostendaten Bau und Unterhalt) 

• Daten aus Realtime-Systemen (z.B. Messdaten) 

• u.a.m. 

Bei solchen Fremdapplikationen ist zu unterscheiden zwischen: 

• Fremdapplikationen mit Programming-Interface oder offenem Daten-Interface (z.B. MS- 

Outlook, MS-Excel, diverse CAD). 

• Fremdapplikationen ohne Interface (Black-Box). Hier ist man auf das Vorhandensein einer 

Output-Datei angewiesen, die u.U. vom Hersteller programmiert werden muss. 

Version 4.1, 30.09.2005 

37


Die nachfolgende Abbildung zeigt, wie der Datentransfer aus solchen Anwendungen möglich ist: 

Fremdapplikation 

mit Interface 

Fremdapplikation 

ohne Interface 

Konnektor 


Output-Datei 

Konnektor 


Abbildung 7: Anbindung von Fremdapplikationen 

Im Rahmen der Entwicklung des Basissystems sind folgende Konnektoren vorgesehen: 

1. Outlook-Konnektor für den Bezug von Daten über Beteiligte (Adressen) 

2. Dokument-Konnektor für die Referenzierung von externen Dokumenten im Filesystem, in 

einem DMS oder auf dem Internet als URL in der Objektklasse "Dokument", sowie für die Ablage 

von Dokumenten, die in MISTRA erstellt werden (Pläne, Reports, Transferdateien usw.) 

Im konkreten Anwendungsfall des ASTRA (MISTRA-Instanz ASTRA) ist die Einführung eines 

integrierten Dokumentenmanagementsystems IDM vorgesehen. Das IDM wird eine SW- 

Komponente zur Verfügung stellen, welche es erlaubt Dateien im IDM zu referenzieren und zu 

öffnen (File-Dialog). 

Der Datenaustausch mit den Fremdapplikationen ist vorerst nur Offline über Transferdateien vorgesehen. 

Der Datenaustausch mit den Fremdapplikationen muss automatisierbar sein: 

• Für jede Fremdapplikation wird je ein Austauschverzeichnis für Import und Export angelegt 

• Exporte müssen über einen Job-Scheduler automatisch gestartet werden können 

• Importe müssen über ein "Polling" der Import-Verzeichnisse automatisiert werden. 

Importe erfolgen immer in einen temporären Importbereich der Sockeldatenbank (zwecks Validierung). 

Version 4.1, 30.09.2005 

38


6.1.10 Verteilung der MISTRA-Instanzen, typische Systemkonfigurationen 

Die offene Systemarchitektur von MISTRA lässt gesamtschweizerisch gesehen viele mögliche 

Systemkonfigurationen zu, nämlich von einer einzigen zentralen MISTRA-Instanz 2 bis hin zu 

mehreren Einzel-Instanzen pro Eigentümer (= Strassenbehörde). Die Systemarchitektur MISTRA 

lässt alle Varianten zu. Auf der Basis der vorhandenen föderalen Strukturen ist davon auszugehen, 

dass das ASTRA, jeder Kanton und jede Agglomeration über je eine autonome MISTRA- 

Instanz verfügen werden und je nach Grösse auch noch pro Eigentümer mehrere Unterinstanzen 

(z.B. pro Kreis) existieren werden. Je nach Grösse der Organisation des Eigentümers sind unterschiedliche 

optimale Systemkonfigurationen zu erwarten. Die nachfolgende Abbildung zeigt einige 

typische Systemkonfigurationen. 

Abbildung 8: Varianten Systemkonfiguration 3 

2 Unter einer Instanz verstehen wir eine eigenständige MISTRA-Installation eines einzigen Eigentümers mit eigener 

Sockeldatenbank. Jede Instanz kann über mehrere Sockeldatenbanken verfügen, z.B. eine zentrale Hauptdatenbank 

und verschiedene dezentrale Arbeitsdatenbanken. 

3 Der Low-End-Bereich wird nicht durch eine spezielle Light-Version abgedeckt, sondern durch die Bereitstellung der 

Grundversion von MISTRA inkl. den Lizenzen der Basissoftware (ESRI) zu sehr guten Konditionen. 

Version 4.1, 30.09.2005 

39


Die Varianten 1 bis 4 stellen je eine eigene MISTRA-Instanz dar. Jede dieser Instanzen funktioniert 

völlig eingeständig. Die dargestellten Netzwerkverbindungen KTV sind für den Normalbetrieb 

nicht notwendig. Sie können für den Austausch von Offline-Dateien verwendet werden. 

Bei der Variante 5 Terminalbetrieb ist eine Netzwerkanbindung zwingend. Sie ist interessant, 

wenn Aussenstellen an eine zentrale MISTRA-Instanz angebunden werden sollen. 

Bei jeder der Varianten müssen zusätzlich mobile Clients angebunden werden können. 

Zwischen verschiedenen MISTRA-Instanzen können Daten ausgetauscht werden. 

Jeder Eigentümer (Strassenbehörde) kann eine oder mehrere MISTRA-Datenbanken betreiben. 

Mehrere Datenbanken sind von Interesse, wenn : 

• die Datenbewirtschaftung dezentral erfolgt 

• separate Test- oder Modell-Instanzen betrieben werden 

• Datenbanken extern, z.B. bei Ingenieurbüros betrieben werden 

Die Eindeutigkeit des Schlüssels von MISTRA-Objekten wird durch einen Universal Unique Identifier 

UUID gemäss ISO 11578 sichergestellt. Weitere UUIDs identifizieren den Eigentümer sowie 

die Datenbank von MISTRA. Die Beschreibung des Schlüssels und weiterer Attribute, welche die 

Datenherrschaft regeln sind im Datenkatalog [3] "MISTRA-Schlüssel, Datenherrschaft" beschrieben. 

Der Datenaustausch zwischen MISTRA-Datenbanken erfolgt im offline-Modus, i.d.R. über Interlis2. 

Folgende Datenaustausch-Szenarien müssen abgedeckt werden können: 

1. Daten zwischen MISTRA-DBs austauschen, ohne Änderung der Datenherrschaft, ohne Änderung 

des Eigentümers. 

2. Daten zwischen MISTRA-DBs austauschen, mit Änderung der Datenherrschaft, ohne Änderung 


3. Daten zwischen MISTRA-DBs austauschen, mit Änderung der Datenherrschaft und Änderung 


4. Neue Daten von FA importieren mit Vergabe von MID, Owner, OrigDB und WriteGrp (s. Datenkatalog 

[3]) 

5. Inkrementelles Update von FA importieren mit Erkennung der Schlüsselattribute 

6. Daten zu handen FA bereitstellen 

Version 4.1, 30.09.2005 

40


Die verschiedenen Varianten in Abbildung 8 lassen sich folgendermassen beschreiben: 

Variante 1und 2 

Potenzial 

Architektur 

Datenhaltung 

Anzahl Applikationen 

Intranet-Plattform 

Internet-Plattform 

BetreiberIn 

Anzahl Records in 

Sockeldatenbank 

Anzahl Interlis2 

Datentransfers 

Mengengerüst 

Anzahl Benutzer 

Basis- und Fachapp 

Anzahl Zugriffe 

pro Jahr 

Grosse Organisationen 

ASTRA, 4 bis 8 grosse Kantone, 1 bis 2 grosse Agglomerationen 

3-Tier, Data- und Application Tier auf getrennten Servern 

Verteilt über mehrere MISTRA-DBs oder in einer zentralen DB 

10 bis 15 Fachapplikationen, 5 bis 10 Fremd-Applikationen. 

Eigene, zentral betriebene Intranet-Plattform MISTRA 

Eigene, zentral betriebene Internet-Plattform 

Interne Informatik oder zentrale Informatik (z.B. BIT für ASTRA) 

100'000 bis 150'000 Kernentitäten 

100'000 bis 200'000 abhängige Entitäten (z.B. Kennzahlen) 

Je Instanz ca. 200 bis 300 Exporte und Importe pro Jahr 

Zusätzlich ca. 50 bis 100 Tranfers je dezentraler MISTRA-Instanz 

Latenzzeit ab Lieferung bis zum Import max. 12 h 

Rich-GIS 

lesend / schreibend 

3 -6 

Arbeitsplätze 

10'000 -20'000 

Mutationen 

Web-GIS 


lesen: 80 -120 

schreiben: 10 -20 

500'000 

Record-Zugriffe 

Web-DWH 

lesend 

Web-Admin 

Rich-Admin 

80 - 120 3 - 5 

8000 - 12000 

Programmstarts 

500 - 1000 

Operationen 

Uptime * 5 x 12 6 x 18 6 x 18 5 x 12 

Verfügbark. zu Uptime* 98% 99% 99% 98% 

Tabelle 4: Mengengerüst grosse Installationen 

Variante 3 

Potenzial 

Architektur 

Datenhaltung 

Anzahl Applikationen 

Intranet-Plattform 

Internet-Plattform 

BetreiberIn 

Anzahl Records in Sockeldatenbank 

Anzahl Interlis2 

Datentransfers 

Kantone und Agglomerationen 

10 bis 15 kleine bis mittlere Kantone, 6 bis 10 kleine bis mittlere Agglomerationen 

3-Tier, Data- und Application Tier Oracle / ArcSDE / ArcGIS-Server / MISTRA 

Server wahlweise auf getrennten Servern oder konzentriert auf einem Server. 

Eine zentrale, produktive MISTRA-DB 

2 bis 10 Fachapplikationen, 1 bis 5 Fremd-Applikationen. 

Eigene, zentral betriebene Intranet-Plattform MISTRA 

Eigene, zentral betriebene Internet-Plattform 

Zentrale Informatik 

20'000 bis 80'000 Kernentitäten 

20'000 bis 100'000 abhängige Entitäten (z.B. Kennzahlen) 

Je Instanz ca.20 bis 200 Exporte und Importe pro Jahr 

Latenzzeit ab Lieferung bis zum Import max. 12 h 

Mengengerüst 

Rich-GIS 


Web-GIS 


Web-DWH 

lesend 

Web-Admin 

Rich-Admin 

Anzahl Benutzer 

Basis- und Fachapp 

1 - 4 

Arbeitsplätze 

lesen: 10 -80 

schreiben: 5 -10 

10 - 80 1 - 3 

Version 4.1, 30.09.2005 

41


Anzahl Zugriffe 

pro Jahr 

2'000 -10'000 

Mutationen 

250'000 

Record-Zugriffe 

1000 - 8000 

Programmstarts 

100 - 600 

Operationen 

Uptime * 5 x 12 6 x 18 6 x 18 5 x 12 

Verfügbark. zu Uptime* 98% 99% 99% 98% 

Tabelle 5: Mengengrüst kleine bis mittelgrosse Installationen 

* Die Uptime darf zusätzlich durch 4 Wartungsfenster zu 1 Tag pro Jahr unterbrochen sein. 

Die Mengenangaben beziehen sich auf den Vollausbau. Bei der Anzahl Benutzer "GIS Intranet" 

und "DWH Intranet" handelt es sich um die Anzahl potenzieller Benutzer. Die gleichzeitige Benutzung 

beträgt 20 bis 30%. 

Version 4.1, 30.09.2005 

42


6.1.11 Authentisierung und Rechte 

Das Zugriffskonzept von MISTRA muss sicherstellen: 

1. Die Verwaltung der Benutzer und Gruppen erfolgt über LDAP. Es dürfen nur LDAP Standardfunktionen 

ohne Hersteller spezifischen Erweiterungen verwendet werden. 

2. Definition der Zugriffsrechte auf Daten über Benutzergruppen. 

3. Unterscheidung der Zugriffsrechte nach "kein Zugriff", "lesen", "schreiben" 

4. Es muss möglich sein die Zugriffsrechte innerhalb einer Tabelle nach Attributen zu differenzieren 

(Auswahl von Spalten). 

5. Es muss möglich sein die Zugriffsrechte innerhalb einer Tabelle nach Zeilen zu differenzieren 

(Auswahl von Zeilen), nicht über LDAP sondern über Attribut Datenherrschaft (s. [3]). 

6. Definition der Ausführungsrechte von UseCases (Funktionen) über Rollen 

7. Wird ein Benutzer oder eine Gruppe einer Rolle zugeordnet, müssen die zur Ausübung dieser 

Rollen notwendigen Zugriffsrechte automatisch definiert werden. 

8. Die Zugriffe auf die Daten (Objektklassen bzw. Tabellen) werden im Data Access Layer oder 

vom DBMS kontrolliert. 

9. Die Verwaltung der Rollen und UseCases erfolgt applikatorisch in MISTRA. MISTRA steuert 

die Ausführungsrechte der UseCases. 

10. Die online zugreifenden Fachapplikationen werden über die gleichen Mechanismen an das 

Basissystem angebunden. Pro FA werden eigene Gruppen und Rollen definiert und in der 

Sockeldatenbank abgespeichert. Hiermit ist die FA auch registriert und deren Zugriffs- bzw. 

Ausführungsberechtigungen definiert. Bei der Inbetriebnahme einer neue FA, müssen die 

entsprechenden Rollen und Gruppen definiert werden. 

Version 4.1, 30.09.2005 

43


6.1.12 Mehrbenutzerbetrieb, Bearbeitungseinheiten 

Die Datenbearbeitung in MISTRA erfolgt in so genannten Bearbeitungseinheiten. Voraussetzung 

für die Dateneingabe ist die Eröffnung einer Bearbeitungseinheit. Sie definiert eine Untermenge 

einer Objektklasse und basiert auf einer Objektselektion (vgl. Kap 6.1.22). 

Bei der Eröffnung werden zu der Bearbeitungseinheit folgende Eigenschaften definiert: 

1. Zugehörigkeit zur Objektklasse (automatisch) 

2. Geografische Ausdehnung als Bounding Box (automatisch aus Objektselektion) 

3. MISTRA-Basisattribute (automatisch) 

Nach Abschluss der Bearbeitung wird die Bearbeitungseinheit geschlossen. Bei der Schliessung 

wird die Bearbeitungseinheit als geschlossen markiert und es werden folgende Eigenschaften 

ermittelt und in die Metadaten gespeichert: 

1. Beschreibung des Aktualisierungsumfanges (manuell) 

2. Bemerkungen (manuell) 

3. Angaben zur Genauigkeit (automatisch aus Einzelobjekten) 

4. Datum der letzten Aktualisierung (automatisch aus Einzelobjekten) 

Es muss sichergestellt sein, dass: 

1. ein MISTRA-Objekt gleichzeitig nur von einer Bearbeitungseinheit geöffnet sein kann 

2. ein MISTRA-Objekt ohne offene Bearbeitungseinheit nicht bearbeitet werden kann 

Version 4.1, 30.09.2005 

44

TP 

TP 

TP 

PT Die 

PT Die 

PT WS-AtomicTransaction 


6.1.13 Service-Interface 

Für den Zugriff zur Sockeldatenbank in den Basis- und Fachapplikationen ist in MISTRA eine 

Programmierschnittstelle als Service-Interface zu entwickeln. Sämtliche Server-Funktionen in der 

Middle-Tier müssen vom Client als Web-Service aufgerufen werden können. Diese Interfaces 

umfassen u.a. folgende, für Fachapplikationen wichtige Funktionen: 

1. Abruf einer MISTRA-Identifikation als UUID für neue FA-Objekte. 

2. WebMap-Services zur Übermittlung von Kartenausschnitten 

3. WebFeature-Services für Objektabfragen 

4. Online-Bezug von Basis- inkl. Metadaten, selektiv nach Objektklassen 

5. Online-Bezug von Generalisten- inkl. Metadaten, selektiv nach Objektklassen 

6. Online-Ablage von Basis- inkl. Metadaten in die Importzone, selektiv nach Objektklassen 

7. Online-Ablage Generalisten- inkl. Metadaten in die Importzone, selektiv nach Objektklassen 

8. Transformation XY > UV 

9. Transformation UV > XY 

10. Transformation Kilometrierung > UV 

11. Transformation UV > Kilometrierung 

12. Zugehörigkeit von MISTRA-Objekten zu Flächen bestimmen 

13. Aggregation von MISTRA-Objektdaten pro Fläche 

14. Zugehörigkeit von MISTRA-Objekten zu Fachnetzen bestimmen 

15. Aggregation von MISTRA-Objektdaten pro Fachnetz 

16. Verschnitt von Fachnetzen 

Diese Services sind im UseCase-Modell [4] beschrieben. Für die Implementierung des Service- 

Interface ist das SOAP-Protokoll zu verwenden [14]. 

Im Rahmen der Detailspezifikation ist zu prüfen, inwiefern nebst den OGC-Standards neue Web- 

Service-Standards angewendet werden sollen. Zur Diskussion stehen: 

4 

• WS-AdressingTP PT, für den Umgang mit Internetadressen 

5 

• WS-SecurityTP PT, für Authentisierung und Datenverschlüsselung 

6 

• WS-Atomic TransactionTP PT, für das Abwickeln von Transaktionen 

Die Schnittstelle muss versioniert sein. Das Basissystem muss gleichzeitig mehrere Versionen 

der Schnittstelle unterstützen können (mindestens zwei). Ziel ist, dass später bei Fachapplikatio- 

4 

5 

Web Services Addressing Spezifikation wurde vom W3C als 'member submission' im August 2004 akzeptiert [20] 

Web Services Security Spezifikation existiert in Version 1.0 als OASIS Standard (OASIS Standard 200401, March 

2004, "Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)". Die Version 1.1 existiert als Draft. 

[21] 

6 

und in Verbindung stehende Spezifikationen werden für den unbesehenen Gebrauch und nur 

für Bericht und Auswertung von Microsoft, BEA und IBM zur Verfügung gestellt. [22] 

Version 4.1, 30.09.2005 

45


nen, die diese Schnittstelle nutzen, kein Migrationszwang entsteht, wenn das Basissystem erweitert 

wird. 

Version 4.1, 30.09.2005 

46


6.1.14 Standardisierte Schnittstelle (Interlis2) 

Geschäftsprozesse BP4 (Export Service), IP1 (Basisdatenintegration), IP2 (Generalistendatenintegration). 

Für die Sockeldatenbank muss eine Schnittstelle für Datenimporte und –exporte realisiert werden. 

Diese Schnittstelle baut auf den Service-Interfaces gemäss Kap. 6.1.13 auf. Sie wird von 

den Datenbankadministratoren der Anwenderorganisationen ausgeführt. 

6.1.14.1 Allgemeine Anforderungen: 

1. Die Schnittstelle unterstützt sowohl den vollen als auch den inkrementellen Datenaustausch 

nach dem Interlis2-Standard (vgl. [10]) 

2. Die Metadaten müssen mit der gleichen Transferdatei übertragen werden. Diese sind im Datenkatalog 

[3] beschrieben. 

3. Es muss möglich sein Daten von einer MISTRA-Instanz zu einer anderen über diese Schnittstelle 

zu übertragen, auch wenn beide Installationen nicht den gleichen Release-Stand aufweisen 

(die Version des aktuellen und des letzten Haupt-Release der Schnittstelle müssen 

unterstützt werden). 

4. Beim Datentransfer ist die UUID der Senderinstanz mitzugeben. Über diese UUID ist die Erkennung 

des Senders möglich. Die Senderinstanz ist in der Sockeldatenbank in der Tabelle 

"Datenbank" registriert. 

5. Der Datenaustausch muss über den Windows Taskplaner (Scheduler) automatisch gestartet 

werden können. Diese Tasks werden in der Sockeldatenbank verwaltet. Der Bezug der Importdateien 

bzw. die Speicherung der Export-Dateien erfolgt aus bzw. in vordefinierte Verzeichnisse. 

6. Bei Import- und Exportvorgängen wird der Status (Fortschritt) am Bildschirm angezeigt (nur 

bei interaktiver Ausführung) und in eine LOG-Datei geschrieben. Über jeden Vorgang und 

Fehler wird ein Eintrag in eine LOG-Tabelle gemacht. 

7. Bei fehlerhaften Daten ist der Import dennoch möglichst vollständig abzuarbeiten. 

6.1.14.2 Abweichungen vom Interlis2-Standard 

Im MISTRA sind folgende Abweichungen speziell zu beachten 

1. Unterschiedliche Schlüsselbildung (MISTRA verwendet UUIDs nach ISO 11578) 

2. Interlis2 unterstützt keine linearen Bezugssysteme. Interlis2 kann diese Merkmale nur wie 

normale Sachdaten behandeln. Transformationen müssen applikatorisch durchgeführt werden. 

3. Veränderungen im Raum/Zeit-Bezug werden von Interlis2 nicht berücksichtigt. Anpassungen 

müssen applikatorisch gemacht werden. 

Version 4.1, 30.09.2005 

47


6.1.14.3 Ablauf eines Imports 

Der Import der Daten über die Interlis2-Schnittstelle erfolgt grundsätzliche in Teilschritten: 

1. Import der Daten mit: 

• Validierung der Daten durch die Schnittstelle 

• Bereinigung und Vervollständigung durch die Schnittstelle 

• Speicherung der Daten in einen Validierungsbereich der Sockeldatenbank als Importversion 

(Versionierung ArcSDE) mit Interpretation der Differenzen (Sachdaten mutiert, Geometrie 

mutiert, neu, gelöscht). 

2. Grafisch-interaktive Validierung durch den/die BenutzerInnen mit der Möglichkeit Differenzen 

zu akzeptieren oder zurück zu weisen. 

3. Definitive Übernahme der Daten (Integration). 

6.1.14.4 Validierung beim Import 

Die Import-Schnittstelle führt eine Validierung der Daten durch. Diese beinhaltet: 

1. Bezugssystem prüfen 

2. Prüfen ob Metadaten vorhanden und regelkonform 

3. Prüfen ob obligatorische Attribute und Kennzahlen vorhanden und regelkonform 

4. Zeitbezug prüfen, z.B. Fremdschlüsselbeziehungen auf MISTRA-Objekte, die durch die Beendigung 

der zeitlichen Gültigkeit nicht mehr anwendbar sind. 

5. Prüfen ob Raumbezug (RBBS und/oder XY) vorhanden und regelkonform (Extent) 

6. Prüfen ob übrige Attribute regelkonform 

7. Falls MISTRA-Schlüssel (UUID) mitgegeben wird, Gültigkeit (Übereinstimmung) prüfen 

Die Ergebnisse der Validierung werden in eine LOG-Datei geschrieben. 

6.1.14.5 Bereinigung und Vervollständigung beim Import 

Ist die Validierung erfolgreich abgelaufen, führt die Schnittstelle eine Bereinigung und Vervollständigung 

der Daten durch. Diese beinhaltet: 

1. Modelltransformation auf das Datenmodell MISTRA 

2. Werden Daten in einem anderen Bezugssystem (LV03, WGS84) als das für MISTRA (LV95 

und LHN95) geliefert, muss beim Import eine Transformation durchgeführt werden. 

3. Schlüssel 

• Erzeugen fehlender MISTRA-Schlüssel 

• Ev. Ersatz von Fremdschlüsselbeziehungen 

4. Zeitbezug 

• Ergänzen fehlender Zeitattribute 

• Anpassung der zeitlichen Granularität 

Version 4.1, 30.09.2005 

48


• Bei der inkrementellen Nachführung muss die History sowohl des MISTRA-Objekts selbst 

als auch bezüglich abhängiger Objekte (Fremdschlüsselbeziehungen) nachgeführt werden. 

• Wenn das liefernde System Geodaten ohne RBBS-Bezug liefert, die Sockeldatenbank 

diese jedoch vorsieht, wird der RBBS-Bezug beim Importieren erstellt. 

5. Raumbezug 

• Beim Import von Daten mit RBBS-Bezug muss dieser nachgerechnet werden, sofern das 

RBBS-Datum der importierten Daten älter ist, als das aktuelle RBBS in der Sockeldatenbank. 

• Duale Koordinatenablage (linear/planar) auf der Basis der Bezugsgeometrie vervollständigen. 

6. Übrige Attribute 

• Transformation von Masseinheiten 

• Transformation von Bezügen zu Auswahllisten und Textkatalogen 

• Bestimmung von berechneten Attributen 

6.1.14.6 Ablauf eines Exports 

Der Export der Daten über die Interlis2-Schnittstelle erfolgt in folgenden Teilschritten: 

1. Definition des Exportparameter: 

• Adressat als Beteiligter 

• Art des Exports voll/inkrementell 

• Wiederholungsparameter 

• Datenselektion gem. Kap. 6.1.22 

• Historie J/N 

• Bezugsdatum 

• Verzeichnis für Datenablage 

• Zeitpunkt 

• Medium für Versand 

• usw. 

Diese Daten werden in der Sockeldatenbank gespeichert. 

2. Starten des Exportvorgangs interaktiv oder über Taskplaner (Scheduler). 

3. Erstellen der Exportdateien inkl. Modellbeschreibung 

4. Versand der Daten 

Beim Export an Fach- oder Fremdapplikationen, welche keine History verwalten, ist immer nur 

der aktuelle Zustand zu liefern. 

6.1.15 Export WebGIS KOGIS 

Die Sockeldaten müssen periodisch in die Geo-Datenbank von KOGIS übertragen werden. Der 

Transfer (in der Systemarchitektur gemäss Abbildung 4 als "ETL Geodaten" bezeichnet) erfolgt 

Version 4.1, 30.09.2005 

49


über die normale Interlis2-Exportfunktion des Basissystems inkrementell. Wegen der unterschiedlichen 

Datenmodelle muss jedoch zusätzlich eine Modelltransformation durchgeführt werden. 

Die Modelltransformation umfasst: 

1. Unterdrücken von Daten, welche nicht für die Öffentlichkeit bestimmt sind 

2. Vereinfachung und Denormalisierung der Daten 

3. Auflösung der Katalogbezüge und der Auswahllisten 

4. Umbenennung von Tabellen- und Attributbezeichnungen 

Das Datenmodell der Zieldatenbank ist noch nicht festgelegt. 

Die Funktion muss als Batch-Job definiert und ausgeführt werden können (vgl. Import-/Export- 

Modul gemäss Kap 6.1.14). 

6.1.16 Import Daten Beteiligter 

Für den Import der Daten Beteiligter ist als Minimalversion ein Outlook-Konnektor zu realisieren. 

Dieser übernimmt Daten aus der Exchange-Datenbank, ev. via einer Zwischendatei .CSV. Die 

Daten werden in den Validierungsbereich der Sockeldatenbank abgelegt und anschliessend mit 

den Grundfunktionen des Basissystems validiert und integriert. 

Mittelfristig ist für das ASTRA eine Schnittstelle in die Adressverwaltung des IDM zu realisieren. 

Die Spezifikation für diese Schnittstelle ist noch nicht hinreichend bekannt und soll nur als Option 

offeriert werden. 

6.1.17 Import Daten zu Dokumenten 

Für den Import der Daten zu Dokumenten ist als Minimalversion eine Anbindung an das Filesystem 

zu realisieren. Dieser übernimmt Links auf Dateien des Filesystems in die Sockeldatenbank. 

Mittelfristig ist für das ASTRA eine Schnittstelle in die Dokumentenverwaltung des IDM zu realisieren. 

Die Spezifikation für diese Schnittstelle ist noch nicht hinreichend bekannt und soll nur als 

Option offeriert werden. 

6.1.18 Import Daten Verkehrsnavigation 

Es ist vorgesehen regelmässig Daten Verkehrsnavigation in die Sockeldatenbank zu integrieren. 

Sie liefert Daten zur Topologie, zu Fachnetzen und Geometrie. Die Schnittstelle von der Datenbank 

des Anbieters nach Interlis2 wird vom Anbieter der Navigationsdaten realisiert. Der Import in 

die SDB läuft über die Interlis2-Schnittstelle, mit der Modellbeschreibung der Sockeldatenbank 

(d.h. zum Import in die SDB ist keine Modelltransformation erforderlich). 

Version 4.1, 30.09.2005 

50


6.1.19 Import Daten Verkehrsinformation 

Hier geht es um die Verkehrsereignisse von GEWI / Viasuisse, wie Stau, Unfall, Falschfahrer, 

Baustellen sowie den TMC Location Codes. Die Schnittstelle ist zum heutigen Zeitpunkt noch 

nicht spezifiziert. 

6.1.20 Export Metadaten KOGIS 

Die Metadaten von MISTRA werden nach dem ISO-Standard 19115 verwaltet. Das ASTRA arbeitet 

mit KOGIS nach dem Partnerschaftsmodell B, d.h. die Daten werden lokal in der Sockeldatenbank 

verwaltet und periodisch in die Metadatenbank KOGIS transferiert. Das Basissystem benötigt 

hierzu eine Export-Schnittstelle. 

Die Anforderungen an diese Schnittstelle sind: 

1. Der Transfer erfolgt nach Interlis2 

2. Die Daten müssen gemäss der Interlis-Beschreibung im Metadatenmodell [12] geliefert werden. 

3. Die Funktion muss als Batch-Job definiert und ausgeführt werden können (vgl. Import-/Export- 

Modul gemäss Kap 6.1.14). 

6.1.21 Weitere Schnittstellen 

Zusätzlich zu Interlis2 sollen die folgenden Datenschnittstellen angeboten werden: 

1. Export von Tabellendaten als Excel- und .CSV-Datei 

2. Export und Import von Geometriedaten im DXF-Format 

3. Export und Import von Geometrie- / Sachdaten im ESRI-Shape-Format 

4. Import von Interlis1 

5. Export von Reports im PDF-Format 

Die Unterstützung von GML wird erst in einer späteren Realisierungseinheit gefordert. 

Version 4.1, 30.09.2005 

51


6.1.22 Selektionswerkzeug 

Mit dem Selektionswerkzeug sollen Basis- und Generalistendaten nach sachbezogenen und/oder 

räumlichen Kriterien selektiert werden können. Sie dienen als Grundlage für: 

• Definition des Perimeters von Bearbeitungseinheiten 

• Definition des Perimeters von Datenexporten und ETL-Prozessen. 

• Objektselektion für Berechnungs- und Transformationsfunktionen 

• Objektselektion für Auswertungen 

• Massenattributierung 

• Usw. 

Die Anforderungen an das Selektionswerkzeug sind: 

1. Die Selektionen müssen als Satz von Abfragen (nicht als Selektionsmenge) gespeichert und 

in definierter Reihenfolge wieder verwendet werden können. 

2. Das Selektionswerkzeug umfasst alle von ArcGIS/ArcMap unterstützten Operatoren. 

3. Die Selektionsparameter (Werte von Vergleichsoperationen) müssen vom Benutzer für den 

jeweiligen Anwendungsfall eingegeben werden können. 

4. Für die interaktive Benutzung ist ein Formular zu implementieren, in dem sämtliche zur Selektion 

gehörigen Abfragen aufgelistet und parametrisiert werden können. 

5. Die Selektionen müssen auch von Batch-Prozessen ausgeführt werden können. 

6.1.23 Clients / Benutzeroberfläche 

Die Benutzung des Basissystems erfolgt über folgende Clients: 

RichGIS 

WebGIS 

WebDWH 

RichAdmin 

WebAdmin 

Tabelle 6: Client-Typen 

Windows- oder Terminal-Arbeitsplatz auf welchem die für MISTRA notwendigen 

Windows-Anwendungen (ArcGIS, BusinessObjects, Office usw.) mit ihren 

MISTRA-Erweiterungen gestartet werden können. 

Browser-Arbeitsplatz auf welchem die MISTRA-Webanwendungen mit GIS- 

Funktionalitäten gestartet werden können. 

Browser-Arbeitsplatz auf welchem Auswertungen über das DWH stattfinden. 

Physisch kann es der gleiche Client wie WebGIS sein. 

Windows- oder Terminal-Arbeitsplatz auf welchem komplexe Administrationsfunktionen, 

die nicht effizient über den WebAdmin-Client möglich sind, ausgeführt 

werden können. Physisch kann es der gleiche Client wie RichGIS sein. 

Browser-Arbeitsplatz auf welchem komplexe Administrationsfunktionen ausgeführt 

werden können. Physisch kann es der gleiche Client wie WebGIS sein. 

Über diesen Client-Typ wird auch das Web-Problem- und Change-Management 

abgewickelt. 

Die Rich-Clients sind möglichst klein zu halten. Sie greifen auf eine für MISTRA entwickelte Middleware 

in der Application-Tier. 

Version 4.1, 30.09.2005 

52


Die GUIs sind nach einheitlichen Richtlinien zu gestalten. Die Design-Richtlinien und Detailanforderungen 

sind im Rahmen des Systemdesigns festzulegen. Die nachfolgende Abbildung zeigt die 

Aufteilung der Oberfläche für den Rich-GIS- und Web-GIS-Client. 

Titelleiste 

Menüleiste 

Iconleisten 

Legende 

Treeview 

Kartenfenster 

Property Grid 

Navigation 

Statusleiste 

Abbildung 9: Bildschirmlayout GIS-Clients 

Der Property Grid ist eine spezielle Implementation der Sachdatenmaske, in dem die Sachdaten 

von MISTRA-Objekten ähnlich dem i-Werkzeug von ArcMap als einfache Liste angezeigt werden. 

Als Labels der Attribute müssen die mehrsprachige Alias verwendet werden. Werte aus Textkatalogen 

und Auswahlisten müssen als Text in der jeweils aktuellen Sprache dargestellt werden. 

Weitere Angaben siehe Kap. 6.1.25. 

Im Rich-GIS müssen Legende, Treeview und Property Grid als dockable Windows implementiert 

werden. Der Benutzer soll einzelne Fenster ganz weglassen können. Im Web-GIS kann die Umstellung 

zwischen diesen Fenstern über Registerkarten erfolgen. 

Version 4.1, 30.09.2005 

53


6.1.24 Anwendungsfälle (UseCases) 

Definition: "A Use Case represents a discrete unit of interaction between a user (human 

or machine) and the system. It is performed as a whole or not at all and returns something 

of value to the user. Examples of Use Cases are AddOrder, DeleteOrder, Modify- 

Order, ListTrains, ListLocations & etc." nach Geoffrey Sparks, 2000 

Die nachfolgende Abbildung zeigt die Prozesslandkarte aus [2]. 

Abbildung 10: Prozesslandkarte Basissystem (Makro-Ebene) 

Die nachfolgenden Tabelle zeigt die Zuordnung der Anwendungsfälle zu Prozessgruppen oder 

Prozessen. Die Zuordnung ist nicht eindeutig. Ein Prozess kann mehrere Anwendungsfälle umfassen, 

z.B. besteht der Prozess "Bearbeiten übrige Basisdaten DP2" aus den Anwendungsfällen 

differenziert nach den Datenarten "Raumbezug", "Fachnetze" usw. und nach der Mutationsaufgabe 

"Erfassen", "Mutieren", "Löschen". Ein Anwendungsfall kann in mehreren Prozessen vorkommen, 

z.B. "Legende laden", "Erfassen von Metadaten" oder "Öffnen einer Bearbeitungseinheit". 

Es gibt auch Prozesse, die ohne Basissystem abgewickelt werden und somit keinen Anwendungsfall 

benötigen, z.B. "Definition der Systemgrenze FP5". 

Die UseCases des Basissystems sind im Begleitdokument [4] dokumentiert. Die nachfolgende 

Tabelle zeigt welche UseCases über welche Clients angewendet werden. 

Nr 

Use Case 

10000 LP Leistungserstellungsprozesse 

10100 LP Explore GIS 

Priorität 

Rich- 

GIS 

10101 LP GIS starten 1 Z Z 

10102 LP Legende laden 1 Z Z 

10103 LP Zoomen, Pannen 1 Z Z 

10104 LP Navigation über Suchfunktion 1 Z Z 

10106 LP Navigation über Treeview 1 Z Z 

10107 LP Abfragen durchführen 1 Z Z 

10108 LP Kartensicht 4 Z Z 

10109 LP Formularsicht 1 Z Z 

10110 LP Tabellensicht 1 Z Z 

10300 LP1 Karten Service 

Web- 

GIS 

Prozess 

Rich- 

Admin 

Web- System 

Admin 

Version 4.1, 30.09.2005 

54


Nr 

Use Case 

Priorität 

Rich- 

GIS 

Web- 

GIS 

10301 LP1 Karte bereitstellen, bearbeiten, 

ausgeben 4 Z Z 

10400 LP2 Achsband Service 

10401 LP2 Achsband definieren 4 Z 

10405 LP2 Achsbandplan bereitstellen, bearbeiten, 

ausgeben 4 Z 

10500 LP3 Report Service GIS 

10501 LP3 AdHoc GIS-Report bereitstellen, 

bearbeiten, ausgeben 4,6 Z 

Prozess 

Rich- 

Admin 

Web- System 

Admin 

10502 LP3 Vordefinierten GIS-Report bereitstellen, 

bearbeiten, ausgeben 4,6 Z Z 

10504 LP3 Report freigeben 6 Z 

10600 LP4 Datenexport Service 

10601 LP4 Export konfigurieren 3 Z 

10602 LP4 Export Interlis 3 Z 

10603 LP4 Export Excel 3 Z O 

10604 LP4 Export CSV 3 Z O 

10605 LP4 Export Shape 3 Z 

10606 LP4 Export DXF 3 Z 

10700 Metadaten Service 

10701 LP4 Metadaten an KOGIS exportieren 5 Z 

10702 FP6 Metadaten publizieren 5 Z 

10800 LP7 Datenwiederherstellung (Restore) 

10801 LP7 Daten wieder herstellen 5 Z O 

10900 LP Selektionen 

10901 LP Selektion erstellen, mutieren, 

löschen 3 Z O 

10902 LP Selektion ausführen 3 Z Z Z 

11000 LP Service Interface für FA 

11001 LP1 WebMap-Service bereitstellen 5 Z 

11002 LP1 WebFeature-Service bereitstellen 5 Z 

11003 LP4 Basisdaten aus SDB beziehen 5 Z 

11004 LP4 Generalistendaten aus SDB beziehen 

5 Z 

11005 LP Basisdaten in SDB ablegen 5 Z 

11006 LP Generalistendaten in SDB ablegen 

5 Z 

11007 LP6 WS Transformation UV XY 5 Z 

11008 LP6 WS Transformation XY UV 5 Z 

11009 LP5 WS Zugehörigkeit MISTRA- Objekten 

zu Flächen 5 Z 

Version 4.1, 30.09.2005 

55


Nr 

Use Case 

Priorität 

Rich- 

GIS 

Web- 

GIS 

Prozess 

Rich- 

Admin 

Web- System 

Admin 

11010 LP5 WS Aggregation MISTRA-Objekte 


11011 LP5 WS Zugehörigkeit MISTRA- 

Objekte zu Fachnetze 5 Z 

11012 LP5 WS Aggregation MISTRA-Objekte 

zu Fachnetze 5 Z 

11013 LP5 WS Verschnitt von Fachnetzen 5 Z 

11014 LP UUID-Service 5 Z 

11015 LP6 WS Transformation Km > UV 5 Z 

11016 LP6 WS Transformation UV > Km 5 Z 

20000 DP Datenbearbeitungsprozesse 

20100 DP1 Antrag Datenkorrektur (Update 

Request) 

20101 DP1 Update Request erfassen, behandeln, 

löschen 2 Z 

20102 DP1 Update Requests sichten 2 Z 

20103 DP1 Update Requests Report erstellen 2 Z 

20300 DP2 Bearbeiten übrige Basisdaten 

20301 DP2 Fläche erfassen, mutieren, löschen 

2 Z S 

20302 DP2 Kennzahl zu Fläche erfassen, 

mutieren, löschen 2 Z Z 

20303 DP2 Beteiligter löschen 2 Z Z 

20304 DP2 Zuordnung Beteiligter zu 

MISTRA-Objekt erfassen, mutieren, 

löschen 2 Z Z 

20305 DP2 Dokument erfassen, mutieren, 

löschen inkl. Link in Filesystem 2 Z Z 

20306 DP2 Zuordnung Dokument zu 

MISTRA-Objekt erfassen, löschen 2 Z Z 

20307 DP2 Bemerkung erfassen, mutieren, 

löschen 2 Z Z 

20309 LP51 Zugehörigkeit MISTRA-Objekte 


20310 LP51 Aggregation MISTRA-Objekte zu 

Flächen 2 Z 

20400 DP2 Bearbeiten Basisdaten Raumbezug 

20401 DP2 Achse erfassen, mutieren, löschen 

2 Z S 

20402 DP2 Bezugspunkt erfassen, mutieren, 

löschen 2 Z S 

20403 DP2 Geometrie erfassen, mutieren, 

löschen 2 Z 

Version 4.1, 30.09.2005 

56


Nr 

Use Case 

Priorität 

Rich- 

GIS 

Web- 

GIS 

Prozess 

Rich- 

Admin 

Web- System 

Admin 

20404 DP2 Kalibrierungspunkt erfassen, mutieren, 

löschen, kalibrieren 2 Z 

20405 DP2 Transformation UV XY 2 Z 

20406 DP2 Transformation XY UV 2 Z 

20407 DP2 Transformation Km UV 2 Z 

20408 DP2 Transformation UV Km 2 Z 

20500 DP2 Bearbeiten Basisdaten Topologie 

20501 DP2 Knotenorte erfassen, mutieren, 

löschen 2 Z 

20502 DP2 Knoten erfassen, mutieren, löschen 

2 Z S 

20503 DP2 Knotenhierarchie bearbeiten 2 Z 

20504 DP2 Kante erfassen, mutieren, löschen 

2 Z S 

20505 DP2 Abbiegeregel erfassen, mutieren, 


20506 DP2 Topologisches Netz generieren, 

ergänzen 2 Z 

20507 DP2 Anschluss erfassen, mutieren, 


20508 DP2 Zuordnung Knoten zu Anschluss 

erstellen, entfernen 2 Z 

20509 DP2 Topologie aus Objekten erstellen 2 Z 

20510 DP2 Topologie nach Mutationen nachführen 

2 Z 

20600 DP2 Bearbeiten Basisdaten Fachnetze 

20601 DP2 Fachnetz erfassen, mutieren, 


20602 DP2 Kennzahl zu Fachnetz erfassen, 

mutieren, löschen 2 Z S 

20603 DP2 Zuordnung Abschnitte zu Netz 

erfassen 2 Z 

20604 DP2 Zuordnung Abschnitte zu Netz 

entfernen 2 Z 

20605 DP2 Netzabschnitt erfassen, mutieren, 


20606 DP2 Kennzahl zu Netzabschnitt erfassen, 

mutieren, löschen 2 Z S 

20607 LP52 Zugehörigkeit MISTRA-Objekte 

zu Fachnetze 2 Z 

20608 LP52 Aggregation MISTRA-Objekte zu 

Fachnetze 2 Z 

20609 LP52 Verschnitt von Fachnetzen 2 Z 

Version 4.1, 30.09.2005 

57


Nr 

Use Case 

Priorität 

20610 LP52 Knotenbezug erstellen 2 Z 

20611 LP52 Streckenbezug erstellen 2 Z 

20612 LP52 Netzverfolgung 2 Z 

20650 DP3 Bearbeiten Inventarobjekte 

Rich- 

GIS 

20651 DP3 Inventarobjekt erfassen, mutieren, 

löschen 2 Z 

20700 DP Bearbeiten Metadaten 

20701 DP Metadaten erfassen, mutieren, 

löschen 2 Z 

20800 DP4 Bearbeiten PeriNS Daten 

20801 DP4 Projekt erfassen, mutieren, löschen 

2 Z S 

20802 DP4 Zuordnung Projekt zu Inventarobjekt 

erstellen, entfernen 2 Z Z 

20900 DP5 Bearbeiten Generalistendaten 

(temporär) 

20901 DP5 Bauwerk erfassen, mutieren, löschen 

2 Z S 

20902 DP5 Kennzahl zu Bauwerk erfassen, 

mutieren, löschen 2 Z Z 

20903 DP5 Zuordnung Bauwerk zu Inventarobjekt 

erstellen, entfernen 2 Z Z 

25100 DP6 Bearbeiten Spezialistendaten 

Trassen (temporär) 

25101 DP6 Streifen erfassen, mutieren, löschen 

6 O 

25102 DP6 Schichteinbau erfassen, mutieren, 

löschen 6 O 

Web- 

GIS 

25103 DP6 Zustand erfassen, mutieren, löschen 

6 O O 


Verkehrsunfälle (temporär) 

25201 DP6 Unfall erfassen, mutieren, löschen 6 O O 


Verkehrsmonitoring (temporär) 

25301 DP6 Zählstelle erfassen, mutieren, 

löschen 6 O O 

25302 DP6 Verkehr erfassen, mutieren, löschen 

6 O O 


Langsamverkehr (temporär) 

25401 DP6 Weg erfassen, mutieren, löschen 6 O 

25402 DP6 Route erfassen, mutieren, löschen 

6 O 

Prozess 

Rich- 

Admin 

Web- System 

Admin 

Version 4.1, 30.09.2005 

58


Nr 

Use Case 

Priorität 

Rich- 

GIS 

25403 DP6 Signalisation erfassen, mutieren, 

löschen 6 O 

25500 DP6 Bearbeiten Spezialistendaten IVS 

(temporär) 

25501 DP6 IVS-Objekt erfassen, mutieren, 

löschen 6 O 

25502 DP6 Linienobjekt erfassen, mutieren, 

löschen 6 O 

25503 DP6 Punktobjekt erfassen, mutieren, 

löschen 6 O 


Investitions-Controlling (temporär) 

Web- 

GIS 

25601 DP6 Kostenart erfassen, mutieren, 

löschen 6 O 

25602 DP6 Ist-Kosten erfassen, mutieren, 

löschen 6 O 

25700 DP6 Bearbeiten Rapportstrecken, betrieblicher 

Unterhalt (temporär) 

25701 DP6 Rapportstrecke erfassen, mutieren, 

löschen 6 O 

25702 DP6 Werkhof erfassen, mutieren, löschen 

6 O 

25703 DP6 Unterhaltskennzahl erfassen, 

mutieren, löschen 6 O 


Verkehrsinformation (temporär) 

25801 DP6 Verkehrsereignis erfassen, mutieren, 

löschen 6 O 


Erhaltungsmanagement (temporär) 

25901 DP6 Erhaltungsabschnitt erfassen, 

mutieren, löschen 6 O 

25902 DP6 Erhaltungsmassnahmenoption 

erfassen, mutieren, löschen 6 O 

29000 DP Bearbeitungseinheiten, Edit Sessions 

29001 DP Bearbeitungseinheit öffnen, 

schliessen 1 Z Z 

29002 DP Edit Session starten, speichern, 

beenden 1 Z O 

30000 IP Integration Processes 

30100 IP7 Integration GeoDienste Bund 

30101 IP7 WebMap-Service beziehen 1 Z Z 

Prozess 

Rich- 

Admin 

Web- 

Admin 

System 

Version 4.1, 30.09.2005 

59


Nr 

Use Case 

Priorität 

Rich- 

GIS 

30102 IP7 WebMap-Service entfernen 1 Z Z 

30200 IP1 Integration Beteiligte 

Web- 

GIS 

Prozess 

Rich- 

Admin 

Web- 

Admin 

30201 IP1 Neuer / aktualisierte Beteiligte 

importieren (Outlook-Konnektor) 3 Z 

30202 IP1 Importierte Beteiligte validieren 3 Z Z 

30203 IP1 Validierte Beteiligte integrieren 3 Z Z 

30300 IP1-2 Datenintegration via standardisierte 

Schnittstelle (Interlis) 

30301 IP1-2 Daten importieren (Interlis2) 3 Z 

30302 IP1-2 Daten validieren 3 Z S 

30303 IP1-2 Daten übernehmen 3 Z S 

30304 IP1-2 Daten importieren (Interlis1) 6 Z 

30400 IP Extract, Transform, Load ETL 

30405 IP ETL-Konfiguration GIS Internet 

erstellen, ändern 3 O Z 

30406 IP ETL GIS Internet ausführen 3 Z 

40200 FP2 Führung Datenherrschaft 

40201 FP2 Eigentümer ID erstellen 1 O Z 

40202 FP2 Eigentümer ändern, löschen 1 O Z 

40203 FP2 Eigentümer importieren 5 O Z 

40204 FP2 Eigentümer exportieren 5 O Z 

40205 FP2 Dateneigentum ändern 5 O Z 

40206 FP2 Datenherrschaft ändern 5 O Z 

40300 FP4 Führung Benutzer und Zugriffsrechte 

40301 FP4 Benutzer erstellen, mutieren, 

löschen 1 O Z 

40302 FP4 Gruppe erstellen, mutieren, 


40303 FP4 Zugriffsrechte Gruppe verwalten 

1 O Z 

40304 FP4 Zuordnung Benutzer zu Gruppe 

erstellen, entfernen 1 O Z 

40305 FP4 Rolle eintragen, mutieren, löschen 

1 O Z 

40306 FP4 Ausführungsrechte Rolle verwalten 

1 O Z 

40307 FP4 Zuordnung Gruppe zu Rolle 


40400 FP1 Cockpit 

40401 FP1 

SP2 Systemreport erstellen 5 O Z 

System 

Version 4.1, 30.09.2005 

60


Nr 

Use Case 

Priorität 

Rich- 

GIS 

Web- 

GIS 

Prozess 

Rich- 

Admin 

Web- 

Admin 

40402 FP1 

DP8 Datenreport erstellen 5 O Z 

40500 DP7 Prüfen & Reparieren 

40501 DP7 Konsistenz prüfen 5 O Z 

40502 DP7 Inkonsistenzen korrigieren 5 O Z 

40700 SP4 KM Edit Dictionary 

40701 SP4 Flächentypen erfassen, mutieren, 


40702 SP4 Flächentypen importieren 5 O Z 

40703 SP4 Flächentypen exportieren 5 O Z 

40704 SP4 Fachnetztypen erfassen, mutieren, 


40705 SP4 Fachnetztypen importieren 5 O Z 

40706 SP4 Fachnetztypen exportieren 5 O Z 

40707 SP4 Bauwerksarten erfassen, mutieren, 


40708 SP4 Bauwerksarten importieren 5 O Z 

40709 SP4 Bauwerksarten exportieren 5 O Z 

40710 SP4 Katalog erfassen, mutieren, 


40711 SP4 Katalogeintrag erfassen, mutieren, 


40712 SP4 Katalog mit Einträgen importieren 

5 O Z 

40713 SP4 Katalog mit Einträgen exportieren 

5 O Z 

40714 SP4 Kennzahltypen erfassen, mutieren, 


40715 SP4 Kennzahltypen zu Bauwerksarten, 

Flächen- und Fachnetztypen 

zuordnen, entfernen 5 O Z 

40716 SP4 Kennzahltypen importieren 5 O Z 

40717 SP4 Kennzahltypen exportieren 5 O Z 

40718 SP4 Einheiten erfassen, löschen 5 O Z 

40800 SP2 KM Database Management 

40801 SP2 Datenbank-ID generieren 1 O Z 

40802 SP2 Datenbank erfassen, mutieren 


40803 SP2 Datenbank-ID importieren 5 O Z 

40804 SP2 Datenbank-ID exportieren 5 O Z 

40900 SP4 Change Management 

40901 SP4 Change Request erfassen, 5 Z Z 

System 

Version 4.1, 30.09.2005 

61


Nr 

Use Case 

mutieren löschen 

Priorität 

Rich- 

GIS 

Web- 

GIS 

Prozess 

Rich- 

Admin 

40902 SP4 Change Requests sichten 5 Z Z 

Web- 

Admin 

40903 SP4 Change Requests Report 

erstellen 5 Z Z 

41100 SP7 HelpDesk 

41101 SP7 Problem Request erfassen, 

mutieren löschen 5 Z Z 

41102 SP7 Problem Requests sichten 5 Z Z 

41103 SP7 Problem Requests Report 


Z = zwingend, O = Optional, S = nur Sachdaten 

System 

FP = Führungsprozesse; LP = Leistungserstellungsprozesse; DP = Datenbearbeitungsprozesse; IP = Integrationsprozesse; 

SP = Systembetriebsprozesse 

Tabelle 7: UseCases und Zuordnung zu den Clients 

Die Spalte Priorität bezieht sich auf die Iterationen während der Realisierung. 

Die Spalte System enthält die UseCases, welche als Batch-Prozess im Hintergrund ausgeführt 

werden. 

Version 4.1, 30.09.2005 

62


6.1.25 GIS-Basisapplikation 

Das GIS-GUI richtet sich weitgehend nach dem eingesetzten GIS-Fertigprodukt ArcGIS von ESRI 

und ist dort voll zu integrieren. Über diese Oberfläche müssen sämtliche Basisdaten bewirtschaftet 

werden können. Hierfür sind die entsprechenden Funktionen und Sachdatenmasken zu entwickeln. 

Die vom GIS-Fertigprodukt angebotene Grundfunktionalität muss den AnwenderInnen zusätzlich 

uneingeschränkt zur Verfügung stehen. Allerdings darf die Integrität der Sockeldatenbank 

durch den Einsatz von Grundfunktionen nicht gefährdet werden. 

Mit der GIS-Basisapplikation werden primär die Content Processes gemäss [2], zusätzlich aber 

auch die Business und Integration Processes unterstützt. 

Die Funktionalitäten des GIS-GUI verteilen sich auf den Rich-GIS- und den Web-GIS-Client. 

Tabelle 7 in Abschnitt 6.1.24 gibt Auskunft über die Aufteilung. Für nicht UseCase-bezogene E- 

lemente werden die Angaben in der folgenden Liste ergänzt (R+W = Rich + Web). 

Wichtige Elemente des GIS-GUI sind: 

1. Authentisierung (automatisch über LDAP) 

2. Automatische Erstellung von Legenden auf der Basis des Datenkatalogs [3] (R+W) 

Diese Funktion soll es ermöglichen aus einer Auswahl von Themen die gewünschte Legende 

mit den gewünschten Ebeneneinstellungen zu laden. Diese Legendeneinstellungen werden 

als Konfigurationsdateien (z.B. .mxd) im Filesystem gespeichert. Es muss möglich sein Benutzerseitig 

neue Legenden zu definieren und dem Legenden-Lader zugänglich zu machen. 

Beim Laden einer Legende muss auch die Anordnung der Fenster, der Menüs und Symbolleisten 

auf einen definierten Default zurückgestellt werden. 

3. Ergänzende Menüs und Symbolleisten zum Starten der Spezialfunktionen MISTRA (R+W) 

4. Verwaltung von Hintergrundraster für die verschiedenen Kartenwerke (R+W). 

Das ASTRA wird das Hintergrundkartenwerk (Rasterkarten, VECTOR25/200, Luftbilder usw.) 

als WebMap-Service von den Geo Services Bund beziehen. 

5. Navigationshilfsmittel (R+W) für rasche Suche, Positionierung, Zoom, Pan nach: 

a. Kanton, Strasse, Unterhaltsabschnitt 

b. Strasse, Kilometer von/bis 

c. Kanton, Werkhof, Rapportstrecke 

d. Kanton, Inventarobjektname (Volltextsuche) 

e. LK-Blatt 

f. Gemeinde 

Bei der Auswahl eines ersten Suchbegriffes (z.B. Kanton) wird die Auswahl des nächsten 

Suchbegriffes (z.B. Strasse) automatisch auf die verfügbaren Elemente eingeschränkt. 

Die Suchbegriffe müssen nach hinten nicht zwingend vollständig ausgefüllt werden. Will man 

nur auf den Kanton zoomen, reicht es in der ersten Auswahl den Kanton einzugeben und 

dann den Zoom-Befehl einzugeben. 

Version 4.1, 30.09.2005 

63


6. Treeview mit verschiedenen Hierarchien (R+W) 

a. Kanton, Nationalstrasse, Unterhaltsabschnitt, Inventarobjekt 

b. Kanton, Werkhof, Rapportstrecke 

c. Achse, Bezugspunkt 

d. Fachnetztyp, Fachnetz (hierarchisch), Abschnitt 

e. Projekt, Inventarobjekt 

f. Nationalstrasse, Anschluss 

Ausgehend vom Treeview müssen verschiedene Funktionen gestartet werden können: 

a. Zoom auf selektierten Teilbaum oder MISTRA-Objekt 

b. Selektieren von Elementen im Treeview (Teilbäume oder MISTRA-Objekte) 

c. Hinzufügen zur Selektionsmenge oder Entfernen 

d. Anzeige der Sachdaten zum angewählten MISTRA-Objekt. 

Die Veränderung des Kartenausschnitts und der Bildaufbau im Kartenfenster erfolgt nicht implizit 

durch Anklicken im Baum, sondern nur explizit durch Klick auf ein entsprechendes Icon 

in der Funktionsleiste des Treeview (Minimierung der Bild-Refresh). 

7. Editierfunktionen (R+W) 

a. Öffnen und schliessen einer Bearbeitungseinheit 

b. Starten, Beenden, Speichern, Verwerfen von Edit Sessions 

Sämtliche Mutationen werden innerhalb Edit Session durchgeführt. Edit Sessions müssen 

innerhalb einer Sitzung beendet werden. Edit Sessions erlauben es den BenutzerInnen 

versehentliche Änderungen rückgängig zu machen. 

c. Erstellen neuer MISTRA-Objekte: 

- Automatische Voreinstellung der Ebene, Fangparameter, selektierbare Ebenen usw. 

- Automatische Bestimmung der räumlichen Bezüge wo erforderlich (z.B. Kantonszugehörigkeit, 

Landes- und RBBS-Koordinaten, Zuordnung zu Unterhaltsabschnitten 

usw.). Bei nicht-Eindeutigkeit muss der/die AnwenderIn korrigierend eingreifen können. 

- Automatische Vervollständigung der Daten des Raumbezugs mit planaren und soweit 

vorgesehen linearen Koordinaten. 

- Bei der Erstellung von Geoobjekten wird immer zuerst der Sachsatz angelegt, dann 

die zugehörige Geometrie erfasst. 

- Die Erfassung der Geometrie kann auch zu einem späteren Zeitpunkt erfolgen. Das 

MISTRA-Objekt bleibt über den Treeview und über die Attribut-Tabelle zugreifbar. 

d. MISTRA-Objekte mutieren (R+W) 

- Mutieren der Geometrie mit Standardfunktionen des GIS 

- Mutieren der Sachdaten über den Property Grid MISTRA 

- Automatische Erstellung History wo erforderlich (s. Datenkatalog [3]) 

- Es müssen auch mehrere selektierte MISTRA-Objekte auf einmal mutiert werden können 

(Massenattributierung) 

e. MISTRA-Objekte löschen (u.a. über Delete-Taste) (R+W) 

- Löschen u.a. auch über Delete-Taste ermöglichen 

- Auch auf Mehrfachselektionen anwendbar 

- Warnung vor Löschung (trotz Edit Session) 

Version 4.1, 30.09.2005 

64


- Automatische Erstellung History 

8. Sachdatenmasken als Property Grid (vgl. auch 6.1.23 für MISTRA-Objektklassen (R+W) mit: 

a. Das Property Grid zeigt die Attribute des gerade angewählten MISTRA-Objektes an. 

b. Texte in Masken sprachgesteuert (Titel, Labels, Auswahllisten, Meldungen) 

c. Automatischer Bezug von Attributen anderer Objektklassen über Fremdschlüssel 

z.B. Angabe zur Achse in der Maske Bezugspunkte 

d. Dynamische Voreinstellung sinnvoller Defaultwerte bei neuen MISTRA-Objekten 

e. Combos für Auswahllisten (gefüllt ab Textkatalogen) mit Auswahl über Bezeichnungen 

(Codes werden gespeichert, der Anwender sieht aber die Bezeichnungen). 

f. Plausibilitätskontrollen bei der Eingabe 

g. Spezialregister oder Formular für die Eingabe von Beteiligten, Dokumenten, Bemerkungen 

und Kennzahlen (letztere bei Flächen, Bauwerken, Fachnetzen). 

h. Spezialregister oder Formular für die Anzeige des zugehörigen Metadatensatzes 

9. Bewirtschaftung von Metadaten (R+W) 

a. Formulare für das Anlegen eines neuen Metadatensatzes auf Stufe Instanz, Thema oder 

Objektklasse (Metadatenhierarchie). 

b. Erfassen von Daten zu Bearbeitungseinheiten 

c. Formulare für die Bewirtschaftung der Metadaten (ändern, löschen) 

10. Neuberechnung Raumbezüge (R+W) 

Die MISTRA-Objekte enthalten Raumbezüge unterschiedlichster Art und speichern diese in 

der Regel in Form von Fremdschlüsseln ab. Beispiele solcher Raumbezüge sind RBBS- 

Koordinaten, lineare Koordinaten, TMC Location Code, Zuordnung zu einem Unterhaltsabschnitt, 

Kantons- / Gemeindezugehörigkeit usw. Die Belegung der Fremdschlüssel erfolgt wo 

erforderlich automatisch mit der Objekterfassung. Die Basisdaten können jedoch ändern, ohne 

dass die MISTRA-Objekte selbst in ihrer Lage Veränderungen erfahren. Aus diesem Grund 

müssen diese Raumbezüge nachgerechnet werden können. Bei nicht-Eindeutigkeit muss 

der/die AnwenderIn korrigierend eingreifen können. Diese Nachrechnung muss die folgenden 

Anforderungen erfüllen: 

a. Jede Nachrechnung muss innerhalb einer Edit Session erfolgen 

b. Der Basisdatentyp des nachzurechnenden Raumbezuges muss selektiert werden können, 

z.B. RBBS, Kantonszugehörigkeit 

c. Die Nachrechnung muss wahlweise angewendet werden können auf ein Einzelobjekt, einer 

selektierten Menge von MISTRA-Objekten einer Objektklasse (s. Kap. 6.1.22) oder auf 

alle Objekte einer Objektklasse. 

11. Weitere Funktionen (R+W) 

a. Umrechnung des Raumbezuges vom planaren auf das lineare Bezugssystem und umgekehrt 

auf der Basis der Referenzgeometrie (als Basisfunktion). Wichtige Hinweise für die 

Umrechnung sind in [7] zu finden. Erhobene Daten, gemäss Feld Bestimmungsart im Datenkatalog/Raumbezug, 

dürfen jedoch nicht durch einen Automatismus überschrieben 

werden. 

12. Benutzerführung 

a. Hilfe-Datei kontext sensitiv (R+W) 

Version 4.1, 30.09.2005 

65


b. Direkthilfe-Funktion (R+W) 

c. Alle Icons und Maskenfelder mit Tooltip-Texten (R) 

d. Benutzer in Statuszeile über erwartete Aktivitäten informieren (R) 

e. Bei Systemaktivitäten konsequent Sanduhr anzeigen (R+W) 

f. Prompts, Fehlermeldungen, Status-Informationen usw. sprachabhängig (R+W) 

13. Karte erstellen (R+W) 

a. Auswahlmaske für Kartenvorlage, Nordpfeil, Massstab, Legende, Titel, Plannummer, Koordinatengitter, 

darzustellende Basis- und Fachdaten, Beschriftungsoptionen 

b. Interaktive Positionierung des gewünschten Ausschnittes in der Kartensicht inkl. Rotation. 

c. Vorlagen für verschiedene Kartenformate 

d. Nicht nordorientierte (schräge) Kartenausrichtungen müssen möglich sein 

e. Auswahl des Druckers bzw. Plotters. 

f. Die Kartenvorlagen müssen einfach in A4-Schritten vergrössert bzw. verkleinert werden 

können. 

g. Bei den Karten sind pro Ebene die Genauigkeit und das Datum der letzten Nachführung 

gemäss Angaben in den Metadaten an zu geben. 

h. Das verwendete Layout und die Symbologie sind im System Design zu spezifizieren. 

15. Abfragen, Reports und thematische Karten im WebGIS (W) 

Folgende Abfragen sind vor zu definieren. 

Die Auswahlparameter müssen vom Benutzer angegeben werden können. 

a. Liste von Inventarobjekten nach NS, Kanton, UH-Abschnitt 

als Tabelle 

b. Liste von Bauwerken nach NS, Kanton, UH-Abschnitt 

mit Auswählbaren Kennzahlen aus Kennzahltabelle 

als Tabelle 

c. Liste von Abschnitten von Fachnetzen nach NS, Kanton 

mit Auswählbaren Kennzahlen aus Kennzahltabelle 

als Tabelle 

d. Zustand der Fahrbahn nach NS, Kanton, UH-Abschnitt zu einem wählbaren Zeitpunkt 

Auswahl des Zustandsparameters aus Kennzahltabelle 

als Tabelle und thematische Karte 

e. Veränderung des Zustands von Fahrbahnen nach NS, Kanton, UH-Abschnitt in einem 

wählbaren Zeitabschnitt, Auswahl des Zustandsparameters aus Kennzahltabelle 


f. Zustand der Kunstbauten nach NS, Kanton, UH-Abschnitt zu einem wählbaren Zeitpunkt 

Auswahl des Zustandsparameters aus Kennzahltabelle 


g. Veränderung des Zustands von Kunstbauten nach NS, Kanton, UH-Abschnitt in einem 

wählbaren Zeitabschnitt, Auswahl des Zustandsparameters aus Kennzahltabelle 


Version 4.1, 30.09.2005 

66


h. Verkehrsaufkommen pro Zählstelle nach NS zu einem wählbaren Zeitpunkt 

Auswahl des Verkehrsparameters aus Kennzahltabelle 


i. Veränderung des Verkehrsaufkommens pro Zählstelle nach NS in einem wählbaren Zeitintervall. 



j. Verkehrsaufkommen pro Verkehrsabschnitt nach NS zu einem wählbaren Zeitpunkt 



k. Veränderung des Verkehrsaufkommens pro Verkehrsabschnitt nach NS in einem wählbaren 

Zeitintervall. Auswahl des Verkehrsparameters aus Kennzahltabelle 


l. Unfallhäufigkeit pro Unfallabschnitt nach NS in einem wählbaren Kalenderjahr 



m. Veränderung der Unfallhäufigkeit pro Unfallabschnitt nach NS, zwischen 2 Kalenderjahren 



n. Stauhäufigkeit pro Stauabschnitt nach NS in einem wählbaren Kalenderjahr 

Auswahl des Stauparameters aus Kennzahltabelle 


o. Veränderung der Stauhäufigkeit pro Stauabschnitt nach NS, zwischen 2 Kalenderjahren 

Auswahl des Stauparameters aus Kennzahltabelle 


Version 4.1, 30.09.2005 

67


6.1.26 Administrationsapplikation 

Die Administrationsapplikation ist grösstenteils als Web-Anwendung zu realisieren. Einzelne, 

stark raumbezogene UseCases können im Rich-Client implementiert werden. 

Die Applikation umfasst: 

1. Verwaltung von Benutzern, Gruppen und Zugriffsrechten 

2. Verwaltung von Rollen und Ausführungsrechten 

3. Bewirtschaftung der Textkataloge und Kennzahlenkataloge mehrsprachig 

4. Importe und Exporte (Interlis2), automatisierbar als Batch-Job via Scheduler 

5. Publikations-Schnittstelle ETL-Geodaten zur Internet-Web-Applikation (Interlis2) 

6. ETL-Prozesse ins DWH Intranet und Internet 

7. Funktionen zur Überprüfung der Konsistenz der Daten sowie Reparaturfunktionen 

8. Sichten und auswerten der History, ggf. Löschfunktionen für nicht mehr benötigte Daten. 

9. Erfassen, Sichten und Auswerten von Log-Einträgen. 

Von diversen Vorgängen müssen Log-Einträge abgelegt werden. Solche Vorgänge sind: 

Öffnen und Schliessen von Schreib-Sessions (User-Logins/Logouts), Datenimporte, und – 

exporte, Publikationen ins Web, Veränderungen und Erweiterungen der Datenstrukturen der 

Sockeldatenbank. Ein Grossteil der Log-Einträge wird automatisch erfasst. 

Die UseCases sind in [4] beschrieben. 

Version 4.1, 30.09.2005 

68


6.1.27 Applikation Achsband 

Mit Achsbanddarstellungen können Strassendaten in Form von Längs- und Querprofilen dargestellt 

werden. Diese Darstellungsart ist vor allem für die Strassenfachleute von Bedeutung. Im 

STRADA-Leitfaden [9] Kap. 2 ist das Prinzip der Achsbanddarstellung kurz dargestellt. 

Das Applikation Achsband muss als eigenständige Web-Applikation direkt mit der Sockeldatenbank 

kommunizieren. Die Datenquellen und Darstellungen müssen parametrisierbar sein. Die 

Achsband-Applikation besteht aus zwei Teilen: 

1. Achsbandefinition: Einem Teil, in dem die einzelnen Achsbänder definiert werden können. 

Dieser Teil richtet sich an erfahrene Benutzer, z.B. den Datenmanager. 

• Definition der Datenquelle (Objektklasse, Fachnetz) 

z.B. Index I1 des Strassenzustands aus dem Fachnetz mit aggregierten Indizes 

• Breite des Bandes in mm und Zuordnung des darzustellenden Wertebereiches 

z.B. 20 mm für die Darstellung von Indexwerten zwischen 0 und 5 linear 

• Darstellungsart (Punkt, Linie mit/ohne Pfeilspitzen, Histogramm mit seitlicher Skala) 

z.B. Darstellung als Fläche (Histogramm) mit schwarzer Umrandung 

• Symbologie der Darstellung (Symbole, Line-Styles, Flächenfüllung) 

z.B. Flächenfüllung vollflächig 

• Beschriftung der Bezeichnung des Achsbandes fest und variabel aus Attribut 

z.B. fester Teil "Zustand Deckbelag: ", variabler Teil "Messdatum" 

• Beschriftungen fest seitlich (Skala) und im Band mit Positionsangabe 

z.B. Skala der Indizes von 0 bis 5, beidseitig links und rechts 

• Beschriftung von Attributwerten (variabel) im Band mit Positionsangabe 

z.B. Indexwert als Zahl unten 

• Farben von Symbole (Outline und Füllung), Linien, Flächen (Outline und Füllung) fest oder 

in Abhängigkeit von Attributwerten. 

z.B. Farbe variabel je nach Indexwert gemäss Farbskala xxx 

• Bezeichnung der Achsbanddefinition 

z.B. "Index I1 aggregiert 20 mm" 

2. Plandefinition: Einem Teil in dem Achsbandarstellungen erstellt werden können und welcher 

Achsbanddefinitionen des ersten Teiles verwendet. 

Dabei muss der Benutzer folgende Eingabemöglichkeiten haben: 

• Grösse des Planes (Länge x Höhe in mm) 

z.B. 1050 x 420 mm 

• Massstab in Längsrichtung 

z.B. 50'000 

• Position des Planspiegels 

z.B. unten links 

Version 4.1, 30.09.2005 

69


• Titel des Planes 

z.B. "Entwicklung des Zustands des Deckbelages der A1 von 2000 bis 2004) 

• Organisation, Ersteller, Datum, Massstab 

z.B. "Bundesamt für Strassen ASTRA", "H. Muster", 30. April 2005 (Default heute), 

1:50'000 (automatisch) 

• Auswahl der darzustellenden Achse und Achsposition (Achse Nr., Km am Anfang) 

z.B. "A1", Startpunkt bei Km 25.0 

• Auswahl der darzustellenden Achsbänder mit Angabe des darzustellenden Zeitraums 

z.B. "Index I1 aggregiert 20 mm", Zeitraum "2000" 

"Index I1 aggregiert 20 mm", Zeitraum "2002" 

"Index I1 aggregiert 20 mm", Zeitraum "2004" 

Weitere Anforderungen sind: 

1. Als oberstes Band wird immer die abgewickelte Achse mit den Bezugspunkten dargestellt. 

2. Die einzelnen Achsbanddefinitionen und die Plandefinitionen müssen in der Datenbank oder 

als XML abgespeichert werden können. 

Version 4.1, 30.09.2005 

70


6.1.28 Mehrsprachigkeit 

Die konkreten Anforderungen an die Mehrsprachigkeit sind: 

1. Auslegung auf beliebig viele Sprachen 

2. Mit der ersten Realisierungseinheit ist eine vollständige französisch-, deutsch- und italienischsprachige 

Version zu implementieren. 

3. Die Sprachvariabilität bezieht sich auf alle Texte, namentlich auf Legende, Menüs, Icons, 

Titel und Label in Formularen, Tooltip-Texte, Texte aus Katalogen und Auswahllisten, Online-Hilfe, 

Meldungen aus dem Programm (Fehler, Status usw.) 

4. Nicht sprachvariabel sind vom Benutzer frei eingegebene Attributwerte wie Namen, Bemerkungen 

usw. 

5. Die Sprachanforderungen der Dokumentation sind in 6.1.30 beschrieben. 

6. Die Gestaltung der Datenstrukturen für mehrsprachige Datenkataloge und Auswahllisten ist 

im Datenkatalog [3] beschrieben. 

7. Die Wahl der Sprache wird in der Systemkonfiguration von Windows festgelegt. Es ist keine 

Umschaltung während der Bearbeitung durch den Benutzer erforderlich. 

8. Die Sprachumschaltung der Fertigprodukte und den für MISTRA entwickelten Modulen darf 

unabhängig erfolgen. 

6.1.29 Sicherheit 

Die Anforderungen betreffend Sicherheit sind: 

Vertraulichkeit 

Integrität 

Die Sockeldatenbank MISTRA enthält keine Daten welche besondere 

Vorkehrungen betreffend Datenschutz erfordern. 

Die Sockeldatenbank wird ausschliesslich im Intranet (Bundesnetz 

KOMBV) betrieben. Durchgriffe aus der DMZ oder von extern (Internet) 

sind zu unterbinden. Der Zugriff auf die Sockeldatenbank ist 

durch Username und Passwort zu schützen. 

Die Integrität der Daten muss durch geeignete Massnahmen zu 

Laufzeit sichergestellt werden durch: 

1. In erster Linie durch Anwendung der referenziellen Integrität in 

den Datenstrukturen. 

2. Applikatorisch durch Überprüfung der Konsistenzbedingungen 

3. Applikatorisch durch unmittelbare Nachrechnung kontrollierter 

Redundanzen nach Mutationen, z.B. duale Koordinatenhaltung 

linear/planar, abgeleitete Attribute 

Die Integrität der Daten muss durch Kontrollfunktionen überprüft und 

protokolliert sowie im Fehlerfall durch Reparaturfunktionen ohne Datenverlust 

wieder hergestellt werden können (s. UseCases Administ- 

Version 4.1, 30.09.2005 

71


ration in 6.1.24). 

Bei Datenverlusten muss der Datenbestand des letzten abgeschlossenen 

Arbeitstages wieder hergestellt werden können. 

Verfügbarkeit 

Zugriffskontrolle 

Authentisierung 

Tätigkeitsnachweis 

Notfallplanung 

Die geforderte Verfügbarkeit der einzelnen Systemkomponenten ist 

in Kap. 6.1.10 beschrieben. 

Der Zugriff auf alle Daten muss klar geregelt werden können. Die 

Anforderungen sind in Kap. 6.1.11 und 6.1.12 beschrieben. 

Die Anforderungen an die Authentisierung sind in Kap. 6.1.11 beschrieben. 

Zu jeder Veränderung der Daten muss das Datum der Mutation und 

der Benutzername der Person, welche die Mutation ausgeführt hat, 

geführt werden. 

Basisdaten, welche von anderen Basis- oder Fachdaten referenziert 

werden, müssen historisiert werden. 

Batch- oder Hintergrundprozesse müssen Ergebnisse und Fehler 

grundsätzlich in LOG-Dateien protokollieren. 

Bei Notfällen muss der Datenbestand vom letzten vollständigen Arbeitstag 

wieder hergestellt werden können. Die Wiederherstellung 

muss innert 4 Stunden möglich sein. 

Version 4.1, 30.09.2005 

72


6.1.30 Dokumentation 

In der Phase Realisierung und Einführung werden die Dokumente gemäss Hermes [1] benötigt, 

insbesondere: 

1. Systemdesign deutsch oder französisch (nicht gemischtsprachig) mit 

• Systemarchitektur (funktional, logisch, physisch) 

• Systemintegrationsplan 

• Logisches Datenmodell mit Tabellen- und Attributbeschreibungen 

• Applikationsbeschreibungen und Anwendungsfälle der Applikationen 

• GUI-Layoutkonzept 

• Service-Interface / Web-Services: Beschreibung von Funktion und Interface 

• Schnittstellen Import, Export, Migration 

• Benutzerverwaltung, Zugriffsrechte, Sicherheit 

• Weitere für vollständige Dokumentation des Systems inkl. Teilsysteme notwendigen Ergänzungen 

• Index 

2. Betriebshandbuch deutsch, französisch, italienisch (Option) mit 

• Technische Struktur des Systems 

• Voraussetzungen 

• Installation, Konfiguration 

• Betriebsaufnahme, -unterbruch, -beendigung 

• Beschreibung aller administrationsseitigen Anwendungsfälle inkl. Screenprints 

• Erforderliche Überwachungsmassnahmen 

• Hinweise Optimierung des Systembetriebs 

• Mögliche systemseitigen Fehler mit Fehlernummer, -beschreibung, -massnahmen 

• Verwaltung von Gruppen, Rollen, BenutzerInnen, Zugriffs- und Ausführungsrechte 

• Datensicherung, -wiederherstellung 

• Weitere für den ordnungsgemässen Betrieb notwendigen Ergänzungen 

• Index 

3. Supporthandbuch deutsch, französisch, italienisch (Option) mit 

• Beschreibung Systemaufbau, Komponenten, Schnittstellen 

• Ziele und Hauptfunktionen der Applikationen 

• Mögliche anwendungsseitige Fehler mit Fehlernummer, -beschreibung, -massnahmen 

• Weitere für den ordnungsgemässen Support notwendigen Ergänzungen 

• Index 

4. Anwendungshandbuch pro Applikation (GIS, Achsband, Admin) deutsch, französisch, italienisch 

(Option) mit: 

• Beschreibung Systemaufbau und Applikationen mit Hauptfunktionen 

• Beschreibung aller anwenderseitigen Anwendungsfälle inkl. Screenprints 

• Mögliche Fehlerfälle mit Fehlernummer, -beschreibung, -massnahmen 

• Technische Erläuterungen: Datenstrukturen und Algorithmen 

• Index 

Version 4.1, 30.09.2005 

73


5. Quick Reference Guide pro Applikation deutsch, französisch, italienisch, englisch mit einer 

Kurzbeschreibung für die Anwender und Anwenderinnen auf maximal vier Seiten A4. 

6. Produktübersicht MISTRA deutsch, französisch, italienisch, englisch 

7. Schulungsunterlagen pro Kurstyp mit Übungsbeispielen deutsch und französisch. 

8. Online-Help pro Applikation und Plattform deutsch und französisch kontextsensitiv 

Die Dokumentationen (ausser Online-Help) sind als Word- und als PDF-Datei abzugeben. 

6.1.31 Leistungsanforderungen, Antwortzeiten 

Die nachfolgenden Leistungsanforderungen beziehen sich auf eine Systemumgebung unter geringen 

bis normalen Lastbedingungen. Sie müssen in der Umgebung des Herstellers nachgewiesen 

werden, sofern diese in Bezug auf Technologie und Leistung derjenigen des ASTRA weitgehend 

entspricht. 

1. Multiuserbetrieb (gilt nicht für Low-End Einplatzsysteme) 

• Lesender Zugriff durch eine beliebige Anzahl Benutzer 

• Schreibender Zugriff mehrerer Benutzer auf Objekte einer Objektklasse 

2. Verfügbarkeit 

• S. Abschnitt 6.1.10 

• Datensicherung bei laufendem Betrieb (ausser bei Einplatzsystemen) 

3. Antwortzeiten RichGIS-Applikation und Rich-Admin 

• Starten der Applikation inkl. Authentisierung: < 60 Sekunden 

• Beenden der Applikation: < 30 Sekunden 

• Bildschirmaufbau nach Zoom-In, Pan: < 3 Sekunden 

• Bildschirmaufbau nach Zoom-Out: < 5 Sekunden 

• Keine unnötigen Bildschirm-Refresh 

• Start Erstellung eines neuen MISTRA-Objekts: < 1 Sekunde 

• Erstmaliges Öffnen einer Sachdatenmaske: < 3 Sekunden 

• Wiederholtes Öffnen einer Sachdatenmaske: < 1 Sekunde 

• Erstmaliges Speichern einer Mutation: < 3 Sekunde 

• Wiederholtes Speichern einer Mutation: < 1 Sekunde 

4. Antwortzeiten Web-GIS 


• Bildschirmaufbau nach Zoom, Pan: < 5 Sekunden 

• Keine unnötigen Bildschirm-Refresh 





5. Antwortzeiten Administrations-Applikation Rich- und WebAdmin 


Version 4.1, 30.09.2005 

74


• Start Erstellung eines neuen MISTRA-Objekts: < 1 Sekunde 





6.2 Basissystem – Anforderungen Einführung ASTRA 

6.2.1 Einführungskonzept 

Im Rahmen der Einführung ist für das ASTRA ein Einführungskonzept nach Hermes [1] zu erstellen, 

mit: 

1. Beschreibung der Einführungsorganisation und Abläufe bei der Einführung 

2. Inbetriebnahme des Basissystems MISTRA 

• Textkataloge 

• Bauwerksarten, Flächen- und Fachnetztypen und deren Kennzahlen 

• Eigentümer, Datenbanken, Fachapplikationen 

3. Vorgehen bei der Integration vom bisherigen zum neuen System 

• Parallelbetrieb 

• Integration von Objektinventar und Bauwerke aus UH-PERI 

• Integration von Achsen, Bezugspunkte, Geometrien, Netze (Topo- und Geonetze), Joker, 

Verkehr aus STRADA 

• Ausserbetriebnahme des alten Systems 

4. Vorgehen Bereitstellung von Basisdaten 

• Rasterhintergrund (PK25, PK100, PK200, PK500, PK1000, Luftbilder usw.) 

• Einrichten Flächennetze 

• Einrichten von Fachnetzen (Geschwindigkeitsabschnitte, Strassenkategorien usw.) 

5. Mittelbedarf 

6. Information 

7. Ausbildungskonzept (s. 6.2.4) 

6.2.2 Systemabnahme 

Die Systemabnahme erfolgt mehrstufig (vgl Terminplan 9.1.2): 

1. Teilabnahmen nach jeder Iteration 

2. Gesamtabnahme der Software 

3. Abnahme des produktiven Systems ASTRA 

Die Abnahmen erfolgen auf den Systemen des ASTRA. Bei allen Abnahmen sind Vertreter des 

ASTRA anwesend. Die Abnahmen beziehen sich auf das Funktionieren der Softwarekomponenten 

und den Systembetrieb. Die Dokumentation wird in Rahmen von separaten Reviews geprüft. 

Version 4.1, 30.09.2005 

75


Die genaue Organisation und Inhalt der Abnahme sind im Testplan gemäss Kap. 9.2 zu beschreiben. 

6.2.3 Installation 

Für jede der Applikationen sowie der eingesetzten Fertigprodukte ist ein separates Setup-Skript 

zur erstellen. Diese Skripts müssen alle Installationsschritte umfassen. Manuelle Installation von 

Dateien und die manuelle Anpassungen von Konfigurationsdateien sind nicht zulässig. 

Das Installationsprozedere ist im Betriebshandbuch vollständig zu beschreiben. 

Umfang der Installationsarbeiten: 

1. Testinstallationen beim ASTRA; je für die 6 Iterationen (2 Clients). 

2. Installation für Abnahme Gesamtsoftware beim ASTRA (Server + 2 Clients) 

3. Installation Produktionsumgebung des ASTRA (DB-Server, ArcSDE-Server, Server-Module 

Basissystem, 2 Rich-GIS-Clients 

6.2.4 Schulung 

Im Rahmen der Einführung ist ein Ausbildungskonzept nach Hermes [1] zu erstellen, mit: 

1. Beschreibung der Ausbildungsorganisation 

2. Beschreibung der Ausbildungsanforderungen 

3. Beschreibung des Ausbildungsangebots (Kursbeschreibung, Lernziele, Zielpublikum) 


5. Auswertungen 

Schulungsangebot je in deutsch und französisch: 

1. Einführung ArcGIS-Desktop für MISTRA (2 Tage) 

2. Operateure Basissystem (2 Tage) 

3. Abfragen und Nutzung über WebGIS (3 Std) 

4. Administratoren Basissystem (3 Tage) 

6.3 Basissytem - Anforderungen Betrieb 

6.3.1 Konfigurationsmanagement 

Das Konfigurationsmanagement ist in der Betriebsphase mit jedem Software-Release nach zu 

führen. 

Version 4.1, 30.09.2005 

76


6.3.2 Wartung 

6.3.2.1 Changemanagement 

Die Changemeldungen werden als CM systematisch erfasst und bis zum Abschluss verwaltet. 

Die CM werden 1 mal im Monat mit den Vertretern des ASTRA (Geschäftstelle MISTRA) besprochen 

und über deren weitere Bearbeitung entschieden. 

Für die Behandlung des Changemanagement ist eine Web-Plattform bereit zu stellen, auf welche 

alle mit der Wartung betrauten Personen (Wartungsorganisation, MISTRA-Leiter, Super-User) 

Zugriff haben. Die Anforderungen an die Web-Plattform sind: 

1. Betrieb über Internet 

2. Authentisierung mit benutzerspezifischem Username und Passwort 

3. Maske für die Erfassung von Changemeldungen CM mit: 

ID, Titel, Problemmelder, betroffenes Modul, Beschreibung, Fehler oder CR, Dringlichkeit, 

Wunschtermin usw. 

4. Maske für weitere Behandlung der CM 

Bearbeitungsstatus, Lösungsvorschlag, geschätzter Aufwand und Kosten, Datum Problemlösung, 

Kommentare, verknüpfte Dokumente Release für Freigabe usw. 

5. Möglichkeit den CM Anlagen bei zu heften 

6. Zugriffrechte auf Felder differenziert nach Rolle 

7. Erstellung von CM-Reports: Report Übersicht und Report CM-Details 

6.3.2.2 Option Wartung Basissoftware 

Für die Wartung der Basissoftware (Oracle, ESRI usw.) ist ein Lizenzvertrag zwischen dem 

ASTRA und den Kantonen und den Herstellern abzuschliessen. (Als Option zu offerieren). 

6.3.2.3 Wartung der entwickelten Module 

Für die Wartung der für MISTRA entwickelten Komponenten wird ein Wartungsvertrag mit einer 

Zeitdauer von 5 Jahren abgeschlossen. Dieser beinhaltet: 

1. Grundwartung (ausserhalb des CM-Verfahrens): 

• Vorhalten von qualifiziertem Personal 

• Vorhalten der Entwicklungsumgebung 

• Verwaltung und Pflege des Programmcodes und Versionierung 

• Vorbeugende Massnahmen bei Konflikten mit Hardware und Betriebssystemen 

• Kleinere Anpassungen an neue Versionen von Betriebssystemen, Datenbanken und GIS- 

Basis-Software 

• Kleinere Fehlerkorrekturen und Programmanpassungen 

• Kleinere Anpassungen an der Dokumentation 

Die Grundwartung wird als Pauschale pro Jahr, zahlbar monatlich, abgegolten. 

Version 4.1, 30.09.2005 

77


2. Hauptwartung: Diese wird im Rahmen des Change-Managements budgetiert und abgewickelt. 

Die Verrechnung erfolgt monatlich zu den im CM-Verfahren ermittelten Kosten. 

6.3.2.4 Nachführung der Dokumentation 

Die Dokumentation gemäss Kap. 6.1.30 ist laufend der Entwicklung des Produkts anzupassen. 

Die Aufwändungen werden über die Wartung abgegolten. 

6.3.3 Release Management 

Die Releaseplanung ist so auszuführen, dass wichtige Neuerungen in Major Releases ca. alle 1 

bis 2 Jahre erscheinen, während zwischen-Versionen ca. alle 6 bis 12 Monate verteilt werden. 

Für Fehlerkorrekturen sind Patches über die Website MISTRA bereit zu stellen. 

Das Change Management dient als Input in die Release-Planung. In diesem Geschäftsprozess 

werden die anstehenden Änderungen und Erweiterungen am Basissystem koordiniert und ein 

Terminplan für die Berücksichtigung der einzelnen CM erstellt. 

Die Versionierung der Software ist eine wichtige Voraussetzung für das Release Management. 

Dementsprechend sind Hilfsmittel für das Versionenmanagement und die Verwaltung des Quellcodes 

zu verwenden. Es muss sichergestellt sein, dass die letzten zwei Major Releases von 

MISTRA unterstützt und gewartet werden können. 

6.3.4 Support (Problem Management) 

6.3.4.1 Vorhalten eines HelpDesk 

Der Support-HelpDesk muss folgende Anforderungen erfüllen: 

1. Zweisprachig deutsch und französisch 

2. Erreichbarkeit Montag bis Freitag 8:00 bis 18:00 Uhr 

3. Nach Eingang der Anfrage erhält der Anfrager eine Bestätigung der Problemmeldung des 

Trouble-Tickets per E-Mail 

4. Reaktionszeit maximal 4 Stunden. In dieser Zeit muss die Problemlösung durch eine kompetente 

Person in Angriff genommen werden. 

5. Problemlösungszeit einfacher und mittlerer Probleme durch Second Level Support maximal 2 

Arbeitstage 

6.3.4.2 Option: First Level Support 

Beim First Level Support erfolgen die Anfragen direkt durch die MISTRA-Benutzer. Dieser Support 

wird im Normalfall intern durch Super-User und Administratoren beim Auftraggeber abgedeckt 

und ist nicht Bestandteil der Leistungen des Auftragnehmers. 

Version 4.1, 30.09.2005 

78


6.3.4.3 Second Level Support 

Kann der First Level Support die Anfrage nicht lösen, wird er durch den First Level Support an 

den Second Level Support weitergeleitet. Die Anfragen erfolgen ausschliesslich durch die für den 

First Level Support verantwortlichen Personen (Super-User). Der Second Level Support ist immer 

Bestandteil des Leistungsumfangs des Auftragnehmers. 

6.3.4.4 Third Level Support 

Die Anfragen an den Third Level Support erfolgen grundsätzlich über den Second Level Support 

des Auftragnehmers. Der Third Level Support umfasst die weitergehende Unterstützung durch 

die Hersteller von Basissoftware. 

Version 4.1, 30.09.2005 

79


7 Datenintegration 

Eine umfassende Beschreibung der Datenintegration ist in [6] enthalten. Die im Rahmen der Realisierung 

des Basissystems auszuführenden Integrationsarbeiten beschränken sich auf die 

MISTRA-Instanz des ASTRA. 

7.1 Basisdatenintegration 

7.1.1 Schnittstelle STRADA 

Die Schnittstelle STRADA dient der einmaligen Übertragung von Daten aus einer STRADA- 

Datenbank in eine MISTRA-Datenbank. Inkrementelle Updates sind nicht vorgesehen. Es kann 

aber sein, dass die Übertragung pro Thema (Raumbezug, Topologie, Fachnetze, Fahrbahn, 

PMS, Verkehr usw.) zeitlich getrennt vorgenommen wird. 

Die Schnittstelle wird von den heutigen STRADA-Instanzen nicht zeitgleich, sondern je nach Kanton 

zu unterschiedlichen Zeitpunkten je nach Einführungskonzept der einzelnen Betreiber eingesetzt. 

Die Schnittstelle soll die Version 3.02 von STRADA unterstützen. Massgebend ist das mit 

den Testdaten abgegebene Datenmodell STRADA. 

STRADA verfügt über eine Export-Schnittstelle im Interlis1-Format. Alle Daten aus der STRADA- 

DB werden über die Interlis-Schnittstelle gemäss Kap. 6.1.14 in die Datenbank MISTRA importiert. 

Für die Datenübernahme ist im Rahmen der Realisierung das Datenmodell in der Beschreibungssprache 

von Interlis1 zu erstellen. 

Wegen der strukturellen Unterschiede der Datenmodelle STRADA und MISTRA muss für den 

Datentransfer eine Modelltransformation stattfinden. Das hierzu notwendige Software-Tool gehört 

ebenfalls zum Leistungsumfang der Realisierung. 

Modell 

STRADA 

ili 

Modell 

MISTRA 

ili 

STRADA-DB 

STRADA 

Export 

Transfer- 

Datei 

Modell- 

Transformation 

Transfer- 

Datei 

MISTRA 

Import 

MISTRA-DB 

Abbildung 11: Modelltransformation STRADA MISTRA 

Da STRADA auch Funktionen und Daten von Fachapplikationen enthält (z.B. PMS, Verkehr) 

müssen die zugehörigen Spezialistendaten bei der Inbetriebnahme des Basissystems temporär, 

d.h. bis zur Übernahme durch eine Nachfolge-Fachapplikation, in der Sockeldatenbank gespeichert 

und bewirtschaftet werden können. Dementsprechend müssen vom Basissystem entsprechende 

Datentabellen vorgehalten werden. 

Die Schnittstelle muss für die folgenden Daten aus STRADA ausgelegt werden: 

Version 4.1, 30.09.2005 

80


Thema 

Raumbezug 

Bezugspunkte 

Achsen 

Geometrie, Kalibrierung 

Geometrie 

Kalibrierungspunkte 

Horizontalsegmente 

Horizontalelemente 

Fachnetze 

Knotenorte 

Knoten 

Anschlüsse, Kreuzungen 

Kanten 

Toponetze 

Geonetze 

Sektoren 

Textkataloge 

Kataloge 

Katalogtexte 

Auswahllisten 

Eigentümer 

Projekte 

Fahrbahn 

Querprofile 

Streifen, Nutzung 

Verkehr 

Joker 

Tabelle 

STRTB_REFERENCE_PS 

STRTB_AXES 

GEOMETRIES 

HOR_CAL_POINTS 

HOR_SEGMENTS 

HOR_ELEMENTS 

STRTB_NODE_LOCS 

STRTB_NODES 

STRTB_JUNCTIONS 

STRTB_LINKS 

STRTB_LINK_GROUPS 

STRTB_GEO_NETS, STRVE_GNE_REPV 

STRTB_GEO_SEGMENTS 

STRTB_CATALOGS, STRTB_CAT_TITLES, 

STRTB_CAT_COLUMNS, STRTB_COL_TITLES 

STRTB_CAT_TEXTKEYS, STRTB_CAT_TEXTS, 

STRTB_ELEM_TXTKEYS, STRTB_ELEM_TEXTS, 

STRTB_COMPRULES 

STRTB_CODES, STRTB_CODETYPES 

STRTB_OWNERS, STRTB_DATAOWNERS, 

STRTB_OWNER_NAMES 

Für die Eigentümer müssen UUIDs generiert und bei entsprechenden 

Fremdschlüsselbeziehungen eingesetzt werden. 

STRTB_PROJECTS 

STRTB_CROSS_SECTS, STRTB_CR_S_USAGES 

STRTB_LAT_LANES 

Diverse Tabellen 

Diverse Tabellen 

Zuordnung zu Fachnetzen 

Tabelle 8: Schnittstelle STRADA 

Nicht aus STRADA übernommen werden müssen Daten zu Beteiligte, Dokumente, Unfälle und 

Baustellen. 

Version 4.1, 30.09.2005 

81


7.1.2 Schnittstelle UH-PERI 

Bei UH-PERI handelt es sich um einen einzigen Datenbestand, welcher zu übernehmen ist. Dabei 

handelt es sich um eine Access-Datenbank. Das Vorgehen für die Datenübernahme ist frei. 

Inkrementelle Updates sind nicht vorgesehen. Zu beachten sind die strukturellen Unterschiede 

der Datenmodelle UH-PERI und MISTRA (vgl. [6]). 

Die heutige Applikation UH-PERI GIS wird durch die GIS-Basisapplikation (Bearbeitung Inventarobjekte) 

und durch temporäre Funktionen bzw. Fachapplikationen (Nachführung Bauwerke) vollständig 

abgelöst. Entsprechende UseCases sind definiert. 

7.1.3 Datenübernahme 

Die Datenübernahme für das ASTRA umfasst folgende Daten: 

1. Anbindung des WMS-Servers Swisstopo mit Karten (PKxx), VEKTOR25 und Luftbildern 

2. Integration des Objektinventars aus UH-PERI 

3. Integration der STRADA-Daten aus der STRADA-Instanz des ASTRA 

7.1.4 Datenaufbereitung 

Für die erste Inbetriebnahme von MISTRA beim ASTRA sind folgende Daten auf zu bereiten: 

1. Aufbau der Textkataloge 

2. Aufbau der Kennzahlenkataloge 

3. Nachbearbeitung Daten Inventarobjekte und Bauwerke. 

4. Aufbereitung von Fachnetzen der Nationalstrassen: 

• Netz der Nationalstrassennummern als Abschnittsnetz 

• Strassenkategorien als Abschnittsnetz 

• Strassenkategorien TERN als Abschnittsnetz 

• Unterhaltsabschnitte als Streckennetz (Import aus STRADA) 

• Betriebsstrecken als Streckennetz (Import aus STRADA) 

• Kantonszugehörigkeitsnetz als Streckennetz 

• TMC-Location-Codes als Streckennetz 

5. Aufbereitung von Flächennetzen: 

• Kantone 

• Bezirke 

• Gemeinden 

Die UseCases für die Bearbeitung der Fachnetze sind in den UseCases für das Basissystem 

(Kapitel 6.1.24, UseCases 20600) enthalten. 

Version 4.1, 30.09.2005 

82


7.2 Integration weiterer Basisdaten 

7.2.1 Integration Daten Verkehrsnavigation 

Import der Navigationsdaten von Navteq bzw. TeleAtlas. Die Daten werden im Interlis2-Format 

geliefert. Die Schnittstellensoftware für den Export aus der Navigationsdatenbank wird vom Lieferanten 

entwickelt. Die Daten werden als Input verwendet für: 

• Topologie (Knoten, Kanten, Abbiegeregeln) 

• Geometrie (als Alternative zur Geometrie Swisstopo) 

• Fachnetz signalisierte Geschwindigkeit 

• Fachnetz Streifigkeiten 

• Fachnetz LKW-Beschränkungen (Höhe, Breite, Last) 

Die Daten werden über die standardisierte Schnittstelle für das Basissystem (Kapitel 6.1.24, Use- 

Cases 30300) in den Validierungsbereich importiert, validiert und übernommen. 

7.2.2 Integration Daten Verkehrsinformation 

Import der Verkehrsinformationsdaten von GEWI / ViaSuisse. Die Daten werden im Interlis2- 

Format geliefert. 

Die Daten werden als Input verwendet für Verkehrsereignisse (Stau, Falschfahrer, Unfälle, Baustellen 

usw.) und den Location Codes zugeordnet. Die Location Codes werden als Fachnetz aufbereitet 

(siehe 7.1.4) 

Die Daten werden über die standardisierte Schnittstelle für das Basissystem (Kapitel 6.1.24, U- 

seCases 30300) in den Validierungsbereich importiert, validiert und übernommen. 

7.3 Integration Generalistendaten 

7.3.1 Schnittstelle Trassen 

Der Import der Generalistendaten zur Fahrbahn aus STRADA (Streifen, Querprofile, Verkehr, 

Joker) ist in Kapitel 7.1.1 und in [6] beschrieben. 

7.3.2 Integration Kunstbauten mit Kennzahlen 

Die zur Zeit vorhandenen Kunstbauten für Nationalstrassen werden mit der Datenübernahme aus 

UH-PERI gemäss 7.1.2 vollständig integriert. Die Nachführung, die Übernahme von Kunstbauten 

an Kantonsstrassen sowie die Integration von Kennzahlen (z.B. Spannweite bei Brücken) erfolgt 

erst, wenn seitens KUBA die Interlis2-Schnittstelle realisiert ist (KUBA 4.1, ca. Mitte 2007). 

7.3.3 Integration Unfalldaten 

Für die Integration von Unfalldaten gibt es heute zwei Datenbestände, nämlich die Unfalldatenbank 

des BfS von 1994 bis 2004 und die dezentralen Datenbestände der Kantonspolizeien. Ers- 

Version 4.1, 30.09.2005 

83


terer ist durch den Auftragnehmer Realisierung Basissystem zu integrieren, letzterer nach der 

Fertigstellung der Standardschnittstelle über die FA Verkehrsunfälle ab 2008. 

Der Datenbestand BfS ist nach dem Unfallprotokoll strukturiert. Die Georeferenzierung ist nur 

teilweise gemacht und sehr heterogen. Das genaue Vorgehen muss im Rahmen der Detailspezifikation 

besprochen werden. 

Verkehrsunfälle werden auf dem gesamten Verkehrsnetz erhoben und sollen vollständig in die 

Sockeldatenbank übernommen werden. Die Erfassung erfolgt durch die Polizei in die kantonalen 

Unfalldatenbanken. 17 Kantone benutzen die Software von PTV Swiss, die übrigen benutzen 

andere Software (siehe [26]). Parallel zur Realisierung des Basissystems MISTRA wird die Fachapplikation 

Verkehrsunfälle FA VU entwickelt. Die heute heterogenen Daten werden von der FA 

VU in die zentrale Unfalldatenbank des ASTRA übernommen. Von dort werden die Generalistendaten 

im Interlis2-Format an die Sockeldatenbank übergeben. 

7.3.4 Integration Verkehrsdaten 

Ein Teil der Verkehrsdaten wird einmalig mit der Datenintegration STRADA (s. 7.1.1) durchgeführt 

und ist Bestandteil der Leistungen des Auftragnehmers Realisierung Basissystem. Die anschliessende 

geregelte Integration erfolgt über die Fachapplikation Verkehrsmonitoring FA VM, 

welche parallel zur Realisierung des Basissystems entwickelt wird. Die Daten von den Zählstellen 

werden von der FA VMon in die zentrale Verkehrsdatenbank des ASTRA übernommen. Von dort 

werden die Generalistendaten im Interlis2-Format an die Sockeldatenbank übergeben. 

7.3.5 Integration Langsamverkehr 

Die Daten für den Langsamverkehr werden von Swisstopo aufbereitet und bereitgestellt. Sie umfassen 

vorerst die Themen: 

• Wanderwege, -routen, signalisation 

• Velowanderwege, -routen, signalisation 

• MTB-Wege, -routen, signalisation 

Die Daten werden wahlweise als Shape-Dateien oder im Interlis1-Format bereitgestellt. Sie müssen 

durch den Auftragnehmer Realisierung Basissystem als einmaligen Transfer in die Sockeldatenbank 

übertragen werden. Die Nachführung erfolgt über die Standardschnittstelle MISTRA. 

7.3.6 Integration Daten historische Verkehrswege 

Die Daten der historischen Verkehrswege werden im Auftrag des ASTRA in einer ESRI Personal 

Geodatabase bei Basler & Hofmann verwaltet. Die Daten werden durch den Auftragnehmer Realisierung 

Basissystem ohne Modelltransformation in die Sockeldatenbank MISTRA übernommen. 

Die Daten umfassen die folgenden Feature-Klassen: 

• IVS-Objekte 

• Linienobjekte 

• Punktobjekte 

Version 4.1, 30.09.2005 

84


• Bildmaterial und Dokumente 

7.3.7 Integration Betriebsbuchhaltung 

Die Daten der Betriebsbuchhaltung (betrieblicher Unterhalt) werden heute in der Benchmarking- 

Datenbank verwaltet. Sie umfassen derzeit die Betriebskennzahlen zu Winterdienst, Reinigung, 

Grünpflege, Technische Dienste und Beleuchtung. Die Kennzahlen werden auf Betriebsstrecken 

bezogen. 

Die Erfassung des Fachnetzes Betriebsstrecken ist mit 7.1.4 abgedeckt. Die Betriebskennzahlen 

werden aus der Benchmarking-Datenbank über die Interlis2-Schnittstelle zu Händen der Sockeldatenbank 

bereitgestellt. 

Version 4.1, 30.09.2005 

85


8 Systemanforderungen Data Warehouse 

8.1 Data Warehouse – Anforderungen Realisierung 

8.1.1 Einleitung 

Im Folgenden sind die Anforderungen für das MISTRA-Teilsystem Data Warehouse beschrieben. 

Das Data Warehouse ist ein ergänzender Bestandteil des MISTRA Basissystems und unterliegt 

daher grundsätzlich dessen Vorgaben bzw. Anforderungen. 

Im Rahmen der geplanten Data Warehouse Lösung sind zwei grundlegende Komponenten zu 

unterscheiden: 

1. Internes Data Warehouse 

Das interne Data Warehouse ist für die Nutzung durch interne User bzw. Kunden vorgesehen. 

Der Zugang erfolgt in diesem Fall über Intranet Web-Clients oder installierter Client- 

Software. Das interne Data Warehouse ist der Gegenstand des vorliegenden Pflichtenheftes. 

2. Externes Data Warehouse 

Das externe Data Warehouse ist für den öffentlichen Zugriff (Public Access) vorgesehen. Der 

Zugang erfolgt in diesem Fall über Internet Web-Clients. Die enthaltenen Daten und Funktionen 

(Analysen und Reports) entsprechen nur einer Teilmenge des internen Data Warehouses. 

Das externe Data Warehouse ist nicht Bestandteil des vorliegenden Pflichtenheftes. 

Version 4.1, 30.09.2005 

86


8.1.2 Architektur 

8.1.2.1 Umsysteme / Schnittstellen 

Im Rahmen der ersten Entwicklungsstufe stellt die Sockeldatenbank des MISTRA Basissystems 

die einzige Datenquelle für das Data Warehouse dar. Fachdaten sowie andere Datenquellen sind 

erst für nachfolgende Entwicklungsstufen vorgesehen. 

Die Datenübernahme muss betrieblich automatisiert werden können. Für die Umsetzung ist ein 

gängiges ETL-Tool (z.B. Ascentant oder Informatica) einzusetzen. Ein „Write-Back“ von Daten 

aus dem Data Warehouse in das MISTRA Basissystem ist nicht vorgesehen. 

Für den öffentlichen Zugriff über Internet ist eine externe Instanz des Data Warehouses vorgesehen. 

Diese basiert vollumfänglich auf integrierten Daten der internen Instanz bzw. des internen 

Operational Data Stores. Da die externe Instanz sich jedoch in der Datenmenge und Granularität 

von der internen Instanz unterscheidet, ist für die Datenübertragung ebenfalls eine ETL- 

Komponente notwendig. 

Die folgende Übersicht zeigt die an das Data Warehouse angrenzenden Systeme. Das Data Warehouse 

ist in der Grafik vereinfacht dargestellt. Eine detaillierte Beschreibung folgt im nächsten 

Kapitel. 

ASTRA / Bund / Kantone Public Internet 

Client tier 

Rich-GIS, -Admin 

Web-GIS, -DWH, -Admin 

Web-GIS, -DWH 

Fach-Client 

GIS-Client 

Data tier Application tier 

Appl. Server 

FA 

Data-Access 

Fachdaten 

GIS-Server 

(Service-Interface) 

Data Access Layer 

Geodaten 

Map-Server 

Sach- und 

Metadaten 

Web-Server 

ETL 

ETL 

BI-Server 

Data Marts 

ETL 

ODS 

ETL DWH 

Firewall 

Geo Dienste 

Bund 

GIS-Server 

Data-Access 

GEO-Daten 

Web-Server 

Map-Server 

BI-Server 

Data Marts 

ETL Geodaten 

Internes DWH 

Externes DWH 

Produktionsumgebung 

Intranet (KOMBV) 

DMZ Bund 

Internet-Infrastruktur 

Abbildung 12: DWH - Einbettung in logische Systemarchitektur 

Version 4.1, 30.09.2005 

87


8.1.2.2 Data Warehouse Architektur 

Die zu implementierende Data Warehouse Lösung sollte nicht auf MISTRA Daten und Prozesse 

beschränkt werden, sondern die Möglichkeit bieten, in Zukunft weitere Bereiche auf Stufe ASTRA 

(z.B. MOFIS, FABER, ISA, VM-CH, etc.), Departement oder Bundesverwaltung zu integrieren. 

Daher ist es essentiell, eine offene und beliebig erweiterbare Data Warehouse Architektur anzuwenden. 

Um dieses Ziel zu erreichen, sollte die im Folgenden dargestellte Referenzarchitektur 

verwendet werden, welche sich für Data Warehouse Projekte international und branchenübergreifend 

bewährt hat. 

Abbildung 13: DWH - interne Architektur 

8.1.2.2.1 Datenquellen 

Quellsysteme liefern die Rohdaten für das Data Warehouse. Grundsätzlich kann jedes beliebige 

System innerhalb oder auch ausserhalb der Bundesamts als Datenquelle genutzt werden. Das 

Data Warehouse dient als Integrationsplattform und hat das Ziel, heterogene, inkonsistente Daten 

zu homogenisieren und damit vergleichbar bzw. vernetzbar zu machen. 

Die für das Data Warehouse benötigten Daten können je nach Quellsystem-Plattform und gewählter 

Vorgehensstrategie direkt gelesen oder durch Extraktionsprozesse via Flatfiles zur Verfügung 

gestellt werden. 

8.1.2.2.2 ETL Prozesse 

Version 4.1, 30.09.2005 

88


Die Bewirtschaftung des Data Warehouses wird durch ETL Prozesse sichergestellt. Im Folgenden 

sind die Haupt-Funktionen und –Charakteristiken von ETL Prozessen beschrieben. 

Funktionen: 

• Datenextraktion aus verschiedenen Quellsystemen 

• Data Cleansing (Identifizierung von fehlenden, ungenauen und fehlerhaften Daten) 

• Übersetzung und Attribution (z.B. Zuweisung von einheitlichen Codes 0/1 für männlich/weiblich) 

• Datenintegration 

• Aggregation und Zusammenfassung (z.B. Sortierung und Totalisierung von Records zur 

Bildung von Datenkategorien-Zusammenfassungen) 

• Kalkulation und Derivation (z.B. Ableitung von neuen Ausprägungen/Werten auf Basis von 

Algorithmen, quantitativen Methoden oder Messungen) 

Charakteristiken: 

• Implementierung von Full-Load oder Update-Strategie 

• Implementierung von Initial- und periodischer Loads 

• Automatisierter und wiederholbarer Prozess, welcher über eine Job-Steuerung terminiert 

werden kann 

• Monitoringmöglichkeit und automatische Benachrichtigung von Prozess-Status an zuständige 

Super-User. 

ETL Prozesse werden sowohl für die Bewirtschaftung des ODS als auch der Data Marts eingesetzt. 

Auf beiden Stufen ist der Sachverhalt bezüglich Extraktion und Load ähnlich, da Daten 

grundsätzlich von einer Quelle gelesen und in ein Zielsystem geschrieben werden. Bezüglich 

Transformation unterscheiden sich die beiden ETL-Stufen aufgrund der grundverschiedenen Eigenschaften 

von Quell- und Zielsysteme jedoch wesentlich voneinander. 

Bei der Bewirtschaftung des ODS geht es in erster Linie um die Integration von heterogenen Daten 

aus den unterschiedlichen Quellsystemen und damit um Funktionen wie Data Cleansing, Ü- 

bersetzung und Attribution. Da nicht sämtliche Datenfehler maschinell behoben werden können, 

ist ausserdem ein ausgereiftes Error-Management essentiell. Bei der Bewirtschaftung der Data 

Marts wird hingegen mit dem ODS eine Datenquelle verwendet, welche bereits über integrierte, 

konsistente und fehlerfreie Daten verfügt. Auf dieser ETL-Stufe geht es folglich nicht um Integration 

bzw. Bereinigung sondern um die Überführung der Daten von einer relationalen in einer multidimensionalen 

Struktur. Die granularen ODS Daten werden durch Funktionen wie Aggregation, 

Version 4.1, 30.09.2005 

89


Kalkulation und Derivation in die für die Data Marts zu bildenden Summen und Kennzahlen transformiert. 

8.1.2.2.3 Operational Data Store 

Das ODS ist das Herz der Data Warehouse Architektur. Es beinhaltet integrierte granulare Daten, 

welche durch die vorgelagerten ETL Prozesse generiert wurden. Die ODS Inhalte können direkt 

als Datenbasis für analytische Anwendungen wie z.B. Data Mining oder auch für operationales 

Reporting und detail-level „Drill-Through“ (OLAP Tool) verwendet werden. Das ODS bildet die 

Datenquelle für die Population der weiter aggregierten und segmentierten Data Marts und kann 

ausserdem auch als Staging Area benutzt werden. 

Die im ODS gespeicherten Daten sind per Definition funktionsneutral sowie organisationsübergreifend 

und werden über ein relationales normalisiertes Datenmodell dargestellt. 

8.1.2.2.4 Data Marts 

Data Marts (auch Dimensional Data Store genannt) stellen die Basis für analytische Anwendungen 

wie z. B. OLAP dar und sind auch für diese Funktion technisch optimiert. Sie beinhalten vorberechnete 

summarische Ebenen sowie vordefinierte segmentierte Sichten der ODS Daten und 

unterstützen damit „Drill“ und „Slice“ Funktionalitäten. Die Performance der sehr systembelastenden 

Datenzugriffe wird durch hoch-optimierte Indexe und Partitionierung verbessert. 

Die in Data Marts gespeicherten Daten sind per Definition aggregiert sowie subjekt- und funktionsorientiert 

und werden über ein multidimensionales de-normalisiertes Datenmodell dargestellt. 

Als Systemplattform kann je nach Lösung sowohl eine relationale als auch eine multidimensionale 

Datenbank benutzt werden. 

8.1.2.2.5 Presentation 

Über den Begriff „Presentation“ werden grundsätzlich sämtliche Applikationen und Tools zusammengefasst, 

welche für die Ausgabe der Data Warehouse Daten eingesetzt werden und somit 

den Berührungspunkt der User mit dem System darstellen. Im Wesentlichen geht es um Reporting, 

OLAP (On-Line Analytical Processing) sowie Data Mining Anwendungen, welche häufig 

auch als „Business Intelligence“ Tools bezeichnet werden. 

Diese Anwendungen werden fast ausschliesslich über Standardsoftware implementiert. 

8.1.2.2.6 Metadaten 

Metadaten beschreiben Definition, Verwendung, Bewirtschaftung und Struktur der Data Warehouse 

Objekte. Jede Komponente der Data Warehouse Architektur kann sowohl selber Metadaten 

hervorbringen als auch auf Metadaten von anderen Architektur-Komponenten zugreifen. 

Operationale Metadaten beziehen sich auf Informationen über Datenquellen- und Zielmodell- 

Strukturen. Diese Metadaten beinhalten Spezifikationen für die Transformation, Extraktion, Berei- 

Version 4.1, 30.09.2005 

90


nigung (Cleansing), Integration und Synchronisation von Daten, die für die Bewirtschaftung des 

Data Warehouses verwendet werden. 

Benutzerorientierte Metadaten beziehen sich hingegen auf Geschäftsregeln und Daten- 

Verwendungszwecke, welche in Business Intelligence Tools bzw. Presentations-Applikationen 

zur Anwendung kommen. 

8.1.2.3 Iterativer Implementierungsprozess 

Die folgende Grafik verdeutlicht, wie ein iterativer Implementierungsprozess (Vergleiche Kapitel 

Methodik) bzw. die Skalierbarkeit der Lösung durch die beschriebene Architektur sichergestellt 

wird. Die Daten der in unterschiedlichen Farben gekennzeichneten Fachbereiche werden 

nacheinander in das Data Warehouse integriert und bilden danach eine ganzheitliche Datenbasis, 

welche auf Analyse/Reporting-Ebene auch themenübergreifend genutzt werden kann. 

Abbildung 14. DWH - Iterative Implementierungsprozess 

Gegenstand der ersten Realisierungseinheit ist Phase 1. 

Version 4.1, 30.09.2005 

91


8.1.3 Konzeptionelle Anforderungen 

8.1.3.1 Primärschlüssel 

In der MISTRA Sockeldatenbank wird generell für sämtliche Tabellen die UUID als Primärschlüssel 

verwendet. Dieser Schlüssel ist eindeutig und über die Zeit nicht veränderbar. Um die Konsistenz 

sowie den logischen Zusammenhang zum MISTRA Basissystem zu erhalten, muss dieser 

Primärschlüssel im Data Warehouse übernommen und entsprechend verwendet werden. 

8.1.3.2 Mehrsprachigkeit 

Das System muss sprachunabhängig konzipiert werden. Dies betrifft sowohl die Analyse- und 

Reporting-Oberfläche, als auch die darin angezeigten Daten. Analysen und Reports müssen 

sprachmässig parametrisierbar sein. Für die Datenhaltung ist es von Vorteil, die mehrsprachigen 

Texte in separaten Tabellen zu speichern. 

Die Anforderungen bezüglich Mehrsprachigkeit müssen folglich auch vom eingesetzten BI-Tool 

unterstützt werden. 

8.1.3.3 Aktualität 

Das Data Warehouse wird tagesaktuelle Daten enthalten. Das heisst, dass ein täglicher Export/Import 

der Sockeldaten zum Data Warehouse notwendig ist. 

8.1.3.4 Historisierung 

Strukturdaten (Statische Objektklassen): 

Die Historisierung von Strukturdaten (Dimensionen) muss im Data Warehouse möglich sein. 

Bewegungsdaten (Ereignis- und Aktivitätsklassen): 

Der gesamte Zeitraum aus der Sockeldatenbank muss in das Data Warehouse übernommen 

werden. Bei Veränderungen von Strukturdaten müssen zudem Bewegungsdaten rückwirkend neu 

zugeordnet bzw. berechnet werden. (Vergleiche auch Kapitel Veränderungen von Raum/Zeit- 

Zuordnungen.) 

8.1.3.5 ETL Prozesse 

8.1.3.5.1 Periodizität 

Das MISTRA Data Warehouse muss tagesaktuell sein. Demzufolge ist ein täglicher Data Load 

vorgesehen. 

Version 4.1, 30.09.2005 

92


8.1.3.5.2 Load Strategie 

Die für das Laden der MISTRA Sockeldaten zu implementierenden ETL Prozesse müssen ein 

inkrementelles Vorgehen unterstützen. Zur Erkennung des jeweiligen Deltas bietet sich das „Update 

Datum“, welches in allen Tabellen der Sockeldatenbank enthalten ist, an. Sollten weitere 

Erkennungsmerkmale erforderlich sein, kann das Datenmodell der Sockeldaten entsprechend 

ergänzt werden. 

Neben dem inkrementellen Load muss bei Bedarf jederzeit ein „Full Load“ der Daten möglich 

sein. 

8.1.3.5.3 Veränderungen von Raum/Zeit-Zuordnungen 

Um die Vergleichbarkeit von Daten aus der Vergangenheit mit Daten aus der Gegenwart zu gewährleisten, 

müssen die ETL Prozesse in der Lage sein, Veränderungen von Raum/Zeit- 

Zuordnungen zu handhaben. Dazu ein Beispiel: 

Definition bis 01.01.2005: 

km 

100 

Streckenabschnitt 1 Streckenabschnitt 2 

km 

150 

km 

200 

Strecke 

Definition ab 01.01.2005 

km 

100 

Streckenabschnitt 1 Streckenabschnitt 2 

km 

150 

km 

170 

km 

200 

Strecke 

Abbildung 15: DWH - Veränderung von Raum-/Zeit-Beziehungen 

Wie im Beispiel zu sehen ist, wurde die Definition der Streckenabschnitte 1 und 2 per 01.01.2005 

angepasst. Der Bereich zwischen km 150 und km 170 ist nicht mehr dem Streckenabschnitt 2 

sondern dem Streckenabschnitt 1 zugeordnet. Aufgrund der Neu-Einteilung werden z.B. sämtliche 

Staus oder Unfälle, die in diesem Bereich stattfinden, neu dem Streckenabschnitt 1 zugeordnet. 

Um die Vergleichbarkeit der Daten über die gesamte Zeitachse zu gewährleisten, müssen 

bereits im Data Warehouse geladene Daten, welche sich auf die alte Streckenabschnitts- 

Einteilung beziehen, neu zugeordnet werden. 

Um diese Anforderung zu erfüllen, müssen ETL Prozesse in der Lage sein, Veränderungen der 

Raum-Zuordnung zu erkennen und diese rückwirkend für die gesamte Zeitachse anzuwenden 

bzw. auf bereits geladene Daten zu übertragen. Im oberen Beispiel müssten also sämtliche 

Version 4.1, 30.09.2005 

93


Kennzahlen, welche sich auf die Streckenabschnitte 1 resp. 2 beziehen, durch den entsprechenden 

ETL Prozess neu berechnet werden. 

8.1.3.6 „Write-Back“ Funktion 

Es ist keine „Write-Back“ Funktion auf das MISTRA Basissystem vorgesehen. 

8.1.4 Abfragen und Reports 

8.1.4.1 Ad-Hoc Abfragen 

Im Folgenden sind die wichtigsten Abfragen aufgelistet, welche im Rahmen des MISTRA Data 

Warehouses zu realisieren sind. Es ist zu beachten, dass eine kartografische Darstellung der im 

Abfrageresultat enthaltenen Daten möglich sein muss(siehe Kapitel 8.1.4.3 HTUKartografische DarstellungenUTH). 

N.B.: Die folgende Liste enthält nur die wichtigsten Abfragen und ist nicht abschliessend. 

Nr. Bezeichnung Dimensionen Kennzahlen 

1 

Infrastrukturzustand Bauwerke 

und Fahrbahn 

• Zeit 

• Objekt (Bauwerk) 

• Bauwerksart 

• Region 

• Strasse 

• Zustand-Indizes aktuell 

• Zustand-Indizes prognostiziert 

• Anzahl Unfälle 

• Verkehrsbelastung DTV 

• Lastwagenanteil DTV in % 

• Veränderung Zustand-Indizes 

2 

Lebensdauer Inventarobjekte/Bauwerke 

• Zeit 



• Region 

• Strasse 

• Alter 

3 

Aufwand für geleisteter 

Ausbau, Neubau, betrieblicher 

Unterhalt, baulicher 

Unterhalt 

• Zeit 



• Region 

• Strasse 

• Kosten 

• Zeitaufwand 

4 

Baustellen und Baustellenplanung 

• Zeit 

• Baustelle 



• Region 

• Strasse 

• Anzahl Staus 

• Stau-Länge 

• Anzahl Baustellen 

• Zeitdauer Baustelle 

• Verkehrsbelastung 

5 

Projekte in Planung und 

Ausführung 

• Zeit 

• Projektart 

• Status 

• Anzahl Projekte 

• Kosten (diverse Kostenarten) 

Version 4.1, 30.09.2005 

94



• Region 

• Strasse 

6 Staugeschehen 

• Zeit 

• Ursache 

• Abschnitt/Location 

• Strassenkilometer 

• Strasse 



• Stau-Dauer 

• Stauart 

7 

Verkehrsbelastung, - 

entwicklung und - 

zusammensetzung 

• Zeit 

• Strassenabschnitt 

• Stundenwert 

• Tag-Typ (Wochentage, 

Wochenende, etc.) 

• Ganglisten-Typ 

• Zähler 

• Strasse 

• Durchschnittlicher täglicher Verkehr 

• Lastwagen-Anteil in % 

• Längenklassenanteil in % 

• Ganglinie (Entwicklung) 

• Veränderung der Verkehrsbelastung 

8 Verkehrsunfälle 

9 Betrieblicher Unterhalt 

Tabelle 9: DWH - Abfragen 

• Zeit 

• Ursache 


• Zeit 

• Rapportstrecke 

• Unterhaltstyp 

• Region 


• Sachschaden in SFR 

• Anzahl Tote 

• Anzahl Verletzte 

• Veränderung der Unfallhäufigkeit 

• Kosten 


8.1.4.2 Standardreports 

Im Folgenden sind die wichtigsten Standardreports aufgelistet, welche im Rahmen des MISTRA 

Data Warehouses zu realisieren sind. Sämtliche Standardreports müssen neben der tabellarischen 

Darstellung auch eine kartografische Darstellung der entsprechenden Daten enthalten 

(siehe Kapitel HTUKartografische DarstellungenUTH). 

Generell ist bei den Standardreports eine jährliche Periodizität vorgesehen. Einzelne Reports, wie 

z.B. Verkehrsbelastung oder Stau, sind auch monatlich zu erzeugen. 

N.B.: Die folgende Liste enthält nur die wichtigsten Standardreports und ist nicht abschliessend. 


1 

Netzzustand Bauwerke und Fahrbahn 

(Aktuelle Fahrbahnzustände 

auf den Kantonsstrassen AG je für 

den Index I1 bis I5) 

• Zeit 



• Region 

• Zustand-Index aktuell 

• Zustand-Index prognostiziert 


Version 4.1, 30.09.2005 

95



2 

Verkehrsbelastung DTV / SSV 

(durchschnittlicher täglicher Verkehr 

/ Spitzenstunden Verkehr) 

• Zeit 





• Durchschnittlicher täglicher 

Verkehr 


• Ganglinie (Entwicklung) 

• Längenklassenanteil in % 

3 Neubauprojekte 

• Zeit 

• Projektart 

• Status 

• Region 

• Anzahl Projekte 

• Kosten (diverse Kostenarten) 

4 

Aufwand Unterhaltsprojekte (Baustellen) 

• Zeit 



• Region 

• Kosten 


5 

Zeitdauer und Planung Unterhaltsprojekte 

(Baustellen) - Geplante 

Baustellen auf den Nationalstrassen 

je im nächsten und übernächsten 

Jahr 

• Zeit 

• Baustelle 



• Region 



• Anzahl Baustellen 

• Zeitdauer Baustelle 

6 Verkehrsstaus 

• Zeit 

• Ursache 

• Location 


• Region 



• Stau-Dauer 

• Stau-Art 

7 

Verkehrsunfälle - Unfallhäufigkeiten 

auf den vordefinierten Unfallabschnitten 

im Grossraum Zürich auf 

den Kantons- und Nationalstrassen 

• Zeit 

• Ursache 


• Region 


• Sachschaden in SFR 

• Anzahl Tote 

• Anzahl Verletzte 

• Anzahl Unfälle pro 1'000 

Fahrzeuge DTV 

• %-Anteil Unfälle zu DTV 

8 

Betrieblicher Unterhalt - Kosten für 

die Grünpflege pro Werkhof im vergangenen 

Jahr 

• Zeit 

• Rapportstrecke 

• Unterhaltstyp 

• Region 

• Kosten 


9 

Aktuelle Geschwindigkeitsabschnitte 

auf Nationalstrassen 

• Geschwindigkeitsintervall 

• Strassennummer 

• Strassenkategorie 

• Länge in km 

• Verkehrsbelastung DTV 

• Lastwagenanteil DTV in % 

10 

Tagesspitzen auf den vordefinierten 

Verkehrsabschnitten im Nationalstrassennetz 

für das Jahr 2000 und 

2004 

• Zeit 




• Spitzenstundenverkehr 


Version 4.1, 30.09.2005 

96




11 

Brückenbauwerke mit Angabe der 

Tragfähigkeit 

• Tragfähigkeits-Kategorie 

• Region 

• Bauwerksart (nur Bauwerksarten 

mit Brückenfunktion) 

• Anzahl 

Tabelle 10: DWH - Standardreports 

8.1.4.3 Kartografische Darstellungen 

Es muss möglich sein, thematische Karten im Format A4/A3 mit selektierbaren Parametern in 

einem selektierbaren geografischen Raum und zu einem bestimmten Zeitpunkt bzw. Zeitintervall 

zu erstellen. Die dafür notwendigen Geo-Daten (auch kartografische Daten genannt) werden in 

der GIS (Geographical Information System)-Komponente des MISTRA Basissystems verwaltet. 

Da im Allgemeinen die Verwaltung von Geo-Daten in OLAP oder Reporting Tools nicht möglich 

ist, sind die entsprechenden Daten über ein „Drill-Through“ auf das MISTRA Basissystem für den 

betroffenen Report oder Abfrage herbeizuziehen. 

Das folgende Beispiel zeigt die Darstellung von Geo-Daten innerhalb einer Abfrage. 

Abbildung 16: DWH - Beispiel kombinierter Report 

Version 4.1, 30.09.2005 

97


Neben den kartografischen Darstellungen innerhalb von Analysen bzw. Reports ist es wünschenswert, 

ausgehend vom GIS-System einen entsprechenden Report zu generieren. Abklärungen 

bei BI-Tool Anbietern haben ergeben, dass eine solche Funktionalität durchaus machbar 

ist (siehe auch Kapitel HTUBI-Tool AnforderungenUTH). 

8.1.4.4 Layout 

Die zu entwickelnden Reports müssen ein einheitliches Layout aufweisen. Eine detaillierte Design-Vorgabe 

für die Report-Layouts wird im Rahmen des Projekts noch spezifiziert. Neben den 

dargestellten Daten müssen sämtliche Reports die folgenden Informationen enthalten: 

• Titel 

• Tages-Datum 

• Report-Datum 

• Logos (ASTRA, MISTRA, Kanton, etc.) 

• Mitarbeiter (Report „Generator“) 

Bei kartografischen Darstellungen müssen zusätzlich folgende Informationen dargestellt werden: 

• Legende zur GIS-Grafik 

• Nordpfeil 

• Massstab 

• Koordinaten-Beschriftung (Eck-Koordinaten) 

Version 4.1, 30.09.2005 

98


8.1.5 Funktionale Anforderungen 

Die folgende Liste enthält die Beschreibung der wichtigsten funktionalen Anforderungen an das 

MISTRA Data Warehouse. 

Nr. Bezeichnung Beschreibung 

1 Windows-Standard 

Der Aufbau und die Steuerung der Applikation inkl. Zugang zu Hilfe 

muss den üblichen Windows-Standards entsprechen. 

2 

Reportausgabe in Listen- und 

Grafikform 

Die ausgegebenen Daten müssen innerhalb eines Reports sowohl 

in Listen/Tabellen-Form als auch in grafischer Form dargestellt 

werden. 

3 Grafiken 

Für die grafische Darstellung von Daten muss ein breites Spektrum 

an Grafiktypen und Einstellungsmöglichkeiten vorhanden sein. Als 

Richtwert gilt der in MS Excel vorhandene grafische Funktionumfang. 

4 

5 

Abspeicherung von Abfrageund 

Reportdefinitionen 

Abspeicherung von Abfrageund 

Reportergebnissen 

Es muss für Benutzer möglich sein, die Definition häufig verwendeter 

Abfragen und Reports abzuspeichern und anderen Benutzern 

zur Verfügung zu stellen. Unter Abfrage- und Reportdefinitionen 

verstehen sich sämtliche erforderliche bzw. veränderbare Einstellungen 

wie Layout, Formatierung, Parameter, Filter, Grafik, usw. 

Ein Benutzer soll z.B. eine häufig verwendete Abfrage einmalig 

definieren und später für die Analyse aktualisierter Daten einfach 

wiederverwenden können. Er soll zu einem späteren Zeitpunkt 

ohne zusätzlichen Einstellungsaufwand exakt das selbe Abfrageresultat 

mit aktuellen Daten erhalten. 

Es muss möglich sein, das Resultat einer Abfrage oder eines Reports 

in ein gängiges Fileformat (z.B. PDF) statisch abzuspeichern. 

Ein Benutzer soll z.B. das Resultat eines spezifischen Berichts mit 

dem Resultat des Vormonats vergleichen können. 

6 Datenexport nach Excel 

Es muss möglich sein, eine Abfrage bzw. das Resultat einer Abfrage 

nach MS Excel zu exportieren. 

7 

8 

Reportverteilung („Push“- 

Verfahren) 

Ad-hoc Abfragen („Pull“- 

Verfahren) 

Es muss möglich sein, in Abhängigkeit von festgelegten Intervallen, 

Zeitpunkten oder Ereignissen bestimmte Reports an bestimmte 

Benutzer über Email zu versenden. Der Versand kann entweder in 

Form eines in einem gängigen Fileformat abgespeicherten Reports 

oder durch einen Dokument-Link erfolgen. Als Intervalle sollten alle 

üblichen Zeitabschnitte wie z.B. wöchentlich oder monatlich definierbar 

sein. Zeitpunkte verstehen sich als frei wählbare Datumsangaben 

wie z.B. 13.02.05 oder 24.12.05. Über die Ereignisse 

müssen hingegen Abhängigkeiten zu technischen Prozessen, wie 

z.B. die Fertigstellung eines bestimmten Data-Loads dargestellt 

werden können. 

Es muss möglich sein, dass ein berechtigter User jederzeit eine 

Abfrage oder einen Report „ad-hoc“ spezifizieren und ausführen 

kann. 

Tabelle 11: DWH - Funktionale Anforderungen 

Version 4.1, 30.09.2005 

99


8.1.6 Anwendungsfälle (UseCases) 

Nr 

Use Case 

10000 LP Business Processes BP 

81200 LP Explore DWH 

Priorität 

Prozess 

Web- 

DWH 

81201 LP DWH starten 6 Z 

81203 LP Navigation 6 Z 

81204 LP Abfragen durchführen 6 Z 

81205 LP Tabellensicht 6 Z 

81206 LP Formularsicht 6 Z 

81207 LP Business Grafik Sicht 6 Z 

81208 LP Kartensicht 6 Z 

81209 LP Kombinierte Sicht 6 Z 

81500 LP3 Report Service DWH 

81501 LP3 AdHoc Report bereitstellen, bearbeiten, 

ausgeben 6 Z 

Rich- 

Admin 

Web- System 

Admin 

81502 LP3 Standardreport bereitstellen, 

bearbeiten, ausgeben 6 Z Z 

81503 LP3 Standardreport liefern 6 Z 

81504 LP3 AdHoc-Report freigeben 6 Z 

30000 IP Integration Processes 

83400 IP Extract,Transform,Load ETL DWH 

83401 IP ETL-Konfiguration DWH Intranet 


83402 IP ETL DWH Intranet ausführen 6 Z 

83403 IP ETL-Konfiguration DWH Internet 


83404 IP ETL DWH Internet ausführen 6 Z 

84300 FP4 Benutzer & Rechte Management 

DWH 

84301 FP4 Benutzer erstellen, mutieren, 


84302 FP4 Gruppe erstellen, mutieren, 


84303 FP4 Zugriffsrechte Gruppe verwalten 

6 O Z 

84304 FP4 Zuordnung Benutzer zu Gruppe 


84305 FP4 Rolle eintragen, mutieren, löschen 

6 O Z 

84306 FP4 Ausführungsrechte Rolle verwalten 

6 O Z 

Version 4.1, 30.09.2005 

100


Nr 

Use Case 

Priorität 

Prozess 

Web- 

DWH 

Rich- 

Admin 

84307 FP4 Zuordnung Gruppe zu Rolle 


84400 FP1 Cockpit DWH 

84401 FP1 

SP2 Systemreport erstellen 6 O Z 

84402 FP1 

DP8 Datenreport erstellen 6 O Z 

84900 SP4 Change Management DWH* 

84901 SP4 Change Request erfassen, 


84902 SP4 Change Requests sichten 6 Z Z 

84903 SP4 Change Requests Report 


85100 SP7 HelpDesk DWH 

85101 SP7 Problem Request erfassen, 


85102 SP7 Problem Requests sichten 6 Z Z 

85103 SP7 Problem Requests Report 


* Mitbenutzung der Infrastruktur Basissystem 

Z = zwingend, O = Optional, S = nur Sachdaten 

Web- System 

Admin 

FP = Führungsprozesse; LP = Leistungserstellungsprozesse; DP = Datenbearbeitungsprozesse; IP = Integrationsprozesse; 

SP = Systembetriebsprozesse 

Tabelle 12: DWH - UseCases und Zuordnung zu den Clients 

Version 4.1, 30.09.2005 

101


8.1.7 Software/Tool Anforderungen 

8.1.7.1 BI-Tool Anforderungen 

Es wird an dieser Stelle keine Preferenz für ein spezifisches OLAP/Reporting Tool festgelegt. 

Grundsätzlich sollte die Applikationssoftware eingesetzt werden, welche den ASTRA Bedürfnissen 

am optimalsten entspricht. Da die Darstellung von Geo-Daten auf OLAP/Reporting-Ebene als 

kritisch betrachtet wird, sollte bei der Tool-Auswahl besondere Aufmerksamkeit auf die Einbindung 

von GIS (Geographical Information System) – im Spezifischen von ESRI-GIS – gelegt werden. 

(Für weitere Informationen siehe Kapitel 8.1.4.3 TUKartografische DarstellungenUT.) Darüber hinaus 

ist das Vorhandensein einer Datenexport-Funktion nach MS Excel von grosser Bedeutung. 

Zur Zeit ist keine explizite Software Evaluation vorgesehen. ASTRA wird für die Auswahl des einzusetzenden 

OLAP/Reporting Tools die Empfehlung des Anbieters prüfen und im Entscheidungsprozess 

berücksichtigen. 

8.1.7.2 Vorabklärung zu GIS-Link 

Eine Vorabklärung zur Machbarkeit eines GIS-Links bei drei der führenden Business Intelligence 

Tool Anbieter hat folgendes Resultat ergeben: 

Hyperion: 

• GIS-Link funktioniert sowohl bei Analyse- als auch Reporting-Anwendung. Anbindung 

spezifisch zu ESRI GIS-System ist vorhanden. 

• GIS-Link funktioniert auch in entgegengesetzter Richtung. Das heisst, dass von einer kartografischen 

Darstellung ausgehend ein Report erzeugt werden kann. Die Implementierung 

ist allerdings komplexer als in Richtung BI-Tool zu GIS-System. 

• Hyperion verfügt neuerdings über eine BI Produkt-Suite, in der sowohl Analyse- als auch 

Reporting-Funktionen integriert sind. Grundsätzlich können über ein sogenanntes „Dashboard“ 

eine Vielzahl von Daten aus verschiedensten Quellen und in verschiedensten Darstellungsformate 

presentiert werden. 

Business Objects: 

• Grundsätzlich kann Business Objects die Anforderungen bezüglich GIS-Link erfüllen. 

Version 4.1, 30.09.2005 

102


Cognos: 

• Prinzipiell kann mit ReportNet zu jeder beliebigen Adresse im Web gedrillt werden. Dies 

geht sogar im Standard und ist nur eine Frage des URL Aufbaus. Dabei wird anstelle eines 

Drill-Throughs eine URL hinterlegt. ESRI-GIS bietet einige Schnittstellen, die mit ReportNet 

bedient werden können, z.B. Java und XML (Version 9.1). 

• Offenbar ist es von Relevanz, in welchem Format ESRI-GIS die Filterdaten benötigt. 

Diesbezüglich gibt es bei Cognos gewisse Einschränkungen. 

• Ebenfalls Einschränkungen gibt es bezüglich der GIS System Plattform. Und zwar ist die 

Implementierung eines GIS Web-Systems einfacher als bei einer Server-Variante. 

8.1.7.3 ETL-Tool Anforderungen 

Es wird an dieser Stelle keine Preferenz für ein spezifisches ETL Tool festgelegt. Grundsätzlich 

sollte die Software eingesetzt werden, welche den ASTRA Bedürfnissen am optimalsten entspricht 

und sich im Data Warehouse Markt nachweislich bewährt hat bzw. eine führende Stellung 

hat. 

Zur Zeit ist keine explizite Software Evaluation vorgesehen. ASTRA wird für die Auswahl des einzusetzenden 

ETL Tools die Empfehlung des Anbieters prüfen und im Entscheidungsprozess berücksichtigen. 

Version 4.1, 30.09.2005 

103


8.1.8 Datenschutz und Datensicherheit 

Im Bereich des Data Warehouses werden im Vergleich zum MISTRA Basissystem keine erhöhten 

Anforderungen an den Datenschutz und die Datensicherheit gestellt. Hard- und softwaretechnische 

Massnahmen müssen den branchenüblichen Standards entsprechen. Das System muss 

aber die Integrität und die Durchgängigkeit der gespeicherten Daten und die Datenkonsistenz 

gewährleisten. 

8.1.8.1 Benutzerverwaltung 

Die Verwaltung der Benutzer und Gruppen erfolgt über LDAP. Es dürfen nur LDAP Standardfunktionen 

ohne herstellerspezifischen Erweiterungen verwendet werden. 

Die Zugriffssteuerung muss die Definition von Benutzergruppen zulassen. Die einzelnen Benutzer 

werden keiner, einer oder mehreren Benutzergruppen zugeordnet. 

Im Übrigen gelten die Standards des Basissystems (siehe Kapitel 6.1.11 Basissystem). 

8.1.8.2 Zugriffsberechtigungen 

In analytischen Applikationen gibt es grundsätzlich zwei Ebenen, auf denen Zugriffsrechte definiert 

werden können. 

1. Report-/Auswertungsebene: 

Die Zugriffsrechte werden auf Ebene Report/Analyse festgelegt. Dies bedeutet, dass ein bestimmter 

User bzw. eine User-Gruppe nur Reports bzw. OLAP Analysen einsehen kann, für 

die er zugriffsberechtigt ist. Die zugriffsberechtigten Reports/Analysen können uneingeschränkt 

eingesehen werden. 

2. Datenebene: 

Die Zugriffsrechte werden auf Ebene Daten definiert. Dies wird durch die Verknüpfung von 

Zugriffsberechtigungen mit Dimensions- bzw. Strukturdaten-Ausprägungen erreicht. Ein bestimmter 

User oder eine User-Gruppe darf z.B. nur die Strassendaten einsehen, welche dem 

jeweils entsprechenden Zuständigkeitsbereich zugehören. Angenommen ein User ist nur für 

die Strassen im Kanton Bern zuständig, dann werden ihm in einem Report nur die Daten angezeigt, 

welche der Ausprägung „Bern“ in der Dimension „Kanton“ zugeordnet sind. Der User 

kann auf sämtliche Reports/Auswertungen zugreifen, aber darin nur einen Teil der Daten einsehen. 

Zugriffsrechte auf Datenebene können mit Zugriffsrechte auf Report / Auswertungsebene 

kombiniert werden. 

Für das MISTRA Data Warehouse sind Zugriffsrechte auf Report- / Auswertungsebene ausreichend. 

Version 4.1, 30.09.2005 

104


8.1.8.3 Benutzertypen 

Für das Data Warehouse sind folgende Benutzertypen pro MISTRA-Instanz zu unterscheiden: 

Nr. Benutzer Typ Client Aufgaben / Berechtigungen Anzahl 

1 

BetrV IT * 

Administratoren 

• Verwaltung von Benutzer und Zugriffsrechte 

• Überwachung der Data Warehouse Prozesse 

1 

2 

BetrV Fach * 

Super User 

Web- 

DWH 

• Erstellung von Abfragen und Reports 

10 - 20 

3 Normale User 

Web- 

DWH 

• Ausführung von Abfragen und Reports 

100 

Tabelle 13: DWH – Benutzertypen (* gemäss [2]) 

8.1.8.4 Authentisierung (Login) 

Die Authentisierung für das Data Warehouse System muss über den selben Login-Mechanismus 

wie für das MISTRA Basissystem erfolgen. Das heisst, dass für Benutzer die Anmeldung zum 

Data Warehouse System transparent sein soll (keine Notwendigkeit eines zweiten Login- 

Vorgangs) bzw. automatisch über LDAP erfolgen muss. 

8.1.8.5 Log File 

Die angebotene Lösung muss ein Log File enthalten, in welchem aufgezeichnet wird, welche Benutzer 

zu welchem Zeitpunkt auf welche Analysen/Reports zugegriffen haben. Das Log File muss 

für die Erstellung von Nutzungsstatistiken verwendbar sein. 

8.1.8.6 Datensicherung und Wiederanlaufverfahren 

Die Daten sind täglich über Nacht zu sichern (Backup). Das Verfahren zur Wiederherstellung des 

Systems (Restore) darf höchstens 24 Stunden betragen. 

Version 4.1, 30.09.2005 

105


8.1.9 Technische Anforderungen 

8.1.9.1 Client Software 

Die Benutzer müssen über einen Web-Client auf das entsprechende OLAP bzw. Reporting Tool 

zugreifen können. Eine physische Client-Installation darf nur für Super-User und Administratoren 

in Betracht gezogen werden. 

8.1.9.2 Unterstützte Drucker 

Die für Analyse und Reporting eingesetzte Software muss folgende zur Zeit bei ASTRA verwendete 

Drucker unterstützen: 

• HP Color LaserJet 4550 



• Minolta Di351/251/200 

• Lexmark Optra T614 

• Lexmark Optra T612 

8.1.9.3 System-Verfügbarkeit 

Das Data Warehouse muss für alle Benutzer 6 mal 18 Stunden (täglich von 6.00 bis 24.00 Uhr 

ausser Sonntags) verfügbar sein. Während dieses Zeitfensters dürfen keine technischen Prozesse 

die Verfügbarkeit und die Performance des Data Warehouses beeinträchtigen. 

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 

ETL/Backup-Prozesse 

System für User verfügbar 

Abbildung 17: DWH - Verfügbarkeit 

Die Systemverfügbarkeit während der „Uptime“ muss mindestens 99% betragen. 

Für das „externe“ Data Warehouse (Public Access) ist eine höhere Verfügbarkeit vorgesehen. 

Diese System-Komponente ist jedoch nicht Bestandteil des vorliegenden Pflichtenheftes. 

Version 4.1, 30.09.2005 

106


8.1.9.4 System-Performance 

Für das Data Warehouse System wurden folgende Antwortzeiten festgelegt: 

• Starten der Applikation inkl. Authentifizierung: < 10 Sekunden 



• Starten einer Auswertungsfunktion: < 1 Sekunde 

• Ausführen einer einfachen Abfrage, d.h. Filterung auf einem Attribut bei einer beliebigen 

Anzahl von Objekten: < 3 Sekunden 

• Bei komplexen Abfragen muss eine Statusanzeige den Fortschritt anzeigen, ein Abbruch 

der Abfrage muss möglich sein. 

Für weitere Informationen siehe Kapitel 6.1.31 Leistungsanforderungen, Antwortzeiten im 

MISTRA Pflichtenheft Basissystem. 

8.1.9.5 Anzahl Systemzugriffe 

Instanz 

Anzahl Systemzugriffe pro Jahr 

Grosse MISTRA Instanz 3'000 bis 5’000 

Mittelgrosse MISTRA Instanz 1'000 bis 2’000 

Kleine MISTRA Instanz 400 bis 1’000 

Tabelle 14: DWH - Häufigkeit der Zugriffe 

8.1.9.6 Public Access (Internet-Anbindung) 

Es ist vorgesehen, bestimmte Data Warehouse Inhalte über eine Internet-Plattform öffentlich zugänglich 

zu machen. Die dafür notwendige Architektur-Erweiterung wird an dieser Stelle nicht 

näher festgelegt, da sie nicht Bestandteil des vorliegenden Pflichtenheftes ist. Die zu verwendende 

Lösung muss jedoch soweit wie möglich mit der entsprechenden Internet-Anbindung des 

MISTRA Basissystems konform sein und sämtliche Sicherheitsanforderungen von ASTRA erfüllen. 

Version 4.1, 30.09.2005 

107


8.1.10 Mengengerüst 

Nr. Objekt Datentyp Menge 

Wachstum 

pro Jahr 

Mutationen 

pro Jahr 

Liefer- 

Periodizität 

Basisdaten Administration 

1 Kanton Struktur 26 0 40 - 80 % jährlich 

2 Gemeinde Struktur 3’200 - 0.3 % 1.5 - 3 % jährlich 

3 Inventarobjekt Struktur 10’000 1-2 % 5 % täglich 

4 Bauwerk/Anlage Struktur 17’000 1-2 % 5 % täglich 

5 

BA Kennzahl (Kennzahl 

Bauwerke und 

Anlagen) 

Bewegung 100’000 1-2 % 5 % täglich 

6 Projekt Struktur 1’000 20 % 40 % täglich 

Basisdaten Raumbezug 

Für Data Warehouse nicht relevant 

Basisdaten Fachnetze 

7 Netzabschnitt Struktur 20’000 10 % 10 % täglich 

8 

Kennzahlen von 

Fachnetzen 

Bewegung 100’000 10 % 10 % täglich 

Generalistendaten 

9 Streifen Struktur 90’000 2 % 5 % täglich 

10 Verkehrsunfall Bewegung 1'000’000 10 % 1 % täglich 

11 Verkehrsganglinie Bewegung 5'000’000 2 % 0 täglich 

12 Stau Bewegung 300’000 10 % 0 täglich 

13 Kennzahl Betrieb Bewegung 1’000 10 % 0 täglich 

Tabelle 15: DWH - Mengengerüst 

Version 4.1, 30.09.2005 

108


8.1.11 Dokumentation 

In der Phase Realisierung und Einführung werden die Dokumente gemäss Hermes [1] benötigt, 

insbesondere: 

1. Systemdesign deutsch oder französisch (nicht gemischtsprachig) mit 

• Systemarchitektur (funktional, logisch, physisch) 

• Systemintegrationsplan 

• Logisches Datenmodell mit Tabellen- und Attributbeschreibungen 

• Applikationsbeschreibungen und Anwendungsfälle der Applikationen 

• GUI-Layoutkonzept 

• ETL-Prozesse 

• Benutzerverwaltung, Zugriffsrechte, Sicherheit 

• Weitere für vollständige Dokumentation des Systems inkl. Teilsysteme notwendigen Ergänzungen 

• Index 

2. Betriebshandbuch deutsch, französisch, italienisch (Option) mit 

• Technische Struktur des Systems 

• Voraussetzungen 

• Installation, Konfiguration 

• Betriebsaufnahme, -unterbruch, -beendigung 

• Beschreibung aller administrationsseitigen Anwendungsfälle inkl. Screenprints 

• Erforderliche Überwachungsmassnahmen 

• Hinweise Optimierung des Systembetriebs 

• Mögliche systemseitigen Fehler mit Fehlernummer, -beschreibung, -massnahmen 

• Verwaltung von Gruppen, Rollen, BenutzerInnen, Zugriffs- und Ausführungsrechte 

• Datensicherung, -wiederherstellung 

• Weitere für den ordnungsgemässen Betrieb notwendigen Ergänzungen 

• Index 

3. Supporthandbuch deutsch, französisch, italienisch (Option) mit 

• Beschreibung Systemaufbau, Komponenten, Schnittstellen 

• Ziele und Hauptfunktionen der Applikationen 

• Mögliche anwendungsseitige Fehler mit Fehlernummer, -beschreibung, -massnahmen 

• Weitere für den ordnungsgemässen Support notwendigen Ergänzungen 

• Index 

4. Anwendungshandbuch deutsch, französisch, italienisch (Option) mit: 

• Beschreibung Systemaufbau und Applikationen mit Hauptfunktionen 

• Beschreibung aller anwenderseitigen Anwendungsfälle inkl. Screenprints 

• Mögliche Fehlerfälle mit Fehlernummer, -beschreibung, -massnahmen 

• Technische Erläuterungen: Datenstrukturen und Algorithmen 

• Index 

5. Quick Reference Guide deutsch, französisch, italienisch, englisch mit einer Kurzbeschreibung 

für die Anwender und Anwenderinnen auf maximal vier Seiten A4. 

Version 4.1, 30.09.2005 

109


6. Schulungsunterlagen pro Kurstyp mit Übungsbeispielen deutsch und französisch. 

7. Online-Help deutsch und französisch kontextsensitiv 

Die Dokumentationen (ausser Online-Help) sind als Word- und als PDF-Datei abzugeben. 

Version 4.1, 30.09.2005 

110


8.1.12 Projektplanung 

8.1.12.1 Integrationsmodule 

Im Rahmen des MISTRA Data Warehouses sind verschiedene Integrationsmodule identifiziert 

bzw. spezifiziert worden, welche zeitlich gemäss nachfolgender Tabelle umzusetzen sind. 

Nr. Modul Typ Zeitplan für Realisierung / Einführung 

1 Basissystem Sockeldaten 10.2005 – 12.2006 

2 Verkehrszählung Spezialistendaten 01.2007 – 04.2007 

3 Verkehrsunfälle Spezialistendaten 04.2007 – 07.2007 

4 Verkehrsinformation Spezialistendaten 07.2007 – 10.2007 

5 Trassen Spezialistendaten 10.2007 – 01.2008 

6 Kunstbauten, Tunnel Spezialistendaten 01.2008 – 04.2008 

7 Langsamverkehr Spezialistendaten 04.2008 – 07.2008 

Tabelle 16: DWH - Zeitplan Integrationsmodule 

8.1.12.2 Detaillierte Termine 

8.1.12.2.1 Basissystem (Sockeldaten) 

Leistungspaket Phasen Zeitplan 

Konzeption 

• Analyse 

• Systemdesign 

10.2005 – 12.2005 

Realisierung 

• ETL-Prozesse 

• ODS 

• Data Marts 

• Analysen/Reports 

01.2006 – 06.2006 

01.2006 – 06.2006 

01.2006 – 06.2006 

06.2006 – 10.2006 

Einführung 

• Aufbau 

• Schulung 

• Sachmittel 

10.2006 – 12.2006 

• Hosting ab 10.2006 

Betrieb • Support 

• Wartung 

• Sachmittel 

ab 2007 

Abschluss • Projektdokumentati- 07.2007 – 09.2007 

Version 4.1, 30.09.2005 

111


on 

Tabelle 17: DWH - Detailtermine Modul Sockeldaten 

8.1.12.2.2 Fachapplikationen (Spezialistendaten) 

Leistungspaket Phasen Zeitplan 

Verkehrszählung 

• Realisierung 

• Einführung 

• Betrieb 

01.2007 – 03.2007 

04.2007 – 04.2007 

ab 05.2007 

Verkehrsunfälle 



• Betrieb 

04.2007 – 06.2007 

07.2007 – 07.2007 

ab 08.2007 

Verkehrsinformation 



• Betrieb 

07.2007 – 09.2007 

10.2007 – 10.2007 

ab 11.2007 

Trassen 



• Betrieb 

10.2007 – 12.2007 

01.2008 – 01.2008 

ab 02.2008 

Kunstbauten, Tunnel 



• Betrieb 

01.2008 – 03.2008 

04.2008 – 04.2008 

ab 05.2008 

Langsamverkehr 



• Betrieb 

04.2008 – 06.2008 

07.2008 – 07.2008 

ab 08.2008 

Abschluss • Projektdokumentation 09.2008 – 10.2008 

Tabelle 18: DWH - Termine Module Spezialistendaten 

Version 4.1, 30.09.2005 

112


8.2 Data Warehouse – Anforderungen Einführung ASTRA 

8.2.1 Einführungskonzept 

Im Rahmen der Einführung ist für das ASTRA ein Einführungskonzept nach Hermes [1] zu erstellen, 

mit: 

1. Beschreibung der Einführungsorganisation und Abläufe bei der Einführung 

2. Inbetriebnahme des Data Warehouse MISTRA 

3. Vorgehen Datenübernahme vom Basissystem 


5. Information 

6. Ausbildungskonzept (s.8.2.4) 

8.2.2 Systemabnahme 

Die Systemabnahme erfolgt mehrstufig (vgl Terminplan 9.1.2): 

1. Abnahme der Software auf Testumgebung ASTRA 

2. Abnahme des produktiven Systems ASTRA 

Die Abnahmen erfolgen auf den Systemen des ASTRA. Bei allen Abnahmen sind Vertreter des 

ASTRA anwesend. Die Abnahmen beziehen sich auf das Funktionieren der Softwarekomponenten 

und den Systembetrieb. Die Dokumentation wird in Rahmen von separaten Reviews geprüft. 

Die genaue Organisation und Inhalt der Abnahme sind im Testplan gemäss Kap. 9.2 zu beschreiben. 

8.2.3 Installation 

Für jedes der Applikationen sowie der eingesetzten Fertigprodukte ist ein separates Setup-Skript 

zur erstellen. Diese Skripts müssen alle Installationsschritte umfassen. Manuelle Installation von 

Dateien und die manuelle Anpassungen von Konfigurationsdateien sind nicht zulässig. 

Das Installationsprozedere ist im Betriebshandbuch (s. Kap. 8.1.11) vollständig zu beschreiben. 

Umfang der Installationsarbeiten: 

1. Testinstallationen beim ASTRA und 3 Kantonen (VD, ZH, BE) (Server + 2 Clients). 

2. Installation für Abnahme beim ASTRA (Server + 2 Clients) 

3. Installation Produktionsumgebung des ASTRA (DB-Server, DWH-Serverkomponenten, 2 

WebDWH-Clients 

Die Hardware inkl. Betriebssystem wird Auftraggeberseitig beschafft und installiert. Im Rahmen 

des Angebots sind diese Positionen als Option an zu bieten. 

Version 4.1, 30.09.2005 

113


8.2.4 Schulung 

Im Rahmen der Einführung ist ein Ausbildungskonzept nach Hermes [1] zu erstellen, mit: 

1. Beschreibung der Ausbildungsorganisation 

2. Beschreibung der Ausbildungsanforderungen 

3. Beschreibung des Ausbildungsangebots (Kursbeschreibung, Lernziele, Zielpublikum) 


5. Auswertungen 

Schulungsangebot je in deutsch und französisch: 

1. Abfragen und Nutzung über WebDWH (3 Std) 

2. Administratoren Basissystem (3 Tage) 

8.3 Data Warehouse - Anforderungen Betrieb 

8.3.1 Konfigurationsmanagement 

Das Konfigurationsmanagement ist in der Betriebsphase mit jedem Software-Release nach zu 

führen. 

8.3.2 Wartung 

8.3.2.1 Changemanagement 

Die Changemeldungen werden als CM systematisch erfasst und bis zum Abschluss verwaltet. 

Die CM werden 1 mal im Monat mit den Vertretern des ASTRA (Geschäftstelle MISTRA) besprochen 

und über deren weitere Bearbeitung entschieden. 

Für die Behandlung des Changemanagement wird das gleiche Wartungsgremium und die gleiche 

Web-Plattform wie für das Basissystem benutzt. 

8.3.2.2 Option Wartung Basissoftware 

Für die Wartung der Basissoftware (Oracle, Hersteller BI-Software usw.) ist ein Lizenzvertrag 

zwischen dem ASTRA und den Herstellern abzuschliessen. 

8.3.2.3 Wartung der entwickelten Module 

Für die Wartung der für das DWH entwickelten Komponenten wird ein Wartungsvertrag mit einer 

Zeitdauer von 5 Jahren abgeschlossen. Dieser beinhaltet: 

1. Grundwartung (ausserhalb des CM-Verfahrens): 

• Vorhalten von qualifiziertem Personal 

• Vorhalten der Entwicklungsumgebung 

Version 4.1, 30.09.2005 

114


• Verwaltung und Pflege des Programmcodes und Versionierung 

• Vorbeugende Massnahmen bei Konflikten mit Hardware und Betriebssystemen 

• Kleinere Anpassungen an neue Versionen von Betriebssystemen, Datenbanken und GIS- 

Basis-Software 

• Kleinere Fehlerkorrekturen und Programmanpassungen 

• Kleinere Anpassungen an die Dokumentation 

Die Grundwartung wird als Pauschale pro Jahr, zahlbar monatlich, abgegolten. 

2. Hauptwartung: Diese wird im Rahmen des Problem- und Change-Managements budgetiert 

und abgewickelt. Die Verrechnung erfolgt monatlich zu den im CM-Verfahren ermittelten Kosten. 

8.3.2.4 Nachführung der Dokumentation 

Die Dokumentation gemäss Kap. 8.1.11 ist laufend der Entwicklung des Produkts anzupassen. 

Die Aufwendungen werden über die Wartung abgegolten. 

8.3.3 Support (Problem Management) 

8.3.3.1 Vorhalten eines HelpDesk 

Für das DWH wird das gleiche HelpDesk wie für das Basissystem MISTRA verwendet. 

8.3.3.2 Option: First Level Support 

Beim First Level Support erfolgen die Anfragen direkt durch die DWH-Benutzer. Dieser Support 

wird im Normalfall intern durch Super-User und Administratoren beim Auftraggeber abgedeckt. 

8.3.3.3 Second Level Support 

Kann der First Level Support die Anfrage nicht lösen, wird er durch den First Level Support an 

den Second Level Support weitergeleitet. Die Anfragen erfolgen ausschliesslich durch die für den 

First Level Support verantwortlichen Personen (Super-User). Der Second Level Support ist immer 

Bestandteil des Leistungsumfangs des Auftragnehmers. 

8.3.3.4 Third Level Support 

Die Anfragen an den Third Level Support erfolgen grundsätzlich über den Second Level Support 

des Auftragnehmers. Der Third Level Support umfasst die weitergehende Unterstützung durch 

die Hersteller von Basissoftware. 

Version 4.1, 30.09.2005 

115


9 Planung und Organisation 

9.1 Projektmanagement 

9.1.1 Projekthandbuch, Projektplan 

Im Rahmen der Realisierung und Einführung ist das PM nach Hermes [1] fort zu führen. Die erwarteten 

Ergebnisse sind: 

• Vorgehensmodell für die Realisierung 

• Definition der Entscheidungspunkte und Ergebnisse 

• Projektorganisation des Auftragnehmers 

• Projektablauf, Terminplan 

• Supportorganisation 

• Wartungsorganisation 

• Schulungsorganisation 

Der Projektplan ist nach HERMES 2003 zu erstellen und im Verlauf von Realisierung und Einführung 

laufend nach zu führen. Er ergänzt das bestehende Projekthandbuch. 

Version 4.1, 30.09.2005 

116


9.1.2 Grobterminplan 

Version 4.1, 30.09.2005 

117


Abbildung 18: Terminplan Realisierung und Einführung 

Bemerkungen zum Terminplan: 

1. Der Beginn der Arbeiten ist per 2. August 2005, die produktive Inbetriebnahme beim ASTRA 

per 8. Januar 2007 terminiert. Im Verzugsfall kommen die Bedingungen gemäss den AGB zur 

Anwendung. 

2. Beim abgebildeten Terminplan handelt es sich um einen Vorschlag der Projektleitung. Dieser 

darf innerhalb des vorgesehenen Zeitraumes vom Auftragnehmer angepasst werden. Der definitive 

Terminplan ist im Rahmen des Projektplans zu Beginn zu erstellen. 

3. Die roten Aktivitäten sind Auftraggeberseitig zu erbringen. 

4. Die einzelnen Reviews werden jeweils mit einer Reviewsitzung zwischen Auftraggeber und 

Auftragnehmer abgeschlossen. Nahe beieinander liegende Reviews (z.B. innerhalb von 1 

Woche) werden zusammengefasst. Dies hat keine Auswirkung auf übrige Termine. 

5. Systemdesign und Entwicklung werden in Abbildung 18 in sechs Iterationen beschrieben. Die 

Zuteilung der Design- und Entwicklungsaktivitäten zu den einzelnen Iterationen kann vom Auftragnehmer 

angepasst und muss im Projektplan exakt beschrieben werden. 

9.2 Qualitätssicherung QS 

Im Rahmen der Realisierung und Einführung ist das QS nach Hermes [1] mit dem QS-Plan fort zu 

führen. Die erwarteten Ergebnisse sind: 

• QS-Plan mit QS-Organisation für die Realisierung, Aufgaben und Verantwortlichkeiten 

Version 4.1, 30.09.2005 

118


• Prüf- und Testplan mit Teilnehmer, Ablaufplan, Testverfahren, Infrastruktur, Definition der 

Prüf- und Testobjekte 

Testart je Testobjekt: Komponententest, Integrationstest, Systemtest, Abnahmetest 

Kritikalität je Testobjekt: hoch, mittel, gering 

• Testprotokolle mit Prüf- und Testobjekten mit 

Angaben zur Durchführung: Wer, wann, wo, Testumgebung, Version Testobjekt 

Resultaten: keine, geringfügige oder schwerwiegende Mängel 

• Testbericht pro Teilabnahme / Iteration 

• QS-Bericht alle 3 Monate + Schlussbericht 

Ein besonderes Augenmerk ist auf das Testverfahren zu richten. Die Tests sind sorgfältig zu planen. 

Die Granularität der Tests ist bis auf Stufe Einzelmaske und –funktion vorzusehen. Für die 

Tests sind repräsentative Testdaten mit allen Spezialfällen aufzubereiten. Im Testprogramm muss 

der Bezug zur Detailspezifikation und zum Benutzerhandbuch aufgeführt sein. Die Tests bestehen 

aus internen Tests beim Auftragnehmer und aus den Abnahmetests beim Kunden. Beide 

Tests sind zu protokollieren. Der Auftraggeber stellt die Infrastruktur für die Abnahmetests beim 

Kunden zur Verfügung. Bei den Abnahmetests mit den Kundenvertretern darf ein offensichtliches 

Programm-Fehlverhalten nicht mehr auftreten. Daher muss das Testprogramm vorgängig vom 

Auftragnehmer in der Testumgebung des Kunden durchgespielt werden. Zwischen der Bereitstellung 

der Installation für den Abnahmetest und dem Abnahmetest selbst ist eine Zeitspanne von 

10 Arbeitstagen einzurechnen, in welcher die Vertreter des ASTRA und der Testkantone die 

Tests, im oder ohne Beisein von Vertretern des Auftragnehmers, durchführen können. Die Ergebnisse 

der Tests sind anhand von Testprotokollen zu dokumentieren. 

Die für die Tests erforderlichen Testdaten sind in [5] enthalten. Weitere für die Tests erforderliche 

Daten muss der Auftragnehmer selber bereitstellen. 

9.3 Risikomanagement RM 

Im Rahmen der Realisierung und Einführung ist das RM nach Hermes [1] fort zu führen. Die erwarteten 


• RM-Plan 

• Risikokatalog mit Auswirkungen und Massnahmen zur Risikominimierung mit Überprüfung 

der Risiken alle 3 Monate 

• RM-Bericht alle 3 Monate + Schlussbericht 

9.4 Konfigurationsmanagement KM 

Im Rahmen der Realisierung und Einführung ist das KM nach Hermes [1] zu erstellen und fort zu 

führen. Besonderes Augenmerk gilt der langfristigen Sicherstellung der Wartung. Die erwarteten 


Version 4.1, 30.09.2005 

119


• KM-Plan mit Organisation, Aufgaben und Verantwortlichkeiten, Aufbau des Konfigurationsmanagements, 

Zusammenarbeit, Hilfsmittel, Change-Management, Namenskonventionen, 

Entwicklungsrichtlinien, Verwaltung Quell-Code, Versionenmanagement, Datensicherung 

• Konfigurationsidentifikation der Hard- und Softwarekomponenten pro Konfiguration. 

• Ergebnisbibliothek mit Identifikation, Versionierung, Bezug zum Testverfahren, Zuordnung 

zum Systemdesign und zur Konfigurationsidentifikation 

• KM-Schlussbericht 

Version 4.1, 30.09.2005 

120

Pflichtenheft Basissystem - MISTRA Public

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?