SAGA-Modul Grundlagen. Version de.bund 5.1.0

Transkript

1 SAGA-Modul Grundlagen Version de.bund November 2011

2 2 Herausgeber Die Beauftragte der Bundesregierung für Informationstechnik (BfIT) Redaktion Bundesministerium des Innern Referat IT 2 - IT-Steuerung Bund Alt-Moabit 101 D Berlin it2@bmi.bund.de Stand Version de.bund final Vom Rat der IT-Beauftragten der Ressorts am 3. November 2011 beschlossen.

3 4 Inhaltsverzeichnis 1 Einleitung Rahmenbedingungen Verbindlichkeit Geltungsbereich Zielgruppe Ziele Wirtschaftlichkeit Agilität Offenheit Sicherheit Interoperabilität Wiederverwendbarkeit Skalierbarkeit Grundprinzipien Terminologie Modularisierung und Versionierung Domänenspezifische Varianten Klassifikationssystem Mindestanforderungen an die Offenheit Klassifikationen von Spezifikationen Auflistung der klassifizierten Spezifikationen Lebenslauf klassifizierter Spezifikationen Nicht klassifizierte Spezifikationen Bewertung von Spezifikationen Nicht klassifizierte Spezifikationen Vorgeschlagene Spezifikationen Neuere Versionen und Alternativen Offenheit Dokumentation der Eigenschaften einer Spezifikation...18

4 Kriterien für die Einordnung in die SAGA-Klassifikationen Erneute Bewertung bereits klassifizierter Spezifikationen Prozesse Übersicht Entwicklung einer Hauptversion Entwicklung einer Zwischenversion Beteiligte...25 A B Berücksichtigung internationaler Entwicklungen...26 Standardisierungsstatus von Spezifikationen...27 B.1 DIN / CEN / ISO...27 B.2 Ecma...28 B.3 OASIS...29 B.4 W3C...29 C D Literatur...30 Abkürzungsverzeichnis...32

5 1 Einleitung 6 1 Einleitung SAGA 1 ist eine Zusammenstellung von Referenzen auf Spezifikationen und Methoden für Software- Systeme der öffentlichen Verwaltung. SAGA ist modular aufgebaut. Die SAGA-Module können zeitlich und weitgehend inhaltlich unabhängig voneinander publiziert werden. Jedes SAGA-Modul wird separat versioniert. Die aktuelle Gesamtversion von SAGA setzt sich aus den neuesten Versionen aller SAGA-Module zusammen. Alle verfügbaren SAGA-Module sind auf der Website der oder des Beauftragten der Bundesregierung für Informationstechnik (BfIT) 2 zu finden. Dieses SAGA-Modul erläutert die Ziele, Rahmenbedingungen, Grundprinzipien sowie die Prozesse zur Erstellung und Fortschreibung von SAGA. SAGA berücksichtigt die Vorgaben des European Interoperability Framework (EIF) 3 und unterstützt dessen Empfehlungen. Die Ziele von SAGA sind Wirtschaftlichkeit, Agilität, Offenheit, Sicherheit, Interoperabilität, Wiederverwendbarkeit und Skalierbarkeit. Das Klassifikationssystem von SAGA unterscheidet vorgeschlagene, beobachtete, empfohlene, verbindliche, bestandsgeschützte und verworfene Spezifikationen. Grundlage für die Klassifikation der Spezifikationen ist vor allem die Bewertung, wie gut sie geeignet sind, die Ziele von SAGA zu erfüllen. SAGA bietet die Möglichkeit, domänenspezifische Varianten zu erstellen, sodass SAGA an die unterschiedlichen Anforderungen seiner Anwender angepasst werden kann. Die SAGA-Konformität eines Software-Systems kann anhand des im SAGA-Modul Konformität 4 beschriebenen Verfahrens beurteilt werden. 2 Rahmenbedingungen 2.1 Verbindlichkeit Die Verbindlichkeit von SAGA wird für die jeweilige Domäne 5 durch Festlegungen außerhalb des Dokuments geregelt. Beispielsweise wird für die Domäne Bundesverwaltung die Verbindlichkeit von SAGA vom Rat der IT-Beauftragten der Ressorts (IT-Rat) beschlossen. Nachgeordnete Domänen dürfen verbindliche Festlegungen der übergeordneten Domäne nicht außer Kraft setzen. 6 1 SAGA ist ein Eigenname, der ursprünglich als Abkürzung von Standards und Architekturen für egovernment-anwendungen eingeführt wurde. 2 Siehe 3 Siehe (ISA, 2010) 4 Siehe (BFIT, 2011A) 5 Siehe auch Abschnitt 4.3 Domänenspezifische Varianten auf Seite 11 6 Beispielsweise kann für die Domäne Bundesverwaltung der IT-Rat die verbindliche Anwendung von SAGA beschließen. Wenn das Bundesministerium des Innern für seine nachgeordnete Domäne Inneres des Bundes eine domänenspezifische Variante von SAGA erstellt, müssen verbindliche Festlegungen der Domäne Bundesverwaltung auch für die Domäne Inneres des Bundes verbindlich bleiben.

6 2 Rahmenbedingungen 7 Auch ohne Festlegungen zur Verbindlichkeit kann SAGA als unverbindliche Orientierungshilfe oder für eigene Standardisierungs-Rahmenwerke genutzt und an spezielle Anforderungen angepasst werden Geltungsbereich SAGA wird bei Beschaffung, Erstellung und Weiterentwicklung von Software-Systemen angewendet. Die Vorgaben von SAGA gelten für alle neuen Software-Systeme 8. Ein neues System liegt dann vor, wenn es keinen Vorgänger gibt oder wenn der Vorgänger vollständig abgelöst wird, es also keine Wiederverwendung von Software-Einheiten gibt. Für bestehende Software-Systeme gelten die Vorgaben nur für Erweiterungen des Funktionsumfanges. Eine solche liegt vor, wenn Individual-Software erweitert wird oder wenn ein Produkt an die funktionalen Bedürfnisse des Auftraggebers angepasst wird und neue Funktionen hinzugefügt werden. Alle im Rahmen der Erweiterung des Software-Systems zu treffenden Auswahlentscheidungen hinsichtlich Spezifikationen und Methoden müssen auf der Grundlage von SAGA erfolgen. Durch Kapselung des neuen (oder des bestehenden) Funktionsumfangs kann eine SAGA-konforme Fertigstellung von Teilen eines Software-Systems unterstützt werden. Es sollte jedoch für das gesamte bestehende Software-System geprüft werden, ob die Umsetzung der aktuellen Vorgaben von SAGA vorteilhaft ist. Es liegt keine Erweiterung des Funktionsumfanges vor, wenn Software parametrisiert (konfiguriert) wird oder wenn Mängel behoben werden. In diesen Fällen muss SAGA nicht angewendet werden. Abbildung 2-1: Geltungsbereich von SAGA Hardware-Systeme und autonome eingebettete Systeme 9 liegen außerhalb des Geltungsbereichs von SAGA. Für nicht autonome eingebettete Systeme muss geprüft werden, ob es für die Schnittstellen des Systems relevante Vorgaben in SAGA gibt. 7 Siehe auch Abschnitt 4.3 Domänenspezifische Varianten auf Seite 11 8 Software-Systeme sind im weitesten Sinn ausführbare Programme und die zugehörigen Daten und Dokumentationen 9 Eingebettete Systeme umfassen sowohl Hardware- als auch Software-Einheiten, siehe (BFIT, 2010), zum Beispiel so genannte Appliances

