Startseite > Embedded > Qualitätssicherung im Softwareentwicklungsprozess

Basis für Zuverlässigkeit und Sicherheit

Qualitätssicherung im Softwareentwicklungsprozess

30. November 2010, 16:19 Uhr | Joachim Terasa, Geschäftsführer der Coming GmbH

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Anzuwendende Qualitätskriterien

Die in der Spezifikation anzuwendenden Qualitätskriterien sind überschaubar:

Korrektheit: Was in der Spezifikation steht, muss richtig sein. Widersprüche können aufgedeckt, Fehler nur vom wirklich kundigen Leser entlarvt werden.
Vollständigkeit: Eine Spezifikation wird nie wirklich vollständig sein. Triviales und ausgesucht Selbstverständliches sollte weggelassen oder ausgegliedert werden, denn sonst leidet die Verständlichkeit.
Verständlichkeit: Die Spezifikation ist das zentrale Kommunikationsmittel zwischen Kunde und Entwickler. Was nicht oder falsch rüberkommt, ist wie ein Fehler zu sehen.

Beispiele aus dem Entwickleralltag zeigen, dass Spezifikationen zu erstellen, nicht einfach ist:

Eine zehnseitige Bedienungsanleitung eines Vorgängergerätes, mit einer Seite Ergänzungen und der sinngemäßen Anmerkung »genau das, nur etwas anders« stellte sich im Laufe der Entwicklungstätigkeit als »ganz anders, stellenweise ähnlich« heraus. Weitere, zum Teil widersprüchliche Dokumente folgten mit immer neuen Anforderungen. Das ist zwar verständlich, aber weder korrekt noch irgendwie vollständig.
Ein mehrere 100 Seiten starkes Tabellenwerk, das hauptsächlich Zustandsübergänge und Querverweise enthält. Das ist zwar möglicherweise vollständig, vielleicht auch korrekt, aber absolut unlesbar. Als Vorlage diente ein inoffizielles Modell, das wahrscheinlich weder vollständig noch korrekt war, man konnte es aber verstehen.
Ein etwa 100-seitiges Dokument, das aus Angst vor Mangel an Dicke per Copy/Paste aufgeblasen wurde. Das mündete darin, dass ein 40-zeiliger Passus etwa 50 mal vervielfältigt wurde und an jeder Kopie zwei Details verändert wurden (sogar das wurde an drei Stellen vergessen). Wahrscheinlich vollständig, leicht inkorrekt, aber abschreckend.

Unterschiedliche Branchen haben dabei ihren ganz eigenen Wortschatz. Dem Softwareentwickler kann in der Regel zugemutet werden, diesen zu erlernen. Ebenso sollte es umgekehrt möglich sein, schließlich hat der Kunde ein ureigenes Interesse, sich verständlich mitzuteilen. UML ist hier ein Standard, und der relevante Wortschatz beschränkt sich auf die Verhaltensdiagramme, wobei von denen vor allem die Use- Case-Diagramme zum Einsatz kommen. Was zum Einsatz kommen kann, wird auch durch das einzusetzende Werkzeug bestimmt.

Das Design ist das Ergebnis unter anderem einer Analyse der Spezifikation und beschreibt, wie die Software aufgebaut ist. Begriffe, die in diesem Zusammenhang auftreten können, sind z.B. Klassen, Objekte, Prozesse, Daten und Tasks – das sind alles Begriffe, um Struktur in das Problem zu bringen.

So vielfältig wie diese Begriffe sind, so vielschichtig sind die Qualitätskriterien, die vielfach in Konkurrenz zueinander stehen: Korrektheit, Wartbarkeit, Testbarkeit, Zeitverhalten, Ergonomie, Zuverlässigkeit und Reproduzierbarkeit, Robustheit, Sicherheit, Wiederverwendbarkeit, Portierbarkeit, Skalierbarkeit, Arbeitspaketfähigkeit bzw. Arbeitsteilung sowie Verständlichkeit. Was auch hier alles falsch laufen kann zeigen zwei Beispiele:

Konzept Haupttask: Der Steuerrechner eines diagnostischen Gerätes war mit einem wirklich akzeptablen, multitaskingfähigen Echtzeitbetriebssystem ausgestattet. Der Projektleiter, dem diese Welt nicht so vertraut war, rief deshalb einen Berater zu Hilfe. Dieser hatte zwar den gleichen Praxishintergrund, konnte den aber besser verkaufen. Ergebnis war eine einzige riesige Task, die den kompletten Funktionsumfang des durchaus komplexen Gerätes beinhaltete, dazu noch einen einfach strukturierten kooperativen Scheduler, um die einzelnen Funktionen abzurufen, und eine Menge Code, der die Nachteile dieser Konstruktion kompensieren sollte. Korrekt, was durch riesigen Testaufwand nachgewiesen wurde; nicht wartbar; kaum testbar; das Zeitverhalten musste bei jeder kleinen Änderung neu justiert werden; nicht robust, weil das kooperative Tasking auf Daten-Bursts kritisch reagierte. Was in den einzelnen Arbeitspaketen entstand, war anerkennenswert. Was in der beschriebenen Laufzeitumgebung daraus wurde, war traurig.
Konzept Global Database: Zu einer Zeit, als Objektorientierung bereits ein häufig benutztes Schlagwort war, wurde sich für ein Avionic-Steuergerät entschieden, das alle Daten global deklariert, weil es so viel einfacher sei, darauf zuzugreifen. So war es dann auch. Es gab Variablen, die zu jeder Zeit einen rein zufälligen Inhalt hatten, und es war erst mit teurem Test-Equipment möglich zu analysieren, wann wer was wohin schrieb und warum das Gerät so nicht funktionierte, wie es nicht funktionierte. Gut, das ganze wurde in Assembler programmiert, aber gerade dann sollten Designprämissen sehr sorgfältig gewählt werden.

Das Design dient der Kommunikation zwischen Architekt und Programmierer, beide können beides in Personalunion sein, es kommt aber oft genug vor, dass es sich um getrennte Abteilungen oder gar Standorte handelt. In jedem Fall kann man aber davon ausgehen, dass beide Seiten die gleiche Sprache, nämlich UML-Strukturdiagramme, sprechen bzw. verstehen.