Softwaretechnik

Die Softwaretechnik oder Softwaretechnologie, englisch Software Engineering (SE), beschäftigt sich mit
der Herstellung oder Entwicklung von Software, der Organisation und Modellierung der zugehörigen
Datenstrukturen und dem Betrieb von Softwaresystemen. Eine Definition von Helmut Balzert beschreibt das
Gebiet als

„Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und

Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von
umfangreichen Softwaresystemen.“
– 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;[1] 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.

Inhaltsverzeichnis
Teilgebiete
Projektmanagement
Qualitätsmanagement
Risikomanagement
Anforderungserhebung
Systemdesign/technische Konzeption
Implementierung
Softwaretest
Softwareeinführung
Wartung/Pflege
Literatur
Weblinks
Einzelnachweise

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)
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, Agile Softwareentwicklung.

Die Softwaretechnik beinhaltet 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 zzgl. der benötigten Hardware und
Netzwerke.

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 Projektart, sind auch die
Vorgehensweisen bei der Projektentwicklung: Von einer sehr strukturierten Herangehensweise, siehe
Wasserfallmodell, über verschiedene Mischformen bis hin zu sehr flexiblen, offenen Methoden wie der Agilen
Softwareentwicklung. Entsprechend wird auch zwischen 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:

Kernprozesse Unterstützungsprozesse

1. Planung 6. Anforderungsmanagement

Anforderungserhebung 7. Projektmanagement
Lastenheft (Anforderungsdefinition)
Risikomanagement
Pflichtenheft (Mit technischen Ansätzen
verfeinertes Lastenheft) Projektplanung
Aufwandsschätzung (z. B. mittels Projektverfolgung und -steuerung
Function-Point-Verfahren oder Management von
COCOMO) Lieferantenvereinbarungen
Vorgehensmodell
8. Qualitätsmanagement
2. Analyse
Capability Maturity Model
Auswertung SPICE (Software Process Improvement
Mock-up and Capability Determination)
Prozessanalyse / Prozessmodell Incident Management
Systemanalyse Problem-Management
Strukturierte Analyse (SA) Softwaremetrik (Messung von
Softwareeigenschaften)
Objektorientierte Analyse (OOA)
statische Analyse (Berechnung von
3. Entwurf Schwachstellen)
 Softwarearchitektur Software-Ergonomie
Strukturiertes Design (SD)
Objektorientiertes Design (OOD) 9. Konfigurationsmanagement
Fundamental Modeling Concepts (FMC) Versionsverwaltung
Änderungsmanagement /
4. Programmierung
Veränderungsmanagement
Normierte Programmierung Releasemanagement
Strukturierte Programmierung Application-Management (ITIL)
Objektorientierte Programmierung
(OOP) 10. Softwareeinführung
Funktionale Programmierung 11. Dokumentation
5. Validierung und Verifikation Technische Dokumentation
Softwaredokumentation
Modultests (Low-Level-Test)
Systemdokumentation (Weiterentwicklung
Integrationstests (Low-Level-Test)
und Fehlerbehebung)
Systemtests (High-Level-Test)
Betriebsdokumentation (Betreiber/Service)
Akzeptanztests (High-Level-Test)
Bedienungsanleitung (Anwender)
Geschäftsprozesse (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.[2]
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 TQM oder nach ISO 9000, können integriert werden, um die Qualität des Projekts und die des Produkts
zu verbessern.[2]

Wie generell im Projektmanagement ist dem permanenten Zielkonflikt

zwischen Qualität, Kosten und Zeit Rechnung zu tragen.[3] Speziell
in Softwareprojekten steht die Projektleitung häufig unter hohem
Termindruck und ist einem besonders hohen Risiko ausgesetzt, die
Qualität zu vernachlässigen.[4]

Risikomanagement

Aufgrund der Komplexität von Informationssystemen sind „absolute“

Magisches Dreieck
Sicherheit oder Qualität nicht ökonomisch realisierbar. Daher werden
zur Kategorisierung und Priorisierung häufig Methoden des
Risikomanagements 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 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 u. dgl.). 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
Pflichtenhefts die Programmarchitektur fest. Soweit Standardsoftwareprodukte 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 Datenmodells und der einzelnen Funktionen und 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 Implementierungsphase 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 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 Systemtest eine alleinige Angelegenheit des Auftragnehmers ist, erfolgt der 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 auf den Computersystemen des Auftraggebers oder des Betreibers (eines
Application Service Providers) 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 Datenbankanwendungen erfolgt ggf. noch ein Tuning der Datenbank.
In einigen Fällen erfolgt noch eine 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 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-Vertrag geregelt.