7 2 Rahmenbedingungen Zielgruppe SAGA richtet sich an Entscheider, Projektleiter, Architekten und Entwickler mit Verantwortung für Software-Systeme der öffentlichen Verwaltung. Die Vorgaben von SAGA gelten sowohl für die Auftraggeber als auch für ihre Auftragnehmer. Darüber hinaus ist die interessierte Öffentlichkeit 10 herzlich eingeladen, SAGA für eigene Zwecke einzusetzen und an der Fortschreibung mitzuwirken Ziele Aufgrund der kurzen Innovationszyklen in der Informationstechnik einerseits und den hohen Investitions- und Migrationskosten für Entwicklungen und Einführungen von Software-Systemen andererseits sind die Ziele von SAGA mittel- bis langfristig ausgelegt, um sie erreichbar zu machen und eine dauerhafte Wirkung mit ihnen zu erzielen. Diese Nachhaltigkeit soll dauerhafte IT-Lösungen schaffen und einen ausreichenden Investitionsschutz gewährleisten. Für SAGA wurden sieben Ziele aufgestellt: Wirtschaftlichkeit, Agilität, Offenheit, Sicherheit, Interoperabilität, Wiederverwendbarkeit und Skalierbarkeit. Alle Ziele sind gleichberechtigt. Konflikte zwischen den Zielen müssen individuell betrachtet und beurteilt werden. 3.1 Wirtschaftlichkeit Auch bei der Informationstechnik sind die Grundsätze der Wirtschaftlichkeit und Sparsamkeit zu beachten und durch entsprechende Wirtschaftlichkeitsuntersuchungen nachzuweisen (siehe 7 Abs. 1 und 2 BHO) 12. Dabei sind nicht nur die einmaligen Investitionskosten zu betrachten, sondern auch fortlaufende (Betriebs-, Pflege- und Wartungs-)Kosten 13 sowie solche, die bei der späteren Ablösung eines Software-Systems entstehen. Des Weiteren sind Risiken zu minimieren und Investitionssicherheit anzustreben. 10 Zum Beispiel Wirtschaft und Wissenschaft 11 Siehe Abschnitt 7.4 Beteiligte auf Seite Siehe beispielsweise 7 der Bundeshaushaltsordnung (BHO) (BMJ, 2009B) 13 Siehe beispielsweise die Ausführungen der WiBe 4.1 (BMI, 2007)

8 3 Ziele Agilität Die öffentliche Verwaltung soll Gesetze und Verordnungen jederzeit fristgerecht umsetzen können. Dafür sind informationstechnische Systeme notwendig, die kurzfristig und flexibel wechselnde funktionale und nicht funktionale Anforderungen erfüllen können. 3.3 Offenheit Mit diesem Ziel wird angestrebt, dass informationstechnische Systeme bei der Weiterentwicklung nicht von den Interessen einzelner Marktteilnehmer abhängig sind. Offene Spezifikationen schaffen eine transparente Basis für alle Marktteilnehmer, für die öffentliche Verwaltung als Kunde einerseits und die Lieferanten von Informationstechnik andererseits. Damit unterstützen sie das Prinzip der Nachhaltigkeit für die Informationstechnik in der öffentlichen Verwaltung und fördern zugleich die Erhöhung des Wettbewerbs sowie die Verbreitungsgeschwindigkeit innovativer Technologien in der IT-Branche. 3.4 Sicherheit Angesichts der zunehmenden Ausbreitung der Informationstechnologie und der wachsenden Bedrohungslagen ist die Sicherheit der Informationstechnik für die öffentliche Verwaltung von besonderer Bedeutung. Die öffentliche Verwaltung verarbeitet Daten, die im Sinne des IT-Grundschutzes 14 des Bundesamtes für Sicherheit in der Informationstechnik (BSI) teilweise einen sehr hohen Schutzbedarf bezüglich der Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit aufweisen. 3.5 Interoperabilität Interoperabilität 15 verbessert die Vernetzung beziehungsweise Vernetzbarkeit von Systemen und ermöglicht den elektronischen Datenaustausch jenseits des Horizonts des ursprünglich geplanten Einsatzbereiches. Sie ermöglicht die Realisierung von vernetzten Software-Systemen mit unterschiedlichen Lieferanten. Interoperabilität führt dazu, dass die Kunden bei der Auswahl von Software-Systemen nicht eingeschränkt werden und fördert so den Wettbewerb und die Verbreitung von Innovationen in der IT-Branche. Sie fördert die Nachhaltigkeit von Software-Systemen und unterstützt zugleich weitere Ziele, wie Agilität, Offenheit und Wiederverwendbarkeit. 14 Siehe (BSI, 2011) 15 Analog zum European Interoperability Framework (EIF) der Europäischen Kommission versteht SAGA unter Interoperabilität die Fähigkeit von Informationssystemen, Daten auszutauschen und Wissen zu teilen. Es wird zwischen organisatorischer, semantischer und technischer Interoperabilität unterschieden. Organisatorische Interoperabilität fordert passende Prozessabläufe und passende Rollen der Kommunikationspartner, technische Interoperabilität klärt die Repräsentation und den Transport von Informationen und semantische Interoperabilität ist für ein gemeinsames Verständnis der Bedeutung der auszutauschenden Informationen verantwortlich, siehe (ISA, 2010).

9 3 Ziele Wiederverwendbarkeit Die Wiederverwendbarkeit von Software-Systemen 16 und ihrer Elemente ermöglicht eine mehrmalige Nutzung für gleiche oder ähnliche Anforderungen. Eine redundante Entwicklung wird somit vermieden sowie Betrieb, Pflege und Wartung vereinfacht. Sie unterstützt damit direkt die weiteren Ziele Wirtschaftlichkeit und Agilität. 3.7 Skalierbarkeit Skalierbarkeit bedeutet die Fähigkeit eines Software-Systems, mit geringem Aufwand einen wachsenden oder schrumpfenden Bedarf an Verarbeitungskapazität zu decken. Je skalierbarer ein Software-System ist, desto geringer ist der notwendige Anpassungsaufwand bezogen auf veränderte Nutzerzahlen, Transaktionen oder andere Leistungsindikatoren. Damit unterstützt Skalierbarkeit die weiteren Ziele Wirtschaftlichkeit und Agilität. 4 Grundprinzipien 4.1 Terminologie In SAGA gibt es bezüglich der Klassifikation von Spezifikationen und der Verbindlichkeit von Vorgaben eine einheitliche Regelung für die Verwendung der Verben MUSS, SOLLTE, KANN sowie der Verneinungen DARF NICHT und SOLLTE NICHT 17 : MUSS: Kennzeichnet eine Aussage mit dem Charakter einer verbindlichen Festlegung. SOLLTE: Kennzeichnet eine Aussage mit dem Charakter einer positiven Empfehlung. KANN: Kennzeichnet eine Aussage mit dem Charakter einer gestatteten Option. DARF NICHT: Kennzeichnet eine Aussage mit dem Charakter eines verbindlichen Verbotes. SOLLTE NICHT: Kennzeichnet eine Aussage mit dem Charakter einer negativen Empfehlung. Zur besseren Übersicht werden die Verben in den Texten der SAGA-Module typografisch hervorgehoben. 4.2 Modularisierung und Versionierung SAGA ist modular aufgebaut. Die SAGA-Module können zeitlich und weitgehend inhaltlich unabhängig voneinander publiziert werden. Die Inhalte der SAGA-Module sind beispielsweise Technische Spezifikationen (Präsentation, Kommunikation, Datenaustauschformate, Sicherheit etc.) Semantische Spezifikationen (Kernkomponenten, Code-Listen, Taxonomien, Datenwörterbücher etc.) 16 Die Wiederverwendbarkeit bezieht sich auf Individualentwicklungen, da die Wiederverwendbarkeit von Produkten und Lizenzen in der Regel ausgeschlossen ist. 17 Die Regelung orientiert sich am IETF RFC 2119 (IETF, 1997) und der deutschen Übersetzung des DIN.

