Vorgehensmodell zur Softwareentwicklung

Ein Vorgehensmodell zur Softwareentwicklung ist ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen („ingenieursmäßigen“) Anwendungsentwicklung. Es ist ein standardisierter, organisatorischer Rahmen für den idealen Ablauf eines Entwicklungsprojektes[1] und dient dazu, die Softwareentwicklung übersichtlicher zu gestalten und in der Komplexität beherrschbar zu machen.

Ein Vorgehensmodell ist eine abstrakte Darstellung eines Softwareprozesses. Der Prozess wird hierbei immer nur aus einer bestimmten Perspektive dargestellt[2]. Daher beinhaltet ein Vorgehensmodell immer nur einen Teil der Informationen über den Prozess. Dies hat allerdings den Vorteil, dass die den einzelnen Softwareprozessen zugrunde liegenden Prinzipien übersichtlich und verständlich dargestellt werden können.

Entwicklungsplan
Das Wasserfallmodell

Da komplexe Software nur schwer zu erstellen und zu warten ist, bedienen sich Softwareentwickler eines Planes zur Entwicklung von Software. Dieser Plan (das Vorgehensmodell) unterteilt den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenzte Phasen. Die Software wird somit Schritt für Schritt fertiggestellt. Der eigentliche Entwicklungsprozess wird dabei vom Projektmanagement und der Qualitätssicherung begleitet.

Vorgehensmodelle spalten einzelne Aktivitäten auf verschiedene Phasen im Entwicklungsprozess auf und diese werden dann – u. U. mit geringen Modifikationen – einmal (z. B. Wasserfallmodell) oder mehrmals durchlaufen (z. B. Spiralmodell).[3] Bei mehrmaligen Durchläufen erfolgt eine iterative (d. h. wiederholte) Verfeinerung der einzelnen Softwarekomponenten. Um die optimalen Vorgehensmodelle herrscht Uneinigkeit.[4] In der Regel unterscheiden sie beim Entwicklungsprozess mindestens zwei große Tätigkeitsgruppen: die (von der programmiertechnischen Realisierung unabhängige) Analyse von Geschäftsprozessen (Geschäftsprozessmodell und Datenmodell) einerseits und die EDV-technische Realisierung (Design und Programmierung) andererseits.

Vorgehensmodelle unterscheiden sich wesentlich in ihrem Detaillierungsgrad. OOTC-Approach, Rational Unified Process, Rapid Application Development etc. sind detailliert ausgearbeitete Vorgehensweisen, die den an der Entwicklung Beteiligten konkrete Arbeitsanweisungen an die Hand geben. Das V-Modell nimmt diesbezüglich übrigens eine Zwitterstellung ein: Es ist sowohl ein Prinzip (jeder Stufe der Entwicklung entspricht eine Testphase) als auch (wie zumeist gebräuchlich) ein detailliertes Modell, siehe auch V-Modell (Entwicklungsstandard).

Die agile Softwareentwicklung beschäftigt sich mit Methoden, die den Entwickler kreativ arbeiten und Verwaltungsaspekte zurücktreten lassen. Alternative Softwaretechnologien (Universal Application, Software factory u. ä.) verfolgen Ansätze, welche die konventionelle Vorgehensweise von Softwareentwurf und anschließender Programmierung grundsätzlich in Frage stellen, indem vorgefertigte universalisierte Software per Konfiguration an die jeweiligen Anforderungen angepasst wird.

Es gibt verschiedene Bewertungsverfahren für den Softwareprozess, u. a. das Capability Maturity Model (Integration) oder „Spice“.

Typen von Vorgehensmodellen
Vorgehensmodell - schematische Darstellung

Es gibt drei unterschiedliche Typen von Vorgehensmodellen bestehend aus mehreren Elementen, die kompakt in der folgenden Grafik dargestellt sind.[5] Folgendes sind die Typen von Vorgehensmodellen:

