Was professionellem Testen oft entgegensteht

Gute Softwarequalität erfordert entsprechende qualitätssichernde Maßnahmen. Das beginnt bei realistischer Projektplanung (Vermeiden des Unterschätzens von Aufwand und Arbeitsumfang), geht über ordentliche und gut dokumentierte Spezifikationen und hört beim Testen noch lange nicht auf. Doch gerade in vielen mittelständisch geprägten „Software-Manufakturen“ weisen die Entwicklungsprozesse noch viel Potential zur Anhebung des Qualitätsniveaus der Softwareprodukte auf. Diplomatisch ausgedrückt.

So ist es immer noch eher der Regelfall als die Ausnahme, dass ein kleines, personell unterbesetztes Entwicklerteam (teilweise freie Mitarbeiter) seinen eigenen Code testet und reviewt. Dabei sollten Entwickeln und Testen unabhängig voneinander nach dem Vier-Augenprinzip ablaufen. Kein Entwickler sollte seine eigene Arbeit prüfen oder testen. Die Gefahr unbewusster blinder Flecken ist psychologisch einfach zu präsent. Von anderen Mängeln aufgrund unsystematischer Vorgehensweise mal abgesehen.

Doch das führt in der Praxis rasch zu der Frage wer das alles testen soll? Man hat schlicht zu knapp kalkuliert oder will mit zu wenig zu viel erreichen. Eine weit verbreitete Problematik, die nicht nur in der Softwareentwicklung anzutreffen ist. Die Auslastung der Entwickler ist so kalkuliert, das sie entweder gar nichts oder doch ihre eigene Arbeit testen. Allenfalls in Ausnahmefällen oder bei offensichtlich aus dem Ruder laufenden Problemen wird auf Freelancer oder externe Testing-Dienstleister zurückgegriffen.

Aber auch Versuche die Qualität des Entwicklungsprozesses als solchen anzuheben, indem Coding-Styles vereinbart werden, bestimmte Dokumentationsnormen oder ein systematisches Spezifizieren und Reviews gefordert werden, trifft bei eher „handwerklich-künstlerisch“ orientierten Entwicklern oft auf hartnäckigen passiven Widerstand. Das fordert weniger Ressourcen als vielmehr die Fähigkeit zur Mitarbeiterführung der Projektverantwortlichen.

Währenddessen steigen die Anforderungen an die Softwarequalität langsam aber kontinuierlich. Insbesondere technischer Fortschritt, organisatorische Veränderungen in Kundenbranchen, Compliance- und Safety-Anforderungen sind da prägende Einflussfaktoren. Ebenso die Forderung komplexe Produkte, bestehend aus Hardware- und Softwarekomponenten (Systems oft systems) sauber getestet und reviewt in definierter Qualität termin- und budgetgerecht entwickeln zu können.

Insbesondere stark vertriebsgesteuerte Mittelständler leiden da unter zunehmenden Marktdruck. Professionalisierung wird von ihnen ebenso gefordert wie Standardisierung und Ausrichtung ihrer internen Abläufe an marktüblichen Branchenstandards. Selbst wenn sie wollten, können diese Unternehmen ihren Entwicklungsprozess oftmals nicht durch eigentlich notwendige Phasen verlängern. Auch wenn sie dadurch qualitativ eindeutig bessere Ware liefern könnten und selbst wenn dadurch das notorische Unterschätzen von Aufwand und Arbeitsumfang eingedämmt werden könnte. Denn nicht alles was vom Markt gefordert wird, bezahlt er auch. Oft müsse daher Konzessionen gemacht werden, deren finanzielle Auswirkungen man dann dort wieder zu korrigieren versucht, wo es der Kunde so schnell nicht bemerkt. Manches später (oder gar nicht) gepatchte Sicherheitsleck und so manche Unausgegorenheit in Softwareprodukten erblickte so das Licht der Welt. An Softwarefehlern hängen aber dennoch Reputation und in barer Münze berechenbare Folgekosten.

