Auswahl eines Produkts für Zweck

Name des Autors

Version:	0.1

Status:	in Arbeit

Stand:	31.05.2012

„Template Produktauswahl“
des Bundesverwaltungsamts ist lizenziert unter einer
Creative Commons Namensnennung 4.0 International Lizenz.

Die Lizenzbestimmungen können unter folgender URL heruntergeladen werden: http://creativecommons.org/licenses/by/4.0

Dieser Lizenztext bezieht sich auf die Vorlage. In Dokumenten, die auf der Vorlage basieren, ist dieser Text zu löschen.

Zusammenfassung

Dieses Dokument beschreibt die Hintergründe zur Auswahl des Produkts Produktname im Projekt Projektname.

Historie

Version	Status	Datum	Autor(en)	Erläuterung
0.1	in Arbeit	xx.xx.xxxx

Inhaltsverzeichnis

Idee dieses Dokuments	2

Ausfüllanweisung	2

1	Einleitung	2

2	Problemstellung	2

3	Lösung	2

4	Bewertung der Lösung	2

4.1	Zukunftssicherheit	2

4.1.1	Beschreibung des Kriteriums Zukunftssicherheit	2

4.1.2	Einschätzung für Produktname	2

4.2	Erfahrung	2

4.2.1	Beschreibung des Kriteriums Erfahrung	2

4.2.2	Einschätzung für Produktname	2

4.3	Konformität zu Standards	2

4.3.1	Relevante Standards	2

4.3.2	Beschreibung des Kriteriums SAGA-Konformität	2

4.3.3	Einschätzung für Produktname	2

4.4	Handhabbarkeit	2

4.4.1	Beschreibung des Kriteriums Handhabbarkeit	2

4.4.2	Einschätzung für Produktname	2

4.5	Architekturkonformität	2

4.5.1	Beschreibung des Kriteriums Architekturkonformität	2

4.5.2	Einschätzung für Produktname	2

4.6	Verfügbarkeit	2

4.6.1	Beschreibung des Kriteriums Verfügbarkeit	2

4.6.2	Einschätzung für Produktname	2

4.7	Konsolidierungsbedarf	2

4.7.1	Beschreibung des Kriteriums Konsolidierungsbedarf	2

4.7.2	Einschätzung für Produktname	2

4.8	Kriterium XYZ	2

4.8.1	Beschreibung des Kriteriums XYZ	2

4.8.2	Einschätzung für Produktname	2

4.9	Lizenzbestimmungen	2

5	Betrachtete Alternativen	2

Idee dieses Dokuments

In Projekten, die Anwendungen nach Architektur der IsyFact erstellen, treten Aufgabenstellungen auf, für die es nützlich ist, fertige Softwarebibliotheken einzusetzen und keine eigene Lösung für ein Problem zu erstellen, für das es fertige und getestete Lösungen gibt. Allerdings muss dabei darauf geachtet werden, dass nicht einfach Produkte in ein Projekt einfließen, die sich bei näherer Betrachtung als wenig tragfähig und zukunftssicher erweisen.

Der sicherste Weg um dies auszuschließen, ist eine breit angelegte Produktauswahl und -bewertung. Dazu fehlt in vielen Situationen aber die Zeit. Dieses Dokument gibt eine kurze Anleitung, wie mit geringem Zeitaufwand ein Produkt ausgewählt werden kann und dennoch die Entscheidung im Rahmen der Möglichkeiten solide und nachvollziehbar bleibt.

Dieses Verfahren unterscheidet sich von einer kompletten Produktauswahl dadurch, dass zum einen nicht alle potentiell einsetzbaren Produkte ermittelt werden und zum anderen nur das favorisierte Produkt gemäß verschiedener, wichtiger Kriterien bewertet wird.

Ausfüllanweisung

Abschnitte, die leicht grau hinterlegt sind, enthalten Hinweise zur Befüllung des Dokuments. Sie sind in der finalen Version des Dokuments zu löschen.

Gelb hinterlegte Schrift bezeichnet Platzhalter, die in der finalen Version des Dokuments durch die entsprechenden Begriffe zu ersetzen sind.

Einige Abschnitte sind bereits vorformuliert und können unverändert übernommen werden. Vorformulierte Abschnitte sollen helfen. Wenn sie nicht passen, können sie natürlich durch selbst formulierte Abschnitte ersetzt werden.

