Wie man Code-Qualität messbar und prüfbar macht

Wenn Software neu entwickelt wird, ist sie „nach Aktenlage“, d.h. aus der Perspektive der Architekturentwürfe und der modellierten Konzepte oftmals qualitativ (noch) einwandfrei. Die Probleme beginnen meist erst auf der Detailebene, wenn sie implementiert wird. Wenn die abstrakten Architekturentwürfe und Datenmodelle in konkreten Code umgewandelt werden.  Da wird dann schon mal aus den unterschiedlichsten Gründen „von der reinen Lehre“ der modellierten Sachverhalte abgewichen. Was dann zahlreiche Probleme mit der Qualität zur Folge haben kann, die es nach Aktenlage gar nicht geben dürfte. Dadurch erhöht sich später auch der Aufwand für Pflege und Wartung der Software erheblich, denn kaum jemand kann den nun unverständlich gewordenen und von der Spezifikation abweichenden Code noch nachvollziehen.

Aus diesem Grunde gibt es in der produzierenden Industrie zahlreiche Kontrollmöglichkeiten, um über einstellbare Parameter nachvollziehen zu können, ob das, was vom Band läuft oder sich durch die Produktionsstraße bewegt, den Spezifikationen der Prototypen und Datenmodellen für die Fertigungsanlagen entspricht.

Solch ein Instrument hat die Firma hello2morrow nun auch für die Softwareentwicklung geschaffen. Mit ihren Werkzeug „Sonar J“ lässt sich für Java-basierte Entwicklungsprojekte prüfen, ob und in wie weit der Code von der Architektur abweicht.

„Wer die Softwarequalität kontinuierlich misst, kann seine Produktivität um etwa 20 Prozent steigern“, so Alexander von Zitzewitz, Managing Director bei hellow2morrow in einem Interview mit heise developer. Denn die Realität ist die, dass sich während der Programmierung Architektur und Software im Laufe eines Projekts immer weiter voneinander entfernen. Die Software erfüllt zwar die technischen und funktionalen Anforderungen. Ihr Inneres ist aber nicht mehr nachvollziehbar strukturiert, so dass sie nur noch schwer zu warten oder zu erweitern ist. Von einer Wiederverwendbarkeit ganz zu schweigen. Von Zitzewitz nennt dieses Phänomen „Erosion der Architektur“.

Mit Hilfe von Sonar J können Entwickler nun die Architekturvorgaben in der Entwicklungsumgebung hinterlegen und beim Codieren sehen, ob und wo ihr Code davon abweicht. Wer Entwicklungsaufgaben an Dritte auslagert, kann mit Hilfe des Programms basierend auf statischen Codeanalysen prüfen, ob die von ihm gemachten strukturellen Qualitätsvorgaben und Coding-Richtlinien eingehalten wurden. Sonar J visualisiert die innere Struktur und wertet die Softwaremetriken aus. Den Entwicklern geht so im Rahmen der Industrialisierung der Softwareentwicklung erneut ein weiteres Stückchen Freiheit verloren. Dafür aber wird die Umsetzung konzeptioneller Überlegungen im Projekt prüfbar und nachvollziehbar.

Auf Heise Developer findet sich ein ausführlicher Artikel über Sonar J. Das Tool ist als Plugin für Eclipse sowie als eigenständiges Programm erhältlich und kann von Hobbyisten und Kleinprojekte-Entwicklern (bis ca. 20.000 Codezeilen) sogar kostenlos genutzt werden. Zudem werden von hello2morrow ähnliche Produkte auch für ABAP/ABAPObjects, C/C++ oder C#-basierte Entwicklungsprojekte angeboten.

Die Vision von sicherer, verlässlicher Software

Erst kürzlich wurde zehntausenden Nutzern von EC-Karten mal wieder bewusst gemacht, was es bedeuten kann, wenn Software gravierende Fehler aufweist und nicht richtig funktioniert. Dabei sind die Programme auf den EC-Kartenchips, die zu Jahresbeginn zu massiven Problemen im Zahlungsverkehr führten, noch recht überschaubar, wie Informatiker Prof. Holger Hermanns von der Uni Saarbrücken befindet: „Zu Recht ärgerten sich Millionen Bankkunden über die stümperhafte Software auf ihren Kreditkarten. Offensichtlich ist das passiert, was viele bereits zur Jahrtausendwende 1999 auf 2000 befürchtet hatten: ein Software-Crash!“. Zwar sind Fehler in komplexen Softwaresystemen  leider immer möglich. Jedoch erklärte der Experte für verlässliche Systeme und Software, in einem Interview mit Heute.de: „In dem konkreten Fall der EC-Karten wäre dieser Fehler aber durchaus vermeidbar gewesen. Denn die Programme auf den Kartenchips sind so klein und übersichtlich, da muss das nicht sein.“

