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.

Offene Standards in der Informationstechnik

Die IT-Beauftragte der Bundesregierung Cornelia Rogall-Grothe, als „Bundes-CIO“ für die IT der Bundesverwaltung zuständig, möchte mit offenen IT-Standards ein Höchstmaß an Interoperabilität und Herstellerunabhängigkeit erreichen. Das erklärte sie der c‘t in deren aktueller Ausgabe 15/2010 man ein entsprechendes Interview findet.

Dazu müssten in Frage kommende IT-Standards vollständig offengelegt sein und  ihre Nutzung darf nicht durch Urheberrechte oder lizenzrechtliche Bestimmungen eingeschränkt sein, so Frau Rogall-Grothe. Davon würden auf Dauer auch Anbieter und Dienstleister profitieren, da niemand zertifizierter Partner eines Herstellers sein müsse, um mit Dritten ins Geschäft kommen zu können.

Offene Standards sind insbesondere im Behördenbereich ein Thema von zunehmender Bedeutung. Dafür gibt es gleich eine ganze Reihe von guten Gründen. Die beginnen damit, dass man Bürger, die am e-Government d.h. dem elektronischen Austausch mit staatlichen Institutionen teilnehmen wollen, eigentlich nicht vorschreiben kann, dass das nur mit ganz bestimmten herstellerabhängigen Technologien funktioniert. Schließlich werden staatliche Einrichtungen von allen Steuerzahlern finanziert, nicht nur von denen die Produkte z.B. von Microsoft, Adobe oder Siemens einsetzen.

Von der öffentlichen Verwaltung wird Transparenz hinsichtlich ihres Wirkens und dem Zustandekommen ihrer Entscheidungen erwartet. Nahezu alles was Behörden tun, ist daher formal rechtlich prüfbar. Dazu gehört auch eine Offenlegung entsprechender Informationen in allgemein verfügbaren Datenformaten. Gesetzliche Informationsfreiheit ist da nur ein Anfang.

In diese Richtung zielt auch die Forderung nach Open Government und Open Data, d.h. offenem Zugriff auf maschinenlesbare Informationen, die im Zuge staatlicher Aktivitäten entstanden sind und die der Allgemeinheit, der diese Informationen ja eigentlich gehören, zur freien Verwendung zur Verfügung zu stellen sind. Beispiele wären z.B. Katasterkarten, Umweltmesswerte oder statistisch aggregierte Daten über die Bevölkerung in Stadtvierteln.

Wichtiger aber wäre noch die Kompatibilität auf Verfahrens- und Datenebene in den Verwaltungen. Da heute noch jede Behörde und jede Kommunalverwaltung mit einer Vielzahl eigener, zum Teil selbst entwickelter IT-Systeme arbeitet, könnten offene Standards sowie die Verpflichtung zu deren Einhaltung die Verwaltungskosten deutlich senken helfen. Bei gleichzeitig verbesserten Werten bezgl. Bearbeitungs- und Reaktionszeiten sowie einer Senkung von Verfahrensfehlern bei der Bearbeitung von Bürgeranliegen. Allerdings ist dafür eine längere Übergangszeit einzuplanen, da die funktionelle Erweiterung oder Neubeschaffung eines behördlichen Fachverfahrens (einer IT-Anwendung) Zeit und Geld kostet, die in Zeiten knapper Kassen erst mal politisch bewilligt und begründet sein wollen.

Offene Standards helfen Herstellerabhängigkeit zu vermeiden. Wer z.B. nur Microsoft-Architekturen oder SAP-Produkte einsetzt, macht sich direkt abhängig von der Produktpolitik und den Preisvorstellungen dieser beiden Softwaregiganten. Da können dann schon mal 80% des jährlichen IT-Budgets einer Firma nur für die Erneuerung von monopolpreisigen Lizenzen draufgehen. Oder eine gerade eben mit Mühe eingeführte und geschulte IT-Infrastruktur muss in absehbarer Zeit verschrottet und ersetzt werden, nur weil der Hersteller das Produkt aus seinem Angebot geworfen hat, Supportverträge nicht mehr verlängert und stattdessen das Nachfolgemodell verkaufen will.

