Softwareentwicklungsprozess: Unterschied zwischen den Versionen

(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)

Zeile 8:

=== Anforderungsanalyse ===

Ziel ist es, die Anforderungen des Auftraggebers für alle beteiligten verständlich, übersichtlich und vollständig zu erfassen. Die Anforderungen müssen niedergeschrieben oder in Modellen spezifiziert werden. Der Fokus liegt auf der fachlichen Beschreibung. Wenn möglich, ist auf technische Details zu verzichten. Bereits die Analyse kann objektorientiert unter Einsatz der UML erfolgen. Anwendungsfall, Aktivitäts- und Klassendiagramme sind geeignet, das zu erstellenden System fachlich zu beschreiben.

Ziel ist es, die Anforderungen des Auftraggebers für alle beteiligten verständlich, übersichtlich und vollständig zu erfassen. Die Anforderungen müssen niedergeschrieben oder in Modellen spezifiziert werden. Der Fokus liegt auf der fachlichen Beschreibung. Wenn möglich, ist auf technische Details zu verzichten. Bereits die Analyse kann [[Objektorientierung|objektorientiert]] unter Einsatz der [[UML]] erfolgen. Anwendungsfall, [[Aktivitätsdiagramm|Aktivitäts]]- und [[Klassendiagramm|Klassendiagramme]] sind geeignet, das zu erstellenden System fachlich zu beschreiben.

Gilt es eine Datenbank zu entwickeln wird in dieser Phase meist das Entity-Relationship-Diagramm eingesetzt, um benötigte fachliche Daten zu sammeln und deren fachlichen Zusammenhang deutlich zu machen.

Gilt es eine [[Datenbank]] zu entwickeln wird in dieser Phase meist das [[Entity-Relationship-Modell|Entity-Relationship-Diagramm]] eingesetzt, um benötigte fachliche [[Daten]] zu sammeln und deren fachlichen Zusammenhang deutlich zu machen.

[[Datei:Typen Anforderungsdefinition.jpg|mini]]

Zeile 35:

* nutzbar, nützlich: Auch bei teilweiser Realisierung soll bereits ein produktives System entstehen.

Die Bewertungen stehen teilweise in Konkurrenz zueinander. Das Ergebnis der Anforderungsaufnahme ist eine Liste mit Anforderungen aus Kundensicht, die in ein Lastenheft überführt werden. Das Ergebnis der Analyse stellt die Grundlage für das Pflichtenheft dar, welches im Rahmen der folgenden Designphase erstellt wird.

Die Bewertungen stehen teilweise in Konkurrenz zueinander. Das Ergebnis der Anforderungsaufnahme ist eine Liste mit Anforderungen aus Kundensicht, die in ein [[Lastenheft]] überführt werden. Das Ergebnis der Analyse stellt die Grundlage für das [[Pflichtenheft]] dar, welches im Rahmen der folgenden Designphase erstellt wird.

== Design ==

Softwaredesign (auch Softwareentwurf) ist der Prozess zur Planung einer Software-Lösung. Softwaredesign ist in aller Regel erforderlich, um die Komplexität, welche die meisten Computerprogramme aufweisen, für die Programmierer handhabbar zu machen und das Risiko von Fehlentwicklungen zu verringern. Insbesondere im Hinblick auf die Wartbarkeit einer Lösung, ist der Prozess des Designs gewissenhaft zu durchlaufen.

Auf Grundlage der Anforderungsanalyse erarbeitet der Auftragnehmer zusammen mit dem Auftraggeber über verschiedene Vorgehensweisen ein Konzept. Hier wird festgelegt, mit welchen Techniken und Algorithmen diese Anforderungen erfüllt und programmiert werden sollen. Der Auftragnehmer hält die Ergebnisse dieses Konzepts in dem sogenannten Pflichtenheft fest.

Auf Grundlage der Anforderungsanalyse erarbeitet der Auftragnehmer zusammen mit dem Auftraggeber über verschiedene Vorgehensweisen ein Konzept. Hier wird festgelegt, mit welchen Techniken und [[Algorithmus|Algorithmen]] diese Anforderungen erfüllt und programmiert werden sollen. Der Auftragnehmer hält die Ergebnisse dieses Konzepts in dem sogenannten [[Pflichtenheft]] fest.