Dabei wird zwischen einem First-level-Support und einem 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 Versionen verwendeter Standardsoftware, wird als „Softwarepflege“ bezeichnet. Größere
Veränderungen werden über eigene 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.[5]

Literatur
Helmut Balzert: Lehrbuch der Software-Technik. Bd. 1. Software-Entwicklung. Spektrum
Akademischer Verlag, Heidelberg 1996, 1998, 2001, ISBN 3-8274-0480-0.
Thomas Grechenig, Mario Bernhart, Roland Breiteneder, Karin Kappel: Softwaretechnik. Mit
Fallbeispielen aus realen Entwicklungsprojekten. Pearson Studium, Hallbergmoos 2010, ISBN
978-3-86894-007-7.
Jochen Ludewig, Horst Lichter: Software Engineering. Grundlagen, Menschen, Prozesse,
Techniken. 3. Auflage. dpunkt, Heidelberg 2013, ISBN 978-3-86490-092-1.
Gustav Pomberger, Wolfgang Pree: Software Engineering. Architektur-Design und
Prozessorientierung. 3. Auflage. Hanser, München 2004, ISBN 3-446-22429-7.
Ian Sommerville: Software Engineering. 9. Auflage. Pearson, Hallbergmoos 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. Aufl., Springer Vieweg,
Wiesbaden [2019], ISBN 978-3-658-25974-7.

Weblinks
Wikibooks: Softwaretechnik – Lern- und Lehrmaterialien
Einführung in die Softwaretechnologie (http://www.kreissl.info/download.php?Downloadname=
Softwaretech_hokr.pdf)

Einzelnachweise
1. Lerne programmieren Programmierung vs. Softwareentwicklung [1] (http://www.lerneprogrammi
eren.com/blog/theorie/programmierung-vs-softwareentwicklung)
2. The Project Management Institute (Hrsg.): A Guide to the Project Management Body of
Knowledge (PMBOK Guide). Deutsche Ausgabe 2000, Newton Square, Penn., Project
Management Institute. ISBN 978-1-930699-21-2, S. 95–103
3. Kessler, Heinrich; Winkelhofer, Georg: Projektmanagement. 4. Auflage. Heidelberg 2004,
Springer. S. 55–56
4. Wendt, Dierk (Sprecher der Arbeitsgruppe): Klassische Fehler in der Software-Entwicklung (htt
p://pi.informatik.uni-siegen.de/stt/15_4/15_4_tb_cefe/15_4_se-errors-2.html), TU Ilmenau,
Version vom 6. Oktober 2005, abgerufen am 9. Februar 2011
5. Ian Sommerville, Software Engineering, PEARSON, Version 9, 2012, S. 276, ISBN 978-3-
86894-099-2

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Softwaretechnik&oldid=213603995“

Diese Seite wurde zuletzt am 6. Juli 2021 um 09:40 Uhr bearbeitet.

Der Text ist unter der Lizenz „Creative Commons Attribution/Share Alike“ verfügbar; Informationen zu den Urhebern und
zum Lizenzstatus eingebundener Mediendateien (etwa Bilder oder Videos) können im Regelfall durch Anklicken dieser
abgerufen werden. Möglicherweise unterliegen die Inhalte jeweils zusätzlichen Bedingungen. Durch die Nutzung dieser
Website erklären Sie sich mit den Nutzungsbedingungen und der Datenschutzrichtlinie einverstanden.
Wikipedia® ist eine eingetragene Marke der Wikimedia Foundation Inc.