Wo es Mittelständlern demnach an Ressourcen und Prozessreife mangelt, kämpfen die großen Unternehmen mit anderen Problemen. Bei ihnen sind es die Instabilität ihrer eigenen Organisation (häufige Umstrukturierungen, oftmals rein zu Profilierungszwecken neuer Vorstände) oder deren Gegenteil in Form starrer bürokratischer Vorgaben, die dazu führen können, dass das Qualitätsmanagement ein kaum beachtetes oder gar ignoriertes Eigenleben neben den produzierenden Kollegen in der Softwareentwicklung führt.

Auf Berater und Experten im Bereich Softwarequalität kommt daher eine Doppelaufgabe zu:

Zum einen Kunden und einkaufende Betriebe davon zu überzeugen, dass der Anspruch an immer mehr und besserer Software unausweichlich mit umfangreicheren Testprozeduren und anderen qualitätssichernden Maßnahmen einhergeht.

Zum anderen werden sich Entscheider in den Unternehmen Gedanken machen müssen, wie sie die Anforderung von besserem und effektiverem Testen mit schmaler werdenden Budgets vereinbaren können.

Microsoft rüstet nächstes Visual Studio fürs Testen auf

Microsoft hat in den letzten Jahren beträchtlich in die interne Qualitätssicherung investiert, um seine Produkte sicherer und fehlerärmer zu machen. So wurden Dinge wie das „Security by Design“-Prinzip ebenso umgesetzt, wie eine personelle Aufstockung der Qualitätssicherung (etwa ein Tester pro Entwickler) oder die Entwicklung und Verbreitung von Prüftools für Security-Tester.

Ein Teil der so gewonnene Erkenntnisse soll auch in die kommende Version der Microsoft-Entwicklungsumgebung „Visual Studio“ eingehen. Visual Studio 2010 wird Funktionalitäten für Tester, Testmanager und Qualitätssicherer enthalten. So ist eine Unterstützung der Bereiche Qualitätssicherung (Unit Tests, Code Coverage, Coded UI Tests, Web Performance Tests, Lasttests), Debugging und Fehlerdiagnose (statische Codeanalyse, Codemetriken, Profiling, Bugtracking) sowie Verwaltung von Testumgebungen und teilweise Testautomation (Einrichten und Zurücksetzen von virtuellen Umgebungen, Testfallverwaltung, manuelle Ausführung von Tests, Aufzeichnung und Abspielen von manuellen Tests) geplant. Ebenso eine stärkere Integration von Projektmanagement- und Teamarbeitsfunktionen direkt in die Entwicklungsumgebung.

So soll speziell im Bereich nichttechnisches bzw. manuelles Testen eine durchgängige Zusammenarbeit zwischen Softwareentwicklern und Testern auf der Basis einer einheitlichen Umgebung erreicht werden. Das dürfte sich speziell auf die Anbieter heutiger Testumgebungen und Testmanagementwerkzeuge auswirken, die meist zusätzlich zu einer bereits vorhandenen Entwicklungsumgebung dazugekauft werden. Microsoft verfolgt hier seine aus dem Windows-Umfeld bereits bekannte Strategie weiter, vormals von Drittanbietern entwickelte Tools zunehmend in seine Plattform zu integrieren und somit deren Zukauf überflüssig zu machen.

Die neue Entwicklungsumgebung Visual Studio 2010 soll im März 2010 erscheinen. Eine Betaversion kann aber jetzt schon zum Testen von Microsoft heruntergeladen werden.

Zudem ging Microsoft eine Kooperation mit der imbus AG, einem Anbieter von Beratungsdienstleistungen und Schulungen rund um Softwarequalität und Testing, um sich so zusätzliches Know-how mit an Bord zu holen.

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.

Ein Blick auf den neuen ISTQB Certified Tester Advanced Level

Der ISTQB Certified Tester hat sich im Laufe der Jahre zum „Goldstandard“ der zertifizierten fachlichen Fortbildung für Softwaretester entwickelt. Weltweit gibt es etwa 100.000 zertifizierte Tester, davon ca. 15.000 in Deutschland. Die international abgestimmten Curricula für die Testerzertifizierung werden in Deutschland vom German Testing Board (GTB) weiterentwickelt. Und für die Aufbauzertifizierung ISTQB Certified Tester Advanced Level stand nun nach längerer Vorbereitung eine grundlegende Überarbeitung der zertifizierungsrelevanten Inhalte an.