10 4 Grundprinzipien 11 Methodische Spezifikationen Vorgehensmodelle und Prozessmodelle (V-Modell XT, WiBe, DOMEA etc.) Betrieb von Software-Systemen (ITIL, Gesamtinfrastruktur, Referenz-Infrastruktur, Service Level Agreements etc.) Software-System-Architekturen Juristische, politische und europäische Rahmenbedingungen und Strategien (Elektronische Signatur, Datenschutz, EU-Dienstleistungsrichtlinie etc.) Jedes SAGA-Modul wird separat versioniert und publiziert. Durch die Modularisierung von SAGA 5 wird es keine Gesamtpublikation von SAGA 5 mehr geben. Die aktuelle SAGA-Version besteht immer aus den jeweils neuesten SAGA-Modulen. Mit einer Gesamtversionsnummer für SAGA wird jede Zusammenstellung der Versionen aller Module gekennzeichnet. Auf der Website der oder des Beauftragten der Bundesregierung für Informationstechnik (BfIT) 18 sind die aktuellen SAGA-Module zu finden. Die Versionsnummern der einzelnen SAGA-Module sind dreigeteilt, z. B , wobei die erste Ziffer die Hauptversionsnummer von SAGA kennzeichnet, die zweite die Hauptversion des Moduls und die dritte die Zwischenversion des SAGA-Moduls. Eine Hauptversion entsteht bei einer vollständigen Überarbeitung des SAGA-Moduls. Werden lediglich einzelne Abschnitte oder Aspekte aktualisiert oder ergänzt, erfolgt die Publikation als Zwischenversion. Die Gesamtversionsnummer von SAGA beginnt stets mit einer 5 als Hauptversionsnummer, gefolgt von einer laufenden Ziffer, die bei jeder Ergänzung oder Überarbeitung eines Moduls hochgezählt wird. Dabei wird nicht unterschieden, ob es sich um eine neue Haupt- oder Zwischenversion der SAGA-Module handelt. Die erste Gesamtversion von SAGA ist die 5-0. Wird ein weiteres Modul ergänzt oder ein bestehendes Modul überarbeitet, lautet die Gesamtversionsnummer 5-1 usw. Die Zusammenstellung der Module zu SAGA-Versionen wird ebenfalls auf der Website der oder des Beauftragten der Bundesregierung für Informationstechnik (BfIT) dokumentiert. 4.3 Domänenspezifische Varianten SAGA bietet die Möglichkeit, domänenspezifische Varianten 19 von SAGA-Modulen zu erstellen, sodass die SAGA-Module an die unterschiedlichen Anforderungen ihrer Anwender angepasst werden können. Lediglich dieses Modul Grundlagen und das SAGA-Modul Konformität 20 sind sinngemäß für alle Varianten gültig. Abgeleitete domänenspezifische Varianten von SAGA-Modulen können: 18 Siehe 19 Eine Domäne wird in diesem Zusammenhang aus einem oder mehreren klar abgegrenzten Handlungsfeldern der öffentlichen Verwaltung gebildet. Die gesamte Bundesverwaltung ist beispielsweise eine Domäne mit dem Namen de.bund. Ihr nachgeordnet ist zum Beispiel die Domäne Inneres des Bundes (de.bund.inneres) für die Handlungsfelder des Bundesministeriums des Innern (BMI). Darunter könnte Geodateninfrastruktur als ein Handlungsfeld des Bundesamtes für Kartographie und Geodäsie (BKG) als eine eigene Domäne beispielsweise mit dem Namen de.bund.inneres.geo betrachtet werden. 20 Siehe (BFIT, 2011A)

11 4 Grundprinzipien 12 Nicht verbindliche Festlegungen weglassen, Nicht verbindliche Festlegungen verbindlich machen, Festlegungen (nicht verbindliche und verbindliche) ergänzen. Die Abschwächung verbindlicher Festlegungen für nachgeordnete Domänen ist nicht zulässig. Domänenspezifische Varianten müssen im Namen kenntlich machen, für welche Domäne sie gelten und diese klar abgrenzen, z. B. als Aufgabengebiet einer oder mehrerer Organisationen. Ferner müssen domänenspezifische Varianten in ihrem Namen ausweisen, von welcher Hauptversion oder Variante von SAGA sie sich ableiten, z. B. SAGA-Modul Technische Spezifikationen, Version de.bund.justiz 5.0.0, Variante der Version de.bund Domänenspezifische Varianten müssen dem Herausgeber der Hauptversion von SAGA am Anfang der Ableitungskette angezeigt werden, damit Hauptversion und alle Ableitungen zusammen an einem zentralen Ort zugänglich gemacht werden. So wird sichergestellt, dass aus einer Quelle ermittelt werden kann, welche SAGA-Version für ein Software-System relevant ist. Ferner müssen für domänenspezifische Varianten auch angepasste Checklisten zur Erklärung der SAGA-Konformität für Individualentwicklungen und Produkte bereitgestellt werden 21. Domänenspezifische Varianten gelten auch weiterhin, wenn übergeordnete Versionen aktualisiert werden. Im Konfliktfall überschreiben allerdings die Vorgaben der aktualisierten übergeordneten Versionen die Festlegungen der domänenspezifischen Varianten. Es liegt in der Verantwortung der Herausgeber der domänenspezifischen Varianten, diese an aktualisierte übergeordnete Versionen anzupassen. Herausgeber übergeordneter Versionen sollten die Verantwortlichen für bereits vorhandene Ableitungen an der Fortschreibung als Interessenvertreter einbeziehen. 22 Domänenspezifische Varianten müssen kennzeichnen, wenn Klassifikationen sich aus Verpflichtungen ergeben, die über den Festlegungen der SAGA-Hauptversion stehen, also z. B. Regelungen aus Bündnisverpflichtungen oder Gesetzen. In Konfliktfällen mit der SAGA-Hauptversion gelten dann die Regeln der domänenspezifischen Variante. Die Publikationsform der SAGA-Module unterstützt die Erstellung von domänenspezifischen Varianten. 5 Klassifikationssystem 5.1 Mindestanforderungen an die Offenheit Ein Ziel von SAGA ist die Verwendung von offenen Spezifikationen in Software-Systemen der öffentlichen Verwaltung 23. Dazu werden Mindestanforderungen an die Offenheit gestellt. Eine Spezifikation, die diese Anforderungen erfüllt, kann in SAGA als Beobachtet, Empfohlen oder Verbindlich klassifiziert werden. Sie ist jedoch nicht notwendigerweise ein offener Standard im Sinne einer Definition irgendeines Standardisierungsgremiums Siehe Modul Konformität (BFIT, 2011A), Abschnitt 2.2 Definition der SAGA-Konformität 22 Siehe Abschnitt 7.2 Entwicklung einer Hauptversion auf Seite Siehe Abschnitt 3.3 auf Seite 9 24 Über die Mindestanforderungen hinausgehende Eigenschaften von Spezifikationen können für die Klassifizierung herangezogen werden, um offenere Spezifikationen höher zu klassifizieren als weniger offene, siehe Abschnitt Dokumentation der Eigenschaften einer Spezifikation auf Seite

