Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.08.1986 - 

Ingenieurdisziplin kontra Programmierchaos:

SW-Engineering spart langfristig Kosten

Noch Immer wird ein Großteil der Software nicht nach ingenieurmäßigen Methoden entwickelt. Dem drohenden Programmierchaos will der Rheinisch-Westfälische TÜV, Essen, mit Softwareengineering begegnen. Nach der Erfahrung von Werner Philipp* investieren nach wie vor zu viele Anwender in SW-Produkte, die sich sinnvoller durch neue, qualifizierte Software ersetzen ließen.

Herkömmliche Methoden der SW-Entwicklung und der Auswahl lassen aufgrund unzureichender Bewertungsverfahren Programme entstehen und zum Einsatz kommen, die entscheidende Mängel beinhalten oder für den vorgesehenen Zweck nicht einsetzbar sind. Insbesondere die Wartung von Software, die Anpassung an geänderte Aufgabenstellungen und die Übertragung auf andere Rechenanlagen ist derart aufwendig, daß ein großer Teil der Gesamtkosten für Software bei der Wartung anfällt.

Speziell der letztgenannte Punkt war der Grund dafür, daß sich der RWTÜV bereits seit 1978 mit dem Themenbereich Softwarequalitätssicherung befaßt hat. Investiert wurde vornehmlich in Werkzeuge, die den SW-Erstellungsprozeß und insbesondere die Wartung von Software unterstützen. Diese Tools münden in den Aufbau eines Qualitätssicherungswesens für die hausinterne Softwareerstellung.

Flexible Software bremste systematische Entwicklung

Die Anstrengungen des RWTÜV entstanden aus der Notwendigkeit, große fremderstellte Softwarepakete für Begutachtungszwecke einsetzen zu müssen. Im Laufe der Jahre stellte sich heraus, daß die Probleme dabei genereller Natur waren.

Die Erkenntnis, daß Software außerordentlich flexibel ist, hat in der Vergangenheit dazu geführt, daß die Anforderungen an ein System nicht in ausreichendem Maße zu Beginn der Entwicklung festgelegt wurden. Die Flexibilität war auch der Grund dafür, daß sich die Entwickler zunächst wenig Gedanken über die Systematik der SW Erstellung machen mußten.

Die Hauptschwierigkeit bei Softwareentwicklung und -einsatz liegt immer noch in der Tatsache, daß die Flexibilität der Software überstrapaziert wird. Es scheint verfehlt, daraus einen globalen Vorwurf an die Softwareentwickler abzuleiten. Ursache für die Probleme sind vielmehr die Arbeitsweise der SW-Entwickler und die rasante Entwicklung im Datenverarbeitungsbereich. Da die Nachfrage nach Software in den vergangenen Jahren extrem gestiegen ist blieb den Entwicklern nahezu keine Zeit, über die Grundlagen ihrer Arbeit nachzudenken.

SW-Engineering zwingt Weichwerker zum Umdenken

Seit zirka fünf Jahren werden auch in Europa Anstrengungen unternommen, um dieses Defizit auszugleichen. Ein wesentlicher Ansatzpunkt zur Verbesserung der Situation wird heute in einer Entwicklung gesehen, die mit dem Begriff des Softwareengineering stark verknüpft ist.

Softwareengineering umschreibt eine Vorgehensweise, die durch die Rückbesinnung auf die Prinzipien der Ingenieurwissenschaften gekennzeichnet ist. Diese Prinzipien sind: - Beschränkung auf das Machbare, das heißt etwas für den Markt - bezogen auf eine Anforderung hin - entwickeln ein Produkt.

- Verwendung von geeigneten konstruktiven Methoden auf der Basis des Standes der Technik (Normen/Standards) und die Verwendung geeigneter Hilfsmittel (Werkzeuge)

- Planung und Einsatz analytischer Methoden zur Qualitätssicherung und Qualitätskontrolle im Fertigungsprozeß zur Sicherstellung und zum Nachweis der geforderten Qualität.

Bei der Übertragung dieser Forderungen auf den SW-Erstellungsprozeß ist jedoch zu beachten, daß bei der Erstellung von Software die Konstruktion und die Produktion zusammenfallen, da mit der Fertigstellung des ersten Exemplars der Software der Produktionsprozeß bereits endet. Grundlegend für das SW-Engineering ist eine exakte Erklärung des Begriffs Software. Durchgesetzt hat sich in den letzten Jahren die folgende Definition: Software besteht aus einem Produktanteil, der die Mensch-Mensch-Kommunikation betrifft. Dies sind Dokumente für die Entwicklung sowie Dokumente für die Benutzung. Hinzu kommt ein Produktteil, der die Mensch-Maschine-Kommunikation betrifft. Dies sind anwendungsbezogene und systembezogene Teile.

Erst wenn alle vier Produktkomponenten vorliegen, kann von Software die Rede sein. Die Programme im landläufigen Sinne sind nur die anwendungsbezogenen Teile der Mensch-Maschine-Kommunikation. Kurzgefaßt läßt sich dieser Softwarebegriff auf die folgende Formel bringen:

Dokumentation + Programme = Software.

Für den Entwicklungsprozeß von Software sind auf der Basis des Softwareengineering sogenannte Softwareengineeringmodelle zunächst theoretisch entwickelt worden. Basis für diese "Produktionsmodelle" bildet jeweils ein sogenanntes Phasenmodell. Diese Modelle beschreiben die Produktionsschritte, in denen das Produkt Software erstellt wird und sie definieren die während der Produktion anfallenden Zwischenprodukte.

