Software Engineering PS (WS2000/2001)
Schwaiger Roland
Project Description
Aufgabe 1
Verwenden Sie den unter Thema angeführten Business Case als Grundlage für die zu erstellende ausführliche Problembeschreibung. Beachten Sie dabei, die unten angeführten Punkte (Ordner mit Zusatzmaterial steht im Sekretariat).Zusatzinformation
Referenzen: 2, 7, 8, 9Das erste Teilziel in einem SW Projekt besteht darin, dass sich Auftraggeber und SW Entwickler darüber klar werden, was eigentlich gemacht werden soll. Das Problemfeld muss identifiziert und abgegrenzt werden, die Anforderungen und der Leistungsumfang müssen defniniert werden. Das Ziel der Problembeschreibung (Problemanalyse) besteht in der Festlegung, welche Aufgaben unter welchen Umgebungsbedingungen computergestützt gelöst werden sollen.
Ausgehend von der Idee (Thema) wird eine Problembeschreibung angelegt. Die Problembeschreibung sollte noch möglichst allgemein gehalten werden und nicht eine Auflistungen der Anforderungen darstellen, die aber ihrerseits von der Problembeschreibung abgeleitet werden (Anforderungskatalog). In der Problembeschreibung sollte erfasst sein, WAS erreicht werden soll, nicht WIE. Falls wichtige Aspekte auftauchen, die NICHT Bestandteil des Projektes sein sollten, dann muss das ebenfalls in der Problembeschreibung enthalten sein. Bei den Anforderungen unterscheidet man funktionale und nicht funktionale Anforderungen. Funktionale Anforderungen werden durch den Benutzer explizit angegeben bzw. in weiteren Interviews erkannt und betreffen die Verarbeitungsfunktionalität des SW Systems. Nicht funktionale Anforderungen bestehen aus einer Beschränkung oder Eingrenzung der vom System zu erbringenden Leitung (z.B: Antwortzeiten eines Systems, benötigter Hauptspeicher, etc.), äusseren Rahmenbedingungen und allgemeine Qualitätsmerkmale.
Als Hilfsmittel zur Erhebung der Problembeschreibung werden wir Einzel-/Gruppeninterviews einsetzen, die der project leader bei der Präsentation durchfüren wird. Also handelt es sich um eine erste Nachiteration der bis zur Präsentation erstellten Problembeschreibung.
Aus dem obigen Paragraph ergibt sich, dass die Problembeschreibung nie perfekt bzw. allumfassend sein kann und sich im evolutionären Sinne im Laufe des Projektes verfeinern wird.
Projekte investieren ungefähr 18% der kompletten Projektzeit in die Spezifikation/Anforderung, 19% in das Design, 34% in die Implementierung und 29% in das Testen (8). Diese Zahlen sind der Durchschnitt von 125 Hewlett-Packard Projekten.
Nicht Bestandteil dieser Aufgabe, aber ebenfalls legitim im Ansatz, ist die Entwicklung eines Prototypen, parallel zur Problembeschreibung, um Missverständnisse zwischen Entwickler und Auftraggeber zu bereinigen, fehlende Funktionen zu entdecken (wird teilweise durch Use-Cases ebenfalls erreicht), etc.