12 5 Klassifikationssystem 13 Die Mindestanforderungen bezüglich der Offenheit sind: 1. Die Spezifikation wurde vollständig publiziert und die Publikation ist entweder kostenfrei oder gegen ein angemessenes Entgelt erhältlich. 2. Die Verwendung der Spezifikation ist für Hersteller und Nutzer der Software-Systeme uneingeschränkt und kostenfrei möglich Zum Zeitpunkt der Bewertung ist nicht erkennbar, dass die Spezifikation in der Zukunft die ersten zwei Anforderungen nicht mehr erfüllen wird. 5.2 Klassifikationen von Spezifikationen Spezifikationen werden bewertet und aufgrund der Beurteilung in eine von sechs Klassen eingeordnet: Vorgeschlagen, Beobachtet, Empfohlen, Verbindlich, Bestandsgeschützt oder Verworfen. Konkurrierende Spezifikationen 26, die nicht klassifiziert sind, sollten nicht oder nur in Ausnahmefällen angewendet werden 27. Vorgeschlagen Die Klassifikation Vorgeschlagen ist die initiale Klassifikation einer Spezifikation in SAGA. Spezifikationen werden als Vorgeschlagen klassifiziert, wenn ein Interessenvertreter eine Änderungsanfrage zur Aufnahme der Spezifikation in SAGA an den Änderungsverantwortlichen heranträgt und die Spezifikation nicht bereits anderweitig klassifiziert worden ist sowie das Potenzial besitzt, in Software-Systemen eingesetzt zu werden. Mit dieser Klassifikation wird keine Aussage über die Reife und Qualität einer Spezifikation getroffen. Mit der Klassifikation Vorgeschlagen wird zeitnah auf neue Entwicklungen reagiert und extern kommuniziert, welche Spezifikationen bei der nächsten Fortschreibung näher untersucht werden. Beobachtet Spezifikationen werden als Beobachtet klassifiziert, wenn sie einer erwünschten Entwicklungsrichtung folgen, finalisiert sind und die Mindestanforderungen an die Offenheit 28 erfüllen. Gegebenenfalls haben sie sich aber noch nicht ausreichend in der Praxis bewährt oder erfüllen bislang nicht alle Ziele von SAGA Damit ist nicht gemeint, dass es zwangsläufig kostenfreie Implementationen geben muss. Das Kriterium ist erfüllt, wenn für Implementation und Nutzung der Spezifikation im Kontext der öffentlichen Verwaltung keine spezifischen Kosten anfallen, z. B. aufgrund von Patenten, und wenn die Verwendung nicht eingeschränkt wird, z. B. durch eine Bedingung, dass ein Produkt keine weiteren alternativen Spezifikationen parallel implementieren darf. 26 Konkurrierende Spezifikationen sind solche, die für dieselbe Aufgabe geeignet sind, aber unterschiedliche Lösungsansätze anbieten. Die Eignung ist wesentlich von der Aufgabe abhängig. So kann z. B. zur Kodierung mitteleuropäischer Texte sowohl ISO als auch UTF-8 verwendet werden. Beide Spezifikationen sind für diese spezifische Aufgabe geeignet und damit im Sinne dieses Abschnitts Konkurrenten, auch wenn UTF-8 viel universeller einsetzbar ist, z. B. auch zur Kodierung osteuropäischer und asiatischer Texte. 27 Siehe Abschnitt 5.5 auf Seite Siehe Abschnitt 5.1 auf Seite Siehe Kapitel 3 auf Seite 8

13 5 Klassifikationssystem 14 Empfohlen Spezifikationen werden als Empfohlen klassifiziert, wenn sie sich in der Praxis bewährt haben, es aber für ihr Themenfeld weitere geeignete Spezifikationen gibt oder sie nicht alle Ziele von SAGA erfüllen. Es müssen jedoch die Mindestanforderungen an die Offenheit erfüllt werden und Investitionssicherheit gegeben sein. Verbindlich Spezifikationen werden als Verbindlich klassifiziert, wenn sie sich in der Praxis bewährt haben und die einzig bevorzugte Lösung darstellen. Dazu müssen sie am Markt etabliert sein und alle Ziele von SAGA erfüllen. Bestandsgeschützt Spezifikationen werden als Bestandsgeschützt klassifiziert, wenn besser geeignete (höher klassifizierte) konkurrierende Spezifikationen existieren und sie zuvor mindestens die Klassifikation Empfohlen besaßen oder in der Vergangenheit am Markt eine große Relevanz hatten. 30 Verworfen Spezifikationen werden als Verworfen klassifiziert, wenn sie von dem Änderungsverantwortlichen erfasst und abgewiesen wurden. Die Klassifikation Verworfen informiert darüber, welche vorgeschlagenen Spezifikationen abgelehnt wurden, sodass eine andere Klassifikation nicht mehr zu erwarten ist. Wurde eine verworfene Spezifikation weiterentwickelt und unterscheidet sich in den kritisierten Punkten von der alten Version, dann kann die neue Version über die Klassifikation Vorgeschlagen in SAGA aufgenommen werden. 5.3 Auflistung der klassifizierten Spezifikationen Alle Spezifikationen, die gleich klassifiziert wurden, sind in den folgenden Listen zusammengefasst, die auf der Website der oder des Beauftragten der Bundesregierung für Informationstechnik (BfIT) veröffentlicht werden 31 : Vorschlagsliste für die Klassifikation Vorgeschlagen Beobachtungsliste für die Klassifikation Beobachtet Empfehlungsliste für die Klassifikation Empfohlen Pflichtliste für die Klassifikation Verbindlich Bestandsschutzliste für die Klassifikation Bestandsgeschützt Negativliste für die Klassifikation Verworfen 30 Z. B. wurde der veraltete Zeichensatz ISO durch Unicode abgelöst und das veraltete HTML 3.2 wurde durch HTML 4.01 ersetzt 31 Siehe (BFIT, 2011B)

