MISTRA Managementinformationssystem Strasse und Strassenverkehr. Configuration, Change und Release Management

Transkript

1 Eidgenössisches Departement für Umwelt, Verkehr, Energie und Kommunikation UVEK Bundesamt für Strassen ASTRA F. Pointet, J.-P. Bolli, Version 1.2 vom Doku Code: M QS MISTRA Managementinformationssystem Strasse und Strassenverkehr KM-Plan Gesamtprojekt Techdata AG Projekt- und Baumanagement Effingerstrasse 13, Postfach, 3001 Bern Tel , Fax bern@techdata.net C:\Documents and Settings\jpb.TECHDATA\Bureau\R M KM-plan V12.doc

2 , Impressum Impressum Erstelldatum: 2. September Letzte Änderung: 31. Juli 2009 Projektleiter: Florian Besançon, Antoine Buntschu Assistenz: François Pointet, Jean-Pierre Bolli Verzeichnis/Datei: O:\PROJ\TDLA\ASTRA GS MISTRA LA.N.07003\Betrieb\Konfigurationsmanagement\R M KM-plan V12.doc Seitenanzahl gesamt inkl. Deckblatt 25 und Inhaltsverzeichnis: Dokumentenverwaltung Version Datum Autor Bemerkungen JPB Ergänzung nach Arbeitssitzungen April/März FP Erarbeitung Kapitel FP Ergänzungen gemäss Gesamtsteurungssitzung vom FP Kapitel 7.5 mit Dokumentname ergänzt FP Ergänzungen gemäss Sitzung vom FP Ergänzungen gemäss Sitzung vom JPB Version zur Genehmigung durch GPL JPB Bemerkungen Gesamtsteuerungssitzung und KRM vom Sept JPB Definitionen (Kap. 0.3), KRM-Organisation (Kap. 3.2), Verfahren (Kap. 5.2), Wartung Dokumentation (Kap. 7.2), Identifikation Versionisierung (Kap. 7.5) R M KM-plan V12.doc

3 Inhaltsverzeichnis Inhaltsverzeichnis Seite 0. Allgemeines HERMES 2003, Submodell Konfigurationsmanagement ITIL Incident Management Problem Management Change Management Release Management Configuration Management Definitionen Abgrenzungen 4 1. Zweck des Dokuments 5 2. Systemprozess MISTRA 6 3. Organisation Betriebsorganisation KRM-Organisation Rollenbeschrieb KRM Sitzungswesen KRM Koordination Release Management Wartungsleitung Fachapplikation Anforderungen an die Subsysteme Schnittstellen Schnittstelle zum BIT (Betrieb) Schnittstelle zu IT-Dienstleister (Entwickler) Schnittstelle zu KOGIS/Swisstopo Schnittstelle zum Helpdesk Schnittstelle zu Projekt (ab Phase Realisierung, bzw. Implementation) Change Management Zustände Verfahren Werkzeuge Release-Management Verfahren Planung Configuration Management Abgrenzung Anforderungen an die Ergebnisse (Ergebnisbibliothek) Ablagestruktur Identifikation der Release Identifikation externe Libraries, Dateien, Schnittstellen Namenskonventionen KRM-Dokumente 19 R M KM-plan V12.doc

4 Inhaltsverzeichnis Abbildungen Seite Tab. 1: Begriffsdefinitionen KRM MISTRA 3 Tab. 2: verwendete Abkürzungen 4 Tab. 3: Sitzung Koordination KRM 8 Tab. 4: Sitzung Wartungsleitung Fachapplikation 9 Tab. 5: Benachrichtigungen 14 Tab. 6: Rollen und Rollenträger 14 Tab. 7: Zeitplanung Release Management 15 Tab. 8: Objekte des Configuration Management 16 Tab. 9: Release Identifikation 18 Tab. 10: Release Identifikation vor Produktion 18 Tab. 11: Identifikation externe Libraries, Dateien, Schnittstellen 19 Tab. 12: Definition Dateinamen 19 Tabellen Seite Tab. 1: Begriffsdefinitionen KRM MISTRA 3 Tab. 2: verwendete Abkürzungen 4 Tab. 3: Sitzung Koordination KRM 8 Tab. 4: Sitzung Wartungsleitung Fachapplikation 9 Tab. 5: Benachrichtigungen 14 Tab. 6: Rollen und Rollenträger 14 Tab. 7: Zeitplanung Release Management 15 Tab. 8: Objekte des Configuration Management 16 Tab. 9: Release Identifikation 18 Tab. 10: Release Identifikation vor Produktion 18 Tab. 11: Identifikation externe Libraries, Dateien, Schnittstellen 19 Tab. 12: Definition Dateinamen 19 R M KM-plan V12.doc

