SAGA-Modul Konformität. Version de.bund 5.1.0

Transkript

1 SAGA-Modul Konformität Version de.bund November 2011

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

3 3

4 4 Inhaltsverzeichnis 1 Einleitung Grundprinzipien der SAGA-Konformität Terminologie Definition der SAGA-Konformität Anwendung des Klassifikationssystems SAGA-Konformität trotz niedriger Klassifikation Verantwortung für SAGA-Konformität Migration zur Konformität Zertifizierung von SAGA-Konformität SAGA-Konformität in der Ausschreibung...11 A B C V-Modell XT Bund und SAGA-Konformität...14 Literatur...15 Abkürzungsverzeichnis...16

5 1 Einleitung 5 1 Einleitung SAGA 1 ist eine Zusammenstellung von Referenzen auf Spezifikationen und Methoden für Software- Systeme der öffentlichen Verwaltung. SAGA ist modular aufgebaut. Die SAGA-Module können zeitlich und weitgehend inhaltlich unabhängig voneinander publiziert werden. Jedes SAGA-Modul wird separat versioniert. Die aktuelle Gesamtversion von SAGA setzt sich aus den neuesten Versionen aller SAGA-Module zusammen. Alle verfügbaren SAGA-Module sind auf der Website der oder des Beauftragten der Bundesregierung für Informationstechnik (BfIT) 2 zu finden. Dieses SAGA-Modul erläutert, 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 entwickeln, nach dem bestehende und neue Lösungen beurteilt werden können. Gleiches gilt für die Erstellung von SAGA. SAGA entfaltet erst dann seinen vollen Nutzen bei der Entwicklung von Software-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 SAGA- Konformitä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 SAGA ist ein Eigenname, der ursprünglich als Abkürzung von Standards und Architekturen für egovernment-anwendungen eingeführt wurde. 2 Siehe 3 Siehe 4 Siehe 5 Siehe (BFIT, 2011C), Abschnitt 4.1 Terminologie

6 2 Grundprinzipien der SAGA-Konformität 6 MUSS: Zur Erreichung von SAGA-Konformität sind keine Abweichungen von verbindlichen Festlegungen zulässig. SOLLTE: Unter der Angabe von nachvollziehbaren Gründen (z. B. Wirtschaftlichkeit oder besondere fachliche Anforderungen) kann von positiven Empfehlungen abgewichen werden, ohne die SAGA-Konformität zu verletzen. KANN: Kennzeichnet eine gestattete SAGA-konforme Option. DARF NICHT: Zur Erreichung von SAGA-Konformität müssen verbindliche Verbote eingehalten 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ätsaussage zunächst in einzelne Einheiten untergliedert werden. Hier wird zwischen individuell entwickelten Software-Einheiten (SW-Einheiten 6 ) und Externen Einheiten 7 (Produkten) unterschieden, siehe Abbildung 2-1. Zur Beurteilung der SAGA-Konformität von Produkten wird vor allem Wert auf Kommunikationsschnittstellen, Datenaustauschformate und Sicherheit gelegt. Für Individualentwicklungen 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 Modellierung 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 Produkte 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 Individualentwicklungen oder Produkte von Belang sind. 6 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 SW-Einheit. 7 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 Externe Einheit. 8 Siehe (BFIT, 2011B)

7 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 Mobiltelefone 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 Software-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 Spezifikationen 10 gibt, die bestandsgeschützt, beobachtet, empfohlen oder verbindlich sind. Wenn es keine konkurrierenden Spezifikationen gibt, die höher klassifiziert wurden, befindet sich das Themenfeld noch außerhalb der Festlegungen von SAGA und ist für die Betrachtung der SAGA-Konformität nicht relevant. Beobachtet Wenn es neben den beobachteten Spezifikationen keine konkurrierenden empfohlenen oder verbindlichen 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 Software- Systems geeignet sind.