14 5 Klassifikationssystem Lebenslauf klassifizierter Spezifikationen Die folgende Abbildung stellt die möglichen Übergänge zwischen den sechs Klassifikationen dar: Abbildung 5-1: Übergänge zwischen SAGA-Klassifikationen Eine Spezifikation kann mehrere Übergänge auf einmal durchlaufen. So kann eine Spezifikation von einer SAGA-Modulversion zur nächsten z. B. von Vorgeschlagen über Beobachtet und Empfohlen schließlich Verbindlich werden. Lediglich die Klassifikation Bestandsgeschützt kann nicht sofort verlassen werden, da mit dieser Klassifikation Bestandsschutz gewährt wird. Jede Prüfung kann stets zum Ergebnis haben, dass eine Spezifikation ihre Klassifikation beibehält. Zum Beispiel bleibt eine Spezifikation Vorgeschlagen, wenn sie zum Zeitpunkt der Prüfung noch nicht finalisiert wurde und die Arbeiten an der Spezifikation aber auch nicht eingestellt worden sind. Die folgenden Übergänge zwischen den Klassifikationen sind möglich, siehe Abbildung 5-1: 1: Neue Spezifikationen mit dem Potenzial in Software-Systemen eingesetzt zu werden, werden von einem Interessenvertreter mit einer Änderungsanfrage zur Aufnahme der Spezifikation in SAGA an den Änderungsverantwortlichen herangetragen. Ohne eine vertiefte Prüfung werden diese Spezifikationen zunächst mit der Klassifikation Vorgeschlagen gesammelt. 2: Vorgeschlagene Spezifikationen, die nach erfolgter Prüfung für neue und bestehende Software-Systeme nicht eingesetzt werden sollten, erhalten die Klassifikation Verworfen. 3: Vorgeschlagene Spezifikationen, die nach erfolgter Prüfung in neuen Software-Systemen nicht eingesetzt werden sollten, jedoch in bestehenden Software-Systemen noch genutzt werden könnten, erhalten die Klassifikation Bestandsgeschützt. 4: Nach einer positiven Prüfung der entsprechenden Anforderungen erhalten vorgeschlagene Spezifikationen die Klassifikation Beobachtet. 5: Beobachtete Spezifikationen werden nach einer erfolgreichen Prüfung der entsprechenden Anforderungen als Empfohlen klassifiziert.

15 5 Klassifikationssystem 16 6: Empfohlene Spezifikationen werden nach einer erfolgreichen Prüfung der entsprechenden Anforderungen als Verbindlich klassifiziert. 7: Verbindliche Spezifikationen werden nach einer Prüfung und der entsprechenden Neubewertung auf Empfohlen herabgesetzt. 8: Wenn empfohlene Spezifikationen nach erfolgter Prüfung in neuen Projekten nicht mehr eingesetzt werden sollten, erhalten sie die Klassifikation Bestandsgeschützt. 9: Bestandsgeschützte Spezifikationen, für die ausreichend lange Bestandsschutz gewährt wurde und die in bestehenden Software-Systemen nicht mehr weiter verwendet werden sollten, erhalten die Klassifikation Verworfen. 10: Beobachtete Spezifikationen, die keine Aussicht mehr haben, jemals als Empfohlen oder gar Verbindlich klassifiziert zu werden, erhalten die Klassifikation Verworfen. Aus den Verzweigungen in den Übergängen zwischen Klassifikationen ergeben sich verschiedene Lebensläufe für Spezifikationen. Eine einzelne Version einer Spezifikation kann jedoch nur einem der möglichen Lebensläufe folgen. Die Anwendung der verschiedenen Klassifikationen wird im SAGA-Modul Konformität näher erläutert Nicht klassifizierte Spezifikationen Wenn Spezifikationen nicht in SAGA aufgeführt werden, ist ihre Behandlung davon abhängig, ob es im Klassifikationssystem konkurrierende Spezifikationen gibt. Wenn ja, sind sie so zu behandeln, wie Spezifikationen der Klassifikation Verworfen 33. Gibt es für das gewünschte Einsatzgebiet der nicht-klassifizierten Spezifikation keine bereits klassifizierte Alternative, ist das Einsatzgebiet also nicht Gegenstand der Betrachtungen von SAGA, sind sie so zu behandeln, wie Spezifikationen der Klassifikation Vorgeschlagen 34. Neue Spezifikationen, die im Rahmen von Pilotprojekten erprobt werden sollen, sollten zur Aufnahme in SAGA vorgeschlagen werden. Verschiedene Gründe können dazu führen, dass Spezifikationen keine Klassifikation erhalten: sie haben keine spezielle Relevanz für Software-Systeme der jeweiligen Domäne, sie beziehen sich auf eine andere Detailebene als die in SAGA aufgeführten Spezifikationen, sie sind in klassifizierten Spezifikationen inbegriffen, werden durch klassifizierte Spezifikationen referenziert, impliziert oder ausgeschlossen, sie sind zu neu oder zu umstritten, um verlässlich die baldige Etablierung als Standard für die öffentliche Verwaltung voraussetzen zu können oder sie sind nie zur Aufnahme in SAGA vorgeschlagen worden, weil sie mit klassifizierten Spezifikationen konkurrieren und Ziele von SAGA einschränken. 32 Siehe (BFIT, 2011A), Abschnitt 2.3 Anwendung des Klassifikationssystems 33 Siehe (BFIT, 2011A), Abschnitt 2.3 Anwendung des Klassifikationssystems 34 Siehe (BFIT, 2011A), Abschnitt 2.3 Anwendung des Klassifikationssystems

16 6 Bewertung von Spezifikationen 17 6 Bewertung von Spezifikationen Im folgenden wird dargelegt, welchen Untersuchungen eine Spezifikation unterzogen wird, um in das Klassifikationssystem von SAGA eingeordnet zu werden. Damit wird konkretisiert, was die Definitionen der Klassifikationen 35 bedeuten und wie sich die Verfolgung der Ziele von SAGA 36 in der Klassifizierung niederschlägt. Die Bewertung einer Spezifikation erfolgt stets im Kontext ihres vorgesehenen Einsatzfeldes für Software-Systeme der jeweiligen Domäne 37. Da eine Spezifikation für verschiedene Anwendungsfälle in mehreren Themenfeldern von SAGA relevant sein kann, ist es möglich, dass eine Spezifikation mehrere und auch unterschiedliche Bewertungen und daraus resultierende Klassifikationen in SAGA erhält Nicht klassifizierte Spezifikationen Für die Aufnahme einer Spezifikation in die Vorschlagsliste erfolgt keine Untersuchung ihrer Qualität. Es muss lediglich geprüft und dokumentiert werden: Was ist der Zweck der Spezifikation? Welche Bedeutung könnte ihr im Rahmen von Software-Systemen der jeweiligen Domäne zukommen? Die Spezifikation kann als Vorgeschlagen klassifiziert werden, wenn ihr Einsatz im Rahmen von Software-Systemen der jeweiligen Domäne zweckmäßig sein könnte und sie vor der Veröffentlichung der nächsten Version des SAGA-Moduls vertieft untersucht werden sollte. 6.2 Vorgeschlagene Spezifikationen Neuere Versionen und Alternativen Vor der genauen Untersuchung einer Spezifikation ist zu prüfen, ob es eine neuere Version als die zu untersuchende gibt, die noch nicht als Vorgeschlagen eingeordnet wurde. Ebenso ist von vornherein zu prüfen, ob es sich bei der Spezifikation um eine Norm handelt und ob es alternative Normen und Spezifikationen gibt, die noch keine SAGA-Klassifikation erhalten haben. Falls es neuere Versionen oder Alternativen gibt, ist zu entscheiden, ob sie die Anforderungen für die Klassifikation Vorgeschlagen erfüllen und ob sie gegebenenfalls sofort eine geprüfte SAGA-Klassifikation erhalten sollen. Ist kurzfristig (noch vor der Erstellung der nächsten Version des Moduls) eine hohe Relevanz der neuen Versionen oder Alternativen für Software-Systeme der jeweiligen Do 35 Siehe Abschnitt 5.2 Klassifikationen von Spezifikationen auf Seite Siehe Kapitel 3 Ziele auf Seite 8 37 Für die Domäne Bundesverwaltung werden alle Bewertungen von Spezifikationen veröffentlicht, siehe 38 Z. B. kann JPEG im Themenfeld Austauschformate für Bilder als Verbindlich klassifiziert sein und im Themenfeld Langzeitspeicherung lediglich als Empfohlen.

