nach oben
Meine Merkliste
Ihre Merklisteneinträge speichern
Wenn Sie weitere Inhalte zu Ihrer Merkliste hinzufügen möchten, melden Sie sich bitte an. Wenn Sie noch kein Benutzerkonto haben, registrieren Sie sich bitte im Hanser Kundencenter.

» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.
Ihre Merklisten
Wenn Sie Ihre Merklisten bei Ihrem nächsten Besuch wieder verwenden möchten, melden Sie sich bitte an oder registrieren Sie sich im Hanser Kundencenter.
» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.

« Zurück

Ihre Vorteile im Überblick

  • Ein Login für alle Hanser Fachportale
  • Individuelle Startseite und damit schneller Zugriff auf bevorzugte Inhalte
  • Exklusiver Zugriff auf ausgewählte Inhalte
  • Persönliche Merklisten über alle Hanser Fachportale
  • Zentrale Verwaltung Ihrer persönlichen Daten und Newsletter-Abonnements

Jetzt registrieren
Merken Gemerkt
Software-Qualität - Softwareentwicklungsprozess

Der Softwareentwicklungsprozess

Organisation und Management von Projekten sind ein zentrales Anliegen der Softwaretechnik. Die produktorientierten Tätigkeiten sind in prozessorientierte Tätigkeiten eingebettet, die sie ermöglichen. Dieser Zusammenhang wird in Abbildung 1 (in Anlehnung an [Andersen 90] verdeutlicht.

Abb. 1. Produkt- und prozeßorientierte Tätigkeiten bei der Softwareentwicklung

Abb. 1. Produkt- und prozeßorientierte Tätigkeiten bei der Softwareentwicklung

B. Meyer fordert in [Meyer 97] den Übergang von einem prozessorientierten zu einem produktorientierten Vorgehensmodell, in dessen Mittelpunkt die Bereitstellung von Dienstleistungen (in Form von Klassenbibliotheken) für ein Anwendungssystem steht. Durch diese Orientierung soll die Herstellung wiederverwendbarer Designelemente unterstützt werden.

Beteiligte bei der Softwareentwicklung

Traditionell sind die Rollen „Softwareproduzent“ und „Auftraggeber“, wobei die einen das produzieren, was die anderen in eindeutiger Form bestellen. Diese Rollenverteilung macht nicht deutlich, dass bei der Softwareentwicklung anwendungsfachliches und softwaretechnisches Wissen zusammenkommen müssen und dass damit oft tiefgreifende betriebliche Veränderungen einhergehen.

Softwareentwicklung tangiert die Belange von Personengruppen mit unterschiedlichen Interessen und Zielen, sie ist mit übergreifenden Zielen der beteiligten Organisationen verbunden und unterliegt ökonomischen Erfordernissen [Nygaard 86]. In einer erweiterten Sicht wird Softwareentwicklung als Dienstleistung gesehen [Naur 92].

Entsprechend liegt eine stärkere Rollendifferenzierung der beteiligten Gruppen nahe, zumindest:

  • Auftraggeber und Softwarehersteller sind auf rechtlicher und organisatorischer Ebene die Vertragspartner eines Softwareprojektes, auch wenn dies innerhalb einer Organisation durchgeführt wird.
  • Die Entwickler , d.h. alle Mitglieder des Entwicklerteams, repräsentieren als Analytiker, Designer oder Programmierer das softwaretechnische Wissen. Die Verantwortung für ein Softwareprojekt trägt das Entwicklungsmanagement .
  • Die Anwender setzen direkt oder indirekt das Softwaresystem ein und repräsentieren das Anwendungswissen. Dabei ist die Rolle der unmittelbaren Benutzer des Systems herauszuheben.
  • Schließlich entscheidet das Anwendungsmanagement über die Verwendung des Systems im Einsatzkontext.

In der Softwaretechnik wurden daher auch geeignete Formen der Zusammenarbeit entwickelt. Von großer Bedeutung sind dabei Leitbilder, die sowohl für die Gestaltung von Anwendungssoftware als auch für den Entwicklungsprozeß selbst Orientierung geben.

Leitbilder bei der Softwareentwicklung

Ein Leitbild in der Softwareentwicklung charakterisiert die jeweils vorherrschende Sichtweise für die Gestaltung von Softwaresystemen. Damit bestimmt es, wie der jeweils betrachtete Ausschnitt von Realität wahrgenommen, verstanden und gestaltet wird. Ein Leitbild umfasst immer auch eine Wertvorstellung und eine Rollenzuweisung für Benutzer und Entwickler. Es ist damit für die Softwareentwicklung von großer Bedeutung.

Auch für den Entwicklungsprozess selbst haben Leitbilder eine Bedeutung. Die engere Sicht der Softwaretechnik sieht Softwareentwicklung als industrielle Produktion . Dabei kann die Herstellung von Software von ihrem Einsatz getrennt werden. Die Herstellung basiert auf fixierten schriftlichen Anforderungen. Die Produktion geschieht möglichst arbeitsteilig und personenunabhängig unter Einsatz weitgehend formalisierter Verfahren und Hilfsmittel. Dabei wird oft die Metapher von der Softwarefabrik verwendet.

Ein alternatives Leitbild sieht Softwareentwicklung als Design [Floyd 94]. Im Vordergrund steht dabei die Verständigung zwischen den Beteiligten und die Einbettung von Software in einen veränderlichen Einsatzkontext. Design betrifft sowohl das Produkt Software und seinen Gebrauch als auch den Entwicklungsprozess und seine methodische Unterstützung. Dieser wird als wechselseitiger Lernprozess aufgefasst, mit ineinandergreifenden Zyklen von Analyse, Synthese, Bewertung und Revision.

Kooperation und Koordination

Teammodelle

Sie beschreiben Formen der Zusammenarbeit bei der Softwareentwicklung. Sie definieren Rollen wie Projektleiter, Entwickler, Tester, Projektverwalter und ihre Aufgaben. Sie legen Kommunikations- und Berichtswege fest und ordnen Verantwortlichkeiten für Ergebnisse zu. Maßgeblich geprägt wurde die Diskussion durch das hierarchische Chefprogrammiererteam, in dem der Projektleiter die Gesamtverantwortung trägt und das der Top-Down-Vorgehensweise entspricht. Ganz anders ist das demokratische Team aufgebaut, in dem gleichberechtigte Team-Mitglieder sich ihre Ordnung selbst definieren (siehe [Pasch 94]).

Koordination des Entwicklungsprozesses

Projektmanagement bedeutet, die Kommunikation im Team zu sichern, die Fertigstellung und Überprüfung von Zwischenergebnissen zu gewährleisten, auf Termineinhaltung zu achten und Qualitätssicherung einzuplanen (siehe z.B. [Andersen 90]). Bei der Projektetablierung werden die Ziele vereinbart und die Grundlagen der Zusammenarbeit geklärt. Im laufenden Projekt dienen Referenzlinien der Sicherung von Zwischenergebnissen aufgrund von Autor-Kritiker-Zyklen und strukturierten Reviews. Projektstadien oder Meilensteine gestatten die Überprüfung von Projektzielen und Projektfortschritt sowie die Planung des weiteren Vorgehens an Hand von organisatorischen Randbedingungen.

Kooperation mit Anwendern

Der Zusammenarbeit mit den verschiedenen Beteiligten muss organisatorisch Rechnung getragen werden. Wesentlich ist dabei, das Mitspracherecht der Beteiligten zu klären und ihre Qualifikation voranzutreiben. Dazu gibt es verschiedene Organisationsmodelle, die je nach Projektsituation sinnvoll sind, z.B. partizipative Projekte mit direkter Entscheidungskompetenz von Benutzern, die Einrichtung eines Anwenderbetreuers oder eines Ombudsmanns für Benutzerbelange oder auch die Bildung von User-Groups, die die Interessen der Anwender vertreten. Darauf aufbauend gilt es, die Kommunikation über die Verwendung von Software im Einsatzkontext zuverlässig zu gestalten mit dem Ziel, die Gebrauchsqualität von Software zu gewährleisten (siehe auch Abschnitt "Qualitätssicherung").

Produkt- und Konfigurationsverwaltung

Ein Softwareprodukt setzt sich aus Programmen und definierenden Texten (Dokumenten) zusammen. Um die Anpassbarkeit zu erhöhen, wird Software häufig realisiert als

  • adaptierbare Grundversion mit Ausbaustufen,
  • Sammlung wiederverwendbarer Bausteine in Bibliotheken,
  • generisches Rahmenwerk mit jeweils spezifischen Anwendungskomponenten.

Die Aufgabe, das entstehende Produkt zu verwalten, beginnt bereits beim Entwurf. Dazu führt der Projektverwalter eine Projektbibliothek, die an Hand der Architektur des Softwaresystems aufgebaut wird und verschiedene Versionen der einzelnen Programmkomponenten enthält (siehe [Denert 91]). Während der Entwicklung wird zum Beispiel die Arbeitsversion von der Testversion und der freigegebenen Version unterschieden, die einer geordneten Zustandsüberführung unterworfen werden. Nach der Auslieferung muss eine Produktverwaltung gewährleisten, die Historie der aufeinanderfolgenden Versionen und die Vielfalt parallel existierender Varianten so verfügbar zu machen, dass die Bildung von lauffähigen Konfigurationen nach verschiedenen Gesichtspunkten möglich wird.

Qualitätssicherung

Unter Qualitätssicherung versteht man die Summe aller Maßnahmen, die die Qualität des entstehenden Produktes gewährleisten sollen (zum Stand der Technik vgl. [Wallmüller 90, Knöll 96, Balzert 96]).

Für Softwareprojekte ist die konstruktive Qualitätssicherung von besonderer Bedeutung. Sie basiert auf dem Einsatz von Methoden, Werkzeugen, Konstruktionsprinzipien, formalen Verfahren und Vorgehensmodellen und betrifft die Gebrauchsqualität, die Produktqualität und die Prozessqualität (siehe Abschnitt "Sicherung der Prozessqualität").

Die analytische Qualitätssicherung prüft, ob bestimmte Qualitätsmerkmale in einer bereits entwickelten Softwarekomponente vorhanden sind. Dazu zählen zunächst statische Analysen, bei denen das Prüfobjekt nicht ausgeführt wird. Beispiele sind der Einsatz von Metriken, die verschiedenen informellen Verfahren wie Review und Audit, aber auch der Einsatz von Analysewerkzeugen und von formalen Verifikationsmethoden. Die dynamische Analyse kommt in der Praxis als Testen vor.

Testen

Beim Testen wird ein Programm ausgeführt, um Fehler zu finden (siehe [Myers 95, Schmitz 83, Liggesmeyer 93, Riedemann 97]). In der Literatur werden Black-Box-Test und White-Box-Test unterschieden. Beim Black-Box-Test wird ein Programm nur an Hand seiner Spezifikation getestet. Beim White-Box-Test wird der innere Aufbau eines Programms mit berücksichtigt, um etwa die Anweisungen oder Programmzweige zu überdecken. Der White-Box-Test ist für den vom jeweiligen Entwickler durchzuführenden Komponententest wichtig.


Darüber hinausgehende Teststufen werden häufig von einer eigenen Testgruppe durchgeführt. Der Integrationstest erfordert eine Teststrategie (z.B. Top-Down, Bottom-Up) zur Zusammensetzung der einzelnen Komponenten, eine Testorganisation (Auswahl und Zusammensetzung einzelner Testfälle) und die technische Unterstützung, z.B. durch Testtreiber (siehe [Denert 91]). Der Systemtest soll die Funktionsfähigkeit des gesamten Systems entsprechend der Spezifikation sicherstellen. Der Abnahmetest findet in der Regel unter echten Einsatzbedingungen statt.

Das prinzipielle Problem des Testens besteht darin, dass Testen nur die Anwesenheit von Fehlern aufzeigen, aber niemals deren Abwesenheit beweisen kann. Ferner sind erschöpfende Tests wegen der Fülle der möglichen Eingaben und Programmzustände bei größeren Programmen nicht möglich.

Konstruktive Kritik

Informelle Analyseverfahren, wie Reviews, Audits oder Walk-Throughs, bei denen spezifizierende und dokumentierende Texte im Entwicklerteam oder von eigenen Gutachtergremien bewertet werden, sind von großer praktischer Bedeutung. Ihr Wert besteht darin, die „Blindheit“ des jeweiligen Autors zu überwinden, Sichtweisen verschiedener Beteiligter zusammenzubringen und so vertiefte Einsichten zu gewinnen und Einzelergebnisse in von der Gruppe getragene überzuführen und als solche zu verabschieden.

Evaluation

Die Gebrauchsqualität, d.h. die Eignung des Systems für Benutzung und Betrieb, kann meist nur durch Evaluation beim Einsatz beurteilt werden. In diesem Sinne ist die evolutionäre Systementwicklung als Ansatz zur konstruktiven Qualitätssicherung zu verstehen (siehe [Kilberth 94]). In eine ähnliche Richtung gehen Vorschläge, die Ideen des japanischen „Total Quality Management“ (TQM, siehe [Knöll 96]) auf die Softwareentwicklung zu übertragen, bei der die Qualitätswünsche der Kunden und deren Zufriedenheit die Unternehmensphilosophie bestimmen.

Sicherung der Prozessqualität

In den letzten Jahren sind unter dem Gesichtspunkt einer ingenieurmäßigen Entwicklung Ansätze vorgeschlagen worden, die sich auf die Qualität des Prozesses selbst beziehen. Von Bedeutung für die Praxis sind das Reifemodell des Softwareprozesses und vor allem die Bestimmung der Normen unter der allgemeinen Bezeichnung ISO 9000.

Reifemodell des Softwareprozesses

Dieses Modell (capability maturity model, [Paulk 93]) liefert eine Vorgehensweise, um den Softwareprozess – die Gesamtheit der Tätigkeiten bei der Softwareentwicklung – in einer Entwicklungsorganisation systematisch zu verbessern. Dazu ist es zunächst notwendig, ihren softwaretechnischen Stand und die Systematik ihres gegenwärtigen Softwareprozesses einzuschätzen. Die Basis bilden fünf Reifegrade (maturity levels). Sie definieren je eine Stufe des Softwareprozesses – „anfänglich“, „wiederholbar“, „definierbar“, „verwaltbar“ und „optimierbar“ – durch Angabe von Tätigkeiten zur Prozessverbesserung, von standardisierten Projekttätigkeiten und von Kennzeichen für die erreichte Güte.
Die Bedeutung des Reifemodells für die europäische Softwareentwicklung ist derzeit eher gering und auch für die USA noch schlecht einzuschätzen.

ISO 9000

Unter diesem Namen sind die gleichlautenden deutschen (DIN) und internationalen (ISO) Normen 9000 bis 9004 und die europäischen (EN) Normen 29000ff. für die Qualitätssicherung im Produktions- und Dienstleistungsbereich bekannt geworden. Sie umfassen ein Begriffssystem, die Darlegung von Elementen der Qualitätssicherung in unterschiedlichen Ausbaustufen und Empfehlungen zum Aufbau eines Qualitätssicherungssystems sowie eine Anleitung zur Verwendung der Normen selbst. Die vorgeschlagenen Qualitätssicherungssysteme umfassen z.B. die Festlegung von Verantwortlichkeiten, die Definition der Entwicklungs- und Prüfungsdokumente, die Dokumentation der Prüfverfahren und die Überprüfung von Verträgen. Für die Softwareentwicklung sind vor allem die Normen 9000 (Begriffssystem und Anwendungshinweise) sowie 9004 („Leitfaden für Dienstleistungen“) wichtig.

Ein Softwarehersteller kann sich bei einer Institution, die dafür durch die jeweilige Normungsinstitution autorisiert ist, nach ISO 9000 zertifizieren lassen. Wegen der damit verbundenen möglichen Wettbewerbsvorteile kommt diesen Normen eine große praktische Bedeutung zu – unabhängig von der bisweilen von Informatikern gestellten Frage, in welchem Ausmaß dadurch die Qualität der Software letztlich erhöht wird.

Literaturhinweis

[Andersen 90] Andersen, N. E.; Kensing, F.; Lundin, J.; Mathiassen, L.; Munk-Madsen, A.; Rasbech, M.; Sorgaard, P.: Professional systems development. New York: Prentice Hall 1990.

[Balzert 96] Balzert, H.: Lehrbuch der Software-Technik. Heidelberg: Spektrum Akad. Verlag 1996.

[Denert 91] Denert, E.: Software engineering: Methodische Projektabwicklung. Berlin: Springer 1991.

[Floyd 94] Floyd, C.: Software engineering – und dann? Informatik Spektrum 17/1 (1994) 29–37.

[Kilberth 94] Kilberth, K.; Gryczan, G.; Züllighoven, H.; Bäumer, D.; Budde, R.; Hasbron-Blume, K.; Sylla, K.-H.; Weimer, V.: Objektorientierte Anwendungsentwicklung. 2. Aufl. Braunschweig: Vieweg 1994.

[Knöll 96] Knöll, H.-D.; Slotos, T.; Suk, W.: Entwicklung und Qualitätssicherung von Anwendungssoftware. Heidelberg: Spektrum Akademischer Verlag 1996.

[Liggesmeyer 93] Liggesmeyer, P.: Modultest und Modulverifikation: State of the Art. Mannheim: BI Wissenschaftsverlag 1993.

[Meyer 97] Meyer, B.: Object-oriented software construction. 2nd ed. Upper Saddle River: Prentice-Hall 1997.

[Myers 95] Myers, G. J.: Methodisches Testen von Programmen. 5. Aufl. München: Oldenbourg 1995.

[Naur 92] Naur, P.: Programming as theory building. In: Naur, P.: Computing: A human activity. New York: ACM Press 1992.

[Nygaard 86] Nygaard, K.: Program development as social activity. In: Kugler, H. G. (ed.): Information Processing ’86 – Proceedings of the IFIP 10th world computer congress. Amsterdam: North-Holland (1986) 189–198.

[Pasch 94] Pasch, J.: Softwareentwicklung im Team. Berlin: Springer 1994.

[Paulk 93] Paulk, M. C.; Curtis, B.; Chrissis, M. B.; Weber, C. V.: Capability maturity model. Version 1.1. IEEE Software 10/44 (1993) 18–27.

[Riedemann 97] Riedemann, E. H.: Testmethoden für sequentielle und nebenläufige Software-Systeme. Stuttgart: Teubner 1997.

[Schmitz 83] Schmitz, P.; Bons, H.; van Mengen, R.: Software-Qualitätssicherung – Testen im Software-Lebenszyklus. Braunschweig: Vieweg 1983.

[Wallmüller 90] Wallmüller, E.: Software-Qualitätssicherung in der Praxis. München: Carl Hanser 1990.

Peter Rechenberg, Gustav Pomberger. Informatik-Handbuch . 3., aktualisierte und erweiterte Auflage. Hanser 2002, S. 780-784.

Weiterführende Information
  • Software-Qualität - Software-Qualität

    Der übliche Software-Qualitätsbegriff greift zu kurz

    Funktionalität allein bringt keinen dauerhaften Erfolg

    Die Praxis zeigt, dass bei der Entwicklung von Software Qualität flexibel einstellbar sein sollte. Gefragt ist eine ganzheitliche Sicht auf Qualität, die Zeit und Kosten spart.   mehr

DIN EN ISO 9001:2015

Zum ISO 9001:2015 Special

Prozesswelt

Serie zum Thema Prozesse, veröffentlicht von QM-Experten deutscher Unternehmen gemeinsam mit der N5 GmbH und der Fachzeitschrift QZ

Zur Prozesswelt