Weiterhin werden in einem Softwareengineeringmodell die konstruktiven Methoden für den Erstellungsprozeß festgelegt und die Zuordnung von Werkzeugen zu den verschiedenen Entwicklungsphasen vorgenommen.

Ziel eines Softwareengineeringmodells ist es, zu einem planvollen und methodisch aufgebauten SW-Produktionsprozeß zu gelangen und die bei der Produktion anfallenden Zwischenprodukte inhaltlich und formal festzulegen (zum Beispiel durch firmeninterne Standards).

In Abbildung 1 ist ein Phasenmodell für Software dargestellt, mit der Zuordnung der konstruktiven und analytischen Maßnahmen zu den verschiedenen Entwicklungsstufen. In diesem Beispiel werden die Zwischenprodukte Anforderung (Pflichtenheft), Entwurf und Programme als Ergebnisse der ersten drei Phasen festgelegt. Mit Abschluß der vierten Phase liegt das Endprodukt vor. Nahezu alle Standards und Empfehlungen nationaler und internationaler regelgebender Organisationen schreiben die Anwendung solcher oder gleichartiger Phasenmodelle vor.

Qualitätssicherung wächst in neue Dimensionen

Anhand eines Qualitätskreises für Software, der dem Qualitätskreis der DIN 55350 für technische Produkte nachempfunden ist (Abbildung 2), lassen sich die Aufgaben der Qualitätssicherung in einem SE-Modell diskutieren. Die Qualitätssicherung kümmert sich sowohl um die Qualität der Zwischenprodukte bei der Softwareproduktion als auch um die Qualität der eingesetzten Werkzeuge und Testmethoden.

Eine weitere Aufgabe der Qualitätssicherung ist es, die Qualität von Software zu bewerten und damit sicherzustellen, daß für ein Unternehmen geeignete Software beschafft wird. Diese Aufgabe wird häufig übersehen. Sie gewinnt aber zunehmend an Bedeutung, da viele Unternehmen die notwendige Software entweder fremderstellen lassen oder Standardsoftware kaufen. Bei der Beschaffung von Software steht der Vergleich der Anforderungen mit dem Produkt im Vordergrund.

Methoden zur Qualitätsbewertung von Software und von Zwischenprodukten im Softwareerstellungsprozeß sind nötig, um festzustellen, ob die Qualitätsziele bei der Softwareentwicklung erreicht wurden oder ob ein zu beschaffendes Softwareprodukt die geforderten Qualitätseigenschaften besitzt.

Mindestanforderungen an SW Güte sind festgelegt

Qualitätsbewertung und im Zusammenhang damit Qualitätsmessung sind derzeit noch stark innovative Themen, was insbesondere dadurch dokumentiert wird, daß die ersten systematischen Untersuchungen zu diesem Problembereich erst Anfang der 70er Jahre durchgeführt wurden.

Für die Bewertung der Qualität eines auf dem Markt angebotenen Softwareproduktes gibt es in Deutschland eine Vornorm des DIN (DIN V 66285). Hier sind Mindestanforderungen an die Güte einer Software formuliert. Die Güte oder Qualitätsanforderung an Software ist im Rahmen dieser Norm weitgehend unabhängig von dem vorgesehenen Einsatzzweck der Software definiert. Nicht behandelt wird dabei die Frage nach der Eignung einer Software für den vorgesehenen Einsatzzweck.

Der Haupteinwand gegen den Einsatz von SW-Engineering bezieht sich auf das sogenannte magische Dreieck Qualität, Kosten und Termine. Eine typische Meinung ist dabei, daß die Anwendung von Softwareengineeringmethoden im Softwareerstellungsprozeß derart zeit- und kostenaufwendig sei, daß die Kosten und Termine eines Projektes gefährdet würden.

Dieser Kritik läßt sich eine Reihe von Argumenten gegenüberstellen: Ein Softwareingenieur, der Methoden beherrscht und das Handwerkszeug richtig benutzten kann, wird seine Arbeit weitaus effektiver erledigen können als der "Erfinder". Fehlt die Ausbildung der beteiligten Mitarbeiter, so ist die Investition in ein Softwareengineeringkonzept nutzlos.

SW-Nachbesserung ist oft teurer als die Erstellung

Software ist als Produkt und Investition zu sehen, das heißt, die für die Auswahl eines SW-Produktes maßgeblichen Kriterien müssen vor der Beschaffung festliegen. Dazu gehören auch Qualitatskriterien. Das Softwareengineering liefert hier entscheidende Hinweise darauf, wie solche Anforderungen ermittelt werden und was sie berücksichtigen sollen. Die Beschränkung auf vordefinierte Ziele spart Kosten und sichert Termine.

Die Kosten für Nachbesserungen und Änderungen können höher sein als die Kosten für die Erstellung einer Software. Nachbesserungen und Änderungen sind dann besonders teuer, wenn die Software schlecht konstruiert oder unvollständig ist, das heißt es fehlen zum Beispiel die Dokumente der Entwicklung. Eine Software, die gut konstruiert und vollständig ist, läßt sich in ihrer Leistungsfähigkeit relativ kostengünstig erweitern.

*Werner Philipp ist Leiter des Bereiches Softwareengineering und -qualitätssicherung beim Rheinisch-Westfälischen TÜV in Essen.