IVS-Wiki - Benutzerbeiträge [de]

Spielwiese

2016-10-10T15:13:37Z

Lahdya:

Testseite sd

[[Los4-Intern:Testseite]]

Test
2. Test

TOGAF-Phase E

2016-02-23T12:39:54Z

Lahdya:

== Phase E – Möglichkeiten und Lösungen ==

;TOGAF

: Phase E. ist die erste Phase, die sich direkt mir der Implementierung befasst. Sie beschreibt den Prozess der Identifizierung von Instrumenten (Projekte, Programme oder Portfolios), zur Implementierung der Zielarchitektur, die in den vorherigen Phasen entworfen wurde.

;IVS-Rahmenarchitektur
: Die Phase E beschreibt den Prozess der Identifizierung von Instrumenten, zur Implementierung der IVS-Architekturprojekte.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Bestimmung/Sicherstellung der wichtigsten Attribute für Veränderungen im Unternehmen ||
|-
| 2 || Bestimmung von geschäftlichen Rahmenbedingungen für die Implementierung ||
|-
| 3 || Review und Konsolidierung von Ergebnissen aus der Gap-Analyse aus Phasen B und D ||
|-
| 4 || Review von IT-Anforderungen aus einer funktionalen Perspektive heraus ||
|-
| 5 || Konsolidierung und Abstimmung von Anforderungen an die Interoperabilität ||
|-
| 6 || Detailliertere Bestimmung und Überprüfung von Abhängigkeiten ||
|-
| 7 || Untersuchung der Reife und des Risikos für Veränderungen aus geschäftlicher Sicht ||
|-
| 8 || Formulierung einer groben Implementierungs- und Migrationsstrategie ||
|-
| 9 || Identifizierung und Gruppierung wichtigster Arbeitspakete ||
|-
| 10 || Identifizierung von Transitionsarchitekturen ||
|-
| 11 || Erstellung von Portfolio- und Projektvereinbarungen und Aktualisierung der Architekturen ||
|}

-----------------------------------------
Es können alternative Lösungsansätze und Architekturbausteine diskutiert und bewertet werden, um im Anschluss möglichst wenige, dafür aber konkrete Empfehlungen zu geben.

TOGAF-Phase E

2016-02-23T12:38:19Z

Lahdya:

== Phase E – Möglichkeiten und Lösungen ==

;TOGAF

: Phase E. ist die erste Phase, die sich direkt mir der Implementierung befasst. Sie beschreibt den Prozess der Identifizierung von Instrumenten (Projekte, Programme oder Portfolios), zur Implementierung der Zielarchitektur, die in den vorherigen Phasen entworfen wurde.

;IVS-Rahmenarchitektur
: Die Phase E beschreibt den Prozess der Identifizierung von Instrumenten, zur Implementierung der IVS-Architekturprojekte.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Bestimmung/Sicherstellung der wichtigsten Attribute für Veränderungen im Unternehmen ||
|-
| 2 || Bestimmung von geschäftlichen Rahmenbedingungen für die Implementierungr ||
|-
| 3 || Review und Konsolidierung von Ergebnissen aus der Gap-Analyse aus Phasen B und D ||
|-
| 4 || Review von IT-Anforderungen aus einer funktionalen Perspektive heraus ||
|-
| 5 || Konsolidierung und Abstimmung von Anforderungen an die Interoperabilität ||
|-
| 6 || Detailliertere Bestimmung und Überprüfung von Abhängigkeiten ||
|-
| 7 || Untersuchung der Reife und des Risikos für Veränderungen aus geschäftlicher Sicht ||
|-
| 8 || Formulierung einer groben Implementierungs- und Migrationsstrategie ||
|-
| 9 || Identifizierung und Gruppierung wichtigster Arbeitspakete ||
|-
| 10 || Identifizierung von Transitionsarchitekturen ||
|-
| 11 || Erstellung von Portfolio- und Projektvereinbarungen und Aktualisierung ||
|}