17 6 Bewertung von Spezifikationen 18 mäne zu erwarten, sollte die Prüfung sofort erfolgen. Dann ist die Spezifikation so zu behandeln, als wäre sie Vorgeschlagen Offenheit Um die Klassifikation Beobachtet, Empfohlen oder Verbindlich erhalten zu können, muss die Spezifikation die Mindestanforderungen an die Offenheit 39 erfüllen. Sind diese Anforderungen erfüllt, ist zu dokumentieren: welches Standardisierungsgremium die Spezifikation herausgibt, welche Identifikationsnummer (z.b. bei ISO und DIN-Normen), welchen Titel und gegebenenfalls welche Versionsnummer die Spezifikation hat, wo die Spezifikation erhältlich ist und zu welchem Preis, welche Aussagen zu Patenten oder Lizenzen gemacht werden, ob es Hinweise auf die uneingeschränkte und kostenfreie Verwendbarkeit durch die jeweilige Domäne, ihre Dienstleister und die Nutzer der Software-Systeme gibt, ob es Hinweise auf die zukünftige Entwicklung der Offenheit gibt. (Ist eine neuere Version mit Lizenzen behaftet? Wird vom Herausgeber in Erwägung gezogen, zukünftig ein höheres Entgelt zu verlangen?) Dazu ist gegebenenfalls eine Anfrage an den Herausgeber der Spezifikation zu stellen, um offene Fragen zu klären. Werden die Mindestanforderungen an die Offenheit nicht erfüllt, kommen nur noch die Klassifikationen Bestandsgeschützt oder Verworfen in Frage. Dann ist zu dokumentieren, welche konkrete Anforderung nicht erfüllt wurde Dokumentation der Eigenschaften einer Spezifikation Zur Wahl der geeigneten Klassifikation für eine Spezifikation sind zur Beurteilung aller Anforderungen die folgenden Fragen zu beantworten: Werden die Mindestanforderungen an die Offenheit erfüllt 40? Wann wurde sie finalisiert oder wann wurde mit der Arbeit an der Spezifikation begonnen? Worin besteht der Leistungsumfang? Welchen Mehrwert bringt ihr Einsatz in Software-Systemen der jeweiligen Domäne gegenüber dem Einsatz von Alternativen? Unterstützt sie die Agilität von Software-Systemen? Ist sie plattformunabhängig? Fördert sie Interoperabilität? Gibt es Möglichkeiten, die Konformität von Implementationen zur Spezifikation zu prüfen? 39 Siehe Abschnitt 5.1 Mindestanforderungen an die Offenheit auf Seite Siehe Abschnitt 6.2.2

18 6 Bewertung von Spezifikationen 19 Gibt es erste Projekte zur Implementation oder sogar für die jeweilige Domäne verfügbare unabhängige Implementationen unterschiedlicher Hersteller? Ist die Spezifikation / sind die Implementationen bereits bewährt / etabliert? Reduziert sie Kosten und Risiken? Gibt es bewährte / etablierte Implementationen, die kostenfrei / quelloffen verfügbar sind? Können mit ihr die Anforderungen an die IT-Sicherheit erfüllt werden? Steht ihr Fortschreibungsprozess allen Interessierten zur Diskussion und Mitbestimmung offen? Bietet sie langfristige Investitionssicherheit? Unterstützt sie die Wiederverwendbarkeit von Software-Systemen und ihren Komponenten? Erlaubt sie das Skalieren von Software-Systemen (geringe Kosten / hohe Performanz bei veränderten Nutzer- / Transaktionszahlen)? Die Antworten auf diese Fragen dienen der Anwendung der nachfolgenden Kriterien und sind Grundlage für den Vergleich konkurrierender Spezifikationen Kriterien für die Einordnung in die SAGA- Klassifikationen Im Folgenden werden Ausschlusskriterien, die für eine Klassifikation erfüllt sein müssen, beschrieben. Die Kriterien müssen für die Software-Systeme der jeweiligen Domäne des SAGA-Moduls gelten, zum Beispiel für die Software-Systeme der Bundesverwaltung. Eine Spezifikation bleibt Vorgeschlagen wenn mit ihrer Spezifikation begonnen wurde, die Spezifikation durch den Herausgeber noch nicht als veraltet deklariert wurde, ihr Einsatz im Rahmen von Software-Systemen zukünftig zweckmäßig sein könnte und sie vor der Veröffentlichung der nächsten Version des SAGA-Moduls erneut untersucht werden sollte. Eine Spezifikation kann als Beobachtet klassifiziert werden, wenn sie die Ausschlusskriterien für Vorgeschlagen erfüllt, ihre Spezifikation finalisiert wurde, sie unter bestimmten Voraussetzungen in neuen Software-Systemen eingesetzt werden darf, sie die Mindestanforderungen an die Offenheit erfüllt, sie das Potenzial hat, zukünftig Empfohlen oder Verbindlich zu werden, an mindestens einer Implementation gearbeitet wird. Eine Spezifikation kann als Empfohlen klassifiziert werden, wenn sie die Ausschlusskriterien für Beobachtet erfüllt,

19 6 Bewertung von Spezifikationen 20 es mindestens zwei unabhängige Implementationen unterschiedlicher Hersteller oder eine lizenzkostenfreie und quelloffene Implementation gibt, es positive Praxiserfahrung aus Einsatzfeldern vergleichbar zur jeweiligen Domäne gibt, Investitionssicherheit angenommen werden kann, es für denselben Zweck keine alternative Spezifikation gibt, die als Verbindlich klassifiziert wurde 41, die Spezifikation selbst eine Norm ist oder es für denselben Zweck keine alternative Norm gibt, die nicht veraltet ist und die der Spezifikation vorgezogen werden müsste 42, es keine als Empfohlen oder Verbindlich klassifizierte Spezifikation gibt, deren paralleler Einsatz den Zielen von SAGA widerspricht 43, sie für neue Software-Systeme eingesetzt werden sollte. Eine Spezifikation kann als Verbindlich klassifiziert werden, wenn sie die Ausschlusskriterien für Empfohlen erfüllt, es keine Alternative gibt, die beim Einsatz in neuen Software-Systemen gegebenenfalls vorgezogen werden darf, sie alle Ziele von SAGA erfüllt, sie am Markt etabliert ist. Eine Spezifikation wird als Bestandsgeschützt klassifiziert, wenn sie zuvor mindestens die Klassifikation Empfohlen hatte oder sie in der Vergangenheit eine große Relevanz für Software-Systeme der jeweiligen Domäne hatte, eine zukünftige Klassifikation als Empfohlen oder Verbindlich nicht mehr möglich oder zu erwarten ist, sie in neuen Software-Systemen nicht mehr ohne SAGA-konforme Alternative eingesetzt werden darf, sie in bestehenden Software-Systemen weiterhin verwendet werden darf (Bestandsschutz), sie durch den Herausgeber nicht bereits seit mehreren Jahren als veraltet deklariert wurde 44. Eine Spezifikation wird als Verworfen klassifiziert, wenn eine zukünftige Klassifikation als Empfohlen oder Verbindlich nicht mehr möglich oder zu erwarten ist, 41 Gegebenenfalls kann auch die verbindliche Klassifikation der Alternative in Frage gestellt werden, um dieses Kriterium zu erfüllen. 42 Siehe (BMJ, 2009A), Abschnitt 2, 8 EG Leistungsbeschreibung, Technische Anforderungen, Absatz 2, der den Ratsbeschluss 87/95/EWG von 1986 umsetzt. 43 In diesem Fall sind die Eigenschaften der Spezifikationen zu vergleichen, um die besser geeigneten höher zu klassifizieren, siehe Abschnitt Dokumentation der Eigenschaften einer Spezifikation auf Seite Wurde eine Spezifikation bereits vor über zwei Jahren durch den Herausgeber als veraltet ( deprecated ) deklariert, sollte sie eher in die Klassifikation Verworfen eingeordnet werden.