Die Neuerungen im Bereich der Testerzertifizierung stellte kürzlich Arne Becher von der imbus Akademie auf den ASQF-Fachgruppentreffen in München vor.

Den ISTQB Certified Tester Advanced Level (CT-AL) kann man – wie bisher auch – in drei Varianten ablegen: Test Analyst Test Manager und Technical Tester). Sie entsprechen inhaltlich in etwa der sich allmählich immer mehr herausbildenden fachlichen Differenzierung in Tester, Testmanager und Testautomatisierer in der Praxis.

Der offizielle Lehrplan für den CT-AL hat deutlich zugenommen. Umfasste er in der alten Fassung nur etwa 38 Seiten, so sind es jetzt 114. So wurde u.a. ein verstärkter Fokus auf Themen wie das Testen von Multisystemen (systems of systems) und sicherheitskritische Systeme gelegt. Relevante Normen und Standards wie z.B. IEEE 829 (Testdokumentation), IEEE 1028 (Review-Prozess), IEEE 1044 (Klassifizierung von Softwareanomalien) und ISO 9126 (Prüfkriterien für Software) werden dargestellt. (Projekt)managementwissen und konzeptionelles Know-how sind verstärkt Gegenstand der Zertifizierung.  Wichtige Dinge wie Testprozesse, Testmethoden, verteiltes Testen, Metriken zur Testerfolgsmessung, betriebswirtschaftliche Darstellung des Testnutzens, Testwerkzeuge und testrelevante allgemeine Methoden aus dem Qualitätsmanagement wurden inhaltlich aktualisiert.

Alle drei Varianten des Certified Tester wurden inhaltlich aufgewertet, Übungen und Praxisanteile bekamen im verpflichtenden Lehrplan mehr Gewicht. Für ihre Vermittlung und Zertifizierung kann  man mit etwa 5-6 Tagen Schulungszeit pro Variante rechnen.

Aktuell stellen alle Schulungsanbieter im Bereich der Testerqualifizierung auf das neuer Curriculum um oder haben das bereits getan. Spätestens zum Jahreswechsel wird dann nur noch nach den neuen erweiterten Anforderungen zertifiziert werden.

Wehrhafte Kängurus

Wenn man beim Testen von neuentwickelter Software zu sparsam vorgeht, können kuriose Dinge passieren, sobald man das Produkt dem Kunden vorführt. Dies ist folgender Geschichte zu entnehmen, die ich (in wechselnden Varianten) bereits mehrmals im Internet fand. Zuletzt in der XING-Gruppe „Qualitätsmanagement für Software-Projekte“.

Auch wenn es wohl eher eine kettenbriefartiger Hoax sein dürfte, ist sie doch ein gutes Beispiel wohin Mängel beim Thema Testen führen können…

Don’t mess with the Aussie wildlife

From a recent Defence Science Lectures Series, as related by the head of   the Australian DSTO’s Land Operations/Simulation division.

They’ve been working on some really nifty virtual reality simulators, the case in point being to incorporate Armed Reconnaissance Helicopters into exercises (from the data fusion point of view).  Most of the people they employ on this sort of thing are ex- (or future) computer game programmers.

Anyway, as part of the reality parameters, they include things like trees and animals.  And for the Australian simulation, they included some kangaroos. In particular, they had to model kangaroo movements and reactions to helicopters (since hordes of disturbed kangaroos might well give away a helicopter’s position).

Being good programmers, they just stole some code (which was originally used to model infantry detachments reactions under the same stimuli), and changed the mapped icon, the speed parameters, etc.  The first time they’ve gone to demonstrate this to some visiting Americans, the hotshot pilots have decided to get „down and dirty“ with the virtual kangaroos.  So, they buzz them, and watch them scatter.

The visiting Americans nod appreciatively … then gape as the kangaroos duck around a hill and launch about two dozen Stinger missiles at the hapless helicopter.

The programmers look rather embarrassed – they forgot to remove *that* part of infantry coding, didn’t they?  Nevertheless, the Americans leave muttering comments about „… don’t mess with the Aussie wildlife …“