8 2 Grundprinzipien der SAGA-Konformität 8 werden. Nur in begründeten Ausnahmen KÖNNEN beobachtete Spezifikationen empfohlenen Alternativen vorgezogen werden. Empfohlen Konkurrierende Spezifikationen können nebeneinander empfohlen sein, wenn sich ihre Anwendungsschwerpunkte deutlich unterscheiden. In solchen Fällen SOLLTE die für die jeweilige Anwendung am besten geeignete Spezifikation angewendet werden. Von den empfohlenen Spezifikationen KANN in begründeten Ausnahmen abgewichen werden. Zu einer empfohlenen Spezifikation gibt es keine verbindliche Alternative, da eine Empfehlung neben einer verbindlich einzusetzenden Spezifikation keinen Sinn macht. Verbindlich Konkurrierende Spezifikationen können nebeneinander verbindlich sein, wenn sich die Anwendungsschwerpunkte 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. Abweichungen 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 Bestandsgeschü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 Spezifikationen 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 Spezifikationen 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 bestehenden Software-Systemen NICHT eingesetzt werden. Spätestens bei funktionalen Änderungen oder Erweiterungen MÜSSEN sie ausgetauscht werden. Dazu MUSS für die Erweiterung des Funktionsumfanges, gegebenenfalls unter Einsatz von Kapselung, von verworfenen Spezifikationen weg migriert oder eine SAGA-konforme Alternative geschaffen werden. Es SOLLTE jedoch für das gesamte bestehende 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.

9 2 Grundprinzipien der SAGA-Konformität 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ünden ist auch der Einsatz von Spezifikationen mit niedrigerer Klassifikation (oder auch ohne Klassifikation) 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 gefü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 Funktionsumfang 13 oder spezielle Anwendungsgebiete, oder die beobachtete Spezifikation ist eine neuere Version der empfohlenen Spezifikation. Werden aufgrund der fachlichen Anforderungen die Features der neuen Version benötigt, darf diese vorgezogen werden. Derartige Abweichungen von den Vorgaben müssen gründlich abgewogen werden, da für beobachtete Spezifikationen keine Investitionssicherheit festgestellt wurde und kein Bestandsschutz zugesichert wird. Bereits mit der nächsten Version des SAGA-Moduls können solche Spezifikationen als Verworfen klassifiziert werden. Parallele Angebote Wenn entsprechend der vorherigen Ausführungen SAGA-konforme Spezifikationen verwendet werden, dürfen zusätzlich Spezifikationen beziehungsweise Formate eingesetzt werden, die SAGA nicht oder in geringerer Klassifikation aufführt. Werden beispielsweise Textdokumente zur Weiterbearbeitung 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. Spezifikationen zur Prozessmodellierung, Datenmodellierung und Software-System-Architektur sind nicht Bestandteil der Checklisten zur SAGA-Konformitätserklärung für Externe Einheiten. Für konkrete Externe Einheiten sollten Auftraggeber prüfen, ob sie in Ausschreibungen gegebenenfalls trotzdem 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

10 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 Beurteilung 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 Software-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-Konformität komplex. Daher wird angestrebt, die Anwender in Zukunft noch besser zu unterstützen. Informationen über aktuelle Entwicklungen in diesem Bereich werden über die Website der oder des Beauftragten 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 Anforderungen angepasst werden zu können. Deshalb können in Entwicklung befindliche oder bestehende 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 sichergestellt 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änderungen beziehungsweise Neuerungen des Systems unter Berücksichtigung der Bestandsschutzliste eine Konformität zur aktuellen SAGA-Version hergestellt werden. Wiederum sollte frühzeitig abgewogen werden, ob Spezifikationen der Bestandsschutzliste durch höher klassifizierte Alternativen abgelöst werden sollten 16 und ob für das gesamte Software-System (also auch eigentlich unveränderte 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 gegebenenfalls 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.

11 2 Grundprinzipien der SAGA-Konformität 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 Aussagekraft 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 Wettbewerbsverzerrung durch Zertifizierungskosten, insbesondere die Benachteiligung von Open-Source-Projekten, befü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 ausschließt. Einzig die Zertifizierung von Personen wurde als tragfähige Option bewertet. Die korrekte Anwendung 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ässigen und um nicht ausschließlich auf Aussagen des Auftragnehmers angewiesen zu sein, sollte der Auftraggeber eine Kriteriengruppe SAGA-Konformität beziehungsweise SAGA-relevante Kriterien 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 Interpretationsspielräume eingeschränkt und Missverständnisse reduziert. Die konkreteren Forderungen sind überprü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)