5 Inhaltsverzeichnis Referenzen Titel Autor(en) Version Nr. / Datum [1] HERMES Systementwicklung Informatikstrategieorgan Bund ISB [2] HD-Plan Gesamtprojekt F. Pointet, J.-P. Bolli [3] Geschäftsprozesse Basissystem /DWH ASTRA M. Peyinghaus, M. Cremosnik / / [4] Projekthandbuch Gesamtsystem J.-P. Bolli / [5] Projektplan Gesamtsystem J.-P. Bolli 4.1 / [6] MISTRA Glossar R. Bobst, E. Bernard [7] Structure de la documentation technique de l OFROU A. Jeanneret, C. Joseph 4.3 / / 2008 [8] Vorlage Configuration Identifikation F. Pointet 0.5 / 2008 [9] Anwendungshandbuch KRM-Tool MANTIS R. A. Cattelan 0.92 / [10] Quick-Step Manual CM F. Besançon 0.9 / R M KM-plan V12.doc

6 Allgemeines 0. Allgemeines 0.1. HERMES 2003, Submodell Konfigurationsmanagement Grundsätzlich wird das Submodell Konfigurationsmanagement gemäss Hermes Systementwicklung 2003 verwendet, um den Betrieb der MISTRA-Applikationen bezüglich Problem-, Change-, Konfigurations- und Release Management zu unterstützen. Gemäss Hermes sind die Aktivitäten folgendermassen organisiert: Abb. 1: Aktivitätendiagramm HERMES Submodell Konfigurationsmanagement Das Konfigurationsmanagement sorgt mit der Vorgabe und Durchführung von KM- Massnahmen für die Integrität des Systems sowie für die Nachvollziehbarkeit seiner Entwicklung. Es unterstützt sowohl die Entscheidungsfindung in Bezug auf technische und wirtschaftliche Konsequenzen bei Änderungen als auch die Abnahme und Überwachung der Ergebnisse. Die Aufgaben des Konfigurationsmanagements müssen über das abzuwickelnde Projekt hinaus wahrgenommen werden und umfassen den gesamten Lebenszyklus des Systems. Die entsprechenden Ergebnisse sind deshalb nach Projektabschluss als Grundlage der Wartung zu übergeben. R M KM-plan V12.doc Seite 1 / 20

7 Allgemeines 0.2. ITIL In der heutigen Praxis wird das Service Management gemäss ITIL (IT Infrastructure Library) von den IT-Dienstleistern angeboten. ITIL ist im Bereich Service Management weit verbreitet und beinhaltet eine umfassende und öffentlich verfügbare fachliche Dokumentation zur Planung, Erbringung und Unterstützung von IT-Serviceleistungen. Der Vergleich mit HERMES zeigt, dass die Aktivitäten des Submodells Konfigurationsmanagement das Service Support Verfahren mit Ausnahme des Incident Managements abdecken. Abb. 2: ITIL Aktivitäten Incident Management Das primäre Ziel ist die schnellst mögliche Wiederherstellung der Service Leistung und die Minimierung der Beeinträchtigung der Geschäftsprozesse Problem Management Das Ziel des Problem Managements ist das Vorbeugen und Reduzieren von Störungen sowie die schnelle und wirksame Lösung von Problemen. Damit wird der zielgerichtete Ressourceneinsatz sichergestellt Change Management Das Ziel des Change Management ist die wirtschaftliche und termingerechte Durchführung von Veränderungen (Changes) mit minimalen Risiken unter Anwendung standardisierter Methoden und Verfahren. R M KM-plan V12.doc Seite 2 / 20

