Alles beginnt mit den Anforderungen

So könnte man den Gang der Dinge bei der Softwareentwicklung, eigentlich aber bei fast jedem ingenieurshaft angegangenen Entwicklungsprojekt beschreiben. Daher gewinnt das Anforderungsmanagement im Systementwicklungsprozess auch laufend an Bedeutung. Denn der 10er-Regel der Fehlerkosten folgend, verzehnfachen sich die Kosten der Behebung von Fehlern mit jeder weiteren Projektphase in etwa. D.h. möglichst viele Fehler gleich zu Beginn des Projekts durch systematisches Vorgehen zu vermeiden, kann immense Summen Geld einsparen (oder im Falle des Unterlassens verschlingen).

Das macht das Anforderungsmanagement zu einer wichtigen Disziplin für all jene, die sich mit Aspekten der Informationssicherheit oder der Qualität von Softwareprodukten befassen. Anforderungen sind die Grundlage für alle Eigenschaften des späteren Produkts (zumindest sollten sie es sein). Anforderungen können Gegenstand späterer Prüfungen des Produktes sein und bilden die Grundlage für das Testmanagement zur Erstellung und Auswahl von Teststrategien und Testfällen. Im Bereich der Produktdokumentation bilden die Anforderungen den Kern des später zu Dokumentierenden und sind Basis für Anwenderschulungen. Auch die spätere Wartung und Weiterentwicklung des laufenden IT-Systems ist auf gut dokumentierte Anforderungen angewiesen.

Daher kann man sich bereits seit geraumer Zeit im Bereich des Anforderungsmanagements nicht nur fortbilden sondern auch ein Fachzertifikat, den „Certified Professional for Requirements Engineering (CPRE)“ mit Prüfung und Siegel erwerben, das auf einem Lehrplan basiert, der vom International Requirements Engineering Board (IREB) e.V. entwickelt wurde. Einem Verband, der sich mit der Kodifizierung von etablierten „best practices“ in diesem Teilbereich der Softwareentwicklung beschäftigt.

Zu den „Klassikern“ der Probleme beim Umgang mit Anforderungen zählen ungenaue, unvollständige, in sich widersprüchliche oder auch gar nicht vorhandene Anforderungen. Beispielsweise weil bei der Produktplanung wichtige Beteiligte übergangen wurden. Weil Dinge als selbstverständlich vorausgesetzt und daher nicht weiter erwähnt wurden. Weil das mit dem Produkt zu lösende Problem nicht wirklich verstanden wurde. Oder weil man es mal wieder zu eilig hatte – „husch husch – time to market – profit profit“ – und daher zu wenig in die konzeptionellen Vorarbeiten der Produktentwicklung investiert hatte. Daher gibt es auch regelmäßig Studien (wie z.B. den sog. „Chaos Report“ der Standish Group), die sich mit den Erfolgs- und Misserfolgsfaktoren in IT-Projekten beschäftigen und dabei regelmäßig die Bedeutung guten Anforderungsmanagements und guten Projektmanagements unterstreichen.

Grundsätzlich hat ein Anforderungsmanager vier Aufgaben, denen er sich zu widmen hat. Er soll Anforderungen erheben, dokumentieren, sie prüfen und mit den Beteiligten abstimmen sowie sinnvoll verwalten und verfügbar machen. Dort wo es die Rolle des Anforderungsmanagers nicht in Reinform gibt, fallen diese Aufgaben den Entwicklern, IT-Architekten, Projektleitern, Produktverantwortlichen etc. zu, was häufig nicht unbedingt zu ihrer vollständigen und zufriedenstellenden Erledigung beiträgt. Zumal ein Anforderungsmanager eigentlich weniger ein technischer Spezialist als ein Experte im Gebiet der Schlüsselqualifikationen und der Methodenkompetenz ist. Denn ihm fallen die „menschlichen Aspekte“ der Produktplanung zu: Er soll die Beteiligten des Vorhabens ausfindig machen, mit ihnen reden und sich so ein Gesamtbild des zu entwickelnden Softwareproduktes verschaffen. Und es so aufbereiten, dass die Entwickler darauf basierend etwas Brauchbares entwickeln können.