Spätestens in der Designphase sollte auf objektorientierte Ansätze zurückgegriffen werden, um das System zu planen. UML Klassendiagramme beschreiben fachlich relevante Klassen und ergänzen sie um technische Notwendigkeiten. Komplexe Objektinteraktionen können in Sequenzdiagrammen geplant werden. Eng abgrenzbare Algorithmen können auch in einem Struktogramm modelliert werden.

Spätestens in der Designphase sollte auf [[Objektorientierung|objektorientierte]] Ansätze zurückgegriffen werden, um das System zu planen. UML [[Klassendiagramm|Klassendiagramme]] beschreiben fachlich relevante [[Klasse|Klassen]] und ergänzen sie um technische Notwendigkeiten. Komplexe Objektinteraktionen können in [[Sequenzdiagramm|Sequenzdiagrammen]] geplant werden. Eng abgrenzbare [[Algorithmus|Algorithmen]] können auch in einem [[Struktogramm]] modelliert werden.

Grundlegende Architekturentscheidungen werden getroffen. Die Datenhaltung in einer Datenbank kann mit Hilfe von ERMs modelliert werden.

Grundlegende Architekturentscheidungen werden getroffen. Die Datenhaltung in einer [[Datenbank]] kann mit Hilfe von [[ERM|ERMs]] modelliert werden.

Am Ende der Designphase steht ein Lastenheft, das beschreibt, wie der Auftragnehmer, die beschriebenen Anforderungen (Pflichtenheft) umsetzen wird. Erst dann erfolgt gegebenenfalls eine Beauftragung durch den Auftraggeber.

Am Ende der Designphase steht ein [[Lastenheft]], das beschreibt, wie der Auftragnehmer, die beschriebenen Anforderungen ([[Pflichtenheft]]) umsetzen wird. Erst dann erfolgt gegebenenfalls eine Beauftragung durch den Auftraggeber.

== Programmierung ==

Zeile 62:

== Test ==

[[Datei:Problem Algorithmus Test im Zusammenhang.jpg|mini]]

Während der Testphase wird geprüft und bewertet, ob die erstellte Software die definierten Anforderungen erfüllt. Neben einzelnen Komponenten und Modulen wird auch das gesamte System überprüft. Die gewonnenen Erkenntnisse werden zur Erkennung und Behebung von Softwarefehlern genutzt. Tests während der Softwareentwicklung dienen dazu, die Software möglichst fehlerfrei in Betrieb zu nehmen. Den Nachweis, dass keine Fehler (mehr) vorhanden sind, kann die Testung nicht erbringen. Es kann lediglich festgestellt werden, dass bestimmte Testfälle erfolgreich waren. Hierfür müssten alle Kombinationsmöglichkeiten aus vorliegenden Daten und Funktionsaufrufen durchgespielt werden, was in der Praxis nur für sehr kleine Systeme geleistet werden kann.

Zeile 67:

Zeile 68:

Ein Testen ist nur dann sinnvoll, wenn für definierte Eingaben entsprechende Soll-Ausgaben definiert werden. Dies setzt die Existenz von Soll-Werten voraus. Ansonsten würde der Tester bei einer alleinigen Betrachtung der Ausgabeergebnisse versuchen, die Ergebnisse zu interpretieren und evtl. zu dem fehlerhaften Schluss kommen, dass sich das Programm „logisch korrekt“ verhält. Die Definition von Eingabewerten und Soll-Ausgaben sind idealerweise Bestandteil der Anforderungsanalyse.

[[Datei:Übersicht Testverfahren.jpg|mini]]

Tests lassen sich grob in dynamische und statische Tests einteilen. Dynamische Tests werden zur Laufzeit durchgeführt. Statische Tests werden ohne Computernutzung, nur durch Überlegungen durchgeführt.

== Bereitstellung ==

Zeile 99:

Zeile 98:

* Rational Unified Process

* Scrum

[[Kategorie:FI_I_SDM]]

[[Kategorie:FI_I_TP2]]

@@ Zeile 8: / Zeile 8: @@
 === Anforderungsanalyse ===