Es ist möglich, dass einzelne Kriterien für die eine konkrete Produktauswahl nicht sinnvoll anwendbar sind. In diesem Fall ist das Kriterium mit „nicht anwendbar“ zusammen mit einer kurzen Begründung zu kennzeichnen.

Einleitung

Im Projekt Projektname soll das Produkt Produktname eingesetzt werden, um folgendes Problem zu lösen: Beschreibung des Problems in einem Satz. In diesem Dokument werden die Überlegungen dokumentiert, die zu dieser Entscheidung geführt haben.

Problemstellung

In diesem Abschnitt soll kurz die Problemstellung beschrieben werden, die durch den Einsatz des Produkts gelöst wird. Dabei bitte das Problem so konkret wie möglich beschreiben. Z. B.:

nicht: Es soll eine Template-Engine ausgewählt werden

sondern: Im Projekt XYZ müssen Emails im HTML-Format erstellt werden. Diese sollen auf Basis von Templates erstellt werden. Gesucht ist eine Lösung, die eine Vorlage für Templates vorgibt und einen Mechanismus bereitstellt, in diesen Templates Platzhalter durch konkrete Werte zu befüllen.

Lösung

Im Produktkatalog ist kein Produkt vorhanden, das eine Lösung dieses Problem bietet. Weder durch den TCA, noch vom PIB wurde eine entsprechende Produktvorgabe gemacht.

Für diese Problemstellung soll das Produkt Produktname eingesetzt werden.

Anschließend noch Hinweise zu der Art und Weise, wie das Produkt eingesetzt werden soll. Zum Beispiel können nur bestimmte Teile des Produkts eingesetzt werden oder bestimmte Richtlinien für die Nutzung gelten. Diese werden hier beschrieben.

Generell gilt in jeder guten Architektur beim Einsatz einer Komponente: Die Nutzung eines Fremdprodukts ist syntaktisch gut vom restlichen Code getrennt, die Aufrufe nicht über den gesamten Anwendungscode verstreut, sondern an wenigen Stellen konzentriert. Ziel ist es dabei, ein Fremdprodukt austauschbar zu machen. Dies wird in der Regel zwar Aufwand bedeuten, aber es muss zumindest möglich und mit vertretbarem Aufwand machbar sein.

Bewertung der Lösung

In diesem Abschnitt wird beschrieben, nach welchen Kriterien das favorisierte Produkt bewertet wurde. Dabei ist eine Bewertung der im Folgenden aufgeführten 7 Pflicht-Kriterien für alle Produkte zwingend vorgegeben. Weitere Kriterien können noch ergänzt werden, um die Wahl des Produkts zu motivieren.

Das gewählte Produkt wird nach folgenden Pflicht-Kriterien bewertet:

Zukunftssicherheit

Erfahrung

Konformität zu relevanten Standards (z.B. SAGA)

Handhabbarkeit

Architekturkonformität

Verfügbarkeit

Konsolidierungsbedarf

Für die Produktwahl werden zusätzlich folgende Kriterien bewertet:

Ggf. noch weitere Kriterien (z.B. Dokumentation, Verfügbarkeit von Support, Marktposition, Clusterfähigkeit, Überwachbarkeit, Performance, Werkzeugunterstützung, …)

Diese Kriterien werden in den folgenden Abschnitten kurz beschrieben, und das favorisierte Produkt wird nach diesen Kriterien bewertet.

Zukunftssicherheit

Beschreibung des Kriteriums Zukunftssicherheit

Die Zukunftssicherheit eines Produkts setzt sich aus mehreren unterschiedlichen Aspekten zusammen. Eine objektive Messung dieser Aspekte von Zukunftssicherheit ist jedoch schwer umsetzbar – letztendlich handelt es sich hier um eine Prognose, die aufgrund von subjektiven Einschätzungen zustande kommt.

Zukunftssicher	Bedingt zukunftssicher	Nicht zukunftssicher
+	O	-
Ein Produkt wird als zukunftssicher angesehen, wenn es sich um einen Quasi-Standard handelt oder es von einem verlässlichen Hersteller oder einer großen Community betreut wird.	Diese Bewertung ist als Kompromiss zwischen + und – zu wählen. + würde das Produkt nach subjektiver Einschätzung zu positiv bewerten, - aber zu negativ.	Ein Produkt wird als nicht zukunftssicher angesehen, wenn bereits eine neuere Version des Produktes existiert oder angekündigt ist oder das Produkt nicht weiterentwickelt wird oder der Hersteller bzw. die Community als nicht zuverlässig angesehen wird.

Folgende Referenzprojekte setzen das Produkt Produktname ein:

