imported>Millbart: 2 Versionen von 262745386 bis 262754090 rückgängig gemacht, unbrauch gem. WP:Belege und WP:KI

2026-04-06T14:23:22Z

2 Versionen von 262745386 bis 262754090 rückgängig gemacht, unbrauch gem. WP:Belege und WP:KI

Neue Seite

Die '''Softwaretechnik''' bzw. '''Softwaretechnologie''' oder das '''Software-Engineering''' ('''SE''') beschäftigt sich mit der Herstellung oder Entwicklung von [[Software]], der Organisation und Modellierung der zugehörigen [[Datenstruktur]]en und dem Betrieb von [[Softwaresystem]]en. Eine Definition von [[Helmut Balzert]] beschreibt das Gebiet als

{{Zitat
|Text=Zielorientierte Bereitstellung und systematische Verwendung von [[Prinzip]]ien, Methoden und [[Werkzeug]]en für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.
|Autor=
|Quelle=[[#Literatur|Lit.]]: Balzert, S. 36}}

Softwaretechnik umfasst eine Vielzahl von Teilgebieten, die in ihrer Gesamtheit die Softwareentwicklung begleiten. Wichtig ist auch die experimentelle Untersuchung von Softwaretechnik, um ihren praktischen Nutzen zu messen und zu verbessern. Zur Beschreibung des „Standes der Technik“ des Fachgebiets gibt es verschiedene Ansätze, unter anderem den ''Guide to the [[Software Engineering Body of Knowledge]] (SWEBOK)'' der [[IEEE Computer Society]].

Die IT-Disziplin Softwaretechnik wird im Sprachgebrauch und als Synonym mit „Softwareentwicklung“ bezeichnet;<ref>[https://www.lerneprogrammieren.com/blog/theorie/programmierung-vs-softwareentwicklung Lerne programmieren ''Programmierung vs. Softwareentwicklung'']</ref> im sprachlich engeren Sinn steht „Softwareentwicklung“ jedoch für die Tätigkeiten, die innerhalb der Disziplin Softwaretechnik ausgeführt werden.

In erweitertem Sinn versteht man unter Softwaretechnik – neben dem Entwickeln – auch das Betreiben von Software unter Nutzung der [[Informationstechnik]] und/oder die technischen Geräte und die [[Systemsoftware]], die dazu oder zur Softwareentwicklung verwendet werden.

== Teilgebiete ==
Aufgrund des hohen Aufwandes zur Erstellung und Wartung komplexer Software erfolgt die Entwicklung durch [[Softwareentwickler]] anhand eines strukturierten (Projekt-)Planes. Dieser Plan (das [[Vorgehensmodell zur Softwareentwicklung|Vorgehensmodell]]) unterteilt den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenzte Phasen. Die Software wird somit Schritt für Schritt fertiggestellt. Die Phasen sind während des ganzen Entwicklungsprozesses eng miteinander verzahnt. In der Praxis werden auch Verfahren eingesetzt, welche die Mehrstufigkeit von Systemanalyse, Systemdesign/Konzept und anschließender Implementierung und Testen aufgeben, beispielsweise unter [[Prototyping (Softwareentwicklung)|Prototyping]], [[Agile Softwareentwicklung]].

Die Softwaretechnik umfasst den gesamten Prozess von der Identifizierung des Bedarfs bis hin zur Inbetriebnahme einer konkreten IT-Lösung, zum Teil auch darüber hinaus. Hauptgegenstand ist die Bereitstellung und Einführung einer [[Anwendungssoftware]], teilweise zuzüglich der benötigten [[Hardware]] und [[Netzwerk]]e.

Die zu implementierende Software kann entweder eine [[Individualsoftware]] oder eine Kombination und Konfiguration von [[Standardsoftware]] sein.

Projekte werden oftmals von oder mit externen Dienstleistungsunternehmen, häufig aber auch als Eigenentwicklung geleistet. Dementsprechend vielfältig, auch abhängig von der [[Projekt#Projektarten|Projektart]], sind auch die [[Vorgehensmodell|Vorgehensweisen]] bei der Projektentwicklung: Von einer sehr strukturierten Herangehensweise, siehe [[Wasserfallmodell]], über verschiedene Mischformen bis hin zu sehr flexiblen, offenen Methoden wie der [[Agile Softwareentwicklung|Agilen Softwareentwicklung]]. Entsprechend wird auch zwischen [[Top-Down- und Bottom-Up-Design|Top-Down- und Bottom-Up]]-Ansätzen unterschieden.

Im Folgenden werden einige wichtige Aspekte und typische Stufen/Phasen der Projektentwicklung beschrieben, die in der Praxis mehr oder weniger ausgeprägt zum Tragen kommen.

Die Phasen und ihre Aufgabenstellungen sind in der folgenden Tabelle aufgeführt:
{| cellspacing="15"
|
'''Kernprozesse'''

'''1. [[Planung]]'''
* [[Anforderungserhebung]]
* [[Lastenheft]] ([[Anforderung (Informatik)|Anforderungsdefinition]])
* [[Pflichtenheft]] (mit technischen Ansätzen verfeinertes [[Lastenheft]])
* [[Aufwandsschätzung (Softwaretechnik)|Aufwandsschätzung]] (z. B. mittels [[Function-Point-Verfahren]] oder [[COCOMO]])
* [[Vorgehensmodell zur Softwareentwicklung|Vorgehensmodell]]

'''2. [[Analyse]]'''
* [[Auswertung (Informatik)|Auswertung]]
* [[Mock-up]]
* [[Prozessanalyse]] / [[Vorgehensmodell zur Softwareentwicklung|Prozessmodell]]
* [[Systemanalyse]]
* [[Strukturierte Analyse (Methode im Rahmen der Softwareentwicklung)|Strukturierte Analyse]] (SA)
* [[Objektorientierte Analyse und Design|Objektorientierte Analyse]] (OOA)
'''3. [[Softwaredesign|Entwurf]]'''
* [[Softwarearchitektur]]
* [[Strukturiertes Design]] (SD)
* [[Objektorientierte Analyse und Design|Objektorientiertes Design]] (OOD)
* [[Fundamental Modeling Concepts]] (FMC)

'''4. [[Programmierung]]'''
* [[Normierte Programmierung]]
* [[Strukturierte Programmierung]]
* [[Objektorientierte Programmierung]] (OOP)
* [[Funktionale Programmierung]]

'''5. [[Softwaretest|Validierung und Verifikation]]'''
* [[Modultest]]s (Low-Level-Test)
* [[Integrationstest]]s (Low-Level-Test)
* [[Softwaretest|Systemtests]] (High-Level-Test)
* [[Akzeptanztest (Softwaretechnik)|Akzeptanztests]] (High-Level-Test)

| valign="top" |

'''Unterstützungsprozesse'''

'''6. [[Anforderungsmanagement]]'''

'''7. [[Projektmanagement]]'''
* [[Risikomanagement#Software-Risiken|Risikomanagement]]
* [[Projektplanung]]
* Projektverfolgung und -steuerung
* Management von Lieferantenvereinbarungen

'''8. [[Qualitätsmanagement]]'''
* [[Capability Maturity Model]]
* [[ISO/IEC 15504|SPICE]] (Software Process Improvement and Capability Determination)
* [[Incident Management]]
* [[Problem-Management]]
* [[Softwaremetrik]] ([[Messung]] von Softwareeigenschaften)
* [[Statische Code-Analyse|statische Analyse]] (Berechnung von Schwachstellen)
* [[Software-Ergonomie]]

'''9. [[Konfigurationsmanagement]]'''
* [[Versionsverwaltung]]
* [[Änderungsmanagement]] / [[Veränderungsmanagement]]
* [[Releasemanagement]]
* [[Application-Management]] ([[ITIL]])

'''10. [[Softwareeinführung]]'''

'''11. [[Dokumentation]]'''
* [[Technische Dokumentation]]
* [[Softwaredokumentation]]
* [[Systemdokumentation]] (Weiterentwicklung und Fehlerbehebung)
* [[Betriebshandbuch|Betriebsdokumentation]] (Betreiber/Service)
* [[Bedienungsanleitung]] (Anwender)
* [[Geschäftsprozess]]e (Konzeption der Weiterentwicklung)
* [[Verfahrensdokumentation]] (Beschreibung rechtlich relevanter Softwareprozesse)
|}
Die oben genannten Teilschritte der Softwareentwicklung werden nicht zwangsläufig bei jedem Projekt komplett durchlaufen. Vielmehr werden einzelne Prozesse spezifisch für die jeweilige Anforderung gewählt. Dies ist aus Sicht der Kosten- und Verwaltungsreduzierung notwendig.

=== Projektmanagement ===
Der gesamte Prozess einer Projektentwicklung unterliegt meist einem mehr oder weniger stark ausgeprägten [[Projektmanagement]]. Im Falle der Realisierung durch einen IT-Dienstleister wird meist sowohl auf [[Auftraggeber]]- als auch auf [[Auftragnehmer]]-Seite ein jeweils eigenständiges Projektmanagement betrieben. Um Konflikte zwischen den beiden Projektleitern aufzulösen, wird dem übergeordnet oftmals noch ein aus dem Management von Auftraggeber und Auftragnehmer zusammengesetztes Kontrollgremium ([[Lenkungsausschuss]]) eingesetzt.

Typischerweise wird für größere Projekte auch ein größerer Projektmanagement-Aufwand betrieben, während mittlere oder kleinere Projekte häufig „nebenbei“ abgewickelt werden.

Oft werden externe [[IT-Berater]] zur Ergänzung und Unterstützung der an der Projektabwicklung beteiligten Personen herangezogen.

=== Qualitätsmanagement ===
Das Qualitätsmanagement innerhalb des Projekts wird als Teilbereich des Projektmanagements verstanden.<ref name="PMBOK">''A Guide to the Project Management Body of Knowledge (PMBOK Guide).'' Deutsche Ausgabe 2000. The Project Management Institute, Newton Square PA, ISBN 978-1-930699-21-2, S. 95–103.</ref> Es umfasst die Teilgebiete:
* [[Qualitätsplanung]], das heißt Identifizierung der für das Projekt relevanten Qualitätskriterien und der Methoden, mit denen sie erfüllt werden können.
* Qualitätssicherung, das heißt regelmäßige und regelgerechte Bewertung der Projektleistung, damit das Projekt die Qualitätsstandards erfüllt.
* Qualitätslenkung, das heißt Überwachen der Projektergebnisse, um festzustellen, ob die Qualitätsstandards erfüllt werden, und um die Ursachen unzureichender Leistungen zu beseitigen.

Das Qualitätsmanagement im Projekt muss sowohl die Leistung des Projekts als auch die Qualität des Projektprodukts ansprechen. Modernes Qualitätsmanagement und modernes [[Produktmanagement]] ergänzen sich. Beide Disziplinen erkennen die Bedeutung von
* Kundenzufriedenheit
* Prävention geht vor Überprüfung
* Managementverantwortung

an. Qualitätsverbesserungsprogramme, die von der Trägerorganisation durchgeführt werden, beispielsweise nach [[Total-Quality-Management|TQM]] oder nach [[ISO 9000]], können integriert werden, um die Qualität des Projekts und die des Produkts zu verbessern.<ref name="PMBOK" />

[[Datei:Magischesdreieck.gif|mini|Magisches Dreieck]]
Wie generell im Projektmanagement ist dem permanenten Zielkonflikt zwischen Qualität, Kosten und Zeit Rechnung zu tragen.<ref>Heinrich Kessler, Georg Winkelhofer: ''Projektmanagement''. 4. Auflage. Heidelberg 2004, Springer. S. 55–56.</ref> Speziell in Softwareprojekten steht die Projektleitung häufig unter hohem Termindruck und ist einem besonders hohen Risiko ausgesetzt, die Qualität zu vernachlässigen.<ref>Dierk Wendt: [http://pi.informatik.uni-siegen.de/stt/15_4/15_4_tb_cefe/15_4_se-errors-2.html Klassische Fehler in der Software-Entwicklung.] [[Technische Universität Ilmenau|TU Ilmenau]], 6. Oktober 2005, pi.informatik.uni-siegen.de; abgerufen am 9. Februar 2011.</ref>

=== Risikomanagement ===
Aufgrund der Komplexität von [[Informationssystem]]en sind „absolute“ Sicherheit oder Qualität nicht ökonomisch realisierbar. Daher werden zur Kategorisierung und Priorisierung häufig Methoden des [[Risikomanagement]]s eingesetzt, um für das jeweilige Projekt ein adäquates Maß an Systemsicherheit und -qualität zu gewährleisten.

Aspekte des Risikomanagements sollten über den gesamten [[Software-Lebenszyklus|System-Lebenszyklus]], also beginnend mit dem Konzept, über die Entwicklung oder Programmierung, Implementierung und Konfiguration und während des Betriebes bis hin zur Stilllegung des Systems berücksichtigt werden.

=== Anforderungserhebung ===
Im Zusammenhang mit der Projektentwicklung ist hier die [[Systemanalyse]] zur Projektvorbereitung gemeint. Gegenstand ist die inhaltliche Erfassung der Anforderungen durch Befragung künftiger Anwender, sowie die systematische Untersuchung weiterer sachlicher und technischer Anforderungen und Randbedingungen (Schnittstellen zu Drittsystemen, gesetzliche Anforderungen und dergleichen). Ergebnis ist meist ein [[Fachkonzept]], oftmals auch ein [[Lastenheft]].

Ein [[Pflichtenheft]] enthält sämtliche Funktionen und Anforderungen an ein Programm. Darin wird festgelegt, welche Funktionen verlangt sind und was diese genau tun. Anhand dieser Übersicht werden die grundlegenden technischen Entwurfsentscheidungen getroffen, und daraus wird die Systemarchitektur abgeleitet.
Im Falle einer Beauftragung eines Dienstleistungsunternehmens ist das Pflichtenheft die vertragliche Grundlage für die vereinbarten Leistungen. Deshalb ist die Vollständigkeit und Richtigkeit der darin getroffenen Festlegungen und Anforderungen von besonderer Bedeutung für den Auftraggeber.

=== Systemdesign/technische Konzeption ===
Ein Systemanalytiker oder -designer, bei kleineren Projekten auch der Programmierer, legt anhand des [[Pflichtenheft]]s die Programmarchitektur fest. Soweit [[Standardsoftware]]produkte zum Einsatz kommen, erfolgt in dieser Phase auch eine [[Spezifikation]] der geplanten Produkteinbindung oder -anpassung.
Für neu zu entwickelnde Software erfolgt der Entwurf des [[ER-Modell|Datenmodells]] und der einzelnen Funktionen und [[Algorithmus|Algorithmen]] oder der Objekt- und Klassenstruktur. Falls bereits vorhandene Software angepasst (adaptiert) werden muss, so wird in dieser Phase festgelegt, welche Veränderungen und Erweiterungen erforderlich sind.
Das Ergebnis des Systemdesigns wird auch [[DV-Konzept]] genannt.

=== Implementierung ===
In der [[Implementierung]]sphase wird die zuvor konzipierte Anwendungslösung technisch realisiert, indem Softwareprodukte konfiguriert, vorhandene Software angepasst oder Programme/Programmteile vollständig neu erstellt werden.

Eine Neuerstellung von Software erfolgt meist durch [[Programmierung]], d. h. die einzelnen Funktionen, Objekte, Klassen usw. werden in einer [[Programmiersprache]] mit Hilfe einer [[Integrierte Entwicklungsumgebung|integrierten Entwicklungsumgebung]] codiert.

=== Softwaretest ===
Die Software wird im [[Softwaretest]] in zweierlei Hinsicht getestet, zum einen
* technisch, d. h. auf eine korrekte Umsetzung des DV-Konzepts und auf [[Programmfehler]], und zum anderen
* inhaltlich, d. h. auf Vollständigkeit bezüglich des Pflichtenhefts und Eignung für den vorgesehenen Zweck.

Während der [[Softwaretest#Systemtest|Systemtest]] eine alleinige Angelegenheit des Auftragnehmers ist, erfolgt der [[Softwaretest#Abnahmetest|Verfahrenstest]] meist in Zusammenarbeit mit den Endanwendern des Auftraggebers.

Es gilt in der Softwareentwicklung als normal, dass Programme fehlerhaft sind. Gelegentlich müssen sogar ganze Teile vollständig neu umgesetzt, also neu programmiert werden. Da in komplexeren Applikationen nicht mit Sicherheit ausgeschlossen werden kann, dass geänderte Programmteile nicht etwa andere Programmfunktionen beeinflussen können (Nebeneffekte), sollte nach der Fehlerbeseitigung ein erneuter vollständiger Test des Gesamtsystems erfolgen. Bis zur endgültigen Freigabe der Software sind meist mehrere Test- und Fehlerbeseitigungszyklen (iteratives Vorgehen) erforderlich.

=== Softwareeinführung ===
Die fertiggestellte Software nebst eventuell erforderlicher Standardsoftwareprodukte, Hardware u. Ä. wird sodann im Zuge der [[Installation (Computer)|Installation]] auf den Computersystemen des Auftraggebers oder des Betreibers (eines [[Application Service Provider]]s) aufgespielt und betriebsbereit gemacht. Hierbei wird oftmals zwischen parallelen „Produktiv“-, „Test“-, „Schulungs“- und „Entwicklungs“-Installationen unterschieden.

Je nach technischer Plattform erfolgt die Installation auf Zentralrechnern ([[Server]]) oder auf den Arbeitsplatzrechnern oder beides. Bei [[Datenbankanwendung]]en erfolgt ggf. noch ein [[Tuning (Datenbank)|Tuning]] der Datenbank. In einigen Fällen erfolgt noch eine [[Migration (Informationstechnik)|Migration]] aus älteren Anwendungslösungen.

Bei größeren Projekten erfolgt oftmals zunächst nur eine Installation auf einem Testsystem oder bei wenigen Pilot-Anwendern. Die nachfolgende Ausweitung (Installation und Inbetriebnahme) auf weitere Standorte nennt man [[Rollout]].

Wesentlicher Teil des Projekts ist die Einführungsunterstützung, insbesondere in Form von Schulung oder Einweisung der Endanwender, [[Power-User]] und [[Administrator (Rolle)|Administratoren]].

Es gibt sehr unterschiedliche Schulungskonzepte. Eine größere Anzahl von Benutzern wird oftmals über sogenannte „Multiplikatoren“ geschult. Multiplikatoren sind Anwender, die wiederum weitere Anwender schulen. Dieses Verfahren nennt man auch [[Train the Trainers]].
Zunehmend erfolgt die Anwenderschulung auch über das Internet mit entsprechenden Trainingsanwendungen.

=== Wartung/Pflege ===
Nach der Inbetriebnahme einer Softwarelösung ist eine kontinuierliche Weiterbetreuung erforderlich und üblich.
Diese umfasst sowohl eine Unterstützung der Anwender z. B. per [[Hotline]] im laufenden Betrieb als auch Erweiterungen der Software bei Bedarf. Bei externer Softwareerstellung / Projektabwicklung wird beides in einem [[Support (Dienstleistung)|Support]]-Vertrag geregelt.

Dabei wird zwischen einem [[Support (Dienstleistung)#Kompetenzen-Aufteilung|First-level-Support]] und einem [[Support (Dienstleistung)#Kompetenzen-Aufteilung|Second-level-Support]] unterschieden. Der First-level Support (auch [[Helpdesk]]) ist erste Anlaufstelle für alle eingehenden Unterstützungsfragen und nimmt alle Problemmeldungen entgegen. Er leitet aber nur schwerwiegende Probleme an den Second-level-Support – bei Standardsoftware z. B. beim Produkthersteller – weiter.

Die laufende Anpassung der Software an sich ändernde Anforderungen oder Umgebungsbedingungen, z. B. an neue [[Version (Software)|Versionen]] verwendeter [[Standardsoftware]], wird als „[[Softwarepflege]]“ bezeichnet. Größere Veränderungen werden über eigene [[Projekt|Wartungsprojekte]] bearbeitet, kleinere Anpassungen häufig als Wartungsaufgaben mit einfacheren Prozessregeln. Das Management des nachträglichen Einbringens von Änderungen in ein laufendes System nennt man [[Veränderungsmanagement]].

Während bis zum Anfang des Jahrtausends von einer strikten Trennung zwischen Softwareentwicklung und -wartung ausgegangen wurde, verschwindet diese Grenze zunehmend. Allgemein wird noch von [[Software-Evolution]] gesprochen.<ref>Ian Sommerville: ''Software Engineering''. Version 9. PEARSON, 2012, ISBN 978-3-86894-099-2, S. 276.</ref>

== Methoden zur Softwareentwicklung ==
Die gängigsten Workflow-Methoden sind:<ref>{{Internetquelle |autor=Julia Gapunenko |url=https://www.adcisolutions.com/knowledge/web-development-methodologies-and-approaches |titel=Web development methodologies and approaches |werk=adcisolutions.com |datum=2023-05-16 |sprache=en |abruf=2023-05-19}}</ref>

'''[[Wasserfallmodell|Wasserfall]]''' (oder '''traditionell'''). Bei der Wasserfall-Methode sieht der Entwicklungsprozess wie ein Strom aus, der die einzelnen Phasen nacheinander durchläuft. Jede Phase muss abgeschlossen sein, bevor die nächste Phase beginnen kann.

'''[[Schlanke Produktion|Lean IT]]'''. Lean ist die Anwendung der Prinzipien von Lean Manufacturing (oder Schlanke Produktion) und Lean Services<ref>{{Internetquelle |autor=Scott Sampson |url=https://opexlearning.com/resources/lean-services/ |titel=Lean Services: Sometimes Less Is More |werk=OpEx Learning |sprache=en |abruf=2023-05-19}}</ref> bei der Entwicklung und Verwaltung von IT-Produkten. Obwohl Lean eine großartige Philosophie ist, bietet sie keine besondere Methodik an. Daher kann es nur als Ergänzung zum Wasserfallmodell oder zu einigen der agilen Modelle betrachtet werden.

'''[[Agile Softwareentwicklung|Agile]]'''. Agile Methoden sind eine Alternative zu Waterfall oder traditioneller sequenzieller Entwicklung. Es handelt sich um eine zeitorientierte Philosophie, die es ermöglicht, ein Projekt inkrementell zu erstellen und in kleine Stücke zu unterteilen.

Es gibt keine genauen Phasen; die Zeit wird in Sprints eingeteilt. Ein Sprint ist eine Zeitspanne, die für bestimmte Aufgaben vorgesehen ist. Der Wert der Aufgaben sollte von einem Kunden definiert werden, der tief in den Webentwicklungsprozess eines neuen Produkts involviert ist.

Wie Lean ist auch Agile keine Methodik, sondern eher ein Ansatz oder sogar eine Philosophie.

'''[[Scrum]]'''. Scrum ist eine agile Entwicklungsmethodik, die auf der Agile-Philosophie basiert. Dabei entscheidet das Team, wie eine Aufgabe umgesetzt werden soll, die Dokumentation und das Schreiben von Spezifikationen entfallen.

Das Scrum-Team wird von einem Scrum Master und einem Product Owner (PO) betreut. Der Scrum Master ist eine Art Coach, der das Entwicklungsteam unterstützt. Der PO ist ein Vertreter der Kundenseite, der die Vision des Kunden widerspiegelt und die Prioritäten auf der „Wunschliste“ der Aufgaben setzt. Auch hier wird die Zeit in Sprints eingeteilt. Sobald ein Sprint vorbei ist, muss das Team ein marktreifes Produkt präsentieren.

'''[[Kanban]]'''. Die Hauptidee von Kanban ist die Visualisierung von Arbeitsabläufen. Es besteht darin, eine (physische) Tafel (Kanban-Tafel) zu erstellen, auf welcher der Fortschritt visuell markiert werden kann. Eine Kanban-Tafel kann von mehreren Teams oder Einzelpersonen gemeinsam genutzt werden. Es ist Scrum ziemlich ähnlich.

== Literatur ==
* [[Helmut Balzert]]: ''Lehrbuch der Software-Technik.'' Band 1: ''Software-Entwicklung''. Spektrum Akademischer Verlag, Heidelberg 1996, 1998, 2001, ISBN 3-8274-0480-0.
* {{Literatur
|Autor=Thomas Grechenig, Mario Bernhart, Roland Breiteneder, Karin Kappel
|Titel=Softwaretechnik. Mit Fallbeispielen aus realen Entwicklungsprojekten
|Verlag=Pearson Studium
|Ort=Hallbergmoos
|Datum=2010
|ISBN=978-3-86894-007-7}}
* {{Literatur
|Autor=Jochen Ludewig, Horst Lichter
|Titel=Software Engineering. Grundlagen, Menschen, Prozesse, Techniken
|Auflage=3.
|Verlag=dpunkt
|Ort=Heidelberg
|Datum=2013
|ISBN=978-3-86490-092-1}}
* {{Literatur
|Autor=[[Gustav Pomberger]], [[Wolfgang Pree]]
|Titel=Software Engineering. Architektur-Design und Prozessorientierung
|Auflage=3.
|Verlag=Hanser
|Ort=München
|Datum=2004
|ISBN=3-446-22429-7}}
* {{Literatur
|Autor=[[Ian Sommerville]]
|Titel=Software Engineering
|Auflage=9.
|Verlag=Pearson
|Ort=Hallbergmoos
|Datum=2012
|ISBN=978-3-86894-099-2}}
* Joachim Goll: ''Entwurfsprinzipien und Konstruktionskonzepte der Softwaretechnik: Strategien für schwach gekoppelte, korrekte und stabile Software.'' 2., aktualis. Auflage. Springer Vieweg, Wiesbaden [2019], ISBN 978-3-658-25974-7.

== Weblinks ==
{{Wikibooks|Softwaretechnik}}
{{Wiktionary|Softwareentwicklung}}
* [http://www.kreissl.info/download.php?Downloadname=Softwaretech_hokr.pdf Einführung in die Softwaretechnologie.] (PDF) kreissl.info

== Einzelnachweise ==
<references />

{{Normdaten|TYP=s|GND=4116521-4|REMARK=Ansetzungsform GND: „Software Engineering“.}}

[[Kategorie:Softwaretechnik| ]]
[[Kategorie:Ingenieurwissenschaftliches Fachgebiet]]
[[Kategorie:Technisches Fachgebiet]]

Softwaretechnik - Versionsgeschichte

imported>Millbart: 2 Versionen von 262745386 bis 262754090 rückgängig gemacht, unbrauch gem. WP:Belege und WP:KI