Tatsächlich beschäftigen sich Informatiker seit Jahrzehnten damit, formale Methoden zu entwickeln, mit deren Hilfe sich die Korrektheit von Software nicht nur testen und prüfen sondern mathematisch beweisen lässt. Jedoch funktioniert das bislang nur für Programme von überschaubarem Umfang und Komplexität. Daher forscht man an der Uni Saarbrücken im Rahmen des Projekt AVACS (Automatic analysis and verification of complex systems) damit, Methoden zu entwickeln, um insbesondere komplexe softwarebasierte Systeme wie Fahrzeuge und medizinische Großgeräte aber auch kritische Infrastrukturen wie Kraftwerke und Verkehrstechnik ausfallsicherer zu machen. Denn während die streikende EC-Karte nur lästig ist, kann ein Absturz des Bordcomputers im ICE rasch lebensgefährlich werden.

Doch viele Qualitätsprobleme sind hausgemacht und daher mit technischen Lösungen nicht zu beseitigen. Prof Hermanns hierzu: „Leider gibt für Computerprogramme bisher noch kein Qualitätssiegel und Programme werden häufig unter Zeitdruck geschrieben.“

„Damit Denk- oder Schreibfehler in einer Software nicht zu unerwarteten Pannen oder gar Katastrophen führen müssen Unternehmen in die Aus-, Fort und Weiterbildung ihrer Mitarbeiter investieren. Pannen passieren immer wieder, weil unter Zeitdruck gearbeitet wird und zu wenig Qualitätskontrollen durchgeführt werden. Leider werden aus Kostengründen zu viele mäßig ausgebildete Fachinformatiker und Programmierer eingestellt. Die Guten sind oftmals zu teuer oder nicht mehr auf dem Markt.“

Es ist also wie auch in anderen Bereichen der Wirtschaft das alte Problem. Qualität kostet Geld und Kunden sind nicht bereit für Qualität extra zu bezahlen, da sie es aus anderen Lebensbereichen gewohnt sind, dass auch ein preiswertes Produkt einwandfrei zu funktionieren hat. Was allerdings häufig eher hoher Regulierungsdichte (Produkthaftung, Zulassungsbedingungen, verbindlicher qualitativer „Stand der Technik“, kein völlig freier Markzugang für jeden …) zu verdanken ist.

Wenn die Kreditkarte streikt – Softwaredefekt legt Kartenzahlung lahm

Als Anbieter von Softwareprodukten an deren Qualität von zu sparen kann richtig teuer, zum Teil sogar existenzgefährdend werden. Diese Erfahrung macht derzeit die Firma Gemalto, die sich selbst bescheiden als „Weltmarktführer in digitaler Sicherheit“ bezeichnet. Sie hatte für deutsche Banken und Sparkassen Millionen EC- und Kreditkarten produziert, die in den ersten Tagen des neuen Jahres den Dienst einstellten und nicht mehr zum Bezahlen oder Geldabheben benutzt werden konnten.

Doch was war geschehen?

Die mit einem programmierten Chip versehenden Karten hatten ein Datumsproblem. Sie konnten das Jahr 2010 nicht korrekt verarbeiten und blockierten daher bei der Kartennutzung die Auszahlung von Geld.

Die neuen, goldfarbenen EMV-Chips (Europay, MasterCard und VISA) sind gut auf der Vorderseite der Karten zu erkennen. Sie speichern und verarbeiten Daten, die vom Lesegerät an die Karte übergeben werden. Die Chips basieren auf dem noch relativ neuen EMV-Standard, sollen Kartenfälschung und Betrug deutlich erschweren und so bargeldloses Bezahlen sicherer machen, als der zuvor eingesetzte passive Magnetstreifen.

Doch die in ihnen hardcodierte und daher nicht mehr nachträglich änderbare Software hatte wohl (mindestens) einen gravierenden Bug, der erst beim Einsatz durch den Kunden auffiel. Gemalto übernahm bereits nach kurzem die Verantwortung und arbeitet seitdem eng mit den Banken zusammen, um das Problem in den Griff zu bekommen. Als ersten Workaround wurden Bankautomaten umprogrammiert, so dass sie den Kartenchip ignorieren und sich rein an den Daten auf dem Magnetstreifen orientieren. Einzelhändler begannen bei defekten Karten den Chip per Klebestreifen zu überkleben, so dass ihre Kassenterminals stattdessen auch wieder den Magnetstreifen verarbeiten. Was natürlich den Sicherheitsgewinn durch die EMV-Technologie wieder aufgibt.