Softwareentwicklungsprozesse dienen zur Steuerung einer Softwareentwicklung von der Konzeption bis zum Einsatz im Echtbetrieb inklusive der im Echtbetrieb anfallenden Änderungen einer Software. Eines der ältesten Modelle ist das Wasserfallmodell, das eine starre Abfolge der einzelnen Phasen annimmt. Weiterentwicklungen wie das Spiralmodell sehen hingegen Iterationen vor, d. h. derselbe Arbeitsschritt (z. B. die Analyse) wird mehrmals durchlaufen und die Ergebnisse des Arbeitsschrittes pro Durchlauf verfeinert und verbessert.

Siehe auch: Liste von Softwareentwicklungsprozessen

Softwarelebenszyklusmanagement erweitert die Phasen über den gesamten Lebenszyklus einer Software. Das Vorgehensmodell definiert die Anforderungen an betriebliche Prozesse (das „WAS“) und beschreibt die konkreten, EDV-technisch realisierten Prozesse (das „WIE“). Dieser Typ ist eine Mischung aus Ist-Beschreibung und normativer Vorgabe. Je nach Standardisierungsgrad werden verschiedene Entwicklungsstufen vergeben. Unternehmen können sich diese Entwicklungsstufen von externen Stellen zertifizieren lassen.

Softwareentwicklungs-Philosophie entspricht einer Programmierer-Philosophie, einem bestimmten Ansatz, wie Software nach Ansicht der Proponenten am besten entwickelt werden sollte. Diese Philosophien beinhalten sehr oft auch Prozesselemente und werden daher ebenfalls als Prozessmodell bezeichnet.

Kritik

Positives
  • Ein genereller Vorteil von Vorgehensmodellen ist, dass Projektmanagement-Prozesse, Qualitätssicherungsprozesse und der eigentliche produkterstellende Prozess gemeinsam abgebildet werden.
  • Ein zielgerichtetes Vorgehen verbessert die Übersichtlichkeit des Gesamtprojektes, die Koordination von Teams und hilft, Fehler frühzeitig zu erkennen. Dies wirkt sich in der Regel positiv auf die Qualität des gesamten Systems aus bzw. erlaubt eine genaue Rekonstruktion des Entwicklungsprozesses und der zu Grunde liegenden Entscheidungen.
  • Vorteile eines Vorgehens nach einem Vorgehensmodell:
    • Trennung der Analyse von Geschäftsprozessen (WAS) von EDV-technischer Realisierung (WIE)
    • Leitfaden für die Systementwicklung
    • projektbegleitende Dokumentation
    • Personenunabhängigkeit
    • frühzeitige Fehlererkennung durch festgeschriebene Testaktivitäten
  • Vorgehensmodelle geben einen Rahmen vor, in dem ein Projekt geordnet ablaufen kann. Das Vorgehensmodell hilft dabei, den Ablauf eines Projektes zu strukturieren und nachzuvollziehen, da es den Prozess und die Dokumente der Softwareerstellung beschreibt. Die Güte der zu erstellenden Software ist demgegenüber auch von den Projektbeteiligten abhängig. Es ist wichtig, dass sie ein großes Vorwissen besitzen, gut zusammenarbeiten und ihrem gesunden Menschenverstand vertrauen. Der Projekterfolg und nicht das Vorgehensmodell ist das primäre Ziel.

