Softwaresicherheit, Teil 3

Zukunftssicherheit von Embedded-Software

29.01.13 | Autor / Redakteur: Peter Siwon und Alexander Sedlak * / Hendrik Härter

Open-Source-Codes: Viele Entwickler arbeiten an einem Softwaresystem. Doch wem gehört der Code?
Open-Source-Codes: Viele Entwickler arbeiten an einem Softwaresystem. Doch wem gehört der Code? (Foto: Gerd Altmann, pixelio.de)

Im dritten Teil unserer Serie geht es um den etwas schwieriger zu definierenden Begriff der Zukunftssicherheit. Dabei soll es nicht ausschließlich darum gehen, dass künftige Anforderungen der Betriebs- und Angriffssicherheit, der Funktionalität, des Designs und der Standards auch in Zukunft wettbewerbsfähig erfolgen

Der Gedanke liegt nahe, dass es hellseherischer Fähigkeiten bedarf, um heute schon sagen zu können, welchen Gefahren und Herausforderungen die aktuelle Embedded Software in der Zukunft ausgesetzt sein wird. Doch zum Glück gibt es auch ganz diesseitige Methoden und Hilfsmittel, die uns, konsequent angewendet, diesem Ziel näher bringen können.

Ein prominentes Beispiel zeigt, wie wichtig die Zukunftssicherheit sein kann: 1977 starteten von Cape Canaveral 2 Trägerraketen, beladen mit den Voyager Raumsonden. Sie hatten die Aufgabe, verschiedene Planeten unseres Sonnensystems zu erkunden. Die geschätzte Projektlaufzeit betrug rund 5 Jahre. Alles musste über diese Lebensdauer störungsfrei funktionieren. Das Voyager-Programm funktioniert viel besser als erwartet.

Bis heute funken die Sonden ihre Signale, rund 30 Jahre länger als geplant. Die verantwortlichen Techniker haben ihre Sache offensichtlich gut gemacht. Das System hatte allerdings einen großen Vorteil: Es blieb über seine Lebensdauer unverändert.

Wie es allerdings ausgehen kann, wenn Software häufigen Änderungen unterworfen ist, zeigte sich beim Smartphone-Betriebssystem Symbian. Es hatte einige Jahre sehr gute Dienste geleistet, doch nach und nach begann es, instabil zu werden. Auch bei kleinen Änderungen wurde immer schwieriger, die Software wieder zu stabilisieren.

Heute verschlänge die Weiterentwicklung so große Ressourcen, dass mit neuen Versionen nicht mehr zu rechnen ist. Diese veränderungsbedingte Fragilität nennt man Softwareerosion. Softwareerosion gehört damit zu den größten Bedrohungen für die schnellen Innovationzyklen in vielen Branchen, wie Thomas Eisenbarth von der Firma Axivion und Prof. Dr. Koschke betonen.

Ergänzendes zum Thema
 
Softwaresicherheit näher betrachtet

Beide befassen sich seit mehreren Jahren mit gezielten Maßnahmen gegen Softwareerosion. Sie sehen in einem besseren Problembewusstsein und in automatisierten Erosionstests in Verbindung mit konsequenten Gegenmaßnahmen wichtige Voraussetzungen. Rudolf Frommknecht, Squoring, ergänzt, welche Bedeutung Ausbildung, Prozessgestaltung und Toolauswahl haben.

Wie sich die Qualität von Software beurteilen lässt

Heute sind die Herausforderungen an Softwareentwickler für Embedded-Systeme, um Zukunftssicherheit bei ihren Produkten hinsichtlich Softwareerosion und auch allgemein zu gewährleisten, bekannter als noch vor wenigen Jahren. Generell gilt der Grundsatz: Keep it simple.

Die Vermeidung undurchsichtiger Konstrukte und die Wahl eines Softwarecodex, der weitgehend selbsterklärende und überschaubare Softwareelemente fordert, ist ein guter Einstieg in diese Zukunftssicherung. Jede Software, die aus der Hand eines Programmierers geflossen ist, kann gewissermaßen in ihrem "so sein, wie sie ist" beurteilt werden. Dieses "so sein" wird landläufig mit dem Begriff der Qualität bezeichnet.

Qualitätsmodelle helfen, spezifische Qualitätskriterien von Produkten zu beurteilen. Klaus Wissing von Squoring erklärte auf dem Embedded Software Engineering Kongress 2011, dass bei der Softwareentwicklung immer mehr Personen mit ganz unterschiedlichen Rollen und Blickwinkeln beteiligt sind. Die Aufgaben innerhalb der Prozesse sind einerseits hochgradig vernetzt, müssen andererseits auch gegeneinander abgegrenzt werden.

Die Vielfalt der sich daraus ergebenden Projektanforderungen zu beherrschen, ist die große Herausforderung. Jeder Projektbeteiligte muss dazu einen realistischen Einblick in den Projektfortschritt und die Softwarequalität erhalten, der seinem Informationsbedürfnis und seinem Kenntnishorizont entspricht. Idealerweise wird diese Information per Knopfdruck auf Basis definierter Qualitätsmodelle automatisch ermittelt und visualisiert.

Die große Kunst besteht nun darin, geeignete Qualitätsmodelle zu erstellen und diese auch an veränderte Bedingungen anzupassen. Bekannte und verbreitete Standards, Normen und Metriken dienen als Grundlage für solche Qualitäts- und Bewertungsmodelle. Der konkrete Fall ist eingehend zu betrachten und angepasste Tools und Maßnahmen sind einzusetzen. In Bezug auf die Beurteilung von Zukunftssicherheit würde das bedeuten, dass eine Software und der damit verbundene Prozess anhand spezifischer Kriterien, wie der Updatefähigkeit, der Wirksamkeit des Change-Managements oder der Stabilität, nach Änderungen geprüft werden.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 34878320 / Projektmanagement)

Embedded Software Engineering Report abonnieren

4 mal jährlich: Die kostenlose Pflichtlektüre für Embedded­-Software- und Systems-Entwickler, von Analyse bis Wartung und Betrieb

* Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung und AGB einverstanden.
Spamschutz:
Bitte geben Sie das Ergebnis der Rechenaufgabe (Addition) ein.