Doch das sind nur Workarounds, um Zeit für eine grundsätzliche Lösung zu gewinnen. Inzwischen scheint es wohl darauf hinauszulaufen, dass nahezu alle Karten mit Chip ausgetauscht werden müssen. Bei geschätzten 5 – 10 € Transaktionskosten pro Kartentausch und einer zweistelligen Millionenzahl an betroffenen Karten eine teure und zeitaufwendige Angelegenheit. Zumal die Geldinstitute zunehmend unter öffentlichen Druck von Politik, Verbraucherschützern und des Einzelhandels geraten, den die hohen Gebühren für die Zahlungsabwicklung schon länger verärgern.

Für den Fachmann zeigen sich gleich zwei Problemfelder der Softwarequalität in diesem Fall. Offenbar hat man bei Gemalto die Kartensoftware nicht hinreichend genau getestet, bevor sie für den Rollout freigegeben und in die Chips hart eincodiert wurde. Obwohl Software im Finanzbereich aufgrund des höheren Regulierungsniveaus und etlicher Branchenstandards im Allgemeinen umfangreicher getestet wird. Und die Nutzung in Form hardcodierter Bauteile, in die kein Patch und kein neues Release eingespielt werden kann, deutlich höhere Qualitätsanforderungen an die Entwicklungsprozesse stellt.

Was genau und aus welchem Grund bei Gemalto schiefgelaufen ist, dürfte allerdings noch länger im Unklaren bleiben. Im Gegensatz zum Jahrtausendwechsel, der insbesondere älteren Programmen Probleme bereitete, sollte das Jahr 2010 für Computerprogramme jedoch keine besondere Herausforderung sein. Insbesondere, wenn sie neu entwickelt wurden.

Andererseits können gerade bei der Wieder- und Weiterverwendung von Codeteilen sowie bei der Nutzung von Frameworks und Bibliotheken darin enthaltene und bislang unentdeckte Fehler über lange Zeit und in zahlreiche Anwendungen weitergetragen werden, bis sich die Umstände ergeben, unter denen der Fehler zum Problem wird. Daher sollten insbesondere solche wiederverwendeten Codeteile und Bibliotheken mehrfach, gründlich und von verschiedenen Instanzen auf Qualitätsprobleme untersucht werden.

Doch auch die abnehmenden Kreditinstitute haben offenbar bei den Abnahmetests für die neue Kartengeneration entweder komplett auf den Lieferanten vertraut oder zumindest nicht hinreichend genau getestet. Gerade Datumsangaben sind häufig Gegenstand von Fehlern (und daher auch von Testfällen), da es sehr viele mögliche Formate für sie gibt. Und man mit dem Datum auch rechnen, vergleichen, es als Bedingung für Entscheidungen verwenden, es numerisch oder alphanumerisch darstellen und noch vieles mehr machen kann.

So oder so – es zeigt sich einmal mehr, dass eine Art Produkthaftung auch im Softwaresektor unumgänglich ist, um Qualitätskosten als Notwendigkeit der Entwicklung und Produktion anstatt als lästiger, unnötiger und gern mal „wegoptimierter“ Kostenfaktor zu sehen. Wie auch in anderen Bereichen der Wirtschaft, reagieren Unternehmen oftmals leider nur auf Druck, drohende Wettbewerbsnachteile und harte (managerhaftungsrelevante) Regulierung.

Vom Qualitätsverständnis in der Softwarebranche

So langsam macht sich in softwareentwickelnden Unternehmen die Erkenntnis breit, das Qualität nicht von selbst entsteht, sondern durch systematisches Planen, Implementieren und Testen erreicht wird. Doch Qualität kostet Geld. Testteams oder gar Testcenter benötigen ein entsprechend großes Budget im Projektetat. Von Testern initiierte Anfragen und Klärungen halten Entwickler vom Programmieren ab. Bleiben Tests im Zeitplan unberücksichtigt oder kommt es durch hohe Fehlerzahlen zu Verzögerungen, kann die Qualitätssicherung die pünktliche Ablieferung des Produktes beeinträchtigen. Nicht zuletzt orientieren sich Kunden bei Ausschreibungen auch gern am billigsten Angebot.

Das bringt softwareentwickelnde Unternehmen in eine Lage, welche die fertigende Industrie vor etwa 25 Jahren durchlief, als sich unter dem Oberbegriff „Total Quality Management“ japanische Managementansätze weltweit als Standards beim Qualitätsmanagement etablierten.

