Software Life Cycle Management: Alle Schotten dicht?

Mangelhafte Routinen und das nachträgliche Ausbessern von Software-Applikationen ziehen in Wirtschaft und Industrie oftmals negative Folgen nach sich. "Neben dem wirklich ermittelbaren monetären Schaden kommt vor allem die massive Rufschädigung aller Beteiligten hinzu, die mitunter um ein Vielfaches schwerer wirkt", sagt Helmut Pichler, Präsident des Austrian Testing Boards (ATB).

Der Zusammenschluss von Experten widmet sich der Erarbeitung von Qualitätsstandards in der sicheren Softwareentwicklung und dem Testing. Seitdem österreichische Bildungseinrichtungen wie die TU Graz und Wien oder die Fachhochschule Hagenberg eigene Vorlesungen zum Thema Qualitätssicherung und Testing offerierten, seien angehende Techniker bereits mit einem relativ fundierten Basiswissen über das Testen gewappnet.

"Die Spezialisten kommen vor allem mit einem höheren Bewusstsein für Aspekte der Qualitätssicherung und die Notwendigkeit des Testens auf den Markt", bilanziert der Softwareexperte. Gefragt sind aber auch weiterhin in vielen Bereichen neue Forschungsansätze, um für die Unternehmen möglichst konkrete Lösungen und Modelle beizusteuern.

Konkret kommen laut Helmut Pichler heute bereits einige neue Verfahren zum Einsatz, etwa Werkzeuge, die in der Lage sind, Testfälle durch Berücksichtigung mehrdimensionaler Äkquivalenzklassen zu generieren und dadurch bislang verborgene Fehler aufzuspüren.

Im Expertenjargon wird dieses Verfahren als so genannte bewusste "Fehlereinpflanzung" in den Code bezeichnet. "Dadurch wird die Robustheit von Code verbessert", betont Pichler, der aber auch andere Verfahren als geeignet ansieht, wie neue Test Script Sprachen wie TTCN-3, die das Testen von Schnittstellen massiv erleichterten.

"Speziell im Produktivbetrieb werden Anwendungen noch vorwiegend als Black-Box betrachtet und es fehlen Automatismen und Prozesse auf Anwendungsebene", sagt Bernd Greifeneder, CTO dynatrace software GmbH, einem Spezialisten für Softwarediagnose. Er sieht den wichtigsten Knackpunkt im Mangel an Softwareunterstützung zur Förderung und Automatisierung der Zusammenarbeit.

Klassische Aufteilung überfordert

Die klassische Aufteilung zwischen Entwicklung, Test Center, Data Center/Operations sei kaum mehr in der Lage, die auftretenden Probleme zu lösen. "Deshalb ist es unumgänglich, auf neue Life-Cycle orientierte Ansätze mit Softwareunterstützung zu setzen", betont der Experte. Der Life-Cycle Ansatz ziele auf eine bessere Automation, Integration und Kollaboration der Testprozedere und Standards, um Fehler möglichst zeitnah während der Entwicklung erkennen zu können und die Fehlerbehebungszeit zu verringern.

"Bei modellgetriebenen Ansätzen wird Code generiert, wobei Formalfehler theoretisch ausgeschlossen werden", so Greifeneder weiter. Allerdings steige damit die Abstraktion und es sei schwieriger, das dynamische Verhalten des generierten Codes, einem für den Entwickler unbekannten Code, abzuschätzen.

Zahlreiche modellgetriebenen Ansätze beziehen fortlaufende Integrationstests und das Performance Management nicht mit ein, deshalb seien externe Werkzeuge und der Lifecycle Ansatz notwendig. "In Unternehmen, in denen die QA-Abteilung (Qualitätssicherung) ein Teil der Entwicklungsabteilung ist, funktioniert der Life-Cycle Ansatz bei funktionalen Tests schon sehr gut", betont Greifeneder.

Life-Cycle Application Performance Management sollte alle Bereiche umfassen, von der Entwicklung über das Testing bis hin zum Produktivbetrieb, um eine maximale Effizienzsteigerung zu erzielen. In Betrieben mit separaten Test-Centern dominiert nach Auffassung von Greifeneder noch eine große Kluft zwischen den IT Abteilungen, was die kontinuierliche Integration erschwere.

Aber auch dort trage der Life-Cycle-Ansatz dazu bei, Brücken zwischen den Abteilungen zu schlagen und die Effizienz zu steigern. "Es ist definitiv ein Umdenken in der klassischen QA erforderlich", betont der Experte. "Das Problem dabei ist, dass die QA zum Teil wegrationalisiert wird, was Ängste schürt", räumt der Experte ein.

Dies lasse sich dadurch vermeiden, indem es gelinge, die Mitarbeiter aus der Qualitätssicherung unmittelbar in die Entwicklerteams zu integrieren und parallel dazu die Test-Automatisierung voranzutreiben. Doch gerade an der sensiblen Schnittstelle zwischen Mensch und Technik treten die größten Schwachstellen hervor.

Neue Methoden und ROI

"Ein Grund, warum neue Methoden vom Markt teilweise zögerlich aufgenommen werden ist, dass der Return of Invest noch nicht nachweisbar ist, also transparent gemacht werden kann", betont Helmut Pichler vom ATB. Im Klartext: Unternehmen lassen sich deshalb nur selten auf risikobehaftete "Experimente" mit neuen Verfahren, Tools, Methoden ein. Sie setzen vielfach ausschließlich auf bereits Erprobtes.

