tada
This commit is contained in:
@@ -5,7 +5,7 @@ Um eine größtmögliche Vielzahl verschiedener Modelle abzudecken, abstrahiere
|
||||
|
||||
\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.
|
||||
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}}\cite{royce1987managing} zurückgegriffen. Auch wenn er selbst dieses Modell als \\ \textcite{``riskant und fehlerbehaftet''} 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}
|
||||
@@ -32,21 +32,21 @@ Die Projektphasen des Wasserfallmodells werden in Anforderungsanalyse, Systemdes
|
||||
\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)
|
||||
\item CI (\textit{Continuous Integration})
|
||||
\item CDE (\textit{Continuous Delivery})
|
||||
\item CD (\textit{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.
|
||||
Die Idee bei \textit{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.\\
|
||||
Bei dem \textit{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. \\
|
||||
\textit{Continuous Deployment} erweitert das \textit{Continuous Delivery} um die automatische Installation und Konfiguration auf dem Zielsystem.
|
||||
Mit \textit{Continuous Deploymen}t 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).
|
||||
|
||||
Reference in New Issue
Block a user