Es läge also nahe, das Thema Qualität auch in der Softwareentwicklung steuerbar zu machen, indem man ein systematisches QM einführt und sich dabei an etablierten Standards orientiert. Dafür würde auch der bereits seit Jahren zu beobachtende Trend sprechen, Softwareentwicklung soweit wie möglich zu industrialisieren, d.h. am Prozessverständnis fertigender Unternehmen auszurichten.

Thorsten Zimmermann hierzu in der Beraterzeitung:

Die Einführung eines QM-Systems ist grundsätzlich ein nicht zu unterschätzender Kostenfaktor. In der Regel sind bei einer System-Einführung alle Prozesse des Unternehmens betroffen, welche es gilt auf die hohen Anforderungen hin anzupassen. Auch Test-Systeme werden in Bezug auf deren tatsächlichen Anschaffungs- und vor allem Unterhaltskosten – ungeachtet der Branche – zu gering abgeschätzt. Dies gilt auch für die Software-Industrie. Die Tatsache, dass es sich hierbei um immaterielle Güter handelt, führt leider nicht zu günstigeren Einführungskosten für Qualitätsprozesse in dieser Branche im Vergleich zum klassischen, produzierenden Gewerbe.

Bei der Etablierung eines QM in der Softwareentwicklung bieten sich grundsätzlich zwei Alternativen an:

1. Man lässt das Testen fast komplett sein und investiert das Projektbudget weitgehend in die eigentliche Entwicklung der projektierten Software. Lediglich zum Schluss wird eine Qualitätsendkontrolle zur Vorbereitung der Abnahme des Produktes durch den Kunden eingeplant.
2. Man plant das Testen anhand eines QM-Konzeptes und sieht es als gleichwertigen, fest in den Entwicklungsprozess integrierten Arbeitsschritt. In jeder Projektphase werden zeitnahe Tests auf allen Abstraktionsebenen (Bsp.: Module, Schnittstellen, Systeme, Geschäftsprozesse) durchgeführt. Das Projektbudget verteilt sich annähernd zu gleichen Teilen auf Kosten für Entwicklung und Test.

Inzwischen werden von Markt- und Trendforschern im IT-Business immer häufiger Studien zu den Folgekosten mangelhafter Qualitätssicherung bei der Softwareentwicklung publiziert. Ihre Quintessenz läuft stets auf ähnliche Ergebnisse hinaus: Wer bei der entwicklungsbegleitenden Qualitätssicherung spart, zahl später drauf. Allerdings sind diese „Draufzahlkosten“ nicht immer leicht erkennbar und kalkulierbar. Sie können in „field defects“, also erst im Produktiveinsatz der Software bei Kunden entdeckten Mängeln bestehen, die nachgebessert werden müssen (Aufwände und Kosten außerhalb des ursprünglichen Projetetats). Aber auch in schwer bewertbaren Reputationsverlusten und fehlendem Auftragseingang, weil im Bereich Qualität besser aufgestellte Konkurrenten sich und ihre Produkte zunehmend am Markt durchsetzen können.

Für das Software entwickelnde Unternehmen stellt sich daher die Frage danach, ob man das Thema Softwaretest komplett selbst stemmen will, auch wenn das bedeuten kann, das man – wie es z.B. Microsoft tut – für jeden Entwickler im Prinzip auch einen Tester einstellt. Oder ob man Teile der Qualitätssicherung an Testing-Dienstleister auslagert. Zumal inzwischen auch das Testen von Software sich zu einer Profession mit spezialisiertem Know-how sowie eigenen Standards und Qualifizierungsnachweisen entwickelt hat.

Hierzu nochmal Thorsten Zimmermann in einer Prognose:

Auch in Zukunft entscheidet Software und dessen Qualität über den wirtschaftlichen Erfolg eines Unternehmens. Firmen mit guten eingeführten Prozessen und Strukturen zur Sicherung der Softwarequalität werden Ihre Marktposition behaupten und erfolgreich ausbauen können. Hierzu verspricht das automatische Analysieren und Testen von Code einen wichtigen Beitrag zu leisten, um Software erfolgreicher und besser gesteuert zu implementieren. […]

Gerade unter den Gesichtspunkten weiterer Spezialisierungen, Kostendruck und Verdrängungswettbewerb sehen Experten bei externen Dienstleistungen und Offshore eine Bedarfszunahme. So teilen im Schnitt 34 Prozent der Unternehmen die Absicht in Zukunft mehr für externe Dienstleister auszugeben. Vor allem 60% der befragten Firmen in Schweden, Dänemark, Großbritannien, Irland und Südafrika wollen zukünftig Offshore-Projekte im Rahmen ihrer Entwicklungen – zum Beispiel im Softwaretest – verstärkt einsetzen. Deutschland, Österreich und Schweiz bilden mit nur 21 Prozent Zustimmung das andere Ende der Bandbreite im internationalen Vergleich.[…]