Es dominiert zudem der verstärkte Kostendruck, der den Qualitätsanspruch oft relativiere, so der Experte weiter. Hinzu kommt das fehlende oder verloren gegangene Qualitätsbewusstsein, sowie eine generelle Kurzsichtigkeit in der Kalkulation von Projekten. Mittlerweile wieder in Mode kommt auch das klassische Requirement-Engineering. Mit Hilfe dieses Verfahren lassen sich gleich zwei Fehlerquellen minimieren.

Einerseits wird mit dem Auftraggeber klar abgestimmt, was bzw. wie sein Produkt am Ende sein soll und andererseits bekommt der Auftragnehmer bereits eine konkretere Aufgabenstellung. "Durch möglichst eindeutige Definition der Anforderungen fällt zwar mehr Aufwand beim Projektstart an, dieser ist jedoch sehr gut investiert - denn die besten Fehler sind natürlich die, die gleich gar nicht gemacht werden", rechnet Helmut Pichler vor.

Oft jedoch lassen sich die passenden Anforderungen anfangs nicht eindeutig definieren. In solchen Fällen bietet sich laut Pichler die "Agile Entwicklungsmethodik" an, ein Verfahren auf das etwa Lösungsanbieter Anecon setzt. Allerdings gibt es auch hier noch offene Fragen.

"Diese Methodik ist sicher die Zukunft, doch bedarf es zur erfolgreichen Umsetzung auch einer gewissen Reife im Grad der Zusammenarbeit zwischen Auftraggeber und Auftragnehmer", räumt der Experte vom ATB ein. Denn bei der "agilen Entwicklungsmethodik greift der Dienstleister unmittelbar ins Geschehen ein.

Ein Vertreter des Auftraggebers wird dabei voll integriert in den fortlaufenden Definitions- und Entscheidungsprozess eingebunden und übernimmt die Verantwortung für jede Iteration am Produkt. Die Grenzlinien zwischen interner und externer Dienstleistung verwischen sich, was ein großes Vertrauensverhältnis im Mix zwischen In- und Outsourcing voraussetzt.

"Beim Auftraggeber setzt diese Methode ebenfalls erfahrene Mitarbeiter voraus, die sich sowohl mit der geänderten Planung auskennen müssen, nämlich immer ein lauffähiges System vorzuhalten und außerdem die hohe Taktfrequenz bewältigen, nämlich im Rhythmus von zwei bis drei Wochen Rhythmus entsprechende Änderungen einzustellen. "Die Tester brauchen dafür viel Erfahrung, um ein vernünftiges Mix an Tests der neuen Funktionen und Regressionstests der bisherigen Funktionalität zu finden", fasst Helmut Pichler zusammen.

Fazit

Selektiv angewendete Testverfahren ohne Bindung zur ganzheitlichen Organisation und zum gesamten Produktlebenszyklus, wie das "blinde" Testen, Fuzzing oder die statische Quellcodeanalyse, greifen nur an isolierter Stelle und drohen somit nur begrenzt effektiv zu sein. "Die genannten Testverfahren sind hilfreich, decken aber nur einen kleinen Teilbereich ab, weil sie hauptsächlich Formalfehler finden, aber das dynamische Anwendungsverhalten nicht berücksichtigen und auch den Sinn der Anwendung nicht kennen" sagt Bernd Greifeneder, CTO von dynaTrace software.

Deshalb sei das hauptsächliche Augenmerk darauf zu richten, Programmierrichtlinien einzuhalten und zu automatisieren, um "Anfängerfehler" möglichst frühzeitig abzufangen. Der Experte plädiert dazu für fortlaufende Codereviews und Unit Tests als das beste methodische Instrumentarium, um so früh wie möglich Programmierprobleme zu erkennen. "Des Weiteren können automatisierte Integrations- und Systemtests mit Softwarediagnose gekoppelt werden, um das dynamische Verhalten von Modulen sowie vom Gesamtsystem abzudecken, bilanziert der Experte.

Dass standardisierte Antworten in der komplexen Softwarewelt gerade angesichts eines hohen Grads an interner wie externer Vernetzung nicht mehr ausreichen, um das Gesamtsystem im Griff zu behalten - zumal immer mehr offene Web 2.0-Applikationen das sensible Terrain entern - das bestätigt auch Jan Overbeck, Geschäftsführer und Gründer der Anecon Software Beratung GmbH in Wien.

Der Experte sieht die Tester nach Abschluss eines Projektes in einer strategischen Schlüsselrolle. "Sowohl die technischen Spezialisten als auch die Personen aus dem jeweiligen Fachbereich kennen das System am besten, denn sie haben auf Herz und Nieren getestet", sagt Overbeck.

Die Fachbereichstester seien daher ideal geeignete Trainer für Anwendereinschulungen und fungierten auch später als wertvolle Ansprechpartner im fortlaufenden Betrieb. "Und damit sind sie auch hervorragende Motivatoren für die Veränderungen, die sich im Unternehmen ergeben, um in sinnvollen Software-Projekten das Unternehmen in die richtige Richtung weiter zu entwickeln", bilanziert Overbeck.

www.austriantestingboard.at
www.anecon.com
www.dynatrace.com