8 Allgemeines Release Management Das Ziel des Release Management ist die erfolgreiche Planung und Steuerung der Hardund Software Installationen Configuration Management Das Ziel des Configuration Managements ist die Bereitstellung von aktuellen und gesicherten Informationen über die eingesetzten Konfigurationselemente und damit die direkte Verknüpfung mit allen übrigen Bereichen des IT Service Management Definitionen Für den Betrieb der MISTRA Fachapplikationen werden folgende Begriffsdefinitionen festgelegt: Begriff Definition Change Change Management Configuration Item Configuration Management Helpdesk Incident Problem Release Release Management Das Hinzufügen, Modifizieren oder Entfernen genehmigter, gewarteter oder zur Ausgangskonfiguration gehörender Hardware, Netzwerke, Software, Applikationen, Umgebungen, Systeme, Desktop- Konfigurationen oder zugehöriger Dokumentation. Beinhaltet die Aktivitäten der Prozesse für das Change Management, d.h. die Verwaltung, Steuerung und Überwachung der Changes aufgrund von Problemen oder Anträgen zur Erweiterung oder Verbesserung einer Software oder Teilen davon. Komponente einer Infrastruktur oder ein mit einer Infrastruktur assoziiertes Element wie etwa ein RfC, die der Kontrolle des Configuration-Managements unterliegt (oder ihr unterliegen wird). CIs können von einem kompletten System (einschließlich der gesamten Hardware, Software und Dokumentation) bis zu einem einzelnen Modul oder einer untergeordneten Hardware- Komponente in ihrer Komplexität, Größe und Art stark variieren. Beinhaltet die Aktivitäten für den Prozess des Konfigurationsmanagements gemäss ITIL, d.h. die Verwaltung der Dokumentation und Information über eine Software oder Teilen davon. Vorfall im Betrieb einer Software, der keine Änderung der Software selber oder Teilen davon zur Folge hat. Beinhaltet die Aktivitäten den Prozessen Incident Management und Problem Management gemäss ITIL. Störung, Zwischenfall: Jedes Ereignis, das nicht Teil des Standardbetriebs eines Services ist und eine Unterbrechung oder Minderung der Qualität dieses Services verursacht oder verursachen könnte. Unbekannte Grundursache eines oder mehrerer Incidents. Ein Release ist eine Reihe neuer oder geänderten Komponenten (CI), die zusammen getestet und eingeführt werden. Beinhaltet die Aktivitäten für den Prozess des Release Managements, d.h. die Planung und Umsetzung von neuen Versionen einer Software oder Teilen davon. Tab. 1: Begriffsdefinitionen KRM MISTRA R M KM-plan V12.doc Seite 3 / 20

9 Allgemeines Abkürzung Definition KRM LR WL Koordination Release Management Leitung Realisierung Wartungsleitung Tab. 2: verwendete Abkürzungen Weitere Abkürzungen und Begriffsdefinitionen sind im Glossar MISTRA [6] aufgeführt Abgrenzungen Die Incident und Problem Management Aktivitäten werden unter der Verantwortung des Helpdesk durchgeführt und sind hier nicht beschrieben (siehe [2]). R M KM-plan V12.doc Seite 4 / 20

10 Zweck des Dokuments 1. Zweck des Dokuments Der vorliegende KM-Plan legt alle organisatorischen und technischen Details des Configurations-, Change- und Release Managements (KRM) des Gesamtsystems fest. Folgende Themen werden behandelt: Organisation Aktivitäten Schnittstellen zur anderen Organisationen Die KRM-Aktivitäten sind in drei Hauptprozesse eingeteilt: das Change Management das Release Management das Configuration Management (Konfigurationsmanagement) Dieser Plan gilt für alle Fachapplikationen (oder Subsysteme des Gesamtsystems), es wird ein KM-Plan auf der Fachapplikationsebene erstellt, der den vorliegenden Plan ergänzt. R M KM-plan V12.doc Seite 5 / 20