Negatives
  • Es existierten mehrere Vorschläge parallel zueinander, ohne dass sich eines der Vorgehensmodelle in der Praxis mit Breitenwirkung durchgesetzt hätte.
  • Die Anbieter von Vorgehensmodellen sind voreingenommen. Vorgehensmodelle sind ein Geschäft, daher berät der Entwickler eines Vorgehensmodells in seinem Interesse. Anbieter stellen gerade ihr Modell als das Allheilmittel für alle Probleme dar. Hier liegt der Grundstein für eine Folge dem Prozess und alles wird gut-Mentalität. Ein Projekt scheitert dann, wenn die Beteiligten es nicht mehr objektiv betrachten und beispielsweise nur die vorgegebenen Checklisten abarbeiten.
  • Aufgrund der Projektstruktur, die ein Vorgehensmodell erzeugt, bietet eine Unternehmensberatung für jede Einzeltätigkeit spezialisierte Berater an. Durch die Zersplitterung der Aufgaben auf Einzelspezialisten steigt der Koordinierungsaufwand überproportional.
  • Vorgehensmodelle können dem Parkinsonschen Gesetz für Verwaltung und Management zur vollen Blüte verhelfen, da sie die Möglichkeit eröffnen, neue Mitarbeiter für neue Aufgaben nach Vorgehensmodell anzufordern. Betroffen von diesem Phänomen sind besonders solche Einrichtungen, die keiner engen wirtschaftlichen Kontrolle unterliegen, weil sie nicht zahlungsunfähig werden können (Behörde, Amt und Anstalt des öffentlichen Rechts). Als Warnung mögen die bis zum Jahr 2004 gescheiterten, erheblich verzögerten, sich als ungeeignet herausgestellten und/oder erheblich verteuerten Softwareprojekte der öffentlichen Hand, wie INPOL-Neu (Polizei), Nivadis (Polizei Niedersachsen), FISCUS (Finanzamt), Herkules (Bundeswehr), Online-Jobbörse (Arbeitsagentur), Toll Collect, A2LL (Arbeitsagentur, „Hartz IV“-Software), POLIKS (Polizei Berlin) etc. dienen.
  • Es ist umstritten, ob der Entstehungsprozess von Software so gut verstanden wird, dass eine „ingenieurmäßige Herstellung“ möglich ist: Kritiker argumentieren, dass Software nichts anderes sei als „ausführbares Wissen“. Wissen jedoch lasse sich nicht ingenieurmäßig herstellen (wie sich etwa eine Brücke oder ein Hochhaus herstellen lässt), sondern werde in einem kreativen Prozess gefunden. Die Gegenposition argumentiert, dass gerade in dem „kreativen Prozess“ die Gefahr von Wartungsproblemen und struktureller Unsauberkeit liegt. Das Argument der Kritiker gelte für andere technische Entwicklungsprozesse (z. B. Bau einer Brücke, eines Hauses, einer Fabrik) auch nicht.

Literatur
  • Tilo Pfeifer, Robert Schmitt (Herausgeber): Qualitätsmanagement in der Softwareentwicklung, Teil IV in: Masing Handbuch Qualitätsmanagement, Carl Hanser Fachbuchverlag München Wien, 6. überarbeitete Auflage (2014), ISBN 978-3-446-43431-8
Commons: Vorgehensmodell zur Softwareentwicklung – Sammlung von Bildern, Videos und Audiodateien

Einzelnachweise
  1. Gnatz, M., Vom Vorgehensmodell zum Projektplan, Diss., München, 2005.
  2. Markus Janker: (Ways to Improve) Software Economics, Universität Salzburg, studentische Arbeit, 21. Mai 2002, Online auf cosy.sbg.ac.at (archiviert von archive.org am 18. September 2004, abgerufen am 27. Februar 2007).
  3. Winston W. Royce: Managing the Development of Large Software Systems. In: Technical Papers of Western Electronic Show and Convention. Los Angeles August 1970, S. 330 (englisch, praxisframework.org [PDF]).
  4. Wolfgang Hesse: Software-Projektmanagement braucht klare Strukturen - Kritische Anmerkungen zum "Rational Unified Process". In: Jürgen Ebert, Ulrich Frank (Hrsg.): Modelle und Modellierungssprachen in Informatik und Wirtschaftsinformatik: Beiträge des Workshops "Modellierung 2000" St. Goar. Fölbach, Koblenz 2000, ISBN 978-3-934795-15-0, S. 143–150 (uni-marburg.de [PDF; abgerufen am 11. Januar 2024]).
  5. Sascha Alpers: Notwendigkeit der Integration von ethischen, rechtlichen und sozialen Aspekten in die gängigen Vorgehensmodelle für IT-Projekte. In: Masud Fazal-Baqaie et al. (Hrsg.): Projektmanagement und Vorgehensmodelle, Lecture Notes in Informatics. Gesellschaft für Informatik e.V., Bonn 2022, ISBN 978-3-88579-721-0, S. 173 (gi.de [abgerufen am 9. Januar 2024]).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.