-----------------------------------------
Es können alternative Lösungsansätze und Architekturbausteine diskutiert und bewertet werden, um im Anschluss möglichst wenige, dafür aber konkrete Empfehlungen zu geben.

TOGAF-Phase C

2016-02-23T12:25:25Z

Lahdya:

== Phase C – Informationssystem-Architektur ==

;TOGAF

: In Phase C erfolgt die Dokumentation der grundlegenden Struktur von unternehmenseigenen IT-Systemen, die die wichtigsten Informationsobjekte und Anwendungssysteme enthalten und diese verarbeiten. Diese Phase besteht aus zwei Schritten, die entweder nacheinander oder gleichzeitig entwickelt werden können:
* Datenarchitektur
* Anwendungsarchitektur.

;IVS-Rahmenarchitektur
: In der Phase C wird die Dokumentation der IVS-Architekturprojekte finalisiert und erstellt.

=== Datenarchitektur ===

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel- Datenarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von RoadmapKomponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Datenarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

=== Anwendungsarchitektur ===

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Anwendungsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel- Anwendungsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von RoadmapKomponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Anwendungsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden die notwendigen Daten und Anwendungen spezifiziert.
*Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
*Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.

TOGAF-Phase D

2016-02-23T12:20:23Z

Lahdya:

== Phase D – Technologie-Architektur ==

;TOGAF

: In Phase D erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie.

;IVS-Rahmenarchitektur
: In der Phase D erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme, aus Hardware, Software und Kommunikationstechnologie der IVS-Architekturprojekte.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Technologiearchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel- Technologiearchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von RoadmapKomponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Technologiearchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden Technologien ausgewählt und vorgeschlagen, die zur späteren Umsetzung im Rahmen der Referenz- und echten Architekturen herangezogen werden können, z.B. Web-Services, XML oder Service-Orientierte-Architekturen.

'''Hinweis:''' Fragen der Architektur von Datensicherheit und Datenschutz können im Projekt allenfalls identifiziert, aber nicht bearbeitet werden. Wie die Erfahrungen im C-ITS-Eurokorridor zeigen, ist das mit erheblichen Aufwänden verbunden, die das vorliegende Budget sprengen würde.

TOGAF-Phase C

2016-02-23T12:11:27Z

Lahdya:

== Phase C – Informationssystem-Architektur ==

;TOGAF

: In Phase C erfolgt die Dokumentation der grundlegenden Struktur von unternehmenseigenen IT-Systemen, die die wichtigsten Informationsobjekte und Anwendungssysteme enthalten und diese verarbeiten. Diese Phase besteht aus zwei Schritten, die entweder nacheinander oder gleichzeitig entwickelt werden können:
* Datenarchitektur
* Anwendungsarchitektur.

;IVS-Rahmenarchitektur
: In der Phase C wird die Dokumentation der IVS-Architekturprojekte finalisiert und erstellt.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel- Datenarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von RoadmapKomponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Datenarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden die notwendigen Daten und Anwendungen spezifiziert.
*Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
*Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.

TOGAF-Phase C

2016-02-23T12:10:41Z

Lahdya:

== Phase C – Informationssystem-Architektur ==

;TOGAF

: In Phase C erfolgt die Dokumentation der grundlegenden Struktur von unternehmenseigenen IT-Systemen, die die wichtigsten Informationsobjekte und Anwendungssysteme enthalten und diese verarbeiten. Diese Phase besteht aus zwei Schritten, die entweder nacheinander oder gleichzeitig entwickelt werden können:
* Datenarchitektur
* Anwendungsarchitektur.

;IVS-Rahmenarchitektur
: In der Phase C wird die Dokumentation der IVS-Architekturprojekte erstellt.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel- Datenarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von RoadmapKomponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Datenarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden die notwendigen Daten und Anwendungen spezifiziert.
*Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
*Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.

TOGAF-Phase C

2016-02-23T12:09:40Z

Lahdya:

== Phase C – Informationssystem-Architektur ==

;TOGAF