20 6 Bewertung von Spezifikationen 21 sie in neuen und bestehenden Software-Systemen nicht mehr ohne SAGA-konforme Alternative eingesetzt werden darf 45, da dies die Ziele von SAGA gefährden würde. 6.3 Erneute Bewertung bereits klassifizierter Spezifikationen Bei jeder Fortschreibung von SAGA-Modulen ist für die Spezifikationen mit den Klassifikationen Beobachtet, Empfohlen und Verbindlich zu überprüfen, ob die Klassifikationen noch angemessen sind. Es ist zu ermitteln und stichpunktartig zu begründen, ob die Klassifikation beibehalten, abgesenkt oder angehoben werden sollte. Für die Einordnung in eine neue Klassifikation gelten die im vorherigen Abschnitt genannten Kriterien. Für Spezifikationen mit der Klassifikation Beobachtet ist zu prüfen: Hat sie sich mittlerweile etabliert beziehungsweise ihre Leistungsfähigkeit nachgewiesen? Kann für ihren Einsatz Investitionssicherheit angenommen werden? Dann ist eine Verschiebung in die Klassifikation Empfohlen möglich. Stagniert die Entwicklung, gab es Rückschläge oder erfolgreichere / vielversprechende Konkurrenz? Dann ist eine Einordnung als Verworfen angemessen. Für Spezifikationen mit der Klassifikation Empfohlen ist zu prüfen: Ist sie mittlerweile die zu bevorzugende Lösung ohne Alternativen? Dann kommt die Klassifikation Verbindlich in Betracht. Hat sie an Boden verloren, sodass beispielsweise zukünftig die Investitionssicherheit nicht mehr gewährleistet werden kann? Dann sollte eine Verschiebung in die Klassifikation Bestandsgeschützt erfolgen. Allerdings sollte dann eine Alternative beziehungsweise neuere Version der Spezifikation als Beobachtet, Empfohlen oder Verbindlich klassifiziert werden. Für Spezifikationen mit der Klassifikation Verbindlich ist zu prüfen: Hat sie an Boden verloren, sodass es mittlerweile in Betracht kommende alternative Lösungen gibt? Dann sollte sie in die Klassifikation Empfohlen verschoben werden. Für Spezifikationen mit der Klassifikation Bestandsgeschützt kann sich aus der Betrachtung alternativer Spezifikationen, die zum Beispiel die Klassifikation Verbindlich erhalten haben, oder aufgrund von Hinweisen aus der Praxis ergeben, eine Neubewertung durchzuführen und sie in die Klassifikation Verworfen zu verschieben. Für Spezifikationen mit der Klassifikation Verworfen können lediglich neuere Versionen der Spezifikation über die Klassifikation Vorgeschlagen eine höhere Einstufung erhalten. 45 Siehe Modul Konformität (BFIT, 2011A), Abschnitt 2.3 Anwendung des Klassifikationssystems

21 7 Prozesse 22 7 Prozesse 7.1 Übersicht Die Weiterentwicklung der SAGA-Module folgt einem kontinuierlichen Verbesserungsprozess (KVP), der in vereinfachter Darstellung einem Plan-Do-Check-Act-Zyklus (PDCA-Zyklus 46 ) entspricht: Abbildung 7-1: Fortschreibungszyklus von SAGA-Modulen Je nachdem, ob eine neue Hauptversion oder eine Zwischenversion eines SAGA-Moduls entwickelt werden soll, teilt sich der PDCA-Zyklus bei näherer Betrachtung in zwei verschiedene Prozesse. Die folgende Abbildung zeigt, wie im Rahmen des Änderungsmanagements die Anforderungen für die nächste Hauptversion gesammelt und gegebenenfalls die Erstellung einer Zwischenversion angestoßen wird: Abbildung 7-2: Änderungsmanagement für SAGA-Module 46 Der PDCA-Zyklus wird nach seinem Erfinder auch Deming-Kreis genannt und hat seinen Ursprung im Qualitätsmanagement. Als solcher findet er auch Verwendung in der ISO 9001 und der ISO auf Basis von IT-Grundschutz.

22 7 Prozesse 23 Für SAGA-Module der Domäne Bundesverwaltung sind beispielsweise die Träger der Rollen: Rolle Träger 47 Änderungssteuerungsgruppe Änderungsverantwortlicher Interessenvertreter IT-Rat BfIT SAGA-Expertenkreis, Anwender von SAGA Tabelle 7-1: Rollen und Träger im Änderungsmanagement für SAGA-Module der Bundesverwaltung 7.2 Entwicklung einer Hauptversion Eine neue Hauptversion wird in der Regel dann entwickelt, wenn der Umfang der Änderungen die Herausgabe eines kompletten SAGA-Moduls rechtfertigt und keine hohe Dringlichkeit zur Bearbeitung der Änderungsanforderungen besteht: Abbildung 7-3: Entwicklungsprozess der Hauptversion eines SAGA-Moduls 47 Vgl. Beschluss Nr. 26/2009 des Rates der IT-Beauftragten vom 7. Oktober 2009

23 7 Prozesse 24 Für SAGA-Module der Domäne Bundesverwaltung sind beispielsweise die Träger der Rollen: Rolle Träger 48 Auftraggeber Auftragnehmer Interessenvertreter IT-Rat BfIT SAGA-Expertenkreis, Anwender von SAGA in der Bundesverwaltung Tabelle 7-2: Rollen und Träger in den Entwicklungsprozessen von SAGA-Modulen der Bundesverwaltung Im Rahmen von Arbeitstreffen zwischen Auftraggeber und Auftragnehmer werden das Pflichtenheft erstellt; die Entwurfsversion abgestimmt; der Umgang mit Stellungnahmen zur Entwurfsversion abgestimmt; SAGA finalisiert (für die Bundesverwaltung gegebenenfalls nach Anweisungen der/des BfIT, des IT-Rats oder der IT-Steuerungsgruppe des Bundes). 7.3 Entwicklung einer Zwischenversion Vor der Publikation einer neuen Hauptversion kann es notwendig sein, auf aktuelle Entwicklungen zeitnah zu reagieren 49. In diesem Fall entscheidet die Änderungssteuerungsgruppe über die Modifikation der aktuellen Version eines SAGA-Moduls. Für die Entwicklung einer Zwischenversion ist der Prozess wie folgt definiert: Abbildung 7-4: Entwicklungsprozess der Zwischenversion eines SAGA-Moduls 48 Vgl. Beschluss Nr. 26/2009 des Rates der IT-Beauftragten vom 7. Oktober Als Beispiel seien erfolgreiche Angriffe auf den Hash-Algorithmus SHA-1 genannt, siehe (BSI, 2008), Abschnitt 3.5 Aktuelle Entwicklungen in der Kryptographie, Seite 46f. In der Folge kann SHA-1 zwar bis Ende 2010 noch zur Erzeugung qualifizierter Zertifikate verwendet werden, aber neue Software-Systeme sollten seit dem Bekanntwerden der Sicherheitsbedenken auf bessere Alternativen ausweichen, siehe (BNETZA, 2011), Kapitel 2 Geeignete Hashfunktionen, Seite 3.