Anforderungsmanagern fällt somit die „Verwaltungswirtschaft“ der Softwareentwicklung zu, da ein Großteil ihrer Arbeit aus dem bereits erwähnten Erheben, Dokumentieren, Prüfen und Abstimmen sowie dem Verwalten der Anforderungen, mithin also aus dokumenten- und personenorientierter Arbeit besteht.

Dort wo Softwareentwicklung aber vom „Handwerk“ zur Ingenieurstätigkeit werden soll, also einem Industrialisierungsprozess unterliegt, kommt man um das Anforderungsmanagement ebenso wenig herum wie um das Plänezeichnen und Prototypenbauen im Automobilbau.

Zumal vollständige, konsistente und genau spezifizierte Anforderungen wie bereits erwähnte die Grundlage für testbare Produkte und prüfbare Prozesse zu deren Entwicklung bilden – somit also die Basis der Qualitätssicherung bilden. Zumal so aus Anforderungen auf dem Papier ausführbarer Testfallcode oder die Grundlage einer sicherheitstechnischen Bewertung des fertigen Softwareproduktes werden kann.

Do wo genau findet das Anforderungsmanagement denn statt?

Bei „klassischen“ Vorgehensmodellen der Softwareentwicklung wie z.B. dem V-Modell XT ist das Anforderungsmanagement eine klar definierte Phase, die der Entwicklung vorangeht und die Basis des zu entwickelnden Systems bildet. Zu einem bestimmten, vorab festgelegten Zeitpunkt wird der Stand der Anforderungen „eingefroren“ und bildet die Ausgangsbasis der weiteren Entwicklungsphasen. Später noch hinzukommende Änderungswünsche werden als genau das behandelt: Änderungswünsche, welche zu nachträglichen Änderungen der Planung und Kostenkalkulation führen können.

Im Gegensatz dazu ist das Anforderungsmanagement bei „agilen“ Vorgehensmodellen wie SCRUM ein Begleitprozess der Entwicklung und es werden nur jeweils die erforderlichen Anforderungen für den nächsten Teilabschnitt in der Entwicklung durch iteratives Vorgehen, inkrementelle Fortschreibung und Präzisierung abschlussfertig ausgearbeitet und umgesetzt.

Doch das Anforderungsmanagement trägt auch auf weitere Weise zu einer besseren Softwarequalität bei. So gilt es z.B. auch die Anforderungen an sich hinsichtlich Inhalt, Abgestimmtheit und Dokumentation qualitätszusichern und dabei Methoden des Qualitätsmanagements wie Beteiligung der Betroffenen, Mehraugenprinzip, Trennung von Fehlersuche und Fehlerkorrektur oder auch Prüfung aus unterschiedlichen Perspektiven anzuwenden. Nicht nur Code sondern bereits die dokumentierten Anforderungen an das spätere System lassen sich durch formale Methoden wie Audits, Inspektionen, Walkthroughs oder Reviews prüfen.

Doch woher kann man als im Bereich IT-Sicherheit und / oder Softwarequalität Tätiger das Know-how zu diesem breiten Thema nehmen? Beginnen kann man mit einschlägiger Fachliteratur, für ein tieferes Eindringen in das Thema Anforderungsmanagement kann ein entsprechendes Seminar oder eine Zertifizierung wie das bereits erwähnte IREB-Zertifikat sinnvoll sein. Letztlich entscheidend dürften dann aber die Erfahrungen der gelebten Projektpraxis „im Feldeinsatz“ werden.

Nachlese zum fünften deutschen IT-Gipfel

Am 07.12. fand der inzwischen fünfte „Nationale IT-Gipfel“ der Bunderegierung statt. Diesmal in Dresden. Es fällt mir regelmäßig schwer zu bewerten ob dies eher ein politischer Dampfplauderertreff, ein Lobbying-Forum für die staatsnahen Teile der IT-Branche oder ein echtes IT-strategisches Jahrehighlight ist. Nehmen doch Themen wie Netzpolitik, Internetregulierung, Compliance, Datenschutz oder e-Government immer rascher an Bedeutung zu. Und macht sich doch die allgemeine IT-Inkompetenz bzw. die gravierenden Wissensdefizite zahlreicher politischer Entscheidungsträger immer drastischer in verfehlten Regulierungsvorhaben wie z.B. Elena, dem Jugendmedienschutz-Staatsvertrag (JMStV) oder den verkorksten Regierungsvorlagen zum Beschäftigtendatenschutz bemerkbar.

