SAGA-Modul Grundlagen Version de.bund 5.1.0

3. November 2011

2

Herausgeber

Die Beauftragte der Bundesregierung für Informationstechnik (BfIT) Redaktion

Bundesministerium des Innern Referat IT 2 - IT-Steuerung Bund Alt-Moabit 101 D 10559 Berlin [email protected] Stand

Version de.bund 5.1.0 – final Vom Rat der IT-Beauftragten der Ressorts am 3. November 2011 beschlossen.

4

Inhaltsverzeichnis 1

Einleitung...................................................................................................................................6

2

Rahmenbedingungen..................................................................................................................6 2.1

Verbindlichkeit........................................................................................................................................................6

2.2

Geltungsbereich.......................................................................................................................................................7

2.3

Zielgruppe...............................................................................................................................................................8

3

Ziele............................................................................................................................................8 3.1

Wirtschaftlichkeit....................................................................................................................................................8

3.2

Agilität.....................................................................................................................................................................9

3.3

Offenheit..................................................................................................................................................................9

3.4

Sicherheit.................................................................................................................................................................9

3.5

Interoperabilität.......................................................................................................................................................9

3.6

Wiederverwendbarkeit..........................................................................................................................................10

3.7

Skalierbarkeit........................................................................................................................................................10

4

Grundprinzipien.......................................................................................................................10 4.1

Terminologie.........................................................................................................................................................10

4.2

Modularisierung und Versionierung.....................................................................................................................10

4.3

Domänenspezifische Varianten.............................................................................................................................11

5

Klassifikationssystem..............................................................................................................12 5.1

Mindestanforderungen an die Offenheit...............................................................................................................12

5.2

Klassifikationen von Spezifikationen...................................................................................................................13

5.3

Auflistung der klassifizierten Spezifikationen.....................................................................................................14

5.4

Lebenslauf klassifizierter Spezifikationen............................................................................................................15

5.5

Nicht klassifizierte Spezifikationen......................................................................................................................16

6

Bewertung von Spezifikationen...............................................................................................17 6.1

Nicht klassifizierte Spezifikationen......................................................................................................................17

6.2

Vorgeschlagene Spezifikationen...........................................................................................................................17 6.2.1

Neuere Versionen und Alternativen...............................................................................................................17

6.2.2

Offenheit.........................................................................................................................................................18

6.2.3

Dokumentation der Eigenschaften einer Spezifikation.................................................................................18

5

6.2.4 6.3

7

Kriterien für die Einordnung in die SAGA-Klassifikationen........................................................................19 Erneute Bewertung bereits klassifizierter Spezifikationen..................................................................................21

Prozesse....................................................................................................................................22 7.1

Übersicht...............................................................................................................................................................22

7.2

Entwicklung einer Hauptversion..........................................................................................................................23

7.3

Entwicklung einer Zwischenversion.....................................................................................................................24

7.4

Beteiligte...............................................................................................................................................................25

A

Berücksichtigung internationaler Entwicklungen...................................................................26

B

Standardisierungsstatus von Spezifikationen..........................................................................27 B.1

DIN / CEN / ISO...................................................................................................................................................27

B.2

Ecma......................................................................................................................................................................28

B.3

OASIS...................................................................................................................................................................29

B.4

W3C......................................................................................................................................................................29

C

Literatur....................................................................................................................................30

D

Abkürzungsverzeichnis............................................................................................................32

1 Einleitung

1

6

Einleitung

SAGA1 ist eine Zusammenstellung von Referenzen auf Spezifikationen und Methoden für SoftwareSysteme der öffentlichen Verwaltung. SAGA ist modular aufgebaut. Die SAGA-Module können zeitlich und weitgehend inhaltlich unab­ hä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 Bundesregie­ rung 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, ver­ bindliche, 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ül­ len. SAGA bietet die Möglichkeit, domänenspezifische Varianten zu erstellen, sodass SAGA an die un­ terschiedlichen 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äne5 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 2 3 4 5 6

SAGA ist ein Eigenname, der ursprünglich als Abkürzung von „Standards und Architekturen für eGovernment-Anwendungen“ eingeführt wurde. Siehe http://www.cio.bund.de/saga Siehe (ISA, 2010) Siehe (BFIT, 2011A) Siehe auch Abschnitt 4.3 „Domänenspezifische Varianten“ auf Seite 11 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“ verbind­ lich bleiben.

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 wer­ den7.