: In Phase C erfolgt die Dokumentation der grundlegenden Struktur von unternehmenseigenen IT-Systemen, die die wichtigsten Informationsobjekte und Anwendungssysteme enthalten und diese verarbeiten. Diese Phase besteht aus zwei Schritten, die entweder nacheinander oder gleichzeitig entwickelt werden können:
* Datenarchitektur
* Anwendungsarchitektur.

;IVS-Rahmenarchitektur
: In der Phase C wird die Dokumentation der IVS-Architekturprojekte erstellt.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel- Datenarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse Definition von RoadmapKomponenten ||
|-
| 5 || Definition von RoadmapKomponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Datenarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden die notwendigen Daten und Anwendungen spezifiziert.
*Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
*Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.

TOGAF-Phase C

2016-02-23T12:02:26Z

Lahdya:

== Phase C – Informationssystem-Architektur ==

;TOGAF

: In Phase C erfolgt die Dokumentation der grundlegenden Struktur von unternehmenseigenen IT-Systemen, die die wichtigsten Informationsobjekte und Anwendungssysteme enthalten und diese verarbeiten. Diese Phase besteht aus zwei Schritten, die entweder nacheinander oder gleichzeitig entwickelt werden können:
* Datenarchitektur
* Anwendungsarchitektur.

;IVS-Rahmenarchitektur
: In der Phase B wird die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von Roadmap-Komponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Geschäftsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden die notwendigen Daten und Anwendungen spezifiziert.
*Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
*Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.

TOGAF-Phase C

2016-02-23T12:00:48Z

Lahdya:

== Phase C – Informationssystem-Architektur ==

;TOGAF

: In Phase C erfolgt die Dokumentation der grundlegenden Struktur von unternehmenseigenen IT-Systemen, die die wichtigsten Informationsobjekte und Anwendungssysteme enthalten und diese verarbeiten. Diese Phase besteht aus zwei Schritten, die entweder nacheinander oder gleichzeitig entwickelt werden können:
• Datenarchitektur
• Anwendungsarchitektur.

;IVS-Rahmenarchitektur
: In der Phase B wird die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von Roadmap-Komponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Geschäftsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden die notwendigen Daten und Anwendungen spezifiziert.
*Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
*Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.

TOGAF-Phase B

2016-02-23T11:53:18Z

Lahdya:

== Phase B – Geschäftsarchitektur ==

;TOGAF

: In Phase B erfolgt die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten Architekturvision.

;IVS-Rahmenarchitektur
: In der Phase B wird die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von Roadmap-Komponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Geschäftsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.

TOGAF-Phase B

2016-02-23T11:52:24Z

Lahdya:

== Phase B – Geschäftsarchitektur ==

;TOGAF

: In Phase B erfolgt die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten Architekturvision.

;IVS-Rahmenarchitektur
: In der Phase B wird die Entwicklung einer Geschäftsarchitektur für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von Roadmap-Komponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Geschäftsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

-----------------------------------------
Es werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.

TOGAF-Phase B

2016-02-23T11:51:59Z

Lahdya:

== Phase B – Geschäftsarchitektur ==

;TOGAF

: In Phase B erfolgt die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten Architekturvision.

;IVS-Rahmenarchitektur
: In der Phase B wird die Entwicklung einer Geschäftsarchitektur für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von Roadmap-Komponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschaft ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Geschäftsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

Erstellung der Dokumentation für die
Architekturdefinition

-----------------------------------------
Es werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.

TOGAF-Phase B

2016-02-23T11:51:09Z

Lahdya:

== Phase B – Geschäftsarchitektur ==

;TOGAF

: In Phase B erfolgt die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten Architekturvision.

;IVS-Rahmenarchitektur
: In der Phase B wird die Entwicklung einer Geschäftsarchitektur für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von Roadmap-Komponenten ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschafts ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Geschäftsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

Erstellung der Dokumentation für die
Architekturdefinition

-----------------------------------------
Es werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.

TOGAF-Phase B

2016-02-23T11:50:25Z

Lahdya:

== Phase B – Geschäftsarchitektur ==

;TOGAF