Doch gleich eines vorweg: Eine generelle informationstechnische Alphabetisierungskampagne für Politiker war leider nicht Gegenstand der Gipfelgespräche.

Allerdings war das Querschnittsthema IT-Sicherheit in mehreren der acht Arbeitsgruppen mit Gegenstand der Beratungen. In diesen Arbeitsgruppen wurden Themen wie die sich mit Themen wie digitale Infrastrukturen, IT-basierte Geschäftsmodelle, Gesundheitstelematik oder e-Government diskutiert. Zwei Arbeitsgruppen befassten sich mit „Vertrauen, Datenschutz und Sicherheit im Internet“ sowie mit „Verantwortung und Schutz in der vernetzten Gesellschaft“, also mit dem Themenfeld Informationssicherheit, Datenschutz und Compliance in einer vernetzten Welt.

Die Ergebnisse des IT-Gipfels wurden in der sog. „Dresdner Vereinbarung“ (PDF, 1 MB) zusammengefasst. Das Dokument enthält zahlreiche mögliche und mehrheitlich auch sinnvolle Ansätze zur Gestaltung der vernetzten Gesellschaft durch Gesellschaft, Staat und Wirtschaft. Allerdings zeigen „Leuchtturmprojekte“ wie DE-Mail, Datenperso, das gescheiterte Immaterialgüterrecht, das Thema Netzneutralität oder die Gesundheitskarte, das politischer Unverstand und Wirtschaftslobbyismus oft mit dem Hintern einreißen, was die Hände zuvor aufgebaut haben. Etwas ausführlicher kann man die Gipfelthemen in der 90-setigen Begleitbroschüre „Programm – Personen – Projekte“ nachlesen, in der die Arbeitsgruppenthermen dargestellt werden (PDF, 2,8 MB)

Etliche Minister nutzten die Gelegenheit, um zu netzpolitischen Themen Stellung zu nehmen. Und die Bundeskanzlerin beklagte (wohl zurecht) die überlange Dauer mancher adipöser IT-Großprojekte der Regierung wie etwa der elektronischen Gesundheitskarte. Außerdem kündigte sie zum werweißwievielten Male den verstärkten Ausbau der Breitbandinfrastrukturen in Deutschland an. Auch wenn sich dieses Problem überhaupt erst durch verfehlte Verträge im Laufe der Telekom-Privatisierung ergeben hat (Nichtfestschreibung des bundesweiten Grundversorgungsauftrags mit Netzinfrastruktur des aktuellen Standes der Technik) und die Telekom sich auf dem Gipfel in weiser Voraussicht für weniger regulierende Eingriffe in ihre marktbeherrschende Position aussprach.

August-Wilhelm Scheer, Präsident des Bundesverbands Informationswirtschaft, Telekommunikation und neue Medien (BITKOM), kündigte auf dem IT-Gipfel eine informationstechnische Bildungsoffensive an. Geplant sei ein Software-Campus, der 100 Spitzenkräfte pro Jahr finanziell fördert sowie ein Bitkom-Management-Club, in dem jährlich 17 Ausnahmetalente von ebenso vielen Betreuern zu jungen Führungskräften herangebildet werden sollen. Mitte 2011 soll ein mehrsprachiges Online-Portal „Work and Study in Germany“ potentiell zuwanderungswilligen IT-Fachkräften das Leben in Deutschland nahebringen. Da wird man aber in der deutsche Arbeits- und Sozialordnung, im deutschen Steuerrecht sowie im Personalmanagement fast aller deutscher Unternehmen noch sehr viel tun müssen, um die realen Defizite in den Bereichen Aus- und Weiterbildung, Personalmanagement, faire Entgelte sowie Steuern und Sozialabgaben abzuräumen. Dem steht das Vorhaben des BITKOM, das für eine erleichterte Zuwanderung nachzuweisende jährliche Mindesteinkommen auf das Einstiegsniveau von Junior-Ingenieuren ohne Berufserfahrung abzusenken, jedoch eher entgegen.

