Rechenschaftsbericht zum SAGA-Modul Konformität de.bund 5.1.0 Dokumentation des Umgangs mit Kommentaren im Entstehungsprozess des SAGA- Moduls Konformität 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 it2@bmi.bund.de Stand 3. November 2011
3 Überblick Das SAGA-Modul Konformität in der Version de.bund 5.1.0 wurde unter Einbeziehung der Anwender erstellt. In Hinweisen zu SAGA 4.0 sowie in Stellungnahmen zu Entwürfen des SAGA-Moduls Konformität 5.0.0 und 5.1.0 wurden insgesamt zwölf verschiedene Vorschläge und Kommentare unterbreitet. Davon konnten sieben Vorschläge vollständig oder teilweise umgesetzt werden. Das entspricht 58 Prozent aller Vorschläge. Ein Kommentar wurde beantwortet und vier Vorschläge mussten abgelehnt werden. Dieser Rechenschaftsbericht dokumentiert den Umgang des SAGA-Autoren-Teams und der Projektgruppe SAGA 5 des IT-Rats mit allen Vorschlägen auf dem Weg zur Erstellung des finalen SAGA- Moduls Konformität de.bund 5.1.0. Inhaltlich identische oder ähnliche Vorschläge wurden zusammengefasst.
4 Inhaltsverzeichnis 1 Einleitung...5 2 Grundprinzipien der SAGA-Konformität...5 2.1 Terminologie...5 2.2 Definition der SAGA-Konformität...5 2.3 Anwendung des Klassifikationssystems...5 2.4 SAGA-Konformität trotz niedriger Klassifikation...6 2.5 Verantwortung für SAGA-Konformität...6 2.6 Migration zur Konformität...6 2.7 Zertifizierung von SAGA-Konformität...7 3 SAGA-Konformität in der Ausschreibung...7 A B C V-Modell XT Bund und SAGA-Konformität...8 Literatur...8 Abkürzungsverzeichnis...8
1 Einleitung 5 1 Einleitung Vorschlag 1: Durch die Ausdehnung der Verbindlichkeit der in SAGA 5 aufgeführten Standards auf alle Software-Systeme der Bundesverwaltung sollten die Punkte Umfang und Lebensdauer der Software-Einheiten in die Konformitätserklärungen Aufnahme finden. Bei der Betrachtung der Anwendbarkeit von SAGA 5 sollte in jedem Fall die Wirtschaftlichkeit im Vordergrund stehen. So könnte eine Empfehlung lauten, dass für Software-Systeme, die nur einen geringen Umfang oder eine kurze Lebensdauer haben, eine Konformitätserklärung nur empfohlen wird, wenn eine Kosten-Nutzen-Betrachtung positiv ausfällt. Reaktion: Das Modul Konformität regelt, wann eine Anwendung SAGA-konform ist. Die Festlegung, welche Anwendungen SAGA-konform sein müssen, wird außerhalb von SAGA festgelegt für die Domäne de.bund durch Beschluss des IT-Rates. Für die Formulierung dieses Beschlusstextes wird die Anregung mitgenommen. 2 Grundprinzipien der SAGA- Konformität 2.1 Terminologie 2.2 Definition der SAGA-Konformität 2.3 Anwendung des Klassifikationssystems Vorschlag 2: Hier wird nicht klar, was man zu tun hat, um sich SAGA-konform zu verhalten. Ist hier gemeint: Vorgeschlagene Spezifikationen können eingesetzt werden, wenn es keine konkurrierenden Spezifikationen in den Klassen bestandsgeschützt, beobachtet, empfohlen oder verbindlich gibt. Vorgeschlagene Spezifikationen sollten nicht eingesetzt werden, wenn es konkurrierende bestandsgeschützte, beobachtete oder empfohlene Spezifikationen gibt. Vorgeschlagene Spezifikationen dürfen nicht eingesetzt werden, wenn es konkurrierende verbindliche Spezifikationen gibt. Reaktion: Die Formulierung wurde präzisiert.
2.4 SAGA-Konformität trotz niedriger Klassifikation 6 2.4 SAGA-Konformität trotz niedriger Klassifikation Vorschlag 3: In Fußnote 13 muss von Zeichenkodierung statt von Zeichensätzen gesprochen werden. Reaktion: Da UTF-16 mit dem SAGA-Modul Technische Spezifikationen 5.0.0 nicht mehr beobachtet wird, musste das Beispiel und damit auch die Fußnote komplett ausgetauscht werden. 2.5 Verantwortung für SAGA-Konformität 2.6 Migration zur Konformität Vorschlag 4: Der letzte Satz: SAGA-Konformität wird bei der Vergabe von Aufträgen verbindlich gefordert sollte abgeschwächt werden zu: SAGA-Konformität sollte bei der Vergabe von Aufträgen verbindlich gefordert werden. Begründung: Beibehaltung von Flexibilität und Verringerung des formalen Aufwands im Projektmanagement, insbesondere für kleine Projekte. Reaktion: Der Zusammenhang dieses Satzes lautet: Die Konformität zu SAGA wird durch folgende Maßnahmen gefördert. Es ist unstrittig, dass die Konformität zu SAGA dadurch gefördert wird, dass SAGA-Konformität bei der Vergabe von Aufträgen verbindlich gefordert wird. Eine Abschwächung zu sollte wäre falsch, da eine fehlende Forderung nach SAGA-Konformität bei der Vergabe die SAGA-Konformität nicht fördert. Aus der Formulierung ergibt sich nicht, dass bei jeder Vergabe SAGA-Konformität gefordert werden muss. Der Geltungsbereich von SAGA 5 wurde durch den Beschluss des IT-Rats zur Verbindlichkeit geregelt. Vorschlag 5: Zu: 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. Dies würde bedeuten, dass bei jeder kleinsten Änderung die Anwendung zumindest in Teilen auf SAGA-Konformität überprüft werden müsste, was dauerhaft nicht handhabbar ist. Es wird daher folgende Formulierung vorgeschlagen: wenn Individual-Software so umfassend angepasst wird, dass dies zu einem neuen Minor- bzw. Major-Release führt ( ) Reaktion: Kleinste Änderungen verändern i.d.r. nicht den Funktionsumfang und eine Erweiterung des Funktionsumfangs wird mindestens zu einem Minor-Release führen. Insofern entspricht die Formulierung in SAGA dem Vorschlag. Vorschlag 6: Über eine Wirtschaftlichkeitsbetrachtung kann nicht abgewogen werden, ob eine Maßnahme sinnvoll ist oder ob Konformität zur aktuellen SAGA-Version hergestellt werden sollte. Formulierungsvorschlag: Bei Entscheidungen über eine Migration ist eine Wirtschaftlichkeitsbetrachtung zu erstellen. Reaktion: Die Formulierung wurde entsprechend geändert.
2.7 Zertifizierung von SAGA-Konformität 7 2.7 Zertifizierung von SAGA-Konformität Vorschlag 7: Es sollte eine zeitnahe Schaffung für ein Schulungsangebot durch die BAköV/FH Bund zur SAGA-Zertifizierung von Projekt-Managern erfolgen. Reaktion: Momentan bietet die BAköV eine allgemeine Zertifizierung von Projekt-Managern an, in deren Rahmen auch Kenntnisse über SAGA gefordert werden. Die IT-Steuerung Bund und die BAköV stehen in engem Kontakt, um ein geeignetes Schulungsangebot für SAGA 5 zu schaffen. Momentan ist keine eigene SAGA-Zertifizierung geplant, aber die Anregung wurde weitergegeben. Vorschlag 8: Es wird empfohlen, eine SAGA-Zertifizierung als ein Instrument zu schaffen, mit dessen Hilfe zusätzliche Mittel für Projekte verteilt werden können. Der Mehrwert, den dieses Instrument schafft, wird den Aufwand für dessen Erstellung rechtfertigen. Reaktion: Die Kosten einer Zertifizierung würden mögliche Boni für die Projekte absorbieren. Eine projektbegleitende Zertifizierung wäre zu formal und sehr aufwändig. Deshalb wurde eine Zertifizierung von Projekten nicht in Betracht gezogen. 3 SAGA-Konformität in der Ausschreibung Vorschlag 9: Der Satz Die pauschale Forderung nach SAGA-Konformität darf deshalb nicht gestellt werden. sollte abgeschwächt werden zu Die pauschale Forderung nach SAGA-Konformität sollte deshalb nicht gestellt werden.. Begründung: Beibehaltung von Flexibilität und Verringerung des formalen Aufwands im Projektmanagement, insbesondere für kleine Projekte. Reaktion: SAGA-Konformität sollte nie pauschal gefordert werden. Auftragnehmer wissen auf Grund der Komplexität des Dokuments nicht, was konkret von ihnen erwartet wird und es kann keine Vertragssicherheit gewährleistet werden. Dies gilt für große und genauso für kleine Projekte. Bei kleinen Projekten können die wirtschaftlichen Auswirkungen besonders gravierend sein. Vorschlag 10: Nach hiesiger Auffassung existiert der Begriff Verdingungsunterlage seit der Novellierung der VOL in 2009 nicht mehr. Leistungsbeschreibung, Vertragsentwürfe und VOL/B werden nunmehr Vergabeunterlage genannt. Reaktion: Der Begriff Verdingungsunterlage wurde durch Vergabeunterlage ersetzt. Vorschlag 11: Die Begriffe Auftragnehmer (nach Auftragserteilung) und Bieter (vor Auftragserteilung in einem Vergabeverfahren) werden unscharf verwendet. Reaktion: Zur besseren Verständlichkeit wird die Komplexität des Themas etwas reduziert und nicht zwischen Bieter und Auftragnehmer unterschieden. Da der Prozess exemplarisch und von vorn bis hinten betrachtet wird, wären der Bieter zu Beginn und der Auftragnehmer am Ende identisch. An den passenden Stellen wurde aber in Klammern die Bezeichnung Bieter ergänzt, um die jeweilige Rolle zu verdeutlichen.
A V-Modell XT Bund und SAGA-Konformität 8 A V-Modell XT Bund und SAGA- Konformität Vorschlag 12: Im Anhang A werden die Möglichkeiten zum Abweichen von der Leistungsbeschreibung zu pauschal dargestellt. Reaktion: Die Darstellungen im Anhang A des SAGA-Moduls Konformität dienen lediglich dazu, einen Überblick über die Einordnung in den Kontext des V-Modell XT Bund zu geben. Von SAGA werden keine Aussagen für Möglichkeiten zum Abweichen von der Leistungsbeschreibung getroffen. Für derartige Festlegungen wird das V-Modell XT Bund referenziert. B Literatur C Abkürzungsverzeichnis