Ein Computercode, der die Zeiten überdauert

21. Mai 2013, 17:33
12 Postings

Von der Waschmaschine bis zur Rakete zehrt jede Technik von einem Rohstoff: Software - Ist der Programmcode nicht vorausschauend geschrieben, stehen die Entwickler der Zukunft vor Problemen

Die Software, die die Wicklungen für spezielle Transformatoren berechnet, funktioniert. Russische Mathematiker haben sie vor vielen Jahren programmiert. Was niemand mehr weiß, ist, wie sie das gemacht haben. "Das Wissen ist nur noch im Code verfügbar", sagt Rudolf Ramler, der sich beim Software Competence Center Hagenberg mit der Qualitätssicherung von Softwaresystemen beschäftigt, über eines seiner Projekte. Mühsam müssen aus der Trafo-Software wieder die mathematischen Formeln, die ihr zugrunde liegen, extrahiert werden. "Dokumentation gibt es in alten Systemen so gut wie nie", sagt Ramler.

Ein Softwaresystem, über das man kaum etwas weiß, ist auch nur schwer erweiterbar. Sogenanntes Reengineering, die Anpassung eines bestehenden Systems bei gleichbleibender Funktionalität, stellt heute einen großen Teil der Arbeit von Softwareentwicklern dar. Umso wichtiger sei es, bei neuen Umsetzungsprozessen von Anfang an Qualitätssicherung zu betreiben und auf die interne Qualität, also Faktoren wie Architektur, Kontrollflüsse, Erweiterbarkeit und modularer Aufbau zu achten, erklärt Ramler.

Die interne Qualität muss zwar nicht unbedingt mit der externen Qualität, also der Fehlerfreiheit aus der Sicht des Benutzers, zusammenhängen. Sie ist allerdings die Voraussetzung dafür, dass das System in der Zukunft keinen Schaden verursacht. Die Softwaresysteme, die uns von der Waschmaschine bis zur Spritzgussmaschine in einer Industrieanlage umgeben, sind über Jahre gewachsen und werden stets neu adaptiert und weiterentwickelt. Allerdings: "Man wird auch heute nicht schaffen, ein System zu bauen, das in Zukunft kein Problem ist", sagt Ramler. Schon die rasante Entwicklung der Hardware sorgt dafür.

Einer der spektakulärsten Beispiele für einen "systematischen Software-Designfehler", wie es eine Untersuchungskommission später nannte, war 1996 der fehlgeschlagene Erstflug der Ariane-5-Rakete der Esa. Lenksoftware, die von Ariane 4 übernommen wurde, aber nicht fehlerfrei aktualisiert wurde, war dafür verantwortlich: neue Hardware, alte Software.

Künftige Anwendung erahnen

Egal, ob die Programme in einer Produktionsanlage, in der Sitzsteuerung eines Autos oder in einem Marsroboter laufen - auch Rover "Curiositys" Software machte bereits Probleme - am besten sollte man eine Software auch auf jene Dinge testen, "an die man selbst nicht denkt". Programme werden weiterentwickelt und für Zwecke eingesetzt werden, die jetzt noch nicht absehbar sind, sagt Ramler. Auch ein Betriebssystem wie Windows werde für Anwendungsprogramme geschrieben, die zum Teil noch nicht existieren.

Tools, die Testfälle automatisieren und ein Programm mit vielen verschiedenen Abfragen konfrontieren, helfen, eine Offenheit für künftige Adaptierungen zu gewährleisten. Andere Werkzeuge klopfen den Code wie ein Rechtschreibprogramm auf Interpretierbarkeit ab. Formale Methoden, bei denen Programmteile mathematisch modelliert werden, und manuelle Inspektion, also tatsächliches "Gegenlesen" der Codezeilen sollen die Fehleranfälligkeit zusätzlich minimieren.

Testgetriebene Entwicklung

"Eine der größten Fehlerquellen liegt darin, wenn zwei Entwickler parallel Änderungen vornehmen, die am Schluss nicht zusammenpassen", umreißt Stefan Biffl vom Institut für Softwaretechnik und Interaktive Systeme der TU Wien ein Kommunikationsproblem bei der Entwicklung. Noch schlimmer ist es aber, wenn Auftraggeber und Team nicht von derselben Sache sprechen. Diesbezüglich habe sich die sogenannte testgetriebene Entwicklung sehr bewährt.

Anstelle zuerst eine Lösung zu entwerfen und sie am Schluss zu testen, entwerfen Auftraggeber und Entwickler im Vorfeld "missionskritische Tests", die die Software bestehen muss.

Um die Koordination der Softwarewerkzeuge aus verschiedenen Fachbereichen kümmert sich Biffl auch in dem von ihm geleiteten Christian-Doppler-Labor. Es bringe erhebliche Vorteile, wenn etwa bei Aufbau und Wartung eines Kraftwerks die Werkzeuge von Maschinenbauern, Elektro- und Softwaretechnikern dieselbe Sprache sprechen. Ein neu eingebauter Füllstandssensor kann etwa Änderungen bei Verkabelung und Software notwendig machen. Durch die Integration von Daten und Funktionen der beteiligten Werkzeuge versteht die Qualitätssicherung automatisch, wo das neue Signal des Füllstandsensors zu berücksichtigen ist. (Alois Pumhösel, DER STANDARD, 22.5.2013)

  • Bild nicht mehr verfügbar

    Error. Endnutzer sind täglich mit mangelnder Softwarequalität konfrontiert. Genauso wichtig ist aber eine "interne Softwarequalität": durchdachte Architektur, Dokumentation, Erweiterbarkeit.

Share if you care.