Es bleibt also abzuwarten, ob die Vielfalt der Interessenslagen der Beteiligten sowie die äußerst ungleiche Verteilung von Wissen, Kompetenz und Sachverstand zu Themen mit IT-Bezug aus den Programmpunkten konkrete Politikansätze entstehen lassen.

Herausforderung Cloud-Computing

Cloud Computing, also das Auslagern von Daten und IT-Diensten in die Rechenzentren von IT-Dienstleistern, gewinnt immer mehr an medialer Popularität. Dabei stößt man jedoch rasch auf etliche Probleme, wenn das Thema tatsächlich im Unternehmen umgesetzt werden soll. Denn den oftmals erhofften Einsparungen an IT-Kosten stehen beträchtliche Mehraufwände im Bereich Datenschutz und Informationssicherheit gegenüber. Hinzu kommen bislang noch ungelöste Compliance-Risiken. Dies hat die Gesellschaft für Informatik kürzlich in einem Thesenpapier verdeutlicht, dass diese Herausforderungen in den Bereichen Identity Management, Access Control und Integrity Control, Logging und Auditing, Risk Management und rechtlicher Compliance aus technischer und juristischer Sicht beschreiben thematisiert.

Außerhalb ihrer Standorte können Unternehmen ihre Vorstellungen von Sicherheitspolitiken, -strategien und -verfahren sowie Sicherheitsmaßnahmen und ihrer Kontrollierbarkeit meist nicht durchsetzen. Man muss sich schon darauf verlassen, wie weit Verträge, Service-Level-Agreements (SLAs) mit Cloud-Betreibern und deren Subunternehmern im Problemfall wirklich reichen.

Dies – sowie etliche noch offene rechtliche Fragen – führt dazu, dass viele Firmen der Cloud-Technologie eher zurückhaltend begegnen und eher zu Etablierung einer „private cloud“, also einem unternehmensinternen Angebot neigen. So können unternehmensinterne Policies, Vorgaben und Strategien leicht übertragen werden. Das aber ist dann letztlich wieder nur eine weitere technologische Spielwiese der internen IT. Ob dadurch die oft als Pro-Argument aufgeführten Rationalisierungs- und Konsolidierungseffekte erzielt werden können, dürfte fraglich sein.

Will ein Unternehmen jedoch echtes Outsourcing per Cloud Computing betreiben, sollte es sich der Tatsache gewahr werden, dass zwar die Technik und das dazugehörige Personal ausgelagert werden kann. Dass aber die Probleme in Form von Haftungsfragen, Risikoerwägungen, Compliance-Auflagen oder sonstigen, meist rechtlichen Fallstricken im Haus bleiben. Man kommt als Entscheider den Anforderungen seiner Umwelt eben nicht einfach durch das Fremdvergeben eines Auftrags aus.

Dabei beginnen die Probleme oftmals bereits mit der scheinbar simplen Frage, wie sensible Daten zum Cloud-Betreiber hin und von dort wieder zurück ins Kundenunternehmen kommen. Werden dafür öffentliche Netze genutzt, sind Fragen nach hohen und sicheren Verschlüsselungsstandards, Zugriffsrechten, Identity Management und Netzverfügbarkeit zu klären. Oft ist eine echte Ende-zu-Ende-Verschlüsselung auch gar nicht machbar, wenn z.B. Daten Verarbeitungszwischenschritte beim Cloud-Betreiber durchlaufen sollen.

Auch gilt es zu beachten, dass der aktuelle Stand der Technik bei Virtualisierung, Lastausgleich, geografischer Verteilung, Sicherungs- und Sicherheitsmaßnahmen sowie der Datenübertragung über Netzwerke generell nicht unbedingt als sicher und fehlerfrei angesehen werden kann. Es können sich darin kritische, für Dritte gut ausnutzbare Sicherheitslücken befinden. Für Auftraggeber ist das nicht immer nachvollziehbar – wollen sie solche „technischen Probleme“ ja gerade deswegen auslagern, da es ihnen oft am Know-how und den Kapazitäten fehlt, so etwas selbst beurteilen und lösen zu können. Und das obwohl z.B. die datenschutzrechtlichen Auflagen zum Thema Auftragsverarbeitung (§ 11 BDSG) dies explizit dem Auftraggeber als Pflicht bei der laufenden Kontrolle seines Auftragnehmers abfordern.