24 7 Prozesse 25 Die Träger der Rollen sind identisch zum Entwicklungsprozess einer Hauptversion. 7.4 Beteiligte Anwender von SAGA können als Interessenvertreter Änderungsanfragen zu SAGA-Modulen stellen 50. Ausgewählte Interessenvertreter haben zusätzlich die Möglichkeit, Entwurfsversionen von SA GA-Modulen zu kommentieren 51. Die Vorschläge an den Auftragnehmer, die über das Änderungsmanagement oder Abstimmungsprozesse eingereicht wurden, werden in einem Rechenschaftsbericht des SAGA-Moduls 52 aufgelistet und das Ergebnis der Prüfung dokumentiert. Es erfolgt eine Begründung der Annahme oder Ablehnung aller Vorschläge. 50 Siehe Abbildung 7-2 Änderungsmanagement für SAGA-Module auf Seite 22; Für die Domäne der Bundesverwaltung wird ein öffentlich zugängliches Änderungs-Management-System zur Verfügung gestellt. 51 Siehe Abbildung 7-3 Entwicklungsprozess der Hauptversion eines SAGA-Moduls auf Seite Für die Domäne Bundesverwaltung siehe Download

25 A Berücksichtigung internationaler Entwicklungen 26 A Berücksichtigung internationaler Entwicklungen Bei der Weiterentwicklung von SAGA-Modulen der Domäne Bundesverwaltung (de.bund) werden im Rahmen von Kooperationen aktuelle Entwicklungen bei internationalen Partnern beobachtet und die Anwendung der Ergebnisse nach dem Ermessen des IT-Rates beziehungsweise der/des BfIT zeitnah koordiniert. Das Ziel dieser Koordination ist, die breite Anwendung von SAGA durch Konvergenz beziehungsweise Harmonisierung mit internationalen Entwicklungen zu erleichtern. Beispiele für relevante internationale Entwicklungen sind die von der Europäischen Kommission herausgegebene European Interoperability Strategy (EIS) 53 und das European Interoperability Framework (EIF) 54. Die/der BfIT vertritt in den europäischen Gremien die deutschen Interessen und stellt die Verbindung mit nationalen Aktivitäten in Deutschland sicher. Insbesondere das European Interoperability Framework (EIF) beeinflusst die Erstellung von SAGA. Das EIF ist ein nicht technisches Dokument, das die Entwicklung von europäischen Diensten der öffentlichen Verwaltung im Hinblick auf die Interoperabilität zwischen nationalen Grenzen und zwischen verschiedenen fachlichen Domänen unterstützt. Dazu wird nationalen Interoperabilitätsdokumenten, wie SAGA, ein Rahmen vorgegeben. Die Begriffsdefinitionen für Interoperabilität, Dienste und Offenheit fließen in die Erstellung von SAGA ein. Die Empfehlungen von SAGA unterliegen den im EIF beschriebenen Grundprinzipien, die für europäische Dienste der öffentlichen Verwaltung aufgestellt werden. Dies spiegelt sich vor allem in den Zielen von SAGA wider. Auch Implikationen der Empfehlungen des EIF mit Einfluss auf zu verwendende Architekturmuster werden durch die Klassifikationen von SAGA unterstützt. Die Auswahl und Bewertung von Spezifikationen folgt dem im EIF geforderten transparenten Prozess. Die Einhaltung verbindlicher internationaler Vorgaben, die sich z. B. aus Bündnisverpflichtungen Deutschlands ergeben, kann durch SAGA nicht abgeschwächt werden. Beispiele dafür sind die NATO Interoperability Standards Profiles (NISP v3) 55 und das NATO Architecture Framework (NAF) 56. Bei der Fortschreibung von SAGA wird auch hier soweit mit den Zielen von SAGA vereinbar eine Konvergenz angestrebt. Möglichst viele Vorgaben von SAGA sollen mit den internationalen Verpflichtungen vereinbar sein. Dann können domänenspezifische Varianten von SAGA die internationalen Vorgaben integrieren. Kommt es bei der Koordination zu Interessenkonflikten oder Widersprüchen, werden diese individuell betrachtet und entsprechend den Zielen und der primären Zielgruppe von SAGA priorisiert und entschieden. 53 Siehe 54 Siehe (ISA, 2010) 55 Siehe 56 Siehe

26 B Standardisierungsstatus von Spezifikationen 27 B Standardisierungsstatus von Spezifikationen Standards sind dadurch gekennzeichnet, dass sie von einem Standardisierungsgremium herausgegeben werden. Für die Einordnung eines Standards in das Klassifikationssystem von SAGA spielt der Reifegrad der Standardisierung eine große Rolle. Im Kontext von SAGA sind drei Reifegrade von Relevanz: Spezifikation begonnen: Für die Einstiegsklassifikation Vorgeschlagen muss ein Standard mindestens vorweisen können, dass der Standardisierungsprozess eingeleitet wurde und dass eine Entwurfsversion vorliegt. Spezifikation finalisiert: Ab der Klassifikation Beobachtet muss die Standardisierung abgeschlossen sein. Spezifikation veraltet: In dem Fall sind nur noch die Klassifikationen Bestandsgeschützt und Verworfen möglich. Für einige Standardisierungsgremien, die besonders viele Spezifikationen zu SAGA beitragen, werden im Folgenden die verschiedenen Standardisierungsstatus für Spezifikationen aufgelistet und gezeigt, welcher Status jeweils mit Spezifikation begonnen, Spezifikation finalisiert und Spezifikation veraltet gleichzusetzen ist. Neben Standards klassifiziert SAGA auch technische Spezifikationen und Berichte. Deren Entwicklungsstatus wird analog zu den Standards beurteilt. B.1 DIN / CEN / ISO Für SAGA relevante Produkte der Normungsgremien DIN, CEN und ISO sind: Deutsche Norm DIN-Norm Europäische Norm DIN-EN-Norm Europäische Technische Spezifikation CEN/TS beziehungsweise CLC/TS Europäischer Technischer Bericht CEN/TR beziehungsweise CLC/TR Internationale Norm ISO-, IEC- beziehungsweise ISO/IEC-Norm Internationale Technische Spezifikation ISO/TS beziehungsweise IEC/TS Internationaler Technischer Bericht ISO/TR beziehungsweise IEC/TR Public Available Specification PAS Entstehung einer nationalen Norm: 57 Normungsantrag Normungsvorlage Manuskript für Normentwurf 57 Siehe