Warum gutes Testmanagement immer wichtiger wird

Softwarequalität ist in vielen Softwarehäusern immer noch ein „ungeliebtes Kind“. Denn Softwarequalität kostet Geld und ist kompliziert. Man will im Grunde genommen das Geld für die benötige Spezialisten, Werkzeuge und Prozesse nicht ausgeben. Bisher ging es ja auch oft ohne. Oder man beschränkte sich auf die Umsetzung grundlegender Tests durch die Entwickler selbst.

Und tatsächlich befinden sich Softwarehäuser im Vergleich zur produzierenden Industrie in einer komfortablen Lage. Denn es gibt kaum verbindlich vorgeschriebene Gesetze und Normen zur Umsetzung qualitativer Standards. Autos, Maschinen, Medikamente usw. müssen bestimmte Zulassungsnormen erfüllen, bevor sie auf dem Markt angeboten werden dürfen. Die Einrichtungen und Prozesse zu ihrer Herstellung werden regelmäßig auditiert, geprüft und zertifiziert. In der Softwareentwicklung ist das heute noch eher die Ausnahme als die Regel.

Weil Softwarequalität eben Geld kostet und Spezialwissen erfordert, versuchen Unternehmen das Thema oftmals auszulagern, abzugeben, durch billige Kräfte (Praktikanten, Werkstudenten) abdecken zu lassen oder es ganz einzusparen. Das funktioniert vielleicht vorübergehend, wird sich aber schon mittelfristig negativ und kostentreibend bemerkbar machen. Werkstudenten und Praktikanten als billige operative Tester erfordern stringentes Testmanagement, da das fehlende Know-how durch bessere Prozesse und Tools zu ersetzen ist. Und das erfordert bessere Tools und systematische Testmanagement.

So entstanden in den letzten Jahren zum Teil große Beratungshäuser, die sich auf Probleme und Projekte rund ums entwicklerunabhängige Testen von Software spezialisiert haben. Um sie herum zahlreiche Mittelständler, die ebenfalls ihre Marktnische suchen. Sowie Prüfgesellschaften die Softwareprodukte sowie die Prozesse ihre Entstehung auf Normkonformität und Stabilität zertifizieren.

Externe Dienstleister für das Testen von Software erfordern jedoch wiederum interne Steuerung und Überwachung durch eigene Projekt- und Servicemanager. Zunehmende Compliance-Anforderungen (u.a. Risikobewertung, Safety-Anforderungen und revisionssicheres Testen von Anwendungen für die Finanz-, Luftfahrt- und Gesundheitsbranche) erfordern ebenfalls mittelfristig zunehmend qualifizierteres Testing der Softwareprodukte. Dabei sind neben nationalen Gesetzen zunehmend internationale Normen, Auflagen und technische Regulierungen zu berücksichtigen.

Darin kommt der Trend hin zur Industrialisierung der Softwareentwicklung zum Ausdruck. Microsoft setzt z.B. pro Entwickler in etwa einen Tester ein und hat umfangreiche Qualitätssicherungsprozesse implementiert. Auch gewinnen Vorgehens- und Reifegradmodelle sowie Standards zum Prozessmanagement zunehmen an Bedeutung in der Softwareentwicklung.

Das Kernproblem ist also ein fachlich und betriebswirtschaftlich effektives Softwarequalitätsmanagement. Und dort gibt es in vielen Firmen noch beträchtlichen Nachholbedarf.

So brachte es Rex Black, ehem. Präsident des International Software Testing Qualifications Board (ISTQB),  vor kurzem auf einer Branchenveranstaltung auf den Punkt: „Thanks to outsourcing / crowd-sourcing, we have hundreds of millions of entry-lebel testers available … Test managers who must use amateuer testers must put structure in place through good test processes  … The true test professional – experienced, seasoned, trained and certified – will remain like palladium: rare and precious … “.

(im Rest seines Vortrags gab er Testern Empfehlungen für ihre weitere Qualifizierung im Bezug auf absehbare Trends und Entwicklungen).