Name des Beispielprojekts

Einschätzung für Produktname

Kurze Argumentation, warum das Produkt zukunftssicher ist.

Fazit: Das Produkt wird daher im Kriterium Zukunftssicherheit als {zukunftssicher | bedingt zukunftssicher | nicht zukunftssicher} eingeschätzt.

Erfahrung

Beschreibung des Kriteriums Erfahrung

Relevant für dieses Bewertungskriterium sind zunächst die Erfahrungen, die in Organisationsname oder beim Projektteam für dieses Produkt vorliegen. Dabei wird untersucht, ob Anwendungssysteme unter Nutzung dieses Produkts im Wirkbetrieb bei Organisationsname existieren und in wie vielen Projekten das Produkt bei Dienstleistername bereits eingesetzt wurde.

Dieses Bewertungskriterium dient ergänzend auch als Indikator für weitere Qualitätsmerkmale wie Stabilität, Lernkurve, Dokumentation, Erfahrungsangebot auf dem freien Markt, Schulungsangebot und Support. Wenn ein Produkt bei der Firma des Projektumsetzers in vielen Projekten eingesetzt wird, dann muss dieses Produkt auch stabil, gut dokumentiert und leicht zu erlernen sein – und die Kunden müssen in der Lage sein, Wissen durch Schulungen selbst aufzubauen oder auf dem Markt einzukaufen, da sie sonst den Produkten nicht zugestimmt hätten.

Hoch	Mittel	Niedrig
+	O	-
Das Produkt wird in Organisationsname bereits in produktiven Anwendungen eingesetzt. Es sind keine Probleme mit dem Produkt bekannt.	Das Produkt wird in mehr als 10 Projekten bei Dienstleistername eingesetzt. Dienstleistername befürwortet den Einsatz des Produktes auf Basis dieser Projekterfahrungen.	Weder bei Organisationsname noch bei Dienstleistername gibt es bereits positive Erfahrungen mit dem Produkt.

Einschätzung für Produktname

Kurze Beschreibung, welche Erfahrung.

Fazit: Die vorhandene Erfahrung mit dem Produkt wird als {hoch | mittel | niedrig} eingeschätzt.

Konformität zu Standards

In diesem Abschnitt wird die Konformität zu Standards betrachtet, die für den Anwendungbereich relevant sind. Diese Standards werden in einem eigenen Abschnitt zunächst aufgelistet. Danach folgt zu jedem relevanten Standard eine kurzes Beschreibung und anschließend eine Bewertung der Konformität der betrachten Produkts zu diesem Standard. Für den öffentlichen Bereich ist der SAGA-Standard immer relevant. Er ist daher in dieser Vorlage bereits vorgegeben.

Relevante Standards

Für den betrachteten Anwendungsbereich sind folgende Standards relevant:

SAGA

Ggf. weitere Standards

Beschreibung des Kriteriums SAGA-Konformität

Mit den Standards und Architekturen für E-Government-Anwendungen (SAGA) stellt der Bund sicher, dass E-Government-Anwendungen interoperabel, plattformunabhängig und investitionssicher realisiert sind. SAGA enthält eine Bewertung von derzeit existierenden technologischen Standards für unterschiedliche Anwendungsbereiche und weist den Standards einen Status gemäß Abbildung 1 zu. Die Status „vorgeschlagen“, „beobachtet“, „empfohlen“ und „verbindlich“ erlauben den Einsatz eines Technologiestandards, falls kein Standard mit einem höherwertigen Status im selben Anwendungsbereich vorhanden ist. Verbindliche Standards müssen zwingend eingesetzt werden. Neben dem SAGA-Dokument existieren sechs Listen, in denen Standards bewertet werden: die Pflicht-, Empfehlungs-, Beobachtungs-, Bestandsschutz-, Vorschlags- und die Negativliste. Technologien, die auf der Negativliste aufgeführt sind, dürfen nur als parallele Lösung zu einer SAGA-konformen Lösung genutzt werden. Sie dürfen nicht als einzige Lösung verwendet werden. Verbindliche Technologien müssen verwendet werden. Es gibt keine Empfehlungen neben Verpflichtungen. Empfehlungen sind vor beobachteten Technologien einzusetzen. Es bedarf einer projektspezifischen Begründung, um eine beobachtete Technologie einer empfohlenen Technologie vorzuziehen. Bestandsgeschützte Technologien dürfen nicht in Neuentwicklungen berücksichtigt werden. Im Wartungsfall ist zu prüfen, ob eine Umstellung auf eine empfohlene Technologie durchzuführen ist.