Auch die deutsche Softwareindustrie sieht im Bereich Qualitäts-Management für sich Verbesserungspotentiale und beschäftigt sich mit dem Thema Softwarequalität. Sie will dem transzendenten Ansatz ein Ende bereiten, nach dem Qualität eine immanente Güte ist – erkennbar, aber nicht definierbar.

In diese Richtung zeigen auch Projekte wie QuaMoCo, welches ein Gütesiegel für Programmierarbeit „Made in Germany“ am Markt etablieren will, Ansätze wie „Clean Code Development“ und „Security by Design“ sowie die zunehmende Integration von Testing-Tools in Entwicklungsumgebungen wie Microsofts Visual Studio oder das offene Eclipse-System.

Vom Widerstand gegen das Testen

Unternehmen, die greifbare Produkte wie Autos, Lebensmittel oder Maschinen herstellen haben praktisch alle eine fest in den Produktionsprozess eingebaute Qualitätssicherung. Es wäre schon produkthaftungsrechtlich zu riskant, darauf zu verzichten. Auch sorgen kaufmännische Sorgfaltspflichten, wie sie z.B. in § 93 AktG oder § 43 GmbHG normiert sind, dafür, dass Geschäftsführer für fahrlässig eingegangene Risiken bei der Qualität auch persönlich in Regress genommen werden können. Und in stark regulierten Branchen wie der Luftfahrt, dem Gesundheitswesen oder dem Bau von militärisch nutzbaren Gütern werden schon aus Safety-Überlegungen heraus viele Fragen der Qualitätssicherung sehr detailliert in entsprechenden Gesetzen, Normen und Standards geregelt. Was den interpretativen Spielraum operativer Entscheidungsträger deutlich einschränkt.

Speziell im Softwaresektor gibt es dieses hohe Niveau an Qualitätssicherung oftmals nicht. Dort bilden im Konfliktfall letztlich meist nur BGB-Verträge und auslegbare Anforderungsspezifikationen die Grundlage auf der QM-Entscheidungen begründet und gerechtfertigt werden können. Doch hier gilt oftmals „Wenn du einen Vertrag nicht brechen kannst, interpretiere ihn“ (Ferengi-Erwerbsregel Nr. 5), weshalb IT-Projektleiter gut beraten sind, sich qualifiziert im Vertragsrecht auszukennen.

Denn oftmals werden notwendige Tests zur Qualitätssicherung von Softwareprodukten entweder als lästiger Kostenfaktor gesehen, den es wegzuoptimieren gilt. Oder sie sind die Zeitspardose, an die man rangeht, wenn es eng wird mit der Deadline.

So kommen auch relativ hartnäckige Vorurteile wie diese gegen das Testen zustande:

• „Neue Mitarbeiter kommen bei uns erst mal in den Test, damit sie das System kennenlernen. Eine spezielle Ausbildung ist nicht notwendig.“
• „Mit der Testvorbereitung können wir jetzt noch nicht beginnen. Sonst müssen wir die Testfälle noch oft ändern!“
• „Das Angebot ist gut, aber zu teuer! Hmm, wo kann ich am einfachsten sparen? Im Test! 10% weniger Testaufwand = 10% weniger Kosten!“

Die dann entsprechend höheren Kosten der Fehlerbehebung in späteren Projektphasen oder bei Kundenreklamationen nach den Go-Live werden verdrängt. Es regiert das Floriansprinzip: „Nach mir die Sintflut!“.

Manchmal sind es auch die Entwickler, die dem Testen ihrer Software skeptisch gegenüberstehen. Testen ist einerseits bei vielen Entwicklern ähnlich beliebt wie Dokumentieren oder das Einhalten von Code-Style-Richtlinien. Es andererseits aber an Dritte abzugeben (Tester oder Testing-Dienstleister) wird auch skeptisch gesehen. Da greifen dann Bedenken und Ängste, die Tester könnten die Qualität der Arbeit der Entwickler in Frage stellen und so deren Ruf schaden, wenn sie Fehler finden. Oder Fehler könnten von Führungskräften zum Gegenstand von schlechten Beurteilungen gemacht werden. Zumal es kein objektives Maß dafür gibt, wie viele Fehler innerhalb eines Projektes „normal“ sind. Das Fehler bei der Konzeption und Implementierung komplexer technischer Produkte aber zur Tagesordnung gehören und man daher Strukturen zum Umgang damit braucht, lernen Ingenieure und Informatiker bereits in den ersten Semestern.