: In Phase B erfolgt die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten Architekturvision.

;IVS-Rahmenarchitektur
: In der Phase B wird die Entwicklung einer Geschäftsarchitektur für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ||
|-
| 2 || Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur ||
|-
| 3 || Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur ||
|-
| 4 || Durchführung einer Gap-Analyse ||
|-
| 5 || Definition von Roadmap-Komponentens ||
|-
| 6 || Klärung der Auswirkungen auf die gesamte Architekturlandschafts ||
|-
| 7 || Durchführung eines formalen Stakeholder-Reviews ||
|-
| 8 || Finalisierung der Geschäftsarchitektur ||
|-
| 9 || Erstellung der Dokumentation für die Architekturdefinition ||
|}

Erstellung der Dokumentation für die
Architekturdefinition

-----------------------------------------
Es werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.

TOGAF-Phase A

2016-02-23T11:39:09Z

Lahdya:

== Phase A – Architekturvision ==

;TOGAF

: In Phase A erfolgen der Projektaufbau und der Anstoß einer Iteration des Architekturennvicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen und Erwartungen in Bezug auf den jeweiligen Durchlauf. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.

;IVS-Rahmenarchitektur
: In der Phase A wird den Projektaufbau für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Aufsetzen des Architekturprojekts ||
|-
| 2 || Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ||
|-
| 3 || Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen ||
|-
| 4 || Bewertung der Geschäftsfähigkeiten ||
|-
| 5 || Bewertung der Reife für eine Transformation des Geschäfts ||
|-
| 6 || Definition des Wirkungsbereichs ||
|-
| 7 || Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ||
|-
| 8 || Entwicklung der Architekturvision ||
|-
| 9 || Definition des Wertbeitrags der Zielarchitektur und der KPIs ||
|-
| 10 || Identifizierung der Risiken einer Geschäfts-Transformation und der Aktivitäten zur Risikominimierung ||
|-
| 11 || Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit,Sichern der Zustimmung ||
|}

-----------------------------------------------------------------------------
Es werden die Ziele der Bundesregierung und der weiteren Stakeholder für das Straßenverkehrswesen analysiert und auf die High-Level-Capability angewendet. Relevante Bestandteile der Phase sind die Identifikation der betroffenen Stakeholder, die Darstellung des Mehrwerts durch die Architektur und der möglichen Risiken sowie die Entwicklung und Dokumentation der Vision. Hier ergeben sich erste Anforderungen an die Interoperabilität.

TOGAF-Phase A

2016-02-23T11:35:15Z

Lahdya:

== Phase A – Architekturvision ==

;TOGAF

: In Phase A erfolgen der Projektaufbau und der Anstoß einer Iteration des Architekturennvicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen und Erwartungen in Bezug auf den jeweiligen Durchlauf. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.

;IVS-Rahmenarchitektur
: In der Phase A werden die Grundlagen für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Aufsetzen des Architekturprojekts ||
|-
| 2 || Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ||
|-
| 3 || Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen ||
|-
| 4 || Bewertung der Geschäftsfähigkeiten ||
|-
| 5 || Bewertung der Reife für eine Transformation des Geschäfts ||
|-
| 6 || Definition des Wirkungsbereichs ||
|-
| 7 || Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ||
|-
| 8 || Entwicklung der Architekturvision ||
|-
| 9 || Definition des Wertbeitrags der Zielarchitektur und der KPIs ||
|-
| 10 || Identifizierung der Risiken einer Geschäfts-Transformation und der Aktivitäten zur Risikominimierung ||
|-
| 11 || Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit,Sichern der Zustimmung ||
|}

-----------------------------------------------------------------------------
Es werden die Ziele der Bundesregierung und der weiteren Stakeholder für das Straßenverkehrswesen analysiert und auf die High-Level-Capability angewendet. Relevante Bestandteile der Phase sind die Identifikation der betroffenen Stakeholder, die Darstellung des Mehrwerts durch die Architektur und der möglichen Risiken sowie die Entwicklung und Dokumentation der Vision. Hier ergeben sich erste Anforderungen an die Interoperabilität.