Gutes Testmanagement wird also wichtiger werden. Denn die zunehmende firmenübergreifende Zusammenarbeit mit internen und externen Spezialisten, die Anforderungen der Projektwirtschaft und der langsam aber sicher zunehmende Compliance-Druck sowie Qualitätsanforderungen von Kunden und Zertifizierern werden eine Professionalisierung vorantreiben. Und Investitionen in Softwarequalität erforderlich machen, um im Wettbewerb weiter bestehen zu können.

House of open Scrum 2009

Gestern habe ich an einer Vortragsveranstaltung zum Thema Scrum in Oberhaching teilgenommen. Scrum ist ein Vorgehensmodell für Softwareentwicklungsprojekte, das aus der Welt der agilen Methoden stammt. Scrum fördert die lokale Selbstorganisation von Entwicklerteams, indem es Konzepte aus dem Total-Quality-Management sowie dem Toyota-Produktionssystem auf die Softwareentwicklung überträgt.

Mehrere Referenten stellten Teilaspekte von Scrum sowie konkrete Anwendungen in der Praxis vor.

Andrea Tomasini erläuterte die wichtigsten Grundprinzipien von Scrum. Dazu zählen das Kontrollieren der arbeitslast und des Arbeitsflusses sowie die Vermeidung von Verschwendung (unnötige Entwicklung, Overengineering), das Fördern informeller Lernprozesse und der Austausch von Wissen, die schrittweise Verfeinerung von Produkten ebenso wie das häufige Bereitstellen von sauber durchgetesteten und dokumentierten Zwischenständen und Teilergebnissen.

Scrum bedeutet  im Prinzip, Entscheidungen soweit wie möglich auf die Entwicklerebene zu verlagern und Entwicklerteams lokale Selbstorganisation im Gegenzug für Ergebnisverantwortlichkeit zu ermöglichen. Während definierter Zeitfenster (Sprints) des konzentrierten Arbeitens am Produkt werden Anforderungen und Zielsetzungen stabil gehalten, während sie sich beim Wechsel von einem Sprint zum nächsten verändern dürfen. Auch Einmischungen und Störungen des Entwicklungsprozesses von außen werden so systematisch minimiert, um so Termintreue und Ergebnisqualität zu verbessern.

Christian Binder von Microsoft stellte die Prozessmodelle von Microsoft im Bereich der Entwicklung von Visual Studio vor und zeigte, wie man agiler Ansätze wie Scrum mit formalen Entwicklungsprozessen mit Tausenden von Beteiligten zusammenbringen kann. Interessant auch sein Hinweis auf die hohe Anzahl an Softwaretestern und Qualitätssicherern bei Microsoft. Auf jeden Entwickler kommt bei Microsoft ein Tester. Die Sicherheit und Qualität von Microsoft-Produkte soll als Konsequenz so mancher Kritik der letzten Jahre dauerhaft verbessert werden.

Jens Trompeter von itemis erklärte, wie man bei Festpreisprojekten zu guten Aufwandsabschätzungen kommt, in dem man die Beteiligten mit speziellen Spielkarten „Planning Poker“ spielen lässt. Das agiles Vorgehen in Softwareentwicklungprojekten nicht mit der Abwesenheit von Planung verwechselt werden darf. Und das es neben den „offiziellen“ Scrum-Rollen des Teams, des Scrum-Masters und des Product Owners auch die ebenso einflussreichen Rollen des Kunden, des (späteren) Nutzers der zu entwickelnden Software sowie des Managements gibt. Alle können sowohl zur Förderung als auch zur Behinderung des Projektfortschritts beitragen. Daher sieht das Scrum-Modell deren intensive Beteiligung am Projekt vor.

Susanne Mühlbauer von Hood zeigte, dass auch im iterativ vorgehenden Scrum-Modell ein systematisch betriebenes Anforderungsmanagement essentiell für gute Ergebnisse ist. Und wie es sich in die Teildisziplinen des Software-Engineerings mit einfügt.

Gerhard Müller und Martin Wagner vom Hauptsponsor TNG Technology Consulting stellten ihre Praxiserfahrungen mit Tools und Vorgehensweisen in Scrum-Projekten anschaulich zusammen und gaben Tipps zum Aufsetzen und Ausrüsten von Scrum-Projekten mit nützlicher Infrastruktur und Technik.