12 3 SAGA-Konformität in der Ausschreibung 12 AUFTRAGGEBER AUFTRAGNEHMER Projekt gestartet 1 Vergabeunterlagen erstellen mit Kriterien bezüglich SAGA Unterlagen versenden Angebot versenden Angebot erstellen mit Antworten zu Auftraggeber- Kriterien bezüglich SAGA 2 3 Angebot auswerten mit Berücksichtigen der Auftragnehmer-Antworten zu Kriterien bezüglich SAGA Zuschlag erteilen 5 Abnahme durchführen mit Prüfen der SAGA-Konformität Anwendung übergeben Realisierung durchführen mit anschließendem Ausfüllen der SAGA-Konformitätserklärung 4 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 relevanten Aspekte des gewünschten Software-Systems abdecken. Als Vorlage kann die Beispiel-Kriteriengruppe dienen, die auf der BfIT-Website zum Download bereit steht. 18 Diese Beispiel-Kriteriengruppe 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 Kriteriengruppe SAGA-Konformität. Er kann sich an einer ausgefüllten Beispiel-Kriteriengruppe orientieren, 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)

13 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 Angebote, die für die Kriteriengruppe SAGA-Konformität nicht die Anforderungen des Auftraggebers 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-Konformitä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 ausgefü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 Auftragnehmer 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-Konformitä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 stellen gegebenenfalls einen Mangel dar, der bei der Abnahme zu berücksichtigen ist. 20 Siehe (BFIT, 2011B)

14 A V-Modell XT Bund und SAGA-Konformität 14 A V-Modell XT Bund und SAGA- Konformität Nach dem V-Modell XT Bund 21 gestaltet sich ein Projektverlauf analog zu Abbildung A-1. Das stilisierte 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 abgenommen. Iterativ können neue Anforderungen festgelegt werden und der Zyklus beginnt von Neuem. Abbildung A-1: Projektverlauf nach V-Modell XT Bund 22 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 Auftragnehmer (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 SAGA- Kriterien 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 Ausschreibungsunterlagen abweichende Festlegungen getroffen werden, die als Änderungsentscheidung (Change Request) dokumentiert werden müssen. Anschließend wird das Software-System spezifiziert, entworfen, realisiert und integriert. Zur Durchführung der Lieferung muss der Auftragnehmer eine SAGA-Konformitätserklärung vorlegen. Der Auftraggeber prüft anhand des ursprünglichen Angebots, dokumentierter Änderungsentscheidungen und der SAGA-Konformitätserklärung die Einhaltung der Vorgaben 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

15 B Literatur 15 B Literatur (BFIT, 2009) Der Beauftragte der Bundesregierung für Informationstechnik (Hrsg.): V-Modell XT; Version 1.3; Februar 2009; (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; IT-Methoden V-Modell XT Bund Links (BFIT, 2011A) Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Archiv; 2011; Archiv (BFIT, 2011B) Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Material; 2011; Material (BFIT, 2011C) Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Modul Grundlagen; Version de.bund 5.1.0; November 2011;

16 C Abkürzungsverzeichnis 16 C BfIT BMI BMP GIF IT IT-Rat PDA PG SAGA SW Abkürzungsverzeichnis Die/Der Beauftragte der Bundesregierung für Informationstechnik Bundesministerium des Innern Windows Bitmap Graphics Interchange Format Informationstechnologie Rat der IT-Beauftragten der Bundesressorts Personal Digital Assistant Projektgruppe ein Eigenname (ursprünglich: Standards und Architekturen für egovernment-anwendungen) Software