TOGAF-Phase A

2016-02-23T11:31:26Z

Lahdya:

== Phase A – Architekturvision ==

;TOGAF

: In Phase A erfolgen der Projektaufbau und der Anstoß einer Iteration des Architekturennvicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen und Erwartungen in Bezug auf den jeweiligen Durchlauf. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.

;IVS-Rahmenarchitektur
: In der Phase A werden die Grundlagen für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Aufsetzen des Architekturprojekts ||
|-
| 2 || Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ||
|-
| 3 || Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen ||
|-
| 4 || Bewertung der Geschäftsfähigkeiten ||
|-
| 5 || Bewertung der Reife für eine Transformation des Geschäfts ||
|-
| 6 || Definition des Wirkungsbereichs ||
|-
| 7 || Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ||
|-

-----------------------------------------------------------------------------
Es werden die Ziele der Bundesregierung und der weiteren Stakeholder für das Straßenverkehrswesen analysiert und auf die High-Level-Capability angewendet. Relevante Bestandteile der Phase sind die Identifikation der betroffenen Stakeholder, die Darstellung des Mehrwerts durch die Architektur und der möglichen Risiken sowie die Entwicklung und Dokumentation der Vision. Hier ergeben sich erste Anforderungen an die Interoperabilität.

TOGAF-Phase A

2016-02-23T11:29:56Z

Lahdya:

== Phase A – Architekturvision ==

;TOGAF

: In Phase A erfolgen der Projektaufbau und der Anstoß einer Iteration des Architekturennvicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen und Erwartungen in Bezug auf den jeweiligen Durchlauf. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.

;IVS-Rahmenarchitektur
: In der Phase A werden die Grundlagen für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Aufsetzen des Architekturprojekts ||
|-
| 2 || Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen ||
|-
| 3 || Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen ||
|-
| 4 || Bewertung der Geschäftsfähigkeiten ||
|-
| 5 || Bewertung der Reife für eine Transformation des Geschäfts ||
|-
| 6 || Definition des Wirkungsbereichs ||
|-
| 7 || Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien ||
|-

-----------------------------------------
Es werden für eine spezifische High-Level-Capability die betroffenen Organisationstypen mit ihren Interessen und Zielen identifiziert (z.B. Reisende, öffentliche und private Mobilitätsanbieter, Service-Provider, u.a.). Zur Findung und Generierung von High-Level-Capabilities können beispielsweise die Lose 2-4 herangezogen werden. Bestehende Frameworks und Vorgaben für diesen Bereich werden recherchiert und eingebracht, das Wiki wird mit den Arbeitsergebnissen befüllt und damit werden die Ergebnisse den anderen Losen zur Verfügung gestellt.

-----------------------------------------------------------------------------
Es werden die Ziele der Bundesregierung und der weiteren Stakeholder für das Straßenverkehrswesen analysiert und auf die High-Level-Capability angewendet. Relevante Bestandteile der Phase sind die Identifikation der betroffenen Stakeholder, die Darstellung des Mehrwerts durch die Architektur und der möglichen Risiken sowie die Entwicklung und Dokumentation der Vision. Hier ergeben sich erste Anforderungen an die Interoperabilität.

TOGAF-Phase A

2016-02-23T11:28:47Z

Lahdya:

== Phase A – Architekturvision ==

;TOGAF

: In Phase A erfolgen der Projektaufbau und der Anstoß einer Iteration des Architekturennvicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen und Erwartungen in Bezug auf den jeweiligen Durchlauf. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.

;IVS-Rahmenarchitektur
: In der Phase A werden die Grundlagen für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