Zumal sich die Arbeit der Tester aus Entwicklersicht auch kreativ umdeuten lässt: Testen durch professionelle Tester schafft Freiräume für die Entwickler, welche diese dazu nutzen können, sich auf die kreativen, innovativen und herausfordernden Aspekte der Software-Entwicklung zu konzentrieren. Gefundene Fehler halten die Entwickler auf dem richtigen Kurs, ohne dass sie sich (bis auf die Beseitigung der Fehler) weiter darum kümmern müssten. Die Tester arbeiten letztlich auch für die Entwickler, da alle Projektbeteiligten von der Ablieferung qualitativ hochwertiger, betriebssicherer und attraktiver Produkte profitieren. Meist in Form sicherer Arbeitsplätze, Folgeaufträgen und Erfolgsbeteiligungen.

Oft gilt es auch Endnutzer in das Entwicklungs- und Testgeschehen  mit einzubeziehen. Insbesondere bei der Anwendung agiler Entwicklungsansätze ist ein schrittweises Vorgehen bei der Software-Entwicklung in Verbindung mit enger Zusammenarbeit mit Vertretern der späteren Anwender fester Bestandteil jedes Softwareprojektes. Das muss den Beteiligten von Anfang an klar sein. Gerade für Anwender gilt daher: Testen ist neben der Analyse das unverzichtbare zweite Standbein zur Sicherstellung der fachlichen Anforderungen im Prozess der Produktentstehung. Zumal so gut wie niemand sonst in der Kundenorganisation das Produkt so gut kennen wird, wie die an der Entwicklung beteiligten Testanwender und späteren Key-User.

Das bedeutet für den Projektmanager, das ihm eventuell eine zweite Managementaufgabe zuwächst: die des Testmanagements. Hier gilt es zu entscheiden, in wie weit er das selbst abdecken kann bzw. wann und wo er Unterstützung durch einen Test-Manager benötigt. Testmanager können umfangreichere Tests meisten effektiver planen und effizienter abwickeln, da sie mit dem Know-how, den Methoden und Instrumenten der Softwarequalitätssicherung vertrauter sind.

Alle Beteiligten am Entwicklungsprojekt werden sich daher vergegenwärtigen müssen:

• Ohne Testen gibt es keine qualitativen Projektziele (weder definiert, noch erreicht).
  Falls die impliziten Qualitätsziele nicht trivial sind, gibt es ohne Testen keinen nachweisbaren Projekterfolg.
  Testen (und alle anderen Projekt-Tätigkeiten) enden, wenn das Projektziel erreicht ist oder das Projekt beendet wird.

Softwarequalität – wenn die Software „ergrünt“

Softwarequalität ist ein komplexer Begriff. Im Allgemeinen ist Software von guter Qualität, wenn sie fehlerfrei läuft und tut, was sie soll. Tatsächlich steckt weit mehr in dem Begriff. So legt die einschlägige ISO-Norm 9216 dafür maßgebliche Bestandteile wie Funktionalität, Verlässlichkeit, Gebrauchstauglichkeit, Effizienz, Wartbarkeit und Portierbarkeit  fest, die nach den Vorgaben der DIN 12119 (Qualitätsanforderungen und Prüfbestimmungen für Software) bzw. ISO 25051 (Software Product Quality Requirements and Evaluation) auch formal geprüft und zertifiziert werden können.

Angesichts der Diskussion um Klimawandel und Kosteneinsparpotentiale in den Unternehmen wird zunehmend der Effizienz, genauer der Ökoeffizienz der Software Aufmerksamkeit geschenkt. Denn unter dem noch relativ neuen Schlagwort „Green IT“ geht es vor allem darum Informationstechnik so zu gestalten, dass sie effizienter arbeitet und mit weniger Ressourcen auskommt. Dazu zählt im weiteren Sinne nicht nur die Energie für Server im Rechenzentrum oder die bessere Auslastung physischer Server durch Virtualisierung sondern auch die bezahlte Arbeitszeit von Anwendern, deren unnötiger Verbrauch durch Schulungen sowie benutzerfreundlich und aufgabengerecht gestalteter Software deutlich reduziert werden kann. Auch Personalentwicklung kann also „grün“ sein.

Software kann so gestaltet werden, dass sie weniger Strom verbraucht und schneller läuft. So soll Windows 7 nach Angaben von Microsoft etwa 10-20% weniger Energie verbrauchen als sein Vorgänger Vista. Was im Falle des Zutreffens insbesondere Laptop-Nutzer freuen dürfte, deren Akkus dann etwas länger durchhalten. Dass sich an der Performance von Software z.B. durch Optimierung von Datenbankabfragen oder Zugriffen auf Speichermedien etwas tun lässt, ist fast schon Entwicklerallgemeinwissen, gewinnt aber unter dem Aspekt „grüner“ Qualitätsanforderungen neu an Bedeutung.