-Ziel ist es, die Anforderungen des Auftraggebers für alle beteiligten verständlich, übersichtlich und vollständig zu erfassen. Die Anforderungen müssen niedergeschrieben oder in Modellen spezifiziert werden. Der Fokus liegt auf der fachlichen Beschreibung. Wenn möglich, ist auf technische Details zu verzichten. Bereits die Analyse kann objektorientiert unter Einsatz der UML erfolgen. Anwendungsfall, Aktivitäts- und Klassendiagramme sind geeignet, das zu erstellenden System fachlich zu beschreiben.
+Ziel ist es, die Anforderungen des Auftraggebers für alle beteiligten verständlich, übersichtlich und vollständig zu erfassen. Die Anforderungen müssen niedergeschrieben oder in Modellen spezifiziert werden. Der Fokus liegt auf der fachlichen Beschreibung. Wenn möglich, ist auf technische Details zu verzichten. Bereits die Analyse kann [[Objektorientierung|objektorientiert]] unter Einsatz der [[UML]] erfolgen. Anwendungsfall, [[Aktivitätsdiagramm|Aktivitäts]]- und [[Klassendiagramm|Klassendiagramme]] sind geeignet, das zu erstellenden System fachlich zu beschreiben.
-Gilt es eine Datenbank zu entwickeln wird in dieser Phase meist das Entity-Relationship-Diagramm eingesetzt, um benötigte fachliche Daten zu sammeln und deren fachlichen Zusammenhang deutlich zu machen.
+Gilt es eine [[Datenbank]] zu entwickeln wird in dieser Phase meist das [[Entity-Relationship-Modell|Entity-Relationship-Diagramm]] eingesetzt, um benötigte fachliche [[Daten]] zu sammeln und deren fachlichen Zusammenhang deutlich zu machen.
 [[Datei:Typen Anforderungsdefinition.jpg|mini]]
@@ Zeile 35: / Zeile 35: @@
 * nutzbar, nützlich: Auch bei teilweiser Realisierung soll bereits ein produktives System entstehen.
-Die Bewertungen stehen teilweise in Konkurrenz zueinander. Das Ergebnis der Anforderungsaufnahme ist eine Liste mit Anforderungen aus Kundensicht, die in ein Lastenheft überführt werden. Das Ergebnis der Analyse stellt die Grundlage für das Pflichtenheft dar, welches im Rahmen der folgenden Designphase  erstellt wird.
+Die Bewertungen stehen teilweise in Konkurrenz zueinander. Das Ergebnis der Anforderungsaufnahme ist eine Liste mit Anforderungen aus Kundensicht, die in ein [[Lastenheft]] überführt werden. Das Ergebnis der Analyse stellt die Grundlage für das [[Pflichtenheft]] dar, welches im Rahmen der folgenden Designphase  erstellt wird.
 == Design ==
 Softwaredesign (auch Softwareentwurf) ist der Prozess zur Planung einer Software-Lösung. Softwaredesign ist in aller Regel erforderlich, um die Komplexität, welche die meisten Computerprogramme aufweisen, für die Programmierer handhabbar zu machen und das Risiko von Fehlentwicklungen zu verringern. Insbesondere im Hinblick auf die Wartbarkeit einer Lösung, ist der Prozess des Designs gewissenhaft zu durchlaufen.