2.2 Geltungsbereich SAGA wird bei Beschaffung, Erstellung und Weiterentwicklung von Software-Systemen angewen­ det. Die Vorgaben von SAGA gelten für alle neuen Software-Systeme8. 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 Funktionsumfan­ ges. 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 wer­ den. 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 Fertig­ stellung von Teilen eines Software-Systems unterstützt werden. Es sollte jedoch für das gesamte be­ stehende 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 Systeme9 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 8 9

Siehe auch Abschnitt 4.3 „Domänenspezifische Varianten“ auf Seite 11 Software-Systeme sind im weitesten Sinn ausführbare Programme und die zugehörigen Daten und Dokumentationen Eingebettete Systeme umfassen sowohl Hardware- als auch Software-Einheiten, siehe (BFIT, 2010), zum Beispiel so genannte Appliances

2 Rahmenbedingungen

8

2.3 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 Auf­ traggeber als auch für ihre Auftragnehmer. Darüber hinaus ist die interessierte Öffentlichkeit10 herzlich eingeladen, SAGA für eigene Zwecke einzusetzen und an der Fortschreibung mitzuwirken11.

3

Ziele

Aufgrund der kurzen Innovationszyklen in der Informationstechnik einerseits und den hohen Investi­ tions- und Migrationskosten für Entwicklungen und Einführungen von Software-Systemen anderer­ seits 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 be­ achten 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-)Kosten13 sowie solche, die bei der späteren Ablösung eines Software-Systems entstehen. Des Weiteren sind Risiken zu minimieren und Investitionssicher­ heit anzustreben.

10 11 12 13

Zum Beispiel Wirtschaft und Wissenschaft Siehe Abschnitt 7.4 „Beteiligte“ auf Seite 25 Siehe beispielsweise § 7 der Bundeshaushaltsordnung (BHO) (BMJ, 2009B) Siehe beispielsweise die Ausführungen der WiBe 4.1 (BMI, 2007)

3 Ziele

9

3.2 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 funk­ tionale 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 Ver­ waltung 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 Bedro­ hungslagen 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 Schutzbe­ darf bezüglich der Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit aufweisen.

3.5 Interoperabilität Interoperabilität15 verbessert die Vernetzung beziehungsweise Vernetzbarkeit von Systemen und er­ möglicht den elektronischen Datenaustausch jenseits des Horizonts des ursprünglich geplanten Ein­ satzbereiches. Sie ermöglicht die Realisierung von vernetzten Software-Systemen mit unterschiedli­ chen Lieferanten. Interoperabilität führt dazu, dass die Kunden bei der Auswahl von Software-Syste­ men nicht eingeschränkt werden und fördert so den Wettbewerb und die Verbreitung von Innovatio­ nen in der IT-Branche. Sie fördert die Nachhaltigkeit von Software-Systemen und unterstützt zu­ gleich 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 Rol­ len der Kommunikationspartner, technische Interoperabilität klärt die Repräsentation und den Trans­ port von Informationen und semantische Interoperabilität ist für ein gemeinsames Verständnis der Bedeutung der auszutauschenden Informationen verantwortlich, siehe (ISA, 2010).

3 Ziele

10

3.6 Wiederverwendbarkeit Die Wiederverwendbarkeit von Software-Systemen16 und ihrer Elemente ermöglicht eine mehrmali­ ge Nutzung für gleiche oder ähnliche Anforderungen. Eine redundante Entwicklung wird somit ver­ mieden sowie Betrieb, Pflege und Wartung vereinfacht. Sie unterstützt damit direkt die weiteren Zie­ le Wirtschaftlichkeit und Agilität.

3.7 Skalierbarkeit Skalierbarkeit bedeutet die Fähigkeit eines Software-Systems, mit geringem Aufwand einen wach­ senden oder schrumpfenden Bedarf an Verarbeitungskapazität zu decken. Je skalierbarer ein Soft­ ware-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 Vor­ gaben eine einheitliche Regelung für die Verwendung der Verben MUSS, SOLLTE, KANN sowie der Ver­ neinungen DARF NICHT und SOLLTE NICHT17: •

MUSS:

•

SOLLTE:

•

KANN:

•

DARF NICHT:

•

SOLLTE NICHT:

Kennzeichnet eine Aussage mit dem Charakter einer verbindlichen Festlegung. Kennzeichnet eine Aussage mit dem Charakter einer positiven Empfehlung.

Kennzeichnet eine Aussage mit dem Charakter einer gestatteten Option. Kennzeichnet eine Aussage mit dem Charakter eines verbindlichen Verbotes. Kennzeichnet eine Aussage mit dem Charakter einer negativen Empfehlung.

Zur besseren Übersicht werden die Verben in den Texten der SAGA-Module typografisch hervorge­ hoben.

4.2 Modularisierung und Versionierung SAGA ist modular aufgebaut. Die SAGA-Module können zeitlich und weitgehend inhaltlich unab­ hängig voneinander publiziert werden. Die Inhalte der SAGA-Module sind beispielsweise •

Technische Spezifikationen (Präsentation, Kommunikation, Datenaustauschformate, Sicher­ heit etc.)

•

Semantische Spezifikationen (Kernkomponenten, Code-Listen, Taxonomien, Datenwörter­ bü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.

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 im­ mer 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. „5.0.0“, 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 ledig­ lich einzelne Abschnitte oder Aspekte aktualisiert oder ergänzt, erfolgt die Publikation als Zwischen­ version. Die Gesamtversionsnummer von SAGA beginnt stets mit einer „5“ als Hauptversionsnummer, ge­ folgt von einer laufenden Ziffer, die bei jeder Ergänzung oder Überarbeitung eines Moduls hochge­ zä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 Mo­ dul 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 Varianten19 von SAGA-Modulen zu erstellen, so­ dass 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 sinnge­ mäß für alle Varianten gültig. Abgeleitete domänenspezifische Varianten von SAGA-Modulen können: 18 Siehe http://www.cio.bund.de/saga 19 Eine Domäne wird in diesem Zusammenhang aus einem oder mehreren klar abgegrenzten Hand­ lungsfeldern 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)

4 Grundprinzipien

•

Nicht verbindliche Festlegungen weglassen,

•

Nicht verbindliche Festlegungen verbindlich machen,

•

Festlegungen (nicht verbindliche und verbindliche) ergänzen.

12

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üs­ sen domänenspezifische Varianten in ihrem Namen ausweisen, von welcher Hauptversion oder Vari­ ante von SAGA sie sich ableiten, z. B. „SAGA-Modul Technische Spezifikationen, Version de.bund.justiz 5.0.0, Variante der Version de.bund 5.0.0“. 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 In­ dividualentwicklungen und Produkte bereitgestellt werden21. 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 an­ zupassen. 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 Verpflichtun­ gen 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 Vari­ anten.

5

Klassifikationssystem

5.1 Mindestanforderungen an die Offenheit Ein Ziel von SAGA ist die Verwendung von offenen Spezifikationen in Software-Systemen der öf­ fentlichen Verwaltung23. Dazu werden Mindestanforderungen an die Offenheit gestellt. Eine Spezifi­ kation, die diese Anforderungen erfüllt, kann in SAGA als „Beobachtet“, „Empfohlen“ oder „Ver­ bindlich“ klassifiziert werden. Sie ist jedoch nicht notwendigerweise ein offener Standard im Sinne einer Definition irgendeines Standardisierungsgremiums24. 21 22 23 24

Siehe Modul „Konformität“ (BFIT, 2011A), Abschnitt 2.2 „Definition der SAGA-Konformität“ Siehe Abschnitt 7.2 „Entwicklung einer Hauptversion“ auf Seite 23 Siehe Abschnitt 3.3 auf Seite 9 Über die Mindestanforderungen hinausgehende Eigenschaften von Spezifikationen können für die Klassifizierung herangezogen werden, um offenere Spezifikationen höher zu klassifizieren als weni­ ger offene, siehe Abschnitt 6.2.3 „Dokumentation der Eigenschaften einer Spezifikation“ auf Seite

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 un­ eingeschränkt und kostenfrei möglich.25 3. 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 eingeord­ net: Vorgeschlagen, Beobachtet, Empfohlen, Verbindlich, Bestandsgeschützt oder Verworfen. Kon­ kurrierende Spezifikationen26, die nicht klassifiziert sind, sollten nicht oder nur in Ausnahmefällen angewendet werden27. Vorgeschlagen

Die Klassifikation „Vorgeschlagen“ ist die initiale Klassifikation einer Spezifikation in SAGA. Spe­ zifikationen werden als „Vorgeschlagen“ klassifiziert, wenn ein Interessenvertreter eine Änderungs­ anfrage 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 Rei­ fe 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 Entwicklungs­ richtung folgen, finalisiert sind und die Mindestanforderungen an die Offenheit 28 erfüllen. Gegebe­ nenfalls haben sie sich aber noch nicht ausreichend in der Praxis bewährt oder erfüllen bislang nicht alle Ziele von SAGA29.

18. 25 Damit ist nicht gemeint, dass es zwangsläufig kostenfreie Implementationen geben muss. Das Krite­ rium 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 Verwen­ dung nicht eingeschränkt wird, z. B. durch eine Bedingung, dass ein Produkt keine weiteren alterna­ tiven Spezifikationen parallel implementieren darf. 26 Konkurrierende Spezifikationen sind solche, die für dieselbe Aufgabe geeignet sind, aber unter­ schiedliche Lösungsansätze anbieten. Die Eignung ist wesentlich von der Aufgabe abhängig. So kann z. B. zur Kodierung mitteleuropäischer Texte sowohl ISO 8859-1 als auch UTF-8 verwendet werden. Beide Spezifikationen sind für diese spezifische Aufgabe geeignet und damit im Sinne die­ ses Abschnitts „Konkurrenten“, auch wenn UTF-8 viel universeller einsetzbar ist, z. B. auch zur Ko­ dierung osteuropäischer und asiatischer Texte. 27 Siehe Abschnitt 5.5 auf Seite 16 28 Siehe Abschnitt 5.1 auf Seite 12 29 Siehe Kapitel 3 auf Seite 8

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 Investiti­ onssicherheit 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 klassifi­ zierte) konkurrierende Spezifikationen existieren und sie zuvor mindestens die Klassifikation „Emp­ fohlen“ 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 abge­ lehnt 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 werden31: •

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 8859-1 durch Unicode abgelöst und das veraltete HTML 3.2 wurde durch HTML 4.01 ersetzt 31 Siehe (BFIT, 2011B)

5 Klassifikationssystem

15

5.4 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 „Emp­ fohlen“ 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 wer­ den diese Spezifikationen zunächst mit der Klassifikation „Vorgeschlagen“ gesammelt. 2: Vorgeschlagene Spezifikationen, die nach erfolgter Prüfung für neue und bestehende Soft­ ware-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 wer­ den 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.

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 Neubewer­ tung auf „Empfohlen“ herabgesetzt. 8: Wenn empfohlene Spezifikationen nach erfolgter Prüfung in neuen Projekten nicht mehr ein­ gesetzt werden sollten, erhalten sie die Klassifikation „Bestandsgeschützt“. 9: Bestandsgeschützte Spezifikationen, für die ausreichend lange Bestandsschutz gewährt wur­ de 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 er­ läutert.32

5.5 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 Aufnah­ me 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 Spezifika­ tionen 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 Spe­ zifikationen 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“

6 Bewertung von Spezifikationen

6

17

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 De­ finitionen der Klassifikationen35 bedeuten und wie sich die Verfolgung der Ziele von SAGA36 in der Klassifizierung niederschlägt. Die Bewertung einer Spezifikation erfolgt stets im Kontext ihres vorgesehenen Einsatzfeldes für Software-Systeme der jeweiligen Domäne37. Da eine Spezifikation für verschiedene Anwendungsfäl­ le 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ält38.

6.1 Nicht klassifizierte Spezifikationen Für die Aufnahme einer Spezifikation in die Vorschlagsliste erfolgt keine Untersuchung ihrer Quali­ tä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 6.2.1

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 ha­ ben. 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-Klas­ sifikation 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 13 36 Siehe Kapitel 3 „Ziele“ auf Seite 8 37 Für die Domäne „Bundesverwaltung“ werden alle Bewertungen von Spezifikationen veröffentlicht, siehe http://www.cio.bund.de/saga. 38 Z. B. kann JPEG im Themenfeld „Austauschformate für Bilder“ als „Verbindlich“ klassifiziert sein und im Themenfeld „Langzeitspeicherung“ lediglich als „Empfohlen“.

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

6.2.2

Offenheit

Um die Klassifikation „Beobachtet“, „Empfohlen“ oder „Verbindlich“ erhalten zu können, muss die Spezifikation die Mindestanforderungen an die Offenheit39 erfüllen. Sind diese Anforderungen er­ füllt, ist zu dokumentieren: •

welches Standardisierungsgremium die Spezifikation herausgibt,

•

welche Identifikationsnummer (z.B. bei ISO und DIN-Normen), welchen Titel und gegebe­ nenfalls 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 jeweili­ ge 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 Klassifika­ tionen „Bestandsgeschützt“ oder „Verworfen“ in Frage. Dann ist zu dokumentieren, welche konkrete Anforderung nicht erfüllt wurde.

6.2.3

Dokumentation der Eigenschaften einer Spezifikation

Zur Wahl der geeigneten Klassifikation für eine Spezifikation sind zur Beurteilung aller Anforderun­ gen die folgenden Fragen zu beantworten: •

Werden die Mindestanforderungen an die Offenheit erfüllt40?

•

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 12 40 Siehe Abschnitt 6.2.2

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 kos­ tenfrei / 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 of­ fen?

•

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.

6.2.4

Kriterien für die Einordnung in die SAGAKlassifikationen

Im Folgenden werden Ausschlusskriterien, die für eine Klassifikation erfüllt sein müssen, beschrie­ ben. Die Kriterien müssen für die Software-Systeme der jeweiligen Domäne des SAGA-Moduls gel­ ten, 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,

6 Bewertung von Spezifikationen

20

•

es mindestens zwei unabhängige Implementationen unterschiedlicher Hersteller oder eine li­ zenzkostenfreie 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“ klassifi­ ziert wurde41,

•

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 paralle­ ler Einsatz den Zielen von SAGA widerspricht43,

•

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 vor­ gezogen 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“, Ab­ satz 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 6.2.3 „Dokumentation der Eigenschaften einer Spezifikati­ on“ auf Seite 18. 44 Wurde eine Spezifikation bereits vor über zwei Jahren durch den Herausgeber als veraltet („depreca­ ted“) deklariert, sollte sie eher in die Klassifikation „Verworfen“ eingeordnet werden.

6 Bewertung von Spezifikationen

•

21

sie in neuen und bestehenden Software-Systemen nicht mehr ohne SAGA-konforme Alter­ native eingesetzt werden darf45, 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 ange­ messen 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 Verschie­ bung 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 Klas­ sifikation „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 „Be­ standsgeschü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ösun­ gen gibt? Dann sollte sie in die Klassifikation „Empfohlen“ verschoben werden.

Für Spezifikationen mit der Klassifikation „Bestandsgeschützt“ kann sich aus der Betrachtung alter­ nativer Spezifikationen, die zum Beispiel die Klassifikation „Verbindlich“ erhalten haben, oder auf­ grund von Hinweisen aus der Praxis ergeben, eine Neubewertung durchzuführen und sie in die Klas­ sifikation „Verworfen“ zu verschieben. Für Spezifikationen mit der Klassifikation „Verworfen“ können lediglich neuere Versionen der Spe­ zifikation über die Klassifikation „Vorgeschlagen“ eine höhere Einstufung erhalten.

45 Siehe Modul „Konformität“ (BFIT, 2011A), Abschnitt 2.3 „Anwendung des Klassifikationssystems“

7 Prozesse

7

22

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) ent­ spricht:

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 27001 auf Basis von IT-Grundschutz.

7 Prozesse

23

Für SAGA-Module der Domäne Bundesverwaltung sind beispielsweise die Träger der Rollen: Rolle

Träger47

Änderungssteuerungsgruppe

IT-Rat

Änderungsverantwortlicher

BfIT

Interessenvertreter

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 Bearbei­ tung 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

7 Prozesse

24

Für SAGA-Module der Domäne Bundesverwaltung sind beispielsweise die Träger der Rollen: Rolle

Träger48

Auftraggeber

IT-Rat

Auftragnehmer

BfIT

Interessenvertreter

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 reagieren49. In diesem Fall entscheidet die Änderungssteuerungsgruppe über die Modifi­ kation 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 2009 49 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 Alter­ nativen ausweichen, siehe (BNETZA, 2011), Kapitel 2 „Geeignete Hashfunktionen“, Seite 3.

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 stel­ len50. Ausgewählte Interessenvertreter haben zusätzlich die Möglichkeit, Entwurfsversionen von SA­ GA-Modulen zu kommentieren51. Die Vorschläge an den Auftragnehmer, die über das Änderungsma­ nagement oder Abstimmungsprozesse eingereicht wurden, werden in einem Rechenschaftsbericht des SAGA-Moduls52 aufgelistet und das Ergebnis der Prüfung dokumentiert. Es erfolgt eine Begrün­ dung 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 23 52 Für die Domäne Bundesverwaltung siehe http://www.cio.bund.de/saga → „Download“

A Berücksichtigung internationaler Entwicklungen

A

26

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 zeit­ nah koordiniert. Das Ziel dieser Koordination ist, die breite Anwendung von SAGA durch Konver­ genz 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 Fra­ mework (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 öf­ fentlichen Verwaltung im Hinblick auf die Interoperabilität zwischen nationalen Grenzen und zwi­ schen verschiedenen fachlichen Domänen unterstützt. Dazu wird nationalen Interoperabilitätsdoku­ menten, 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 ver­ einbar – eine Konvergenz angestrebt. Möglichst viele Vorgaben von SAGA sollen mit den internatio­ nalen 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 individu­ ell betrachtet und entsprechend den Zielen und der primären Zielgruppe von SAGA priorisiert und entschieden.

53 54 55 56

Siehe http://ec.europa.eu/isa/strategy/ Siehe (ISA, 2010) Siehe http://nhqc3s.nato.int/architecture/_docs/NISPv2/pdf/NISP-Vol2-v2-internet.pdf Siehe http://www.nhqc3s.nato.int/ARCHITECTURE/_docs/NAF_v3/ANNEX1.pdf

B Standardisierungsstatus von Spezifikationen

B

27

Standardisierungsstatus von Spezifikationen

Standards sind dadurch gekennzeichnet, dass sie von einem Standardisierungsgremium herausgege­ ben 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 ab­ geschlossen 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, wer­ den im Folgenden die verschiedenen Standardisierungsstatus für Spezifikationen aufgelistet und ge­ zeigt, welcher Status jeweils mit „Spezifikation begonnen“, „Spezifikation finalisiert“ und „Spezifi­ kation veraltet“ gleichzusetzen ist. Neben Standards klassifiziert SAGA auch technische Spezifikationen und Berichte. Deren Entwick­ lungsstatus 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 http://www.din.de/cmd?level=tpl-artikel&cmstextid=54278&languageid=de

B Standardisierungsstatus von Spezifikationen

•

Normentwurf [Spezifikation begonnen]

•

Manuskript für Norm

•

Deutsche Norm – DIN-Norm [Spezifikation finalisiert]

28

Entstehung einer Europäischen Norm:58 •

Vorschlag

•

Arbeitsgruppe (Manuskript für prEN-Normentwurf)

•

prEN-Normentwurf [Spezifikation begonnen]

•

Öffentliche Umfrage

•

Schlussentwurf

•

Schlussabstimmung

•

Ratifizierung

•

Europäische Normung

•

Nationale Normung – DIN-EN-Norm [Spezifikation finalisiert]

Entstehung einer Internationalen Norm:59 •

Vorschlag (10.00 NP: New Proposal)

•

Annahme des Normungsvorhabens (20.00 New project registered)

•

Komitee-Entwurf (30.00 CD: Committee Draft)

•

Internationaler Normentwurf (40.00 DIS: Draft International Standard / CDV: Committee Draft for Voting) [Spezifikation begonnen]

•

Schlussentwurf (50.00 FDIS: Final Draft International Standard)

•

Internationale Norm (60.00 International Standard under publication)

•

Veröffentlichung als ISO-, IEC- oder ISO/IEC-Norm (60.60 International Standard published) [Spezifikation finalisiert]

•

Zurückgezogen (95.99 Withdrawal of International Standard) [Spezifikation veraltet]

B.2 Ecma Für SAGA relevante Produkte der Ecma: •

Ecma Standard

•

Ecma Technical Report

Entstehung einer Ecma-Norm:60 •

Vorschlag (Work item proposal)

58 Siehe http://www.din.de/cmd?level=tpl-unterrubrik&cmssubrubid=47510&languageid=de 59 Siehe http://www.din.de/cmd?level=tpl-unterrubrik&cmssubrubid=47503&languageid=de und http://www.iso.org/iso/standards_development/processes_and_procedures/stages_description/stages_ table.htm 60 Siehe http://www.ecma-international.org/activities/General/presentingecma.pdf

B Standardisierungsstatus von Spezifikationen

•

Akzeptiert zur Standardisierung

•

Entwurf (1st Draft, ...) [Spezifikation begonnen]

•

interne Abstimmung (Review)

•

finaler Entwurf (Final Draft)

•

Ecma Standard [Spezifikation finalisiert]

•

Ecma withdrawn Standard [Spezifikation veraltet]

29

B.3 OASIS Die Organization for the Advancement of Structured Information Standards (OASIS) kennt die fol­ genden Stufen im Standardisierungsprozess:61 •

Approval of a Committee Draft [Spezifikation begonnen]

•

Public Review

•

Approval of a Committee Specification

•

Approval of an OASIS Standard [Spezifikation finalisiert]

•

Approved Errata

B.4 W3C Das World Wide Web Consortium (W3C) vergibt im Standardisierungsprozess die folgenden Reife­ grade:62 •

Working Draft (WD) [Spezifikation begonnen]

•

Candidate Recommendation (CR)

•

Proposed Recommendation (PR)

•

Proposed Edited Recommendation

•

W3C Recommendation (REC) [Spezifikation finalisiert]

•

Rescinded Recommendation [Spezifikation veraltet]

61 Siehe http://www.oasis-open.org/committees/process.php#standApprovProcess 62 Siehe http://www.w3.org/2005/10/Process-20051014/tr.html

C Literatur

C

30

Literatur

(BFIT, 2010) Die Beauftragte der Bundesregierung für Informationstechnik (Hrsg.): V-Modell XT Bund; Version 1.0 (Basis V-Modell XT 1.3); März 2010; http://www.cio.bund.de/DE/IT-Methoden/V-Modell_XT_Bund/vmodell_xt_bund_node.html; http://www.cio.bund.de/ → „IT-Methoden“ → „V-Modell XT Bund“ → „Links“ (BFIT, 2011A) Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Modul Konformität; Version de.bund 5.1.0, November 2011; http://www.cio.bund.de/saga (BFIT, 2011B) Die Beauftragte der Bundesregierung für Informationstechnik: SAGA; 2011; http://www.cio.bund.de/saga (BSI, 2008) Bundesamt für Sicherheit in der Informationstechnik: Jahresbericht 2006/2007; 2008; https://www.bsi.bund.de/cae/servlet/contentblob/487524/publicationFile/30745/bsi_jahresbe richt_2006-2007_pdf.pdf; https://www.bsi.bund.de/ → „Publikationen“ → „Jahresberichte“ → „BSI Jahresbericht 2006/2007“ (BSI, 2011) Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz; 2011; http://www.it-grundschutz.de/ (BMJ, 2009A) Bundesministerium der Justiz: Bekanntmachung der Vergabe- und Vertragsordnung für Leistungen – Teil A (VOL/A) Ausgabe 2009; November 2009; http://www.bmwi.de/BMWi/Redaktion/PDF/Gesetz/verdingungsordnung-fuer-leistungenvol-a-2009,property=pdf,bereich=bmwi,sprache=de,rwb=true.pdf; http://www.bmwi.de/ → „Wirtschaft“ → „Wirtschaftspolitik“ → „Öffentliche Aufträge“ → „Vergabe- und Vertragsordnung für Leistungen (VOL)“ → „Downloads“ → „Vergabe- und Vertragsordnung für Leistungen (VOL)“ (BMJ, 2009B) Bundesministerium der Justiz: Bundeshaushaltsordnung; Juli 2009; http://www.gesetze-im-internet.de/bundesrecht/bho/gesamt.pdf (BMI, 2007) Bundesministerium des Innern: WiBe 4.1 – Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der Bundesverwaltung, insbesondere beim Einsatz der IT; Januar 2007; http://www.cio.bund.de/SharedDocs/Publikationen/DE/ITMethoden/wibe_fachkonzept_download.pdf?__blob=publicationFile;

C Literatur

31

http://www.cio.bund.de/ → „IT-Methoden“ → „WiBe“ → „Downloads“ → „WiBe Fachkonzept IT 4.1-2007“ (BNETZA, 2011) Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen: Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung; Februar 2011; http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/BNetzA/Sachgebiete/QES/V eroeffentlichungen/Algorithmen/2011AlgoKatpdf.pdf?__blob=publicationFile; http://www.bundesnetzagentur.de/ → „Sachgebiete“ → „Qualifizierte elektronische Signatur“ → „Veröffentlichungen“ → „Algorithmen“ → „Algorithmenkatalog 2011“ (IETF, 1997) Internet Engineering Task Force (IETF), Network Working Group: Key words for use in RFCs to Indicate Requirement Levels; Request for Comments: 2119; März 1997; http://tools.ietf.org/html/rfc2119 (ISA, 2010) ISA: European Interoperability Framework (EIF) for European public services; Dezember 2010; http://ec.europa.eu/isa/strategy/doc/annex_ii_eif_en.pdf; http://ec.europa.eu/isa/strategy/ → „Annex II - EIF (European Interoperability Framework)“

D Abkürzungsverzeichnis

D

32

Abkürzungsverzeichnis

BfIT

Die/Der Beauftragte der Bundesregierung für Informationstechnik

BMI

Bundesministerium des Innern

BMJ

Bundesministerium der Justiz

BNetzA

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen

BSI

Bundesamt für Sicherheit in der Informationstechnik

CD

Committee Draft

CDV

Committee Draft for Voting

CEN

Comité Européen de Normalisation (Europäisches Komitee für Normung)

CENELEC

Comité Européen de Normalisation Électrotechnique (Europäisches Komitee für elektrotechnische Normung)

CR

Candidate Recommendation

CLC

CENELEC

DIN

Deutsches Institut für Normung e.V.

DIS

Draft International Standard

DOMEA

Dokumentenmanagement und elektronische Archivierung im IT-gestützten Ge­ schäftsgang

Ecma

ein Eigenname (früher: European Computer Manufacturers Association)

EIF

European Interoperability Framework

EN

Europäische Norm

EU

Europäische Union

FDIS

Final Draft International Standard

HTML

HyperText Markup Language

IEC

International Electrotechnical Commission

IETF

Internet Engineering Task Force

ISA

Interoperability Solutions for European Public Administrations

ISO

International Organization for Standardization

IT

Informationstechnologie

ITIL

IT Infrastructure Library

IT-Rat

Rat der IT-Beauftragten der Bundesressorts

JPEG

Joint Photographic Experts Group

NAF

NATO Architecture Framework

D Abkürzungsverzeichnis

NATO

North Atlantic Treaty Organization

NISP

NATO Interoperability Standards Profiles

NP

New Proposal

OASIS

Organization for the Advancement of Structured Information Standards

PAS

Public Available Specification

PDCA-Zyklus „Plan-Do-Check-Act“-Zyklus PG

Projektgruppe

prEN

Provisional European Standard (Entwurf einer Europäischen Norm)

REC

Recommendation

RFC

Request for Comments

SAGA

ein Eigenname (ursprünglich: Standards und Architekturen für eGovernment-An­ wendungen)

SHA

Secure Hash Algorithm

TR

Technical Report (Technischer Bericht)

TS

Technical Specification (Technische Spezifikation)

UTF

Unicode Transformation Format

VOL/A

Vergabe- und Vertragsordnung für Leistungen – Teil A

WD

Working Draft

WiBe

Wirtschaftlichkeitsbetrachtung

W3C

World Wide Web Consortium

33