Abbildung 1: mögliche Status eines Standards nach SAGA

SAGA konform	Bedingt SAGA konform	Nicht SAGA konform
+	O	-
Das Produkt erfüllt einen verbindlichen, empfohlenen oder beobachteten SAGA-Standard. Verbindliche Produkte müssen eingesetzt werden.	Das Produkt erfüllt einen auf der Vorschlags- oder Bestandsschutz-Liste stehenden Standard.	Das Produkt steht im Widerspruch zu den SAGA-Standards oder erfüllt Standards, die auf der Negativliste stehen.

Einschätzung für Produktname

Kurze Beschreibung, wie die SAGA-Konformität eingeschätzt wird.

Fazit: Das Produkt wird als {SAGA konform | bedingt SAGA konform | nicht SAGA konform} eingeschätzt.

Handhabbarkeit

Beschreibung des Kriteriums Handhabbarkeit

Dieses Kriterium beschreibt, wie komplex der Einsatz des Produkts aus betrieblicher und softwaretechnischer Sicht ist. Dabei ist insbesondere der zu erwartende Schulungs- und Wartungsaufwand zu berücksichtigen. Zudem muss berücksichtigt werden, ob das Produkt selbst durch Organisationsname/Dienstleister eingesetzt werden kann, oder ob der Hersteller konsultiert werden muss.

Einfach	Mittel	Komplex
+	O	-
Das Produkt ist leicht einsetzbar. Es fallen keine Schulungsaufwände an. Ebenso fallen keine besonderen Wartungsaufwänd an. Der Hersteller des Produkts muss nicht konsultiert werden.	Das Produkt ist mit vertretbarem Aufwand einsetzbar. Der Nutzen des Produktes übersteigt deutlich den zu erwartende Schulungs- oder Wartungsaufwand. Der Hersteller ist nur in kleinem Umfang zu konsultieren.	Das Produkt erfordert erheblichen Schulungs- und Wartungsaufwand. Die Einführung oder zukünftige Änderungen müssen mit dem Hersteller abgestimmt werden.

Einschätzung für Produktname

Kurze Beschreibung, wie gut bzw. einfach ist das Produkt zu handhaben. Je nach Produkt muss hier der Fokus auf den Betrieb oder die Softwareentwicklung oder beide gelegt werden.

Fazit: Die Handhabbarkeit des Produkts wird als {leicht | mittel | komplex} eingeschätzt.

Architekturkonformität

Beschreibung des Kriteriums Architekturkonformität

Dieses Kriterium beschreibt, wie gut sich das Produkt in die bestehende Architektur einfügt. Es beschreibt wie homogen es sich in die bestehende Plattform (Linux, Tomcat, …) bzw. Technologie (Java, Spring, Hibernate) integriert.

Es muss sichergestellt sein, dass im Produktkatalog kein Produkt für denselben Anwendungsbereich vorhanden ist.

Architekturkonforme Produkte bieten einfache Integrationsschnittstellen an, ggf. fremde Technologie ist gekapselt. So kann beispielsweise ein in C++ entwickeltes Produkt architekturkonform integriert werden, wenn dafür eine Java-Client-Bibliothek zur Anbindung angeboten wird.

Für Bibliotheken ist die Anzahl der zusätzlich einzubindenden weiteren Bibliotheken ein Indikator für die Konformität.

Hoch	Mittel	Niedrig
+	O	-
Das Produkt basiert auf den bereits in der IsyFact vorhandenen Technologien. Es wird keine besondere Infrastruktur vorausgesetzt	Das Produkt verwendet Technologien, die noch nicht in der IsyFact Anwendung finden. Allerdings existiert eine gut geeignete Integrationsschnittstelle z.B. eine Webservice-Schnittstelle. Es wird keine besondere Infrastruktur vorausgesetzt.	Das Produkt verwendet Technologien, die noch nicht in der IsyFact Anwendung finden. Eine Integration ist aufwändig bzw. komplex. Womöglich muss für das Produkt eine eigene Infrastruktur geschaffen werden, z.B. Server mit einem anderen Betriebssystem ausgestattet werden. Es gibt ggf. bereits ein konkurrierendes Produkt im Produktkatalog.

Einschätzung für Produktname

Kurze Beschreibung, wie gut das Produkt zur existierenden Architektur passt.

Fazit: Die Konformität des Produkts zur Architektur wird als {hoch | mittel | niedrig} eingeschätzt.