Ausgelagerte geografisch verteilte, sich u.U. im Ausland befindliche Cloud-Rechenzentren Dritter machen es für den Auftraggeber äußerst schwierig, bei eingetretenen Sicherheitsvorfällen selbst forensische Untersuchungen anzustellen, bei sicherheitstechnischen Analysen zu substanziellen Ergebnissen zu gelangen oder den Auskunftspflichten gegenüber ermittelnden Behörden und Staatsanwaltschaften zeitnah nachkommen zu können. Diese schlicht auf den Dienstleister zu verweisen, dürfte in den seltensten Fällen akzeptiert werden, da die Verantwortung rechtlich beim Auftraggeber geblieben ist und nicht mit in die Cloud abgeschoben werden kann.

Und selbst wenn es Ermittlungsbehörden gelänge, auf die Systeme des Cloud-Betreibers zuzugreifen bzw. Beschlagnahmungen durchzuführen, dürfte dabei der auf Virtualisierung und Mehrmandantenfähigkeit basierende Cloud-Betrieb empfindlich gestört werden (Schadensersatzansprüche Dritter!). Auch dürften eventuell gewonnene und potentiell manipulierte Abzüge der Daten aus der Cloud nur verminderten Beweiswert vor Gericht haben. Wobei es zu diesem Problem noch kaum Rechtsprechung gibt, deutsche Gerichte aber in solchen Fragen als sehr konservativ gelten.

Bei unternehmenskritischen Fragen auf die Dienste Dritter zurückzugreifen, bedeutet das Eingehen von Abhängigkeitsverhältnissen. Ein Stück weit ist das unumgänglich, wenn man sich die Vorteile des globalen und verteilten arbeitsteiligen Wirtschaftens zunutze machen will. Es kann aber auch bedeuten, dass die eigenen IT-Systeme zum Stehen kommen, wenn der Cloud-Betreiber über Nacht in die Insolvenz geht und abgeschaltet wird. Cloud-Verträge müssen daher stets auch Regeln enthalten, wie in solchen Fällen rasch zu einem anderen Dienstleister oder zurück in eine (dann noch existente?) interne IT gewechselt werden kann. Je komplexer die ausgelagerten IT-Systeme sind, desto anspruchsvoller ist so ein Rückwechsel-Vorhaben. Rasch kann da ein sog. „Vendor-lock-in“, d.h. eine existenzielle und kurzfristig nicht überwindbare Abhängigkeit von einem Anbieter eintreten. Auch ist bei genauerem Hinsehen längst nicht alles, was vertraglich vereinbart wurde, auch technisch umsetzbar (z.B. technische Unmöglichkeit der Datenlöschung bei Vertragsende oder besonderen Ereignissen wie Insolvenz).

Öffentliche Clouds können bei entsprechender Nutzung durchaus den Charakter kritischer Infrastrukturen annehmen, sofern sie allgemein und weitverbreitet verwendet werden. Dadurch werden schließlich sogar kartellrechtliche Aspekte wie die „Essential-facilities-Doktrin“ tangiert, welche die wenigsten IT-Entscheider mit auf dem Radar haben dürften.

Und so kommt die Gesellschaft für Informatik auch völlig zutreffenderweise zu dem Schluss, dass sich beim Cloud Computing stark erhöhte Anforderungen an die Absicherung unternehmenseigener und auch privater Datenverarbeitung ergeben werden. Und zwar hinsichtlich Vertraulichkeit, Integrität, Verbindlichkeit (z.B. Authentifizierung Berechtigter) und Verfügbarkeit der verarbeiteten Daten sowie der genutzten IT-Systeme. Hinzu kommen auch stark erhöhte Anforderungen an die rechtliche Absicherung (Compliance).