11 Systemprozess MISTRA 2. Systemprozess MISTRA Das KRM und der Helpdesk sind in einem übergeordneten Betriebsprozess eingebunden. Die für das KRM wichtigen Teilprozessschritte sind rot eingerahmt: FP 9 BS Datenaudit (ASTRA) Kundenhinweis Inkonsistenz Daten / Datenverlust / Bedürfnis zusätzliche Daten Kundenhinweis Störung / Anfrage Support Anfrage Anpassung Zugriffsrechte & Dateneigentümerschaft Auftrag ASTRA im Rahmen von MISTRA Auftrag ASTRA im Rahmen von MISTRA SP 1.2 BS Data Request (GS MISTRA) SP 1.3 BS Help Request (GS MISTRA) SP 1.4 BS Zugriffsrechte & Dateneigentümerschaft Request (GS MISTRA) DP 5 BS Konsistenztest (ASTRA) SP 7 BS Informationssicherheit & Datenschutz (ASTRA) Direktanfrage an GS MISTRA z.b. Anfrage Änderung Systemgrenze, Fachanfragen Kundenhinweis Unzulänglichkeit Funktionalitäten SP 2 BS Ticketmanagement (GS MISTRA) SP 1.1 BS Change Request (GS MISTRA) 2nd & 3rd Level Support Nicht zu behebende Störungen SP 3 Help (GS MISTRA) o SP 4 Fachsupport (ASTRA) Direktauftrag SP 5 Sofortmassnahmen (GS MISTRA) o LP 7 BS Datenwiederherstellung (GS MISTRA) DP 1-6 BS Datenbearbeitungsprozesse (ASTRA) FP BS Führungsprozesse FP 1 Applikationskennzahlen FP 2 Systemgrenze FP 3 Definition Funktionalitäten & Usability FP 4 Definition Daten FP 5 Definition Reports FP 6 Lieferantenmanagement FP 7 Führen Zugriffsrechte & Dateneigentümerschaft FP 8 Publikationsrechte Daten / Metadaten Anfrage prüfen (GS MISTRA) Konsultation Koordinationsstelle (KRM, DM) Störung behoben Massnahme umgesetzt Anfrage genehmigen (ASTRA) Umsetzung beauftragen (ASTRA / GS MISTRA) Entwickler / Betreiber / Weitere SP 6 BS Releasemanagement (GS MISTRA) Konsultation Koordinationsstelle (KRM, DM) Change Management Release Management = Prozesse BS = Prozesse FA = Auftragnehmer BS = Auftragnehmer FA = Auftrag o = oder Abb. 3: übergeordneter Betriebsprozess MISTRA (Beispiel Basissystem) Die Koordinationsstelle entspricht der nachfolgend beschriebenen Organisation Koordination KRM. R M KM-plan V12.doc Seite 6 / 20

12 Organisation 3. Organisation 3.1. Betriebsorganisation Gemäss [5] KRM-Organisation Gemäss [5] Gesamtprojektleitung C. Käser Stv.: A. Buntschu Business Collaboration Infrastructure (BCI) Reviews Koordination Release Management Leitung: A. Buntschu, Stv.: J.-P. Bolli Vertreter BIT: S. Greif Helpdesk BS Basissystem DWH ASTRA VUGIS VU Verkehrsunfälle VMON Verkehrsmonitoring LVS KUBA Kunstbauten und Tunnel TRA Trassee. weitere F. Besançon J.-P. Bolli J. Landolt M. Savary J.-L. Miserez M. Baudenbacher H, Burger M. Rubin M. Lindenmann C. Käser J. Bodenmann A. Jeanneret R. Hajdin L. Seiler J. Bodenmann N.N. EBP Trivadis ELCA IMS InNet ELCA CAD-RZ N.N. N.N. B. Gfeller R. Brunner G. Ramuz M. Ostinelli P. Weiss M. Karrer M. Balzarini H. Burger T. Moebel R. Bätschmann G. Schweizer N.N. Abb. 4: Organigramm KRM-Organisation aus Projektplan 3.3. Rollenbeschrieb KRM Die Rollen sind in [5] beschrieben Sitzungswesen KRM Koordination Release Management Ziele Koordination Release Management Koordination Changes Koordination Configuration Management Informationsaustausch Sitzungsrythmus Reservation Sitzungszimmer Ort Einladung Vorsitz Protokollführung 2 monatlich, oder nach Bedarf ASTRA ASTRA, Bern GS MISTRA, J.-P. Bolli GPL MISTRA, A. Buntschu GS MISTRA, J.-P. Bolli R M KM-plan V12.doc Seite 7 / 20