Daniel Koch hierzu in einem Fachartikel auf Heise Developer:

Softwareentwickler werden sich in naher Zukunft immer mehr die Frage stellen, wie sich „Grüne Software“ entwickeln lässt. Denn immer mehr Kunden werden – allein schon aus Kostengründen – auf energiesparende Applikationen setzen. Entwickler müssen zunächst einmal nicht unbedingt neue Wege einschlagen. Vielmehr gilt es, sich auf eines der Hauptziele der Softwareentwicklung zu konzentrieren: Am Ende sollte ein anwenderfreundliches Produkt entstehen. Daran hapert es aber oftmals. Stattdessen kommt Software auf den Markt, die für normale Anwender wenig intuitiv ist und sich nur schwer bedienen lässt. Das führt in Unternehmen dazu, dass regelmäßig Schulungen nötig werden. Diese sind es wiederum, die einen erhöhten Energieaufwand bedeuten. Hält man sich vor Augen, dass durch gute Software der Schulungsaufwand von drei auf einen Tag reduziert werden könnte, hieße das für die Unternehmen eine Einsparung von Energie und Arbeitszeit um zwei Drittel.

Auch Kleinigkeiten wie etwa die Druckoptimierung von Webseiten durch entsprechende Webstandards wie Druck-Stylesheets können zur Ökoeffizienz der Informationstechnik etwas beitragen.

Zur Förderung solcher Zielsetzungen gründete sich kürzlich die unter Federführung der KATE-Kontaktstelle für Umwelt und Entwicklung, dem Forschungszentrum Informatik Karlsruhe und der Karlsruhe Technology Consulting GmbH die Green Software Community. Dort will man sich mit Ideen zum Öko-Management in der IT beschäftigen. Konkreter also mit Dingen wie Umwelt- und Energieeffizienz, nachhaltiger Betriebsführung, laufendes Controlling sowie Umwelt- und CSR-Reporting (Corporate Social Responsibility) mit Bezug zur IT oder unterstützt durch IT.

Mittelfristig werden also auch ökologische Qualitätskriterien und Anforderungen aufgestellt werden, denen gute Software zu genügen hat. Es ist nur eine Frage der Zeit, bis sie Eingang in entsprechende Normen, Standards, Zertifizierverfahren sowie in konkrete Produktanforderungen finden werden. Und man sie zu testen hat. Aber auch Entwickler werden sich zunehmend mit Qualitätsaspekten „grüner“ Software konfrontiert sehen. Im Fokus stehen vor allem eine verbesserte Gebrauchstauglichkeit und schnellere Anwendungen. Denn Software, die schneller läuft und effizienter genutzt werden kann, verbraucht in der Regel auch weniger Energie und Arbeitszeit.

Wie Normen entstehen und Standards gesetzt werden

Immer mehr werden Vorgänge in Wirtschaft und Technik neben Gesetzen auch von Normen und Standards, also von Formen technischer Regulierung bestimmt. Insbesondere in der IT, in der IT-Sicherheit aber auch im Bereich Softwarequalität sind Normen und Standards sowie der Nachweis über Verständnis und Beherrschung ihrer Inhalte von wesentlicher Bedeutung für geschäftlichen Erfolg und berufliche Qualifikation. Zeit also, sich das Zustandekommen dieser Normen und Standards mal genauer anzusehen.

Am einfachsten ist es, wenn Gesetze und Verordnungen dafür ursächlich sind, wie z.B. das Bundesdatenschutzgesetz oder die Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU). Denn diese lassen sich meist als Volltext im Internet finden, so dass ihr Inhalt rasch nachgeschlagen werden kann. Seiten wie z.B. www.gesetze-im-internet.de des Bundesjustizministeriums sind da recht nützlich. Da die meisten Gerichte mittlerweile ihre Entscheidungen ins Internet stellen, ist auch die aktuelle Rechtsprechung zu diesen Gesetzen gut recherchierbar. Juristen sind zudem oftmals auch publikationsfreudige Fachartikelschreiber und Blogger, so dass sich auch fachliche Kommentierungen zu Gesetzen und Urteilen im Web finden lassen.

Ganz anders bei wichtigen Industrienormen und fast allen Dokumenten technischer Regulierung. Wer z.B. nachschlagen will, was die ISO 9000 zum Qualitätsmanagement aussagt, nach welchen Standards Produkte zertifiziert oder Bilanzen geprüft werden, kommt an die Texte der Normen nicht so ohne weiteres heran.

