imported>Michileo am 12. März 2026 um 17:30 Uhr

2026-03-12T17:30:57Z

Neue Seite

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<ref>Gnatz, M., Vom Vorgehensmodell zum Projektplan, Diss., München, 2005.</ref> 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<ref>Markus Janker: ''(Ways to Improve) Software Economics'', ''Universität Salzburg'', studentische Arbeit, 21. Mai 2002, [https://web.archive.org/web/20040918080320/http://www.cosy.sbg.ac.at/~pmm/teaching/SS02/se/papers/0020025.pdf Online auf cosy.sbg.ac.at] (archiviert von ''archive.org'' am 18. September 2004, abgerufen am 27. Februar 2007).</ref>. 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 ==
[[Datei:Waterfall model-de.svg|mini|300px|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]]).<ref>{{Literatur |Autor=Winston W. Royce |Titel=Managing the Development of Large Software Systems |Sammelwerk=Technical Papers of Western Electronic Show and Convention |Ort=Los Angeles |Datum=1970-08 |Sprache=en |Seiten=330 |Online=https://www.praxisframework.org/files/royce1970.pdf}}</ref> Bei mehrmaligen Durchläufen erfolgt eine [[Iteration|iterative]] (d. h. wiederholte) Verfeinerung der einzelnen Softwarekomponenten. Um die optimalen Vorgehensmodelle herrscht Uneinigkeit.<ref>{{Literatur |Autor=Wolfgang Hesse |Titel=Software-Projektmanagement braucht klare Strukturen - Kritische Anmerkungen zum "Rational Unified Process" |Hrsg=Jürgen Ebert, Ulrich Frank |Sammelwerk=Modelle und Modellierungssprachen in Informatik und Wirtschaftsinformatik: Beiträge des Workshops "Modellierung 2000" St. Goar |Verlag=Fölbach |Ort=Koblenz |Datum=2000 |ISBN=978-3-934795-15-0 |Seiten=143-150 |Online=https://www.mathematik.uni-marburg.de/~hesse/papers/Hes_00a.pdf |Abruf=2024-01-11}}</ref> 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 [[Kreativität|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 „[[ISO/IEC 15504|Spice]]“.

== Typen von Vorgehensmodellen ==
[[Datei:Vorgehensmodell.png|mini|Vorgehensmodell – schematische Darstellung]]
Es gibt drei unterschiedliche Typen von Vorgehensmodellen bestehend aus mehreren Elementen, die kompakt in der folgenden Grafik dargestellt sind.<ref>{{Literatur |Autor=Sascha Alpers |Titel=Notwendigkeit der Integration von ethischen, rechtlichen und sozialen Aspekten in die gängigen Vorgehensmodelle für IT-Projekte |Hrsg=Masud Fazal-Baqaie et al. |Sammelwerk=Projektmanagement und Vorgehensmodelle, Lecture Notes in Informatics |Verlag=Gesellschaft für Informatik e. V. |Ort=Bonn |Datum=2022 |ISBN=978-3-88579-721-0 |Seiten=173 |Online=https://dl.gi.de/handle/20.500.12116/39672 |Abruf=2024-01-09}}</ref> 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 [[Software-Lebenszyklus|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.
* Norm [[ISO/IEC 12207]]
* [[Capability Maturity Model]] (CMM)
* [[Capability Maturity Model Integration]] (CMMI)

'''Softwareentwicklungs-Philosophie''' entspricht einer Programmierer-Philosophie, einem bestimmten Ansatz, wie Software nach Ansicht der [[Proponent]]en ''am besten'' entwickelt werden sollte. Diese Philosophien beinhalten sehr oft auch Prozesselemente und werden daher ebenfalls als Prozessmodell bezeichnet.
* [[Extreme Programming]]
* [[Prototyping (Softwareentwicklung)|Prototyping]]
* [[Rational Unified Process]]
* [[Scrum]]
* [[Kanban (Entwicklung)|Kanban]]

== Kritik ==
{{Belege fehlen}}

=== 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 [[Checkliste]]n 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 [[Parkinsonsches Gesetz|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 (IT-Projekt)|Herkules]] (Bundeswehr), Online-Jobbörse (Arbeitsagentur), [[Toll Collect]], [[A2LL]] (Arbeitsagentur, „[[Arbeitslosengeld II|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.

== Weblinks ==
{{Commonscat|Software development methodology|Vorgehensmodell zur Softwareentwicklung}}
* [https://fg-wi-vm.gi.de/ ''Fachgruppe Vorgehensmodelle für die betriebliche Anwendungsentwicklung.''] In: [[Gesellschaft für Informatik]]
* Andreas Kitz: {{Webarchiv |url=http://www.projekthandbuch.de/it_model.htm |text=''Vorgehensmodell für IT-Projekte.'' |wayback=20221205235128}} In: ''projekthandbuch.de''

== Einzelnachweise ==
<references />

{{SORTIERUNG:Vorgehensmodell Zur Softwareentwicklung}}
[[Kategorie:Vorgehensmodell (Software)| ]]

[[ar:عملية تطوير البرمجيات]]
[[fa:فرآیند تولید نرم‌افزار]]
[[ja:ソフトウェア開発工程]]
[[ko:소프트웨어 개발 프로세스]]
[[pt:Processo de desenvolvimento de software]]
[[vi:Quy trình phát triển phần mềm]]
[[zh:软件开发过程]]

Vorgehensmodell zur Softwareentwicklung - Versionsgeschichte

imported>Michileo am 12. März 2026 um 17:30 Uhr