Mit Hilfe offener Standards lässt sich auch die Komplexität heterogener IT-Umgebungen reduzieren, indem man Schnittstellen, Formate sowie den Datenaustausch generell vereinfacht. Und unnötige Komponenten zur Umwandlung von Daten in ein anderes Format ganz streicht, wenn diese Formatumwandlung nicht mehr erforderlich ist. Über längere Zeit gerechnet, können so beträchtliche Beträge an Planungs-, Entwicklungs-, Test-, Betriebs- und Supportkosten eingespart werden.

Eine weitere Möglichkeit zur Reduzierung von Komplexität und Kosten ist der Wegfall von Lizenzen. Jedes wegfallende Lizenzmodell, jede nicht mehr zu verwaltende Lizenz, jede nicht mehr erforderliche rechtliche Prüfung von Lizenzkonditionen, AGBs und sonstiger Vertragsmaterie spart sofort bares Geld. Der Betrieb von Software wie z.B. Lizenzmanagementserver, die keinen produktiven Zweck erfüllt sondern allein der Absicherung fremder Interessen im eigenen Unternehmen dient, kann komplett entfallen.

Viele Hersteller lassen sich in ihren Lizenzen zudem eine Art „Betriebsprüfung“ zusichern, um in den Unternehmen ihrer Kunden die Einhaltung ihrer selbst gesetzten Regeln nachzuprüfen und im Falle der Nichteinhaltung happige Geldforderungen stellen und eintreiben zu können. Dieser unnötige Overhead entfällt beim Einsatz offener Standards und darauf basierender Lösungen ebenfalls.

Daher setzen sich Lobbys aus dem Bereich der Hersteller proprietärer Softwareprodukte zunehmend dafür ein, offene Standards aufzuweichen und zurückzudrängen, wenn es z.B. auf EU-Ebene um Neuregelungen im Bereich offener Standards als Grundlage für vergaberechtliche Festlegungen geht. So wird z.B. aktuell die Neufassung des EU-Rahmenwerks zur Herstellung von Interoperabilität bei E-Government-Diensten (European Interoperability Framework) diskutiert, in der bislang sehr klar gefasste Begrifflichkeiten zur Offenheit von Standards so aufgeweicht werden sollen, dass sich darin auch Positionen von Anbietern proprietärer Technologie sowie der Rechteverwerter unterbringen lassen. Das wäre ein  klarer Rückschritt auf dem Weg zur Offenheit und Anbieterneutralität der öffentlichen Verwaltungen.

Letztlich dürfte die Zulassung von Patent-Kartellen im öffentlichen Sektor auch zu einer indirekten Zustimmung zur umstrittenen Patentierbarkeit von Software ohne demokratische Übereinkunft und ohne Rücksicht auf die Bedenken vieler Europäer darstellen, so der Förderverein für eine Freie Informationelle Infrastruktur (FFII), der die geplante Verwässerung der European Interoperability Framework deutlich kritisiert.

Offene Standards stellen auch bei der Informationssicherheit das Abbild des aktuellen Standes der Technik dar, wie man z.B. im zum Jahresanfang aktualisierten „Kompass der IT-Sicherheitsstandards“, einer von BITKOM und DIN herausgegebenen Übersicht über Standards mit Bezug zur IT-Sicherheit nachlesen kann. In Standards und Normen kommen anerkannte gute Praktiken und erfolgreiche Vorgehensweisen zum Ausdruck. Daher gewinnen auch Forderungen nach einem transparenten Zustandekommen von Normen sowie einem möglichst freien und niedrigschwelligen Zugang zu den Normtexten zum Zwecke der Information und Meinungsbildung an Bedeutung.

Ein Standard kann somit als „offen“ bezeichnet werden, wenn er

• veröffentlich wurde
• kostenlos oder zu akzeptablen Kosten (Schutzgebühr für das Dokument) zur Verfügung gestellt wird.
• ohne weitere Verpflichtungen (z.B. in Form von Lizenzkonditionen) genutzt werden kann und frei von  Rechten Dritter ist.
• auch in Zukunft veröffentlicht und frei nutzbar bleibt.

Was u.a. eine vollständige Offenlegung sowie die Akzeptanz durch ein normgebendes Standardisierungsgremium (ISO, IEEE, DIN usw.) der Fachanwenderschaft voraussetzt.