13 Organisation Teilnehmer A. Buntschu ASTRA, GPL Stv. MISTRA M. Baudenbacher ASTRA, PL VU H. Burger ELCA, WL VU M. Rubin ASTRA, PL VMON M. Lindenmann Sigmaplan, LR VMON L. Seiler ASTRA, PL TRA J. Bodenmann vicoproup, LR TRA und LVS A. Jeanneret ASTRA, PL KUBA R. Hajdin IMC, LR KUBA L. Schildknecht GS MISTRA, LR LBK J.-L. Miserez GS MISTRA, LR VUGIS S. Greif BIT, PL MISTRA J. Landolt GS MISTRA, LR Basissystem / DWH J.-P. Bolli GS MISTRA, Stv Leitung KRM R. Buser KOGIS, Helpdesk WMS Bund Standardtraktanden Bemerkungen Einladung Protokoll Tab. 3: Sitzung Koordination KRM Die Entwickler werden bei Bedarf durch die entsprechenden PL oder LR an die Sitzung eingeladen. 1. Protokoll, Pendenzen 2. Allgemeine Informationen 3. Werkzeuge 4. Configuration Management 5. Change Management 6. Release Management 7. Verschiedenes 8. Nächste Sitzungen Versand an alle Teilnehmer per Versand an alle Teilnehmer und Entschuldigte per R M KM-plan V12.doc Seite 8 / 20

14 Organisation Wartungsleitung Fachapplikation Für jede Fachapplikation (Subsystem) sind Wartungssitzungen gemäss folgenden Vorgaben durch zu führen: Ziele Informationsaustausch Configuration Management der Fachapplikation Change und Problem Management der Fachapplikation Sitzungsrythmus Reservation Sitzungszimmer Ort Einladung Vorsitz Protokollführung Teilnehmer Standardtraktanden ca. alle 2 Monate oder individuell nach Bedarf der FA FA Pro Fachapplikation zu definieren FA FA PL FA Vertreter ASTRA bei Bedarf Vertreter KRM bei Bedarf PL Fachapplikation Wartungsleitung Fachapplikation PL Entwickler Fachapplikation Vertreter Benutzer bei Bedarf 1. Protokoll, Pendenzen 2. Allgemeine Informationen 3. Werkzeuge 4. Change Management (Problembehandlung) 5. Release Management 6. Configuration Management 7. Kosten, Budget 8. Verschiedenes 9. Nächste Sitzungen Bemerkungen Einladung Protokoll Versand an alle Teilnehmer per Versand an alle Teilnehmer und Entschuldigte per Tab. 4: Sitzung Wartungsleitung Fachapplikation R M KM-plan V12.doc Seite 9 / 20

15 4. Subsystem MISTRA Gesamtsystem MISTRA Abb. 5: Übersicht 4.1. Anforderungen an die Subsysteme Für jedes Subsystem muss eine entsprechende Organisation aufgebaut und gelebt werden. Diese Organisation muss an den im vorliegenden Dokument beschriebenen Aktivitäten teilnehmen und ist in einem untergeordneten KM-Plan zu definieren Schnittstellen Schnittstelle zum BIT (Betrieb) tbd Schnittstelle zu IT-Dienstleister (Entwickler) tbd Schnittstelle zu KOGIS/Swisstopo tbd Schnittstelle zum Helpdesk Die Helpdesk Organisation ist zuständig für die Verwaltung der Incidents und Problems. Wird ein Incident als Change identifiziert, so meldet sie einen entsprechenden, neuen Change im Configuration, Change und Releasemanagement an. Die zuständige Organisation liefert Statusmeldungen über die Bearbeitung der Changes an die Helpdesk Organisation zurück. R M KM-plan V12.doc Seite 10 / 20

16 Abb. 6: Schnittstelle Helpdesk mit Schnittstelle zu Projekt (ab Phase Realisierung, bzw. Implementation) Nachfolgend sind die Abhängigkeiten zwischen einem Projekt und dem Configuration, Change und Release Management grafisch dargestellt. Die Koordination zwischen den Projekten und dem Betrieb wird über diese Schnittstelle realisiert. Projekt MISTRA Gesamtsystem MISTRA Abb. 7: Schnittstelle Projekt mit Für jedes Projekt muss das Configuration Management gemäss HERMES durchgeführt werden. Die Anforderungen an die Schnittstelle sind: Spezifikationen mit Auswirkung auf das Gesamtsystem melden Changes mit Auswirkung auf das Gesamtsystem melden Koordination der Planung der ersten produktiven Version Identifikation der Release gemäss 7.4. Lieferung der ersten produktiven Version gemäss 7.2 R M KM-plan V12.doc Seite 11 / 20