Mehrere Anbieter von Projektmanagement-Tools stellten vor, wie man mit Hilfe ihrer Produkte Scrum-Projekte einfach aufsetzen und managen kann. Zumindest was die administrativen Aspekte des Projektmanagements angeht, die man mit Tools gut handhaben kann.

Diese Management-Tools dürften dort, wo man sie einführt, auch das Interesse der Betriebsräte und Datenschutzbeauftragten (sofern vorhanden) wecken. Denn sie verarbeiten personenbezogene Daten und müssten deshalb Bestandteil des betrieblichen Verfahrensverzeichnisses werden. Und sie ermöglichen eine ins Detail gehende Leistungs- und Verhaltensüberwachung der in Scrum-Projekten Beschäftigten. Zum Teil ist das für die operative Kapazitätsplanung durch die Projektmanager zwar erforderlich. Aber die betriebliche Praxis zeigt leider auch, dass mit solchen Funktionen oftmals Missbrauch und Unsinn getrieben wird, falls man keine klaren Regelungen für ihre Nutzung trifft.

Alles in allem eine für mich sehr vielfältige und erkenntnisreiche Veranstaltung.

Durch Softwareprobleme mit Aids infiziert?

Der neu geschaffene Gesundheitsfonds ermöglicht es Ärzten durch Tricksen bei der sog. „Codierung“, d.h. beim Umsetzen einer medizinischen Diagnose in Abrechnungskennzahlen sich und den Krankenkassen Abrechnungsvorteile zu verschaffen. Darüber berichtet der Spiegel online und in der Printausgabe.

Die Recherchen für diesen Artikel brachte jedoch auch eine weitere Skurrilität zutage, wie Alexander Neubacher auf Spiegel online berichtet:

Einigen Kassen war auf ihrer Abrechnung mit dem Gesundheitsfonds aufgefallen, dass sich eine überraschend große Zahl ihrer Versicherten mit dem Aids-Virus HIV infiziert hatte.

Noch ungewöhnlicher war das Alter der Betroffenen. Fast alle Neuinfizierten waren deutlich älter als 65 Jahre. Sogar einige Greise von über 80 Jahren hatten sich noch mit dem Immunschwächevirus angesteckt, darunter auch die Mutter eines Krankenkassenmanagers. […]

Diskret angestellte Nachforschungen ergaben, dass sich die mysteriösen HIV-Fälle ausnahmslos auf Diagnosen von Augenärzten zurückführen ließen. Und noch ein weiteres Muster wurde deutlich. Alle Augenärzte benutzten auf ihren Computern die in der Branche weitverbreitete Praxis-Software der Firma Ifa Systems.

Das Programm aber produzierte einen fatalen Fehler: Gleichsam automatisch hängte es vielen Augenarztpatienten die Codierziffer „B23.8“ an. In der Geheimsprache des Gesundheitsfonds steht das Kürzel für „Sonstige näher bezeichnete Krankheitszustände infolge HIV-Krankheit“. Anschließend wurde diese Diagnose, ebenfalls vollautomatisch, an die Kassenärztlichen Vereinigungen übertragen. Dort wiederum reichte man den Code an das Bundesversicherungsamt und den Gesundheitsfonds weiter.

Der Hersteller der Software weist in einer Stellungnahme darauf hin, dass nicht die Software sondern Menschen Diagnosen erstellen. Menschen die auch fehlbar sind und in der Hektik des Praxisalltags einen falschen Zahlencode zuordnen. Folgt man dieser, so war wohl eine Kombination aus Anwenderfehlern und Probleme bei der Datenqualität der, auf internationalen ICD-Normen basierenden, Diagnosedatenbank der Software für die Zunahme der HIV-Rentner ursächlich.

Den Krankenkassen, die für jeden HIV-Patienten etwa 10.000 € extra aus dem Gesundheitsfonds erhalten, fiel die zunehmende Anzahl von augenärztlich behandelten Rentnern mit HIV-Diagnose erst nach einiger Zeit bei Revisionsprüfungen auf.