Verfügbarkeit

Beschreibung des Kriteriums Verfügbarkeit

Dieses Kriterium beschreibt wie sich die Nutzung bzw. Einführung des Produkts auf die Verfügbarkeit der nutzenden Services bzw. Anwendungen auswirkt. Einfluss auf die Verfügbarkeit hat die Clusterfähigkeit und die Skalierbarkeit des Produktes. Weiterhin muss die Robustheit des Produktes gegen gezielte (Denial-of-Service-)Attacken berücksichtigt werden.

Hoch	Mittel	Niedrig
+	O	-
Das Produkt ist hochverfügbar, z.B. weil es sich leicht clustern und/oder skalieren lässt.	Eine hohe Verfügbarkeit kann mit zusätzlichen Maßnahmen erreicht werden.	Das Produkt bildet einen Single-Point-Of-Failure. DoS-Attacken können kaum abgewehrt werden.

Einschätzung für Produktname

Kurze Beschreibung, wie gut die Verfügbarkeit des Produkts ist.

Fazit: Die Verfügbarkeit des Produkts wird als {hoch | mittel | niedrig} eingeschätzt.

Konsolidierungsbedarf

Beschreibung des Kriteriums Konsolidierungsbedarf

Dieses Kriterium beschreibt den Umfang des entstehenden Anpassungsbedarfs der Standardarchitektur oder der existierenden Systeme bei Einführung des Produktes (z.B. Migrationsaufwand, Zahl der betroffenen Systeme). Zu berücksichtigen ist dabei die Höhe des generierten Homogenisierungsdrucks, z.B. weil eine Zeitlang mehrere konkurrierende Lösungen betrieben werden müssen.

Niedrig	Mittel	Hoch
+	O	-
Es entstehen keine Konsolidierungsbedarfe.	Die entstehenden Konsolidierungsbedarfe sind von ihrer Höhe her gering und nicht zeitkritisch.	Die notwendigen Konsolidierungsmaßnahmen sind aufwändig oder zeitkritisch. Es wird ein Zwang zur Homogenisierung geschaffen.

Einschätzung für Produktname

Kurze Beschreibung, wie hoch der Konsolidierungsbedarf durch Einführung des Produktes ist.

Fazit: Der Konsolidierungsbedarf durch Einführung des Produkts wird als {hoch | mittel | niedrig} eingeschätzt.

Kriterium XYZ

Beschreibung des Kriteriums XYZ

Einschätzung für Produktname

An dieser Stelle werden ggf. weitere Kriterien nach obigem Muster beschrieben. Dies sind in der Regel spezielle Kriterien, die spezifisch für die Produktart sind.

Weitere allgemeine Punkte, die hier betrachtet werden können, sind: Kosten, Dokumentation, Verfügbarkeit von Support, Marktposition des Produkts.

Lizenzbestimmungen

Informationen darüber, welchen Lizenzbedingungen das Produkt unterliegt. Es muss sicher gestellt sein, dass das Produkt im Rahmen der IsyFact eingesetzt und weitergegeben werden darf. Es dürfen keine Produkte zum Einsatz kommen, die eine so genannte „virale“ Lizenz haben, d. h. dass die Lizenzbedingungen der Bibliothek übergehen auf die Software, die diese Bibliothek nutzt. Ein Beispiel für eine virale Lizenz ist die GPL. Ein Beispiel für eine nicht virale Lizenz ist die LGPL (Gnu Lesser Public Licence).

Nicht passende Lizenzbedingungen sind ein Ausschlusskriterium.

Das Produkt Produktname unterliegt der Lizenzname.

Der Einsatz im Rahmen der IsyFact, insbesondere der Einbau in IsyFact Komponenten und die Weitergabe an Dritte ist möglich.

Betrachtete Alternativen

In diesem Abschnitt werden die bekannten Alternativen zu dem favorisierten Produkt aufgezählt. Zu jeder Alternative ist beschrieben, warum dem favorisierten Produkt der Vorzug gegeben wurde. Die Liste der Alternativen muss dabei nicht alle auf dem Markt verfügbaren Alternativen wiedergeben, sondern nur die im Entscheidungsprozess betrachteten Alternativen und eventuell vorhandene Marktführer. Ein Grund, der gegen eine Alternative spricht kann dabei auch sein, dass diese Alternative nicht bekannt ist oder dass keine Erfahrungen damit vorliegen.

00_Allgemein/Produktkatalog.xls