65 lines
4.5 KiB
TeX
65 lines
4.5 KiB
TeX
\chapter{Automatisierung im Software-Entwicklungszyklus}
|
||
In der Softwareentwicklung gibt es eine Vielzahl von Modellen zur Unterstützung des Softwareentwicklungsprozess.
|
||
Wie im ersten Kapitel erwähnt, sollen die Anforderungen so generisch wie möglich formuliert werden.
|
||
Um eine größtmögliche Vielzahl verschiedener Modelle abzudecken, abstrahiere ich deren Komponenten aus dem Modell und versuche ihre Funktion möglichst unabhängig von der Methode darzustellen.
|
||
|
||
\section{Darstellung des Software-Entwicklungsprozesses}
|
||
\label{sec:auto:show}
|
||
Bei der Herleitung dieser generischen Sichtweise auf den Software-Entwicklungsprozess habe auf Elemente des Wasserfallmodell aus der Publikation von Royce, Winston W: \textit{\citetitle{royce1987managing}} zurückgegriffen. Auch wenn er selbst dieses Modell als ``riskant und fehlerbehaftet''\cite{royce1987managing} beschreibt und heute andere Methoden sich etabliert haben.
|
||
Dabei konzentriere ich mich nur auf die Phasen dieses Modells, unabhängig von der Anordnung, Iteration, ihrem Kontext oder Umfang und auch der Philosophie der jeweiligen Methode. Diese einzelnen Schritte lassen sich in ähnlicher Form in vielen anderen Methoden wiederfinden.
|
||
|
||
\subsection*{Projektphasen}
|
||
Die Projektphasen des Wasserfallmodells werden in Anforderungsanalyse, Systemdesign, Programmierung, Testing und Betrieb unterschieden.
|
||
|
||
\begin{description}
|
||
\item[Anforderungsanalyse]
|
||
In diese Phase geht es darum, Anforderungen zu sammeln und zu analysieren. Dies geschieht in Form von Texten oder Modellen, die der Strukturierung und Klassifizierung dienen.
|
||
|
||
\item[Systemdesign]
|
||
Hier wird die Architektur der Module, Schnittstellen und Daten festgelegt, die der Spezifikation aus der Anforderungsanalyse genügen sollen.
|
||
|
||
\item[Implementierung]
|
||
Die Programmierung mit dem dazugehörige Modultest sind Bestandteil der Entwicklungsphase der Implementierung.
|
||
|
||
\item[Softwaretest]
|
||
In der Testphase wird ein System oder eine Komponente gegen die zuvor spezifizierten Anforderungen überprüft. Das Testergebnis dient der Behebung von Softwarefehlern um ein fehlerfreies System in Produktion zu übernehmen.
|
||
|
||
\item[Betrieb]
|
||
Der Betrieb um fasst die Auslieferung und Wartung, Betrieb der Software.
|
||
\end{description}
|
||
|
||
\section{Automatisierung im Entwicklungsprozess}
|
||
\label{sec:auto:auto}
|
||
Es gibt verschiedene weit verbreitete Automatisierungspraktiken. Dazu gehören\cite{bobrovskis2018survey}:
|
||
\begin{itemize}
|
||
\item CI (Continuous Integration)
|
||
\item CDE (Continuous Delivery)
|
||
\item CD (Continuous Deployment)
|
||
\end{itemize}
|
||
Die Idee bei Continuous Integration besteht darin, wiederholt (mehrmals täglich) die Software in einer kontrollierten definierten Umgebung automatisiert zu integrieren und zu testen (automated build). Die Tests können den Modul- Integration- und auch den Abnahmetest umfassen.
|
||
Durch diese Verfahren können Fehler durch Codeänderungen automatisch erkannt werden, die sonst durch aufwendige, manuelle Testverfahren oder sogar erst im Betrieb erkannt worden wären.
|
||
Je nach Umfang kann CI das ganze Volumen von Testszenarien abwickeln und so die Testphase voll automatisiert abdecken.\\
|
||
|
||
\medskip
|
||
|
||
Bei dem Continuous Delivery geht es darum, eine neu entwickelte Softwareversion zur Auslieferung bereitzustellen. Die Installation und der Betrieb der Software erfolgt jedoch manuell.\\
|
||
|
||
\medskip
|
||
Continuous Deployment erweitert das Continuous Delivery um die automatische Installation und Konfiguration auf dem Zielsystem.
|
||
Mit Continuous Deployment werden Komponenten aus der Phase „Betrieb“ automatisiert und das Fehlerrisiko bei der Installation verringert. \\
|
||
|
||
\bigskip
|
||
Diese Grundprinzipien können erweitert werden: so lassen sich z.B. mit Hilfe von statischer Codeanalyse automatisiert Fehler oder Sicherheitsprobleme erkennen (CI).
|
||
Ein Beispiel für die Erweiterung der Phase „Betrieb“ ist das automatisierte Monitoring von Produktionssystemen, welches z.B. Alarmmeldungen in Fehler- und Problemsituationen erzeugt.
|
||
|
||
\medskip
|
||
In der Implementierungsphase gibt es ebenfalls Möglichkeiten zur Automatisierung.
|
||
Sind die Ergebnisse des Designs in einer geeigneten Form dokumentiert worden (z.B. UML oder Open API), lassen sich Teile des Codes wie Datenmodelle oder Server – Boilercode automatisch generieren.
|
||
|
||
\medskip
|
||
Für die Phase der Anforderungsanalyse und des Systemdesigns gibt es ebenfalls eine Vielzahl von Tools, welche der Ergebnisdokumentation dienen – sie können die Aktivitäten zur Analyse und Design aber nur unterstützen und nicht automatisieren.
|
||
|
||
|
||
|
||
|