{| class="wikitable"
! Schritt !! TOGAF !! IVS-Rahmenarchitektur
|-
| 1 || Aufsetzen des Architekturprojekts || |-
| 2 || Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen || |-
| 3 || Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen || |-
| 4 || Bewertung der Geschäftsfähigkeiten || |-
| 5 || Bewertung der Reife für eine Transformation des Geschäfts || |-
| 6 || Definition des Wirkungsbereichs || |-
| 7 || Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien || |-

-----------------------------------------
Es werden für eine spezifische High-Level-Capability die betroffenen Organisationstypen mit ihren Interessen und Zielen identifiziert (z.B. Reisende, öffentliche und private Mobilitätsanbieter, Service-Provider, u.a.). Zur Findung und Generierung von High-Level-Capabilities können beispielsweise die Lose 2-4 herangezogen werden. Bestehende Frameworks und Vorgaben für diesen Bereich werden recherchiert und eingebracht, das Wiki wird mit den Arbeitsergebnissen befüllt und damit werden die Ergebnisse den anderen Losen zur Verfügung gestellt.

-----------------------------------------------------------------------------
Es werden die Ziele der Bundesregierung und der weiteren Stakeholder für das Straßenverkehrswesen analysiert und auf die High-Level-Capability angewendet. Relevante Bestandteile der Phase sind die Identifikation der betroffenen Stakeholder, die Darstellung des Mehrwerts durch die Architektur und der möglichen Risiken sowie die Entwicklung und Dokumentation der Vision. Hier ergeben sich erste Anforderungen an die Interoperabilität.

Los3 Standards

2016-02-18T13:55:16Z

Lahdya: Die Seite wurde neu angelegt: „{| class="wikitable" ! Lfd. Nr !! Referenz || Bermerkung |- | 1 || EsayWay: Deployment Guidelines für Traffic Management und Traveller Information Services(s…“

{| class="wikitable"
! Lfd. Nr !! Referenz || Bermerkung
|-
| 1 || EsayWay: Deployment Guidelines für Traffic Management und Traveller Information Services(siehe http://www.easyway-its.eu/deployment-guidelines/), 2012 ||
|-
| 2 || DIN SPEC 91213 (OTS 2 Schnittstellenspezifikation), Beuth Verlag, 2011 ||
|-

Los3 Literatur

2016-02-18T13:53:47Z

Lahdya:

{| class="wikitable"
! Lfd. Nr !! Referenz || Bermerkung
|-
| 1 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 2 || Hessischen Landesamtes für Straßen- und Verkehrswesen, Schlussbericht zum Projekt WAYflow, 2003 ||
|-
| 3 || Riegelhuth, Kirschfink, Dölger, Stüben, Bohlander, Technische Grundlage des ISM-basierten Korridormanagements und erste Anwendungserfahrungen ||
|-
| 4 || Riegelhuth, Länderübergreifende Verkehrssteuerung in Autobahnkorridoren, Straßenverkehrstechnik, 53, 7, Kirschbaum Verlag, Bonn, 442-448, 2009||
|-
| 5 || Albert Speer & Partner GmbH: LDC – Long Distance Corridor Demonstration Project, Schlussbericht „LDC Pilotentwicklung und Evaluierung“, 2007||
|-
| 6 || Kochs, Kirschfink, Nutzung verteilter Systeme zum Aufbau einer Verkehrsdateninfrastruktur für das strategische Verkehrsmanagement – Teil 2: Zuständigkeitsübergreifendes Strategiemanagement, Straßenverkehrstechnik, 2006||
|-
| 7 || Hessisches Landesamt für Straßen- und Verkehrswesen Newsletter zum Projekt „Long Distance Corridors“, 2008 ||
|-
| 8 || Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik, FGSV-Nr. 305
(http://www.fgsvverlag.de/catalog/product_info.php?products_id=3016)||
|-
| 9 || Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVSRichtlinien mit ÖV-Relevanz, http://www.mobilitaet21.de/programme/fops/ivs-architektur/ ||
|-
| 10 || European ITS Framework Architecture und E-Frame ||
|-
| 11 || Krüger, Philip: Methodische und konzeptionelle Hinweise zur Entwicklung einer IVS-Rahmenarchitektur für Deutschland, Schriftenreihe des Instituts für Verkehr (V30). Darmstadt, [Buch], 2013 ||
|-
| 12 || Status und Rahmenbedingungen für Intelligente Verkehrssysteme in Deutschland, Bericht gemäß Artikel 17(1) der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates von 7. Juli 2010 zum Rahmen für die Einführung intelligenter Verkehrssysteme im Straßenverkehr und für deren Schnittstellen zu anderen Verkehrsträgern ||
|-
| 13 || Internationale und nationale Telematik-Leitbilder und ITS-Architekturen im Straßenverkehr, BASt-Bericht F 79, Manfred Boltze, Philip Krüger, Fachgebiet Verkehrsplanung und Verkehrstechnik, Technische Universität Darmstadt, Achim Reusswig, Ingo Hillebrand, ZIV - Zentrum für integrierte Verkehrssysteme, Technische Universität Darmstadt, 2011 ||
|-
| 14 || Landeshauptstadt Düsseldorf, Schlussbericht zum Projekt Dmotion, 2011 ||
|-
| 15 || Hinweise zur Strategieanwendung im dynamischen Verkehrsmanagement, FGSV-Nr. 381/1, 2011(http://www.fgsv-verlag.de/catalog/product_info.php?products_id=2957)||
|-
| 16 || Leitfaden Verkehrsmanagement Region Frankfurt RheinMain – Leitfaden für die Anwendung (2. Auflage), Hessen Mobil (Hrsg.), Wiesbaden, 2014 ||
|-

Los3 Literatur

2016-02-18T13:51:34Z

Lahdya:

{| class="wikitable"
! Lfd. Nr !! Referenz || Bermerkung
|-
| 1 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 2 || Hessischen Landesamtes für Straßen- und Verkehrswesen, Schlussbericht zum Projekt WAYflow, 2003 ||
|-
| 3 || Riegelhuth, Kirschfink, Dölger, Stüben, Bohlander, Technische Grundlage des ISM-basierten Korridormanagements und erste Anwendungserfahrungen ||
|-
| 4 || Riegelhuth, Länderübergreifende Verkehrssteuerung in Autobahnkorridoren, Straßenverkehrstechnik, 53, 7, Kirschbaum Verlag, Bonn, 442-448, 2009||
|-
| 5 || Albert Speer & Partner GmbH: LDC – Long Distance Corridor Demonstration Project, Schlussbericht „LDC Pilotentwicklung und Evaluierung“, 2007||
|-
| 6 || Kochs, Kirschfink, Nutzung verteilter Systeme zum Aufbau einer Verkehrsdateninfrastruktur für das strategische Verkehrsmanagement – Teil 2: Zuständigkeitsübergreifendes Strategiemanagement, Straßenverkehrstechnik, 2006||
|-
| 7 || Hessisches Landesamt für Straßen- und Verkehrswesen Newsletter zum Projekt „Long Distance Corridors“, 2008 ||
|-
| 8 || Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik, FGSV-Nr. 305
(http://www.fgsvverlag.de/catalog/product_info.php?products_id=3016)||
|-
| 9 || Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVSRichtlinien mit ÖV-Relevanz, http://www.mobilitaet21.de/programme/fops/ivs-architektur/ ||
|-
| 10 || European ITS Framework Architecture und E-Frame ||
|-
| 11 || Krüger, Philip: Methodische und konzeptionelle Hinweise zur Entwicklung einer IVS-Rahmenarchitektur für Deutschland, Schriftenreihe des Instituts für Verkehr (V30). Darmstadt, [Buch], 2013 ||
|-
| 12 || Status und Rahmenbedingungen für Intelligente Verkehrssysteme in Deutschland, Bericht gemäß Artikel 17(1) der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates von 7. Juli 2010 zum Rahmen für die Einführung intelligenter Verkehrssysteme im Straßenverkehr und für deren Schnittstellen zu anderen Verkehrsträgern ||
|-
| 13 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 14 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 15 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-

Los3 Literatur

2016-02-18T13:50:21Z

Lahdya:

{| class="wikitable"
! Lfd. Nr !! Referenz || Bermerkung
|-
| 1 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 2 || Hessischen Landesamtes für Straßen- und Verkehrswesen, Schlussbericht zum Projekt WAYflow, 2003 ||
|-
| 3 || Riegelhuth, Kirschfink, Dölger, Stüben, Bohlander, Technische Grundlage des ISM-basierten Korridormanagements und erste Anwendungserfahrungen ||
|-
| 4 || Riegelhuth, Länderübergreifende Verkehrssteuerung in Autobahnkorridoren, Straßenverkehrstechnik, 53, 7, Kirschbaum Verlag, Bonn, 442-448, 2009||
|-
| 5 || Albert Speer & Partner GmbH: LDC – Long Distance Corridor Demonstration Project, Schlussbericht „LDC Pilotentwicklung und Evaluierung“, 2007||
|-
| 6 || Kochs, Kirschfink, Nutzung verteilter Systeme zum Aufbau einer Verkehrsdateninfrastruktur für das strategische Verkehrsmanagement – Teil 2: Zuständigkeitsübergreifendes Strategiemanagement, Straßenverkehrstechnik, 2006||
|-
| 7 || Hessisches Landesamt für Straßen- und Verkehrswesen Newsletter zum Projekt „Long Distance Corridors“, 2008 ||
|-
| 8 || Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik, FGSV-Nr. 305
(http://www.fgsvverlag.de/catalog/product_info.php?products_id=3016)||
|-
| 9 || Entwicklung einer ÖV-IVS-Rahmenarchitektur in Deutschland unter Einbindung Europäischer IVSRichtlinien mit ÖV-Relevanz, http://www.mobilitaet21.de/programme/fops/ivs-architektur/ ||
|-
| 10 || European ITS Framework Architecture und E-Frame ||
|-
| 11 || Krüger, Philip: Methodische und konzeptionelle Hinweise zur Entwicklung einer IVS-Rahmenarchitektur für Deutschland, Schriftenreihe des Instituts für Verkehr (V30). Darmstadt, [Buch], 2013 ||
|-
| 12 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 13 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 14 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 15 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-

Los3 Literatur

2016-02-18T13:47:53Z

Lahdya:

{| class="wikitable"
! Lfd. Nr !! Referenz || Bermerkung
|-
| 1 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 2 || Hessischen Landesamtes für Straßen- und Verkehrswesen, Schlussbericht zum Projekt WAYflow, 2003 ||
|-
| 3 || Riegelhuth, Kirschfink, Dölger, Stüben, Bohlander, Technische Grundlage des ISM-basierten Korridormanagements und erste Anwendungserfahrungen ||
|-
| 4 || Riegelhuth, Länderübergreifende Verkehrssteuerung in Autobahnkorridoren, Straßenverkehrstechnik, 53, 7, Kirschbaum Verlag, Bonn, 442-448, 2009||
|-
| 5 || Albert Speer & Partner GmbH: LDC – Long Distance Corridor Demonstration Project, Schlussbericht „LDC Pilotentwicklung und Evaluierung“, 2007||
|-
| 6 || Kochs, Kirschfink, Nutzung verteilter Systeme zum Aufbau einer Verkehrsdateninfrastruktur für das strategische Verkehrsmanagement – Teil 2: Zuständigkeitsübergreifendes Strategiemanagement, Straßenverkehrstechnik, 2006||
|-
| 7 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 8 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 9 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 10 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 11 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 12 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 13 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 14 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-
| 15 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strategies and ITS Developments ||
|-

Los3 Literatur

2016-02-18T13:46:02Z

Lahdya:

Los3 Literatur

2016-02-18T13:44:39Z

Lahdya:

Los3 Literatur

2016-02-18T13:43:27Z

Lahdya: Die Seite wurde neu angelegt: „{| class="wikitable" ! Lfd. Nr !! Referenz || Bermerkung |- | 1 || Riegelhuth, Sparmann, Traffic Management Approach in Conurbations by Using Intermodal Strat…“

Los1LiteraturListe

2016-02-18T13:32:43Z

Lahdya: