SAGA-Modul Konformität 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.

3

4

Inhaltsverzeichnis 1

Einleitung...................................................................................................................................5

2

Grundprinzipien der SAGA-Konformität..................................................................................5 2.1

Terminologie...........................................................................................................................................................5

2.2

Definition der SAGA-Konformität.........................................................................................................................6

2.3

Anwendung des Klassifikationssystems.................................................................................................................7

2.4

SAGA-Konformität trotz niedriger Klassifikation.................................................................................................9

2.5

Verantwortung für SAGA-Konformität................................................................................................................10

2.6

Migration zur Konformität....................................................................................................................................10

2.7

Zertifizierung von SAGA-Konformität................................................................................................................11

3

SAGA-Konformität in der Ausschreibung..............................................................................11

A

V-Modell XT Bund und SAGA-Konformität..........................................................................14

B

Literatur....................................................................................................................................15

C

Abkürzungsverzeichnis............................................................................................................16

1 Einleitung

1

5

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, was SAGA-Konformität bedeutet und wie vorzugehen ist, um die SAGA-Konformität von Software-Systemen zu sichern und zu erklären. Ziel jeder Standardisierungsaktivität muss es sein, ein eindeutiges und messbares Regelwerk zu ent­ wickeln, nach dem bestehende und neue Lösungen beurteilt werden können. Gleiches gilt für die Er­ stellung von SAGA. SAGA entfaltet erst dann seinen vollen Nutzen bei der Entwicklung von Soft­ ware-Systemen, wenn die Berücksichtigung des Dokuments nicht nur verbindlich, sondern auch überprüfbar ist. Dieses Modul stellt deshalb vor, wie die anderen Module von SAGA 5 3 anzuwenden sind, und wie trotz der komplexen Inhalte der SAGA-Module ein handhabbares Vorgehen aussieht, um projektbegleitend die Konformität von Software-Systemen zu SAGA sicherzustellen. Die Abnahme der SAGA-Konformitätserklärung ist der Abschluss eines Prozesses, der von Anfang an mit dem Projektablauf verzahnt ist. Dieser Prozess erzeugt nur geringe Mehraufwände gegenüber dem herkömmlichen Prozessablauf und gewährleistet Transparenz und Vertragssicherheit zwischen Auftraggeber und Auftragnehmer hinsichtlich SAGA-Konformität. Zur Beantwortung der Frage, wie die Konformität zu SAGA sichergestellt und überprüft werden kann, wurde auch untersucht, ob Zertifizierungen von Projekten, Software-Produkten und Personen hilfreich sein könnten.

2

Grundprinzipien der SAGAKonformität

2.1 Terminologie Die Erläuterungen in diesem SAGA-Modul machen deutlich, wie die anderen Module von SAGA 5 4 anzuwenden sind, damit die Entwicklung oder Beschaffung eines Software-Systems SAGA-konform erfolgt. Im SAGA-Modul „Grundlagen“5 wird die Bedeutung der verwendeten Verben für alle SA­ GA-Module erläutert. Hier werden die Auswirkungen dieser Verben auf die Konformität zu SAGA betrachtet. 1 2 3 4 5

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 http://www.cio.bund.de/saga Siehe http://www.cio.bund.de/saga Siehe (BFIT, 2011C), Abschnitt 4.1 „Terminologie“

2 Grundprinzipien der SAGA-Konformität

•

MUSS:

•

SOLLTE:

•

KANN:

•

DARF NICHT:

6

Zur Erreichung von SAGA-Konformität sind keine Abweichungen von verbindlichen Festlegungen zulässig. Unter der Angabe von nachvollziehbaren Gründen (z. B. Wirtschaftlichkeit oder be­ sondere fachliche Anforderungen) kann von positiven Empfehlungen abgewichen werden, ohne die SAGA-Konformität zu verletzen. Kennzeichnet eine gestattete SAGA-konforme Option. Zur Erreichung von SAGA-Konformität müssen verbindliche Verbote eingehal­

ten werden. •

SOLLTE NICHT:

Unter der Angabe von nachvollziehbaren Gründen (z. B. Wirtschaftlichkeit oder besondere fachliche Anforderungen) kann von negativen Empfehlungen abgewichen werden, ohne die SAGA-Konformität zu verletzen.

2.2 Definition der SAGA-Konformität Die SAGA-Konformität eines Software-Systems wird anhand der in SAGA beschriebenen Modelle, Methoden und Spezifikationen beurteilt: •

Berücksichtigung standardisierter Prozessmodelle

•

Berücksichtigung standardisierter Datenmodelle

•

Einsatz von Methoden und Spezifikationen anhand der Klassifikationen in SAGA

Um eine umfassende Aussage über die SAGA-Konformität eines Software-Systems insbesondere bei der Umsetzung komplexer Fachverfahren zu ermöglichen, sollte ein System für die Konformitäts­ aussage zunächst in einzelne Einheiten untergliedert werden. Hier wird zwischen individuell entwi­ ckelten Software-Einheiten (SW-Einheiten6) und Externen Einheiten7 (Produkten) unterschieden, sie­ he Abbildung 2-1. Zur Beurteilung der SAGA-Konformität von Produkten wird vor allem Wert auf Kommunikationsschnittstellen, Datenaustauschformate und Sicherheit gelegt. Für Individualent­ wicklungen – unabhängig davon, ob sie von der öffentlichen Verwaltung selbst oder im Auftrag der Verwaltung von Dienstleistern entwickelt werden – sind zusätzlich die Spezifikationen zur Modellie­ rung und Implementierung der Software-Einheiten relevant. Alle Klassifikationen sind in den SA­ GA-Modulen entsprechend gekennzeichnet, ob sie nur für Individualentwicklungen oder für Produk­ te und Individualentwicklungen gelten. Auf der BfIT-Website werden eine leere und eine beispielhaft ausgefüllte Konformitätserklärung mit Checklisten für Software-Einheiten (Individualentwicklung) und Externe Einheiten (Produkte) zur Verfügung gestellt.8 Die Checklisten enthalten die Themenbereiche, die jeweils für Individualent­ wicklungen oder Produkte von Belang sind. 6 7

8

Nach dem V-Modell XT Bund ist eine SW-Einheit das in der Hierarchie am weitesten oben stehende Systemelement, das ausschließlich aus Software besteht. Eine SW-Einheit ist beispielsweise die Kundenverwaltung eines Informationssystems, siehe (BFIT, 2010), Abschnitt 3.7.5 „SW-Einheit“. Nach dem V-Modell XT Bund sind Externe Einheiten Systemelemente, die nicht innerhalb des Projekts entwickelt werden. Bei einer Externen Einheit kann es sich um ein Fertigprodukt, eine Beistellung des Auftraggebers, ein im Vorfeld entwickeltes System oder Segment, welches wiederverwendet wird, ein Nachbarsystem oder das Ergebnis eines Unterauftrags handeln. Eine Externe Einheit ist beispielsweise ein Datenbankserver, siehe (BFIT, 2010), Abschnitt 3.7.4 „Externe Einheit“. Siehe (BFIT, 2011B)

2 Grundprinzipien der SAGA-Konformität

7

Software-System

Einheit 1 (Individualentwicklung)

Einheit 2 (Produkt)

...

Einheit n (...)

Checkliste für SW-Einheiten (Individualentwicklung)

Checkliste für Externe Einheiten (Produkte)

...

Checkliste für ...

Abbildung 2-1: Aufbau SAGA-Konformitätserklärung und Checklisten

Welche konkreten Spezifikationen aus den relevanten Themenbereichen für die Erfüllung der SA­ GA-Konformität zum Einsatz kommen müssen, hängt von den fachlichen Anforderungen an das Software-System ab. Die fachlichen Anforderungen stehen über den Klassifikationen von SAGA. Diese Klassifikationen dienen dazu, die fachlichen Anforderungen hinsichtlich der Ziele von SAGA optimal umzusetzen. Zum Beispiel spielen die Festlegungen, um Informationsangebote für Mobilte­ lefone beziehungsweise PDAs zu erstellen, nur dann für die SAGA-Konformität eine Rolle, wenn diese Endgeräte vom Software-System bedient werden sollen. SAGA-Konformität wird deshalb durch den Einsatz der Teilmenge aller SAGA-Spezifikationen erreicht, die für das jeweilige Soft­ ware-System fachlich sinnvoll ist.

2.3 Anwendung des Klassifikationssystems Im SAGA-Modul „Grundlagen“9 wird das Klassifikationssystem von SAGA 5 für die Bewertung von Spezifikationen erläutert. Hier werden die sechs Klassen hinsichtlich ihrer Auswirkungen auf die Konformität zu SAGA betrachtet. Vorgeschlagen

Es ist nicht SAGA-konform, vorgeschlagene Spezifikationen einzusetzen, wenn es konkurrierende Spezifikationen10 gibt, die bestandsgeschützt, beobachtet, empfohlen oder verbindlich sind. Wenn es keine konkurrierenden Spezifikationen gibt, die höher klassifiziert wurden, befindet sich das The­ menfeld noch außerhalb der Festlegungen von SAGA und ist für die Betrachtung der SAGA-Konfor­ mität nicht relevant. Beobachtet

Wenn es neben den beobachteten Spezifikationen keine konkurrierenden empfohlenen oder verbind­ lichen Spezifikationen gibt, SOLLTEN beobachtete Spezifikationen in Software-Systemen eingesetzt

9 Siehe (BFIT, 2011C), Abschnitt 5.2 „Klassifikationen von Spezifikationen“ 10 Zwei Spezifikationen konkurrieren, wenn beide zur Erfüllung der Anforderungen eines SoftwareSystems geeignet sind.

2 Grundprinzipien der SAGA-Konformität

8

werden. Nur in begründeten Ausnahmen KÖNNEN beobachtete Spezifikationen empfohlenen Alterna­ tiven vorgezogen werden. Empfohlen

Konkurrierende Spezifikationen können nebeneinander empfohlen sein, wenn sich ihre Anwen­ dungsschwerpunkte deutlich unterscheiden. In solchen Fällen SOLLTE die für die jeweilige Anwen­ dung am besten geeignete Spezifikation angewendet werden. Von den empfohlenen Spezifikationen KANN in begründeten Ausnahmen abgewichen werden. Zu ei­ ner empfohlenen Spezifikation gibt es keine verbindliche Alternative, da eine Empfehlung neben ei­ ner verbindlich einzusetzenden Spezifikation keinen Sinn macht. Verbindlich

Konkurrierende Spezifikationen können nebeneinander verbindlich sein, wenn sich die Anwen­ dungsschwerpunkte deutlich unterscheiden. In solchen Fällen MUSS die für die jeweilige Anwendung am besten geeignete Spezifikation verwendet werden. Spezifikationen dieser Klassifikation sind im eigentlichen Sinne des Wortes verbindlich, MÜSSEN also bei der Einführung eines neuen Software-Systems jeder Alternative vorgezogen werden. Abweichun­ gen gefährden die Ziele von SAGA in hohem Maße und sind deshalb nicht zugelassen. Bei der funktionalen Änderung oder Erweiterung eines Software-Systems KÖNNEN als „Bestandsge­ schützt“ klassifizierte Spezifikationen weiterhin genutzt werden. Es MUSS jedoch geprüft werden, ob die Migration zur verbindlichen Spezifikation vorteilhaft ist. Bestandsgeschützt

Bei der funktionalen Änderung oder Erweiterung eines Software-Systems stehen diese Spezifikatio­ nen unter Bestandsschutz und KÖNNEN auch weiterhin eingesetzt werden. Es SOLLTE geprüft werden, ob eine Migration zu den in SAGA als „Beobachtet“ oder „Empfohlen“ klassifizierten Spezifikatio­ nen Vorteile gegenüber dem Festhalten an als „Bestandsgeschützt“ klassifizierten Spezifikationen bringt. Gibt es eine als „Verbindlich“ klassifizierte Alternative, MUSS diese Überprüfung durchgeführt werden. Für neue Software-Systeme SOLLTEN bestandsgeschützte Spezifikationen NICHT mehr zum Einsatz kommen. Verworfen

Verworfene Spezifikationen KÖNNEN dann eingesetzt werden, wenn parallel eine SAGA-konforme Lösung zur Verfügung gestellt wird.11 Allein DÜRFEN diese Spezifikationen in neuen sowie in beste­ henden Software-Systemen NICHT eingesetzt werden. Spätestens bei funktionalen Änderungen oder Erweiterungen MÜSSEN sie ausgetauscht werden. Dazu MUSS für die Erweiterung des Funktionsum­ fanges, gegebenenfalls unter Einsatz von Kapselung, von verworfenen Spezifikationen weg migriert oder eine SAGA-konforme Alternative geschaffen werden. Es SOLLTE jedoch für das gesamte beste­ hende Software-System geprüft werden, ob eine Migration oder Erweiterung vorteilhaft ist. 11

Z. B. dürfen Bilder im BMP-Format eingesetzt werden, obwohl diese Spezifikation verworfen wurde, wenn gleichzeitig die Bilder auch in einem SAGA-konformen Format wie GIF angeboten werden.

2 Grundprinzipien der SAGA-Konformität

9

2.4 SAGA-Konformität trotz niedriger Klassifikation Ein SAGA-konformes Software-System muss nicht zwangsläufig nur mit Spezifikationen realisiert worden sein, die in SAGA die Klassifikation „Verbindlich“ erhalten haben. Aus verschiedenen Grün­ den ist auch der Einsatz von Spezifikationen mit niedrigerer Klassifikation (oder auch ohne Klassifi­ kation) möglich, ohne die SAGA-Konformität zu verletzen.12 Fehlende Alternativen

Beobachtete Spezifikationen dürfen eingesetzt werden, wenn für den jeweiligen Einsatzzweck keine verbindlichen oder empfohlenen Spezifikationen in SAGA geführt werden. Der Einsatz empfohlener Spezifikationen ist stets SAGA-konform, da es nie verbindliche Alternativen gibt. Spezielle Funktionen und Anwendungsgebiete

Werden in SAGA zu einem Einsatzgebiet neben empfohlenen auch beobachtete Spezifikationen ge­ führt, ist der Beschreibung der Spezifikationen zu entnehmen, unter welchen Voraussetzungen die beobachteten Spezifikationen vorgezogen werden dürfen. Gründe dafür sind vor allem ein benötigter erweiterter Funktionsumfang13 oder spezielle Anwendungsgebiete, oder die beobachtete Spezifikati­ on ist eine neuere Version der empfohlenen Spezifikation. Werden aufgrund der fachlichen Anforde­ rungen die Features der neuen Version benötigt, darf diese vorgezogen werden. Derartige Abwei­ chungen von den Vorgaben müssen gründlich abgewogen werden, da für beobachtete Spezifikatio­ nen keine Investitionssicherheit festgestellt wurde und kein Bestandsschutz zugesichert wird. Bereits mit der nächsten Version des SAGA-Moduls können solche Spezifikationen als „Verworfen“ klassi­ fiziert werden. Parallele Angebote

Wenn entsprechend der vorherigen Ausführungen SAGA-konforme Spezifikationen verwendet wer­ den, dürfen zusätzlich Spezifikationen beziehungsweise Formate eingesetzt werden, die SAGA nicht oder in geringerer Klassifikation aufführt. Werden beispielsweise Textdokumente zur Weiterbearbei­ tung im klassifizierten Open Document Format (.odt) angeboten, dürfen dieselben Daten zusätzlich auch in anderen unklassifizierten Formaten, wie dem Rich Text Format (.rtf), zur Verfügung gestellt werden, ohne die SAGA-Konformität zu verletzen. Einsatz von Externen Einheiten (Produkten)

Für Externe Einheiten (in Abgrenzung zu individuell entwickelten Software-Einheiten) wird der Schwerpunkt auf Kommunikationsschnittstellen, Datenaustauschformate und Sicherheit gelegt. Spe­ zifikationen zur Prozessmodellierung, Datenmodellierung und Software-System-Architektur sind nicht Bestandteil der Checklisten zur SAGA-Konformitätserklärung für Externe Einheiten. Für kon­ krete Externe Einheiten sollten Auftraggeber prüfen, ob sie in Ausschreibungen gegebenenfalls trotz­ dem entsprechende Spezifikationen fordern, um z. B. vorhandene Infrastrukturen für den Betrieb der Einheit zu nutzen und um Synergien mit anderen Software-Systemen zu erzielen. 12 Siehe vorheriger Abschnitt 2.3 „Anwendung des Klassifikationssystems“ 13 Zum Beispiel durch eine neuere, aber noch niedriger klassifizierte Version einer Spezifikation

2 Grundprinzipien der SAGA-Konformität

10

Spezifikationen außerhalb des Fokus von SAGA

Themen, zu denen SAGA (noch) keine Aussagen trifft, berühren selbstverständlich nicht die Beurtei­ lung der SAGA-Konformität eines Software-Systems.

2.5 Verantwortung für SAGA-Konformität Die Verantwortung für die Konformität von Software-Systemen zu SAGA liegt bei dem für ein Soft­ ware-System fachlich zuständigen Auftraggeber. Es obliegt auch dem jeweiligen Auftraggeber zu überprüfen, wie Systeme migriert werden können. Aufgrund der Komplexität von SAGA ist auch der Prozess zur Sicherstellung von SAGA-Konformi­ tät komplex. Daher wird angestrebt, die Anwender in Zukunft noch besser zu unterstützen. Informa­ tionen über aktuelle Entwicklungen in diesem Bereich werden über die Website der oder des Beauf­ tragten der Bundesregierung für Informationstechnik (BfIT)14 zur Verfügung gestellt.

2.6 Migration zur Konformität Übergangsphase

SAGA wird kontinuierlich weiterentwickelt und regelmäßig fortgeschrieben, um stets an neue An­ forderungen angepasst werden zu können. Deshalb können in Entwicklung befindliche oder beste­ hende Software-Systeme, die sich an einer älteren SAGA-Version 15 orientieren, nicht zur aktuellen Version konform sein. Es muss mindestens die Konformität zu der älteren SAGA-Version sicherge­ stellt werden. Es sollte so früh wie möglich abgewogen werden, ob eine Migration sinnvoll ist. Bei Entscheidungen über eine Migration ist eine Wirtschaftlichkeitsbetrachtung zu erstellen. Wird der Funktionsumfang eines bestehenden Software-Systems verändert, muss für die Verände­ rungen beziehungsweise Neuerungen des Systems unter Berücksichtigung der Bestandsschutzliste eine Konformität zur aktuellen SAGA-Version hergestellt werden. Wiederum sollte frühzeitig abge­ wogen werden, ob Spezifikationen der Bestandsschutzliste durch höher klassifizierte Alternativen abgelöst werden sollten16 und ob für das gesamte Software-System (also auch eigentlich unveränder­ te Einheiten) eine Konformität zur aktuellen SAGA-Version hergestellt werden sollte. Maßnahmen zur Erzielung von Konformität

Die Konformität zu SAGA wird durch folgende Maßnahmen gefördert: •

SAGA frühzeitig in Projektplanungen einbeziehen,

•

SAGA-Konformität bei der Genehmigung von Projekten fordern und anschließend überprü­ fen,

•

bei Förderung von Projekten durch öffentliche Verwaltungen die Konformität zu SAGA ge­ gebenenfalls verbindlich fordern,

•

SAGA-Konformität bei der Vergabe von Aufträgen verbindlich fordern.

14 Siehe (BFIT, 2011B) 15 Alte Versionen von SAGA sind im SAGA-Archiv verfügbar, siehe (BFIT, 2011A). 16 Wenn es eine als „Verbindlich“ klassifizierte Alternative zu einer bestandsgeschützten Spezifikation gibt, muss überprüft werden, ob eine Migration vorteilhaft ist.

2 Grundprinzipien der SAGA-Konformität

11

2.7 Zertifizierung von SAGA-Konformität Um die Konformität von Software-Systemen zu SAGA sicherzustellen und überprüfbar zu machen, wurden auch verschiedene Optionen einer SAGA-Zertifizierung näher betrachtet. Eine Zertifizierung von Projekten wurde als zu aufwändig und zu komplex bei zu geringer Aussage­ kraft verworfen. Die Verleihung (oder auch Nicht-Verleihung) eines Zertifikats zum Projektende schafft allein kaum einen Mehrwert. Genauso wurde die Zertifizierung von Software-Produkten verworfen, da eine Wettbewerbsverzer­ rung durch Zertifizierungskosten, insbesondere die Benachteiligung von Open-Source-Projekten, be­ fürchtet wurde. Außerdem kann die SAGA-Konformität nur im Kontext von Projektanforderungen beurteilt werden, was die Erklärung einer allgemeinen SAGA-Konformität von Produkten aus­ schließt. Einzig die Zertifizierung von Personen wurde als tragfähige Option bewertet. Die korrekte Anwen­ dung der SAGA-Instrumente von Beginn des Projektes an durch die jeweiligen Projekt-Manager ist erfolgskritisch, um SAGA-konforme Lösungen zu erzielen. Für Mitarbeiter der Bundesverwaltung wird deshalb eine bundeseigene Zertifizierung von Projekt-Managern angeboten, in deren Rahmen auch die Kenntnisse bezüglich der Sicherstellung von SAGA-Konformität, also die Inhalte dieses SAGA-Moduls und des SAGA-Moduls „Grundlagen“ 17, abgefragt werden.

3

SAGA-Konformität in der Ausschreibung

Um bei der Frage der SAGA-Konformität die eigenen konkreten Anforderungen nicht zu vernachläs­ sigen und um nicht ausschließlich auf Aussagen des Auftragnehmers angewiesen zu sein, sollte der Auftraggeber eine Kriteriengruppe „SAGA-Konformität“ beziehungsweise SAGA-relevante Kriteri­ en in seine Vergabeunterlagen aufnehmen. Eine pauschale Forderung nach SAGA-Konformität trägt nicht zur Erreichung der Ziele von SAGA bei. Die pauschale Forderung lässt aufgrund der Komplexität des Dokuments immer Spielraum für Interpretationen und Missverständnisse. Dies erschwert es dem Auftragnehmer, die Anforderungen zu erfüllen, und dem Auftraggeber, die Erfüllung der Anforderungen zu kontrollieren. Die pauschale Forderung nach SAGA-Konformität darf deshalb nicht gestellt werden. Stattdessen sollte der im Folgenden erläuterte Prozess der Konformitätserklärung von Auftraggeber und Auftragnehmer durchlaufen werden, siehe Abbildung 3-1. Durch ihn werden Interpretations­ spielräume eingeschränkt und Missverständnisse reduziert. Die konkreteren Forderungen sind über­ prüfbar und schaffen dadurch Vertragssicherheit zwischen Auftraggeber und Auftragnehmer. Durch die Konkretisierung der Anforderungen wird außerdem vermieden, dass Angebote ungewollt teuer ausfallen.

17 Siehe (BFIT, 2011C)

3 SAGA-Konformität in der Ausschreibung

12

AUFTRAGNEHMER

AUFTRAGGEBER Projekt gestartet

1

Vergabeunterlagen erstellen

Unterlagen versenden

mit Kriterien bezüglich SAGA Angebot versenden

Angebot auswerten 3

mit Berücksichtigen der Auftragnehmer-Antworten zu Kriterien bezüglich SAGA

Abnahme durchführen

2

Zuschlag erteilen

Anwendung übergeben

5

Angebot erstellen mit Antworten zu AuftraggeberKriterien bezüglich SAGA

Realisierung durchführen mit anschließendem Ausfüllen der SAGA-Konformitätserklärung

4

mit Prüfen der SAGA-Konformität

Projekt beendet

Abbildung 3-1: Prozess zur SAGA-Konformitätserklärung

Der Prozess besteht im Wesentlichen aus fünf Schritten, die nachfolgend kurz beschrieben werden: Schritt 1: Aufnahme der SAGA-Konformitätsaspekte in die Vergabeunterlagen einer Ausschreibung

Der Auftraggeber stellt eine Reihe von Ausschluss- und Bewertungskriterien zusammen, die alle re­ levanten Aspekte des gewünschten Software-Systems abdecken. Als Vorlage kann die Beispiel-Kri­ teriengruppe dienen, die auf der BfIT-Website zum Download bereit steht.18 Diese Beispiel-Kriteri­ engruppe enthält mögliche Kriterien, die sich aus der Anwendung von SAGA ergeben können. Der Auftraggeber muss daraus diejenigen Kriterien auswählen oder ergänzen, die für das Projekt relevant sind. Die Beispiel-Kriteriengruppe enthält erklärende Hinweise, die die Auswahl erleichtern. Auch die Entscheidung, ob Kriterien als Ausschluss- oder Bewertungskriterien festgelegt werden, sind vom Auftraggeber zu treffen. Ausschlusskriterien sollten sehr zurückhaltend eingesetzt werden, da sie die Anzahl der Angebote reduzieren. Alternativ sollten hoch gewichtete Bewertungskriterien in Betracht gezogen werden. Schritt 2: Beantwortung der Kriteriengruppe SAGA-Konformität durch den Auftragnehmer im Rahmen der Angebotserstellung

Der potenzielle Auftragnehmer (Bieter) beantwortet im Rahmen seiner Angebotserstellung die Krite­ riengruppe „SAGA-Konformität“. Er kann sich an einer ausgefüllten Beispiel-Kriteriengruppe orien­ tieren, die ebenfalls auf der BfIT-Website zum Download bereit steht.19 Diese enthält erklärende Kommentare, die beim Ausfüllen einer konkreten Kriteriengruppe helfen.

18 Siehe (BFIT, 2011B) 19 Siehe (BFIT, 2011B)

3 SAGA-Konformität in der Ausschreibung

13

Schritt 3: Prüfung der Angaben zur SAGA-Konformität durch den Auftraggeber, Bewertung der entsprechenden Kriterien im Rahmen der Angebotsauswertung

Der Auftraggeber prüft die ausgefüllten Kriteriengruppen der eingegangenen Angebote. Solche An­ gebote, die für die Kriteriengruppe „SAGA-Konformität“ nicht die Anforderungen des Auftragge­ bers erfüllen, d. h. die SAGA-Konformität nicht zusichern können, werden entsprechend bewertet. Schritt 4: Ausfüllen der Konformitätserklärung für das realisierte Software-System durch den Auftragnehmer

Hat der Auftragnehmer das Software-System realisiert, erklärt er schriftlich deren SAGA-Konformi­ tät. Dazu füllt er die Konformitätserklärung für das Software-System aus und fügt die Checklisten für die einzelnen Einheiten des Systems als Anlagen bei. Abweichungen von den Zusagen der ausge­ füllten Kriteriengruppe „SAGA-Konformität“ sollten frühzeitig mit dem Auftragnehmer abgestimmt werden und müssen in der Konformitätserklärung begründet werden. Unterstützung erhält der Auf­ tragnehmer durch die Beispiel-Konformitätserklärung inklusive Checklisten für Software-Einheiten (Eigenentwicklungen) und Externe Einheiten (Produkte), die auf der BfIT-Website zum Download bereit steht.20 Auch leere Vorlagen einer Konformitätserklärung und der Checklisten stehen dort zur Verfügung. Schritt 5: Prüfung der SAGA-Konformität anhand von Angebot und Konformitätserklärung durch den Auftraggeber im Rahmen der Abnahme

Auf der Grundlage der vom Auftragnehmer im Angebot ausgefüllten Kriteriengruppe „SAGA-Kon­ formität“, gegebenenfalls vereinbarten Änderungsentscheidungen (Change Requests) und der nach der Realisierung erstellten Konformitätserklärung kann der Auftraggeber die SAGA-Konformität während der Abnahme beurteilen. Durch die konkreten Vorgaben des Angebots ist diese Beurteilung leicht möglich. Erkannte Abweichungen des Software-Systems von den Zusagen des Angebots stel­ len gegebenenfalls einen Mangel dar, der bei der Abnahme zu berücksichtigen ist.

20 Siehe (BFIT, 2011B)

A V-Modell XT Bund und SAGA-Konformität

A

14

V-Modell XT Bund und SAGAKonformität

Nach dem V-Modell XT Bund21 gestaltet sich ein Projektverlauf analog zu Abbildung A-1. Das stili­ sierte „V“ wird von der linken oberen Spitze nach unten und dann weiter zur rechten oberen Spitze durchlaufen. Wurde das Projekt ausgeschrieben und beauftragt, werden die Anforderungen festgelegt und das System spezifiziert. Danach werden die Systemelemente realisiert und das fertige System anschlie­ ßend integriert. Ist dies geschehen, wird die Lieferung durchgeführt und vom Auftraggeber abge­ nommen. Iterativ können neue Anforderungen festgelegt werden und der Zyklus beginnt von Neu­ em.

Abbildung A-1: Projektverlauf nach V-Modell XT Bund22

Um projektbegleitend die Konformität zu SAGA sicherzustellen, muss SAGA in mehreren dieser Projektabschnitte beachtet werden.23 Beim Ausschreiben des Projektes müssen bereits die relevanten SAGA-Konformitätsaspekte in die Vergabeunterlagen aufgenommen werden. Potentielle Auftrag­ nehmer (Bieter) erstellen ihre Angebote mit Antworten zu den Kriterien des Auftraggebers bezüglich SAGA. Der Auftraggeber wertet die Angebote unter Berücksichtigung der Antworten zu den SAGAKriterien aus und beauftragt auf dieser Grundlage das Projekt. Der Auftragnehmer, der den Zuschlag erhalten hat, legt dann nach dem V-Modell XT Bund mit dem Auftraggeber die Anforderungen fest. Gegebenenfalls können dabei von den Ausschreibungsunterla­ gen abweichende Festlegungen getroffen werden, die als Änderungsentscheidung (Change Request) dokumentiert werden müssen. Anschließend wird das Software-System spezifiziert, entworfen, reali­ siert und integriert. Zur Durchführung der Lieferung muss der Auftragnehmer eine SAGA-Konfor­ mitätserklärung vorlegen. Der Auftraggeber prüft anhand des ursprünglichen Angebots, dokumen­ tierter Änderungsentscheidungen und der SAGA-Konformitätserklärung die Einhaltung der Vorga­ ben von SAGA durch den Auftragnehmer und lässt die Ergebnisse dieser Prüfung in die Abnahme einfließen.

21 Siehe (BFIT, 2010) 22 Siehe (BFIT, 2010) 23 Siehe Kapitel 3 „SAGA-Konformität in der Ausschreibung“ auf Seite 11

B Literatur

B

15

Literatur

(BFIT, 2009) Der Beauftragte der Bundesregierung für Informationstechnik (Hrsg.): V-Modell XT; Version 1.3; Februar 2009; http://www.v-modell-xt.de/ (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-Archiv; 2011; http://www.cio.bund.de/DE/Standards/SAGA/Archiv/saga-archiv_node.html; http://www.cio.bund.de/saga → „Archiv“ (BFIT, 2011B) Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Material; 2011; http://www.cio.bund.de/saga → „Material“ (BFIT, 2011C) Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Modul Grundlagen; Version de.bund 5.1.0; November 2011; http://www.cio.bund.de/saga

C Abkürzungsverzeichnis

C

Abkürzungsverzeichnis

BfIT

Die/Der Beauftragte der Bundesregierung für Informationstechnik

BMI

Bundesministerium des Innern

BMP

Windows Bitmap

GIF

Graphics Interchange Format

IT

Informationstechnologie

IT-Rat

Rat der IT-Beauftragten der Bundesressorts

PDA

Personal Digital Assistant

PG

Projektgruppe

SAGA

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

SW

Software

16