-Auf Grundlage der Anforderungsanalyse erarbeitet der Auftragnehmer zusammen mit dem Auftraggeber über verschiedene Vorgehensweisen ein Konzept. Hier wird festgelegt, mit welchen Techniken und Algorithmen diese Anforderungen erfüllt und programmiert werden sollen. Der Auftragnehmer hält die Ergebnisse dieses Konzepts in dem sogenannten Pflichtenheft fest.
+Auf Grundlage der Anforderungsanalyse erarbeitet der Auftragnehmer zusammen mit dem Auftraggeber über verschiedene Vorgehensweisen ein Konzept. Hier wird festgelegt, mit welchen Techniken und [[Algorithmus|Algorithmen]] diese Anforderungen erfüllt und programmiert werden sollen. Der Auftragnehmer hält die Ergebnisse dieses Konzepts in dem sogenannten [[Pflichtenheft]] fest.
-Spätestens in der Designphase sollte auf objektorientierte Ansätze zurückgegriffen werden, um das System zu planen. UML Klassendiagramme beschreiben fachlich relevante Klassen und ergänzen sie um technische Notwendigkeiten. Komplexe Objektinteraktionen können in Sequenzdiagrammen geplant werden.  Eng abgrenzbare Algorithmen können auch in einem Struktogramm modelliert werden.
+Spätestens in der Designphase sollte auf [[Objektorientierung|objektorientierte]] Ansätze zurückgegriffen werden, um das System zu planen. UML [[Klassendiagramm|Klassendiagramme]] beschreiben fachlich relevante [[Klasse|Klassen]] und ergänzen sie um technische Notwendigkeiten. Komplexe Objektinteraktionen können in [[Sequenzdiagramm|Sequenzdiagrammen]] geplant werden.  Eng abgrenzbare [[Algorithmus|Algorithmen]] können auch in einem [[Struktogramm]] modelliert werden.
-Grundlegende Architekturentscheidungen werden getroffen. Die Datenhaltung in einer Datenbank kann mit Hilfe von ERMs modelliert werden.
+Grundlegende Architekturentscheidungen werden getroffen. Die Datenhaltung in einer [[Datenbank]] kann mit Hilfe von [[ERM|ERMs]] modelliert werden.
-Am Ende der Designphase steht ein Lastenheft, das beschreibt, wie der Auftragnehmer, die beschriebenen Anforderungen (Pflichtenheft) umsetzen wird. Erst dann erfolgt gegebenenfalls eine Beauftragung durch den Auftraggeber.
+Am Ende der Designphase steht ein [[Lastenheft]], das beschreibt, wie der Auftragnehmer, die beschriebenen Anforderungen ([[Pflichtenheft]]) umsetzen wird. Erst dann erfolgt gegebenenfalls eine Beauftragung durch den Auftraggeber.
 == Programmierung ==
@@ Zeile 62: / Zeile 62: @@
 == Test ==
+[[Datei:Problem Algorithmus Test im Zusammenhang.jpg|mini]]
 Während der Testphase wird geprüft und bewertet, ob die erstellte Software die definierten Anforderungen erfüllt. Neben einzelnen Komponenten und Modulen wird auch das gesamte System überprüft. Die gewonnenen Erkenntnisse werden zur Erkennung und Behebung von Softwarefehlern genutzt. Tests während der Softwareentwicklung dienen dazu, die Software möglichst fehlerfrei in Betrieb zu nehmen. Den Nachweis, dass keine Fehler (mehr) vorhanden sind, kann die Testung nicht erbringen. Es kann lediglich festgestellt werden, dass bestimmte Testfälle erfolgreich waren. Hierfür müssten alle Kombinationsmöglichkeiten aus vorliegenden Daten und Funktionsaufrufen durchgespielt werden, was in der Praxis nur für sehr kleine Systeme geleistet werden kann.
@@ Zeile 67: / Zeile 68: @@
 Ein Testen ist nur dann sinnvoll, wenn für definierte Eingaben entsprechende Soll-Ausgaben definiert werden. Dies setzt die Existenz von Soll-Werten voraus. Ansonsten würde der Tester bei einer alleinigen Betrachtung der Ausgabeergebnisse versuchen, die Ergebnisse zu interpretieren und evtl. zu dem fehlerhaften Schluss kommen, dass sich das Programm „logisch korrekt“ verhält. Die Definition von Eingabewerten und Soll-Ausgaben sind idealerweise Bestandteil der Anforderungsanalyse.
+[[Datei:Übersicht Testverfahren.jpg|mini]]
 Tests lassen sich grob in dynamische und statische Tests einteilen. Dynamische Tests werden zur Laufzeit durchgeführt. Statische Tests werden ohne Computernutzung, nur durch Überlegungen durchgeführt.
 == Bereitstellung ==
@@ Zeile 99: / Zeile 98: @@
 * Rational Unified Process
 * Scrum
+[[Kategorie:FI_I_SDM]]
+[[Kategorie:FI_I_TP2]]