Denn diese werden nahezu ausschließlich durch privatrechtliche Organisationen wie das Deutsche Institut für Normung (DIN), die International Organization for Standardization (ISO), das Institute of Electrical and Electronics Engineers (IEEE) oder ähnliche Einrichtungen, von denen es allein in Deutschland etwa 150 gibt. Finanziert werden diese durch Mitgliedsbeiträge von Firmen, die an einer Standardisierung von technischen Vorgehensweisen interessiert sind, da damit Rationalisierungs- und Wettbewerbsvorteile verbunden sein können. Sowie aus den urheberrechtlichen  Lizenzerträgen der Texte und Dokumente, in denen die jeweiligen Standards abgedruckt und kommentiert werden.

Man kann davon ausgehen, dass Prüfgesellschaften und Unternehmen, in denen viel mit Standards gearbeitet wird, diese regelmäßig zur internen Verwendung nachkaufen. In Deutschland hat sich hier z.B. der Beuth-Verlag hervorgetan. Man kann dort einzelne Normtexte für recht happige Preise als PDF kaufen (z.B. die ISO 9000:2005, Qualitätsmanagementsysteme – Grundlagen und Begriffe mit ca. 40 Seiten für gute 140 €). Oder ganze Normenpakete mit Mengenrabatt bzw. als „Normenflatrate“ beim Erwerb von Perinorm, einer ziemlich umfassenden Normendatenbank für die eine vierstellige Summe pro Jahreslizenz und Nutzer fällig wird.

Schon der Einblick in die fertige Norm ist also kompliziert und teuer. Wie aber kommen die Normen zustande? Normen sind in aller Regel freiwillige Übereinkünfte derjenigen, die sie ausformulieren. Verbindlichkeit erlangen sie erst dadurch, dass sich hinreichend viele Unternehmen daran halten, dies auch von Lieferanten und Geschäftspartnern fordern und sich durch entsprechende Zertifizierungen belegen lassen. In ihnen kommen die Regeln und der Stand der zugrunde liegenden Technik zum Ausdruck. Normen und Standards entstehen innerhalb der Normungsinstitutionen durch Prozesse der konsensualen Beratung und Einigung innerhalb von Expertengremien. Bereits bestehende Normen werden in der Regel alle 3-5 Jahre überarbeitet, um sie dem technischen und methodischen Fortschritt anzupassen. In diese Gremien entsenden die Mitgliedsunternehmen und berufsständische Organisationen Fachleute aus ihren Reihen und lassen dort neben fachlichen auch Unternehmensinteressen vertreten. Der Lobbyismus ist also schon ins Verfahren „eingebaut“, so dass es sehr selten zu externer Lobbyarbeit zum Zwecke der Beeinflussung eines laufenden Normungsprozesses kommt. Wobei es dafür auf deutscher Ebene sogar eine eigene Norm gibt (die DIN 820-4), welche den Normungsprozess am DIN-Institut beschreibt.

In der Regel erreicht eine Norm daher meist erst mit Erscheinen entsprechender Fachliteratur und Fortbildungsangeboten einen größeren Bekanntheitsgrad. Ihre frühzeitige Beherrschung kann daher einen beträchtlichen Wettbewerbsvorteil darstellen und als Nachweis fachlicher Professionalität gelten. Deutlich sichtbar ist das z.B. bei Angeboten zur zertifizierbaren IT-Sicherheit nach ISO 27.000, zum Qualitätsmanagement nach ISO 9.000 oder zum Servicemanagement von Organisationen nach ISO 20.000 (aufgebaut nach den ITIL-Büchern, welche ebenfalls zum Standard wurden). Auch Vorgehensmodelle wie das V-Modell XT im Bereich der Softwareentwicklung, Prince2 im Projektmanagement oder Reifegrademodelle wie CMMI für Prozesse  sind letztlich Standards, die meistens anhand der Sekundärliteratur oder im Rahmen betrieblicher Fortbildungen erschlossen werden.

Nichtsdestotrotz werden Normen und Standards insbesondere für im IT-Bereich tätige Menschen immer wichtiger. Gerade bei Themen wie der IT-Sicherheit und zunehmend auch in der Softwarequalität geht ohne fundiertes Verständnis der einschlägigen Normen und Standards fast nichts mehr. Die privatrechtliche Normung ist in Teilen bereits deutlich umfänglicher als das deutsche Steuer- oder Arbeitsrecht. Und sie gilt weltweit. Daher werden 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 gewinnen.

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.