Zumal Rentner bislang eher weniger dafür bekannt waren, sich durch ausgiebigen Kontakt mit dem Fixer- und Strichermilieu einem höheren Ansteckungsrisiko mit Aids auszusetzen als der Durchschnitt der Kassenpatienten.

Es zeigt sich einmal mehr, wie wichtig es ist, sich bei der Entwicklung von Software auch hinreichend mit der Qualitätssicherung zu befassen. Denn nur weil ein Programm sich ohne Fehler compilieren lässt und anschließend über längere Zeiten absturzfrei arbeitet, ist das noch kein Beweis für dessen einwandfreies Funktionieren. Und oftmals sind Fehler und Probleme auf das Zusammenspiel des Systems Benutzer – Software – Daten zurückführbar, ohne das klar ersichtlich wäre, ob die Software, ihr Benutzer oder die Datenbestände letztlich ausschlaggebend für das Problem waren. Was insbesondere für die Wartung bereits länger bestehender Systeme und Datenbestände oftmals eine Herausforderung darstellt.

Coverity-Report: Open-Source-Software wird immer besser

Coverity, ein Anbieter von Werkzeugen zur Codeanalyse, gibt seit 2006 den „Coverity Scan Open Source Report“ (PDF, 2,8 MB) heraus, indem jährlich über die Entwicklung der Softwarequalität von quelloffener Software berichtet wird.

Die Ergebnisse basieren auf einer über drei Jahre gehenden Analyse von 60 Millionen Zeilen Code aus 280 Open-Source-Projekten, darunter Firefox, Linux, PHP, Ruby und Samba. Sie basieren auf Coveritys Scan-Service den die Firma OS-Entwicklern In Kooperation mit der Stanford University und in Zusammenarbeit mit dem US Department of Homeland Security kostenfrei anbietet. Ziel ist es, die Qualität von quelloffener Software grundsätzlich durch formalisierte Qualitätssicherung anzuheben. Nicht zuletzt deshalb, weil die US-Behörde in ihrer National Cyberspace Strategy (PDF, 0,5 MB) u.a. die Ziele der Aufdeckung vorhandener Qualitätsmängel und Sicherheitslücken in verbreiteten Softwaresystemen sowie die Entwicklung von Systemen mit einer geringerer Anzahl an Mängeln verfolgt.

So kam Coverity für 2008/09 zu dem Ergebnis, dass die Integrität, Qualität und Sicherheit von quelloffenem Code weiter zunimmt. Man fand seit 2006 mehr als 11.200 Fehler, die der Scan-Service in 180 zur Prüfung eingereichten Programmen entdeckt hat und die daraufhin beseitigt werden konnten. Insgesamt sieht die Firma einen Rückgang von 16 Prozent der in statischen Analysen festgestellten Fehler.

Coverity legt seiner Prüfung ein eigenes Reifegradmodell zugrunde, anhand dessen es geprüfte Software klassifiziert und zertifiziert. 144 Projekte laufen zurzeit in der ersten Stufe, 36 in der zweiten. Auf der höchsten Stufe finden sich derzeit vier OS-Projekte, darunter die Programmiersprache Ruby, der Samba-Server und das TOR-Netzwerk.

Insgesamt könne ein kontinuierlich steigendes Qualitäts- und Sicherheitsniveau im Bereich der Open-Source-Software festgestellt werden, so die Softwareprüfer. Die Entwickler in den OS-Ptrojeten treiben das Thema Softwarequalität aktiv voran. Die am häufigsten auftretenden Fehler der teilnehmenden Projekte waren über die Jahre hinweg NULL-Pointer-Variablen, Ressourcenlöcher und unabsichtlich nicht beachtete Expressions. Etliche OS-Projekte erreichten bereits den Status „defect-free“, d.h. man fand gar keine Fehler mehr.

