Softwareentwicklungsprozess: Unterschied zwischen den Versionen
Thomas (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Thomas (Diskussion | Beiträge) |
||
| (Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
| Zeile 8: | Zeile 8: | ||
=== Anforderungsanalyse === | === 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]] | [[Datei:Typen Anforderungsdefinition.jpg|mini]] | ||
| Zeile 35: | Zeile 35: | ||
* nutzbar, nützlich: Auch bei teilweiser Realisierung soll bereits ein produktives System entstehen. | * 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 == | == 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. | 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 == | == Programmierung == | ||