17 Change Management 5. Change Management Unter Change Management sind alle nötigen Aktivitäten zusammen gefasst, um Changes (Änderungen) zu verwalten. In Abb. 8: Ablauf Change Management sind die Abläufe und Zuständigkeiten, bzw. die Wechselwirkung zwischen Subsystem (z.b. einer Fachapplikation) und dem KRM MISTRA dargestellt Zustände Jeder Change wird durch einen Eintrag in das KRM-Tool (MANTIS unter gemeldet. Die Anfragen (Changes) können während ihres Lebenszyklus folgende Zustände (Status) annehmen: neu: durch den berechtigten Antragsteller gestellte Anfrage für einen Change (Änderung). in Überprüfung: die Anfrage wird auf inhaltliche Vollständigkeit überprüft, bei Bedarf muss rückgefragt werden. angenommen: die Anfrage wurde angenommen, bzw. definitiv registriert. zugeordnet: die Anfrage wurde einem Verantwortlichen zugeteilt. in Analyse: die Anfrage wird analysiert (Auswirkungen auf andere Applikationen, Kosten, Termine, Release). für Planung freigegeben: die Analyse wird als Change für die Releaseplanung freigegeben. freigegeben: die Anfrage, bzw. der aus der Analyse hervorgegangene Lösungsvorschlag wird für die Umsetzung freigegeben. Die Freigabe erfolgt je nach Kompetenzregelung durch die GPL, GS MISTRA, den Strategieausschuss oder die PL der Fachapplikation. in Umsetzung: die Lösung wird umgesetzt oder ist für die Umsetzung geplant. Die Umsetzung kann in Zwischenschritten wie Spezifikation, Realisierung, Test und Installation unterteilt werden. Umsetzung abgeschlossen: die Lösung wird getestet und installiert. geschlossen: die Lösung für die entsprechende Anfrage (Change) ist installiert. zurück gestellt: die Anfrage, kann zum aktuellen Zeitpunkt nicht behandelt werden oder wird aufgrund der Analyse vorläufig nicht umgesetzt. Dabei handelt es sich in der Regel um Benutzerwünsche. Zurück gestellte Anfragen werden 1x pro Jahr in der Wartungsleitung des entsprechenden Subsystems neu beurteilt (Entscheid für Umsetzung oder definitive Zurückstellung der Anfrage). Die Benachrichtigungen der betroffenen Personen ist in Kap. 5.3 und in [9] beschrieben. R M KM-plan V12.doc Seite 12 / 20

18 Change Management 5.2. Verfahren Change Management Hilfsmittel Subsystem KRM MISTRA Status Mantis Change Problem Management Change Benutzer neu Externe KRM system Change annehmen und prüfen ja in Überprüfung Change priorisieren und kategorisieren angenommen Analyse planen zugeordnet Analysieren mit Abhängigkeiten Abhängigkeiten analysieren Neu changes nötig Autorisiert? Ja Autorisiert? ja in Analyse Implementierung planen (Release Management) (s.6.1) für Planung freigegeben freigegeben freigegeben Implementieren in Umsetzung Überprüfen Installation Realisierung koordinieren Umsetzung abgeschlossen Erfolgreich? Change zurück gestellt ja zurück gestellt Change abgeschlossen geschlossen Abb. 8: Ablauf Change Management R M KM-plan V12.doc Seite 13 / 20

19 Change Management 5.3. Werkzeuge Für das Change und Release Management wird die Software MANTIS eingesetzt. Die entsprechende Dokumentation (Release Notes, Anwendungshandbuch [9]) ist auf dem Extranet MISTRA abgelegt. Eine automatische Benachrichtigung der betroffenen Personen erfolgt aufgrund von Zustandsänderungen (Statuswechsel): Statuswechsel zu Antragsteller Benutzer denen Meldung zugewiesen wurde Manager Neu X X In Überprüfung X X Angenommen X X Zugeordnet X X X In Analyse X X X für Planung freigegeben X X X Freigegeben X X X In Umsetzung X X X Umsetzung abgeschlossen X X X Zurück gestellt X X Geschlossen X X X Tab. 5: Benachrichtigungen Ein Change kann jederzeit mitverfolgt werden (Beobachter). Der Übersicht halber werden die Benachrichtigungen hier nicht aufgezeigt. Sie können aber in [9] nachgelesen werden. Ein Antragsteller kann jeder Benutzer sein, der mindestens die Rolle "Reporter" zugewiesen erhalten hat. Die Meldungen können allen CM-Benutzer zugewiesen werden, die mindestens die Rolle "Beauftragter" zugewiesen erhalten haben. Im CM MANTIS wurden folgende Rollen definiert: Rolle Rollenträger Beauftragte Projektleiter Manager Beobachter Administrator Tab. 6: Rollen und Rollenträger Auftragnehmer für ein Subsystem, z.b. Entwickler, Fachspezialist Projektleiter und Leitung Realisierung für das Subsystem KRM Manager Alle registrierten Benutzer GS MISTRA R M KM-plan V12.doc Seite 14 / 20

20 Release-Management 6. Release-Management 6.1. Verfahren Release Management Subsystem KRM MISTRA Abschluss der Berücksichtigung der Änderungen Vorplanung erstellen Abhängigkeiten analysieren Einschränkungen definieren Definitive Planung erstellen Planungen koordinieren Validieren freigegeben Abb. 9: Ablauf Release Management 6.2. Planung Termin Z 5 Monate Z 4 Monate Z 1 Monate Zieldatum (Z) Aktivität Planung starten Entwicklung starten Abnahmeinstallation Produktiveinstallation Tab. 7: Zeitplanung Release Management R M KM-plan V12.doc Seite 15 / 20

21 Configuration Management 7. Configuration Management 7.1. Abgrenzung Das übergeordnete Configuration Management betreut folgende MISTRA-Applikationen und Komponenten: Abk. Applikation / Komponente Bemerkungen BCI_F5 Zugang Firpass F5 BCI_LDAP LDAP BCI_SSO SSO-Portal EJPD BS Basissystem DWH BS Schnittstelle BS Unterprojekt DWH DWH FFR Schnittstelle FFR Unterprojekt DWH DWH KPI Schnittstelle KPI Unterprojekt DWH DWH VMON Schnittstelle VMON Unterprojekt DWH DWH VU Schnittstelle VU Unterprojekt DWH GEVER Schnittstelle GEVER KUBA Kunstbauten und Tunnel LBK Lärmbelastungskataster LVS Liegenschafts- und Vertragsmanagementsystem SAP Schnittstellen SAP SB Sonderbewilligungen TDcost Schnittstelle TDcost TA Tele Atlas Datenintegration TRA Trassee VMON Verkehrsmonitoring VU Verkehrsunfälle WMS Bund Geodienste Bund (WMS, AV, Geocat) Tab. 8: Objekte des Configuration Management Für jede Applikation können bei Bedarf Unterprojekte eröffnet werden, z.b. für Benutzertests. R M KM-plan V12.doc Seite 16 / 20

22 Configuration Management Ein Unterprojekt hat in der Regel einen vereinfachten Ablauf: Abb. 10: Statusdiagramm für Unterprojekte Das Extranet MISTRA (DMS), die Werkzeuge für den Helpdesk (HD MANTIS) und das Changemanagement (CM MANTIS) sind unabhängig voneinander Anforderungen an die Ergebnisse (Ergebnisbibliothek) Jede erste Lieferung einer MISTRA Applikation oder Komponente besteht aus: System Source code Initial Production Release Notes Betriebshandbuch Supporthandbuch Anwendungshandbuch Konfigurationsidentifikation Jede neue Lieferung (Update, neuer Release) besteht aus: System Source code Release Note Ergänzungen zum Betriebshandbuch Ergänzungen zum Anwendungshandbuch Ergänzungen zum Supporthandbuch Konfigurationsidentifikation Änderungen des Systems sind mindestens als Zusammenfassung in der Systemdokumentation des Releases festzuhalten. Der Code gilt als Referenz. Änderungen des Systems können auch in ergänzenden Dokumenten zur Systemdokumentation festgehalten werden. In der Konfigurationsidentifikation sind die entsprechenden Dokumente zu referenzieren Ablagestruktur Gemäss [4] 5.2.4, 2. Stufe BE und Rel. R M KM-plan V12.doc Seite 17 / 20

23 Configuration Management 7.4. Identifikation der Release Jede Applikation/Subsystem (Software und Daten) hat eine Release Identifikation. Die Bezeichnung setzt sich folgendermassen zusammen: Produktive Identifikation: A.B.C.D Zahl Bedeutung Werte A Realisierungseinheit der Applikation/Subsystem 0-99 B Hauptversionsnummer 0-99 C Verändert sich, wenn eine Change eines anderen Subsystems Auswirkungen auf das Release hat, oder wenn ein Change Auswirkungen auf ein anderes Subsystem hat. Zweitversionsnummer 0-99 Verändert sich, wenn die Funktionalität der Applikation/Subsystem erweitert wird. D Laufnummer bei Nachlieferungen/Patchrelease Tab. 9: Release Identifikation Vor der Produktion ist die Identifizierung durch die folgende Beschreibung gegeben: A.B.C.D X [A-Nummer] Zahl Bedeutung Werte A.B.C.D X [A-Nummer] Identifikation der angestrebten Produktiv-Version Identifikation der Umgebung, zum Beispiel: A: Abnahme T: Test E: Entwicklung Applikationsspezifische Identifikation. Die Struktur und Bedeutung dieser Nummer liegt in der Verantwortung der entsprechenden Wartungsleitung. Tab. 10: Release Identifikation vor Produktion Beispiel: Die Ziel-Version ist: Die erste Entwicklungsversion wird bezeichnet mit: E 001 E,T,A Nach der Entwicklungsarbeit wird die Version E 012 in der Testumgebung installiert und zur Version: T 012 Diese Version wird auf der Abnahmeumgebung installiert und dadurch zu: A 012 Diese Version wird in der Produktionsumgebung installiert und dadurch zu: R M KM-plan V12.doc Seite 18 / 20

24 Configuration Management Muss ein Release erstellt werden um einen dringenden Fehler zu korrigieren (der nur das Subsystem ohne Funktionalitätsänderung betrifft), wird die Version im gleichen Zyklus wie entwickelt Identifikation externe Libraries, Dateien, Schnittstellen Externe Libraries, Dateien, Schnittstellen o.ä., welche zur Software gehören, sind gemäss folgendem Schema zu identifizieren können, bzw. zu bezeichnen: A_B_C Zahl Bedeutung Werte A Realisierungseinheit der zugehörigen Fachapplikation 0-99 B C Hauptversionsummer, verändert sich nur, wenn eine Methode, eine Signatur oder ein Parameter geändert hat. Verändert sich, wenn ein Bugfix oder eine Optimierung des Codes ohne Änderung der Signatur oder der Parameter gemacht wird Tab. 11: Identifikation externe Libraries, Dateien, Schnittstellen Beispiel Webservice: URL WS mit Versionsnummer Mit diesem Ansatz können mehrere Versionen desselben Webservices mit der gleichen URL "zusammen leben", z.b.../getaxes_ws_v2_0.asmx und../getaxes_ws_v2_1.asmx Diese Definition ist für zukünftige Versionen von Schnittstellen anzuwenden. Wenn eine Schnittstelle bei einem neuen Release keine Änderungen aufweist, soll/kann keine Versionsänderung der betroffenen Schnittstelle angegeben werden. Der Bezug des WS zum Release wird beibehalten (History der Schnittstelle). Die erste Nummer wird in diesem Fall für die History verwendet Namenskonventionen KRM-Dokumente NNNNN_AAAA_Dokumentname_RN.N.N.N_VN.N Bezeichnung Bedeutung NNNNN SFS Nummer gemäss [7] AAAA Dokumentname RN.N.N.N VN.N Abkürzung Applikation Dokumentname gemäss [7] 3.3 (sprachabhängig) Identifikation der Release Dokumentversion (fakultativ) Tab. 12: Definition Dateinamen R M KM-plan V12.doc Seite 19 / 20

25 Configuration Management Dokumentname: ManuelUtilisateur Anwendungshandbuch ManuelExploitation Betriebshandbuch ManuelSupport Supporthandbuch DirectivesSaisieDonneesIT RichtlinieITDatenerfassung ReleaseNotes ReleaseNotes IdentificationConfiguration Konfigurationsidentifikation Beispiele: 67041_LVS_Anwenderhandbuch_R _LVS_ManuelUtilisateur_R _KUBA_Konfigurationsidentifikation_R _VMON_ReleaseNotes_R R M KM-plan V12.doc Seite 20 / 20