Ein guter Einstieg in dieses Thema ist das von der bereits erwähnten Bundesbeauftragten für Informationstechnik Frau Rogall-Grothe herausgegebene Werk „Standards und Architekturen für E-Government“ (SAGA) in der derzeit aktuellen Fassung 4.0. Das SAGA-Dokument beschreibt Grundlagen der Standards, Technologien und Methoden für den Einsatz von Informationstechnik in Bundesbehörden und gibt Empfehlungen zur Entwicklung und Pflege von E-Government-Anwendungen der öffentlichen Verwaltung. Es legt Schwerpunkte auf Interoperabilität, Plattformunabhängigkeit und Investitionssicherheit von Softwaresystemen. Ihre wirtschaftliche Relevanz bekommen solche Verwaltungsvorgaben insbesondere dann, wenn sie Eingang ins Vergaberecht finden oder in Vergaben mit einbezogen werden. Denn dann müssen sich Hersteller daran halten, wenn sie Aufträge der öffentlichen Hand akquirieren wollen. Auch das kann ein wirksames Steuerungsinstrument hin zu mehr offenen Standards und wenige „kreativer Inkompatibilität“ sein.

Sicheres Programmieren lernen – Der Weg zu guter Software

Sichere Software gewinnt zunehmend an Bedeutung. Sicher im Sinne von „extrem schwer angreifbar“ (Security) ebenso wie im Sinne von „extrem zuverlässig“ (Safety). Das macht es erforderlich, Sicherheitsaspekte bereits in den Entwicklungsprozess der Software zu integrieren, anstatt die Sicherheit erst nachträglich „reinzupatchen“.

Um Abhilfe zu schaffen, haben sich zahlreiche Unternehmen in einem Verein – dem International Secure Software Engineering Council (ISSECO) – zusammengeschlossen. Und dort einen zertifizierbaren Standard für sichere Softwareentwicklung entwickelt.

Will man das Problem der Sicherheitslücken und Qualitätsmängel in Softwareprodukten an der Wurzel packen, muss das Thema Sicherheit in den Entwicklungsprozess integriert werden, um so frühzeitig der Entstehung von Sicherheitslücken entgegenzuwirken.

Das hierfür notwendige Wissen zur Vermeidung von Sicherheitslücken ist jedoch bis heute nur ein Randthema in der Ausbildung von Softwareentwicklern. Auch wenn Fachverbände wie der Arbeitskreis Software-Qualität und -Fortbildung oder die Gesellschaft für Informatik hier bereits seit längerem Verbesserungen anmahnen. Zudem lässt die zunehmende Komplexität von Softwareprodukten erwarten, dass das Ausmaß der Bedrohungen durch Sicherheitslücken und Qualitätsmängeln in den kommenden Jahren weiter zunehmen wird.

Der ISSECO hat daher einen Standard sowie ein Fortbildungscurriculum (ISSECO Certified Professional for Secure Software Engineering – CPSSE) entwickelt, um diese Lücke zu schließen. Das Thema Sicherheit soll dadurch zum selbstverständlichen Bestandteil jedes Softwareentwicklungsprozesses werden. Dieser internationale Zertifizierungsstandard für sichere Softwareentwicklung soll in der Softwareindustrie etabliert werden, um den Anwendern Sicherheit bei der Verwendung von Softwareprodukten zu garantieren und so auch verlorenes Vertrauen in die Softwarequalität zurück zu gewinnen.

Inhalte des Curriculums zur sicheren Softwareentwicklung sind Themen wie die Angreiferperspektive sowie die Kundenperspektive auf Software, Thread Modeling, Methoden sicherer Softwareentwicklung und Lebenszyklusmodelle für Software, Anforderungsanalyse, sicheres Design von Software, sicheres Testen, sicherer Rollout, Reaktion auf Angriffe und Qualitätsmängel sowie Sicherheit mit Metriken transparent machen. Dies wird entlang der Etappen des Softwareentwicklungsprozesses verdeutlicht:
•    Requirements Engineering
•    Design und Spezifikation
•    Programmierung und Test
•    Evaluierung, Distribution & Maintenance

Erste Schulungsangebote zum CPSSE werden derzeit am deutschen Markt etabliert. Zielgruppen sind Anforderungsanalysten, Softwarearchitekten, Designer, Entwickler, Softwarequalitätsmanager, Softwaretester, Projektmanager – kurz alle, die entscheidend an der Entwicklung von guter Software beteiligt sind.