Daneben bietet Coverity auch eine auf den Qualitätsprüfungen basierende Architekturbibliothek an, in der Architekturdaten von Anwendungen sowie Diagramme zu über 2500 Open-Source-Projekten frei zugänglich hinterlegt sind. Die Architektur-Bibliothek soll Entwicklern zugutekommen, die quelloffene Software in ihre eigenen Applikationen integrieren wollen und dazu die Architektur bekannter Projekte studieren möchten, um ein tieferes Verständnis der Struktur und zu den Fähigkeiten der Software zu erhalten. Sie kann ebenso bei Sicherheits- und Qualitätsaudits als Referenz herangezogen werden. Die Informationen werden unter einer Creative-Commons-Lizenz (CC-BY) bereitgestellt.

Microsoft stellt Prüftools für Security-Tester bereit

Microsoft ist bereits seit längerem bestrebt, sich bzgl. Sicherheit und Softwarequalität seiner Produkte als führend zu positionieren. Daher hat die Firma u.a. das Vorgehensmodell des „Security Development Lifecycle (SDL)“ entwickelt, um Entwicklern bei der weiteren Verbesserung der Qualität sicherheitsbezogener Eigenschaften ihrer Software für die Windows-Plattform zu unterstützen.

Der Microsoft Bin Scope Binary Analyzer überprüft binären Code darauf, ob alle empfohlenen und notwendigen Security Flags, Schutzmechanismen und Kontrollen vorhanden sind. Das stellt sicher, dass in Anwendungen nicht durch gängige Sicherheitsfehler beim Coding Schwachstellen und Sicherheitslücken implementiert werden.

Der Microsoft MiniFuzz File Fuzzer ist eine Lösung für Tester, die unerwartete Verhaltensweisen ihrer Anwendungen eingrenzen wollen. Der Fuzzer automatisiert Sicherheitsüberprüfungen und testet den Code mit zufällig erzeugten Eingabedaten um das Verhalten der Applikation bei deren Verarbeitung zu prüfen. Auf diesem Wege wird bereits sehr früh im Entwicklungsprozess festgestellt, ob etwa Programmabstürze als Sicherheitsrisiken untersucht werden müssen.

„SDL hat sich seit seiner Einführung als effizienter Prozess zur Steigerung der Softwarequalität bewährt“, so Prof. Dr. Sachar Paulus, Vorstandsvorsitzender der ISSECO (International Secure Software Engineering Council e.V.). „Dank der guten Methodologie und einfachen Umsetzbarkeit hat sich SDL mittlerweile bei vielen Entwicklern etabliert. Die beiden neuen Tools sind weitere Bausteine hin zu einer besseren, sichereren Softwareentwicklung“.

Hinzu kommen weitere Hilfen für Entwickler wie z.B. das SDL Process Template für Visual Studio Team System, das SDL Threat Modeling Tool, FxCop (ein Tool zur Analyse von.NET-Assemblies) sowie einige weitere Werkzeuge für die statische Codeanalyse mit Microsoft-Entwicklungsumgebungen.

Alle Tools können bei Microsoft im SDL Tools Repository kostenlos heruntergeladen werden.

Der Security Development Lifecycle ist ein Kernelement der Trustworthy Computing Initiative von Microsoft zur Verbesserung der Sicherheitseigenschaften seiner Produkte. Der Prozess wurde zunächst geschaffen, um firmenintern sichere Anwendungen zu liefern und Attacken besser widerstehen zu können. Jedes Produkt von Microsoft, das mit dem Internet kommuniziert oder für den Unternehmenseinsatz konzipiert ist, muss Angaben von Microsoft gemäß den SDL-Prozess durchlaufen.

Tom Köhler, Direktor Strategie Informationssicherheit Kommunikation bei Microsoft Deutschland hierzu: „Wir schützen damit unsere Plattform. Dazu gehört nicht nur, dass wir unsere eigenen Betriebssysteme und Anwendungen immer sicherer machen, sondern auch Partner und andere Anbieter dabei unterstützen. Gerade Anwendungen von Drittanbietern stehen immer mehr im Zentrum der Attacken durch Schadsoftware. Jeder Entwickler, ob Freiberufler, Microsoft Partner oder Firmenentwickler muss bereits im Designprozess darauf achten, dass seine Anwendungen in der Praxis sicher funktionieren. SDL hilft dabei“.

Kein Zweifel – der Security Development Lifecycle Prozess dürfte für Entwickler auf der Windows-Plattform zunehmend an Bedeutung gewinnen.