Wenn sich Ideen wie der CPSSE im Markt durchsetzen, kann dies ein wichtiger Schritt zu sicherer und qualitativ hochwertigerer Software sein.

Sichere Software und sichere Verträge – Projekt Salomo

Viele Unternehmen, die Entwicklungsaufträge für Software an Dritte vergeben, haben ein Problem: Weder können sie exakt und juristisch belastbar spezifizieren, welche Eigenschaften die zu entwickelnde Software haben soll. Noch verfügen sie über geeignete Tools, um solche Eigenschaften, testen, messen und beurteilen zu können. Das macht es schwer die Entwicklung qualitativ hochwertiger Software rechtlich zu fassen zu bekommen.

Daher arbeiten Informatiker der Uni Freiburg zusammen mit Rechtswissenschaftlern der Uni Mannheim im Rahmen des Projektes „Salomo“ an einer Verbesserung der Entwicklungsverträge für Software. Zielgruppe sind primär kleine und mittelständische Firmen.

Einer Studie der Universität Oldenburg aus dem Jahr 2006 zu Folge wurden nur gut die Hälfte aller in Deutschland laufenden Softwareentwicklungsprojekte erfolgreich abgeschlossen. Weltweit sind es sogar nur ein knappes Drittel. Die damit einher gehenden Rechtsstreitigkeiten und Unsicherheiten werden von den betroffenen Unternehmen zunehmend als echtes Problem empfunden.

Doch wie kann man dem beikommen? Software-Entwicklungsverträge passen in kein vertragsrechtliches Standardschema. Denn juristisch ist nicht einmal klar, ob Programme überhaupt gegenständlich sind oder „geistiges Eigentum“ (an sich ein politischer Kampfbegriff der Verwerterlobby). Was soll „Zuverlässigkeit“ oder „Verfügbarkeit“ bei Programmen und Systemen im konkreten Fall bedeuten: Darf es einmal täglich abstürzen oder nur einmal im Jahr?

Ein Ziel des Forschungsprojekts sind daher vorformulierte Musterverträge für Entwicklungsvorhaben. Sie sollen als Kernstück ein juristisches Novum enthalten: Die Vertragspartner machen nicht nur die exakten Spezifikationen der Anforderungen mit zum Vertragsteil. Sondern sie einigen sich auch auf einzusetzende Werkzeuge und Verfahren, mit denen die Erfüllung der Anforderungen durch das gelieferte Produkt automatisiert getestet werden kann.

Geht es nach den Wissenschaftlern des Salomo-Projekts wird die automatische Überprüfung von Anforderungen an die Software also zum festen Bestandteil des Vertrages. Die Produktabnahme wird teilautomatisiert, objektiviert und insgesamt beschleunigt. Dieser wesentliche Bestandteil der Entwicklungsverträge würde so zudem rechtskulturunabhängig und international verwendbar.

Die dazu benötigten Tools sollen ebenfalls im Verlauf des Salomo-Projektes entwickelt werden. Mit Hilfe von modellbasierten Testverfahren sowie formalen Verifikationsmethoden aus der Informatik soll Software auf korrekte Erfüllung der vertraglich vereinbarten Anforderungen geprüft werden. Auftraggeber könnten die korrekte Erfüllung dann selbst prüfen oder durch Dritte (z.B. eine Prüfgesellschaft mit eigenem Test-Center) prüfen lassen.

Ähnliche Ansätze (anforderungsbasiertes automatisiertes Testen) werden allerdings auch von Anbietern kommerzieller Testumgebungen schon seit einiger Zeit verfolgt. Neu hingegen ist die Idee, sich vertraglich juristisch belastbar auf Testwerkzeuge und –verfahren zu einigen und die Erfüllung des Vertrages vom Ergebnis dieser vorab vereinbarten Tests abhängig zu machen.

Nur sollte dann sichergestellt sein, dass kein „developing to the test“ stattfindet, d.h. dass ein Programm zwar exakt den vereinbarten Test besteht, bei geringfügig veränderten Parametern jedoch ein ganz anderes Verhalten zeigt.

Computerwoche.de: Salomo schafft Mustervertrag. Elektronischer Schiedsrichter wacht über Softwareentwicklung

Badische-Zeitung.de: Ein Elektro-Schiri prüft die Software

Forschungsverbund Salomo