Übungen zur Softwaretechnik

Größe: px

Ab Seite anzeigen:

Download "Übungen zur Softwaretechnik"

Markus Schuler
vor 8 Jahren
Abrufe

1 Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt Oktober 2002 www4.in.tum.de/~rumpe/se Übungen zur Softwaretechnik Aufgabe 1 : Vorgehensmodelle a) Phasen des Wasserfallmodells Diese Lösung soll einen Eindruck geben, was in den jeweiligen Phasen eines Entwicklungsprozesses geschieht. Zu jeder Phase werden Teilschritte mit jeweiligen Beispielergebnissen angegeben. Problem- und Systemanalyse - Grobe Formulierung der Ziele (z.b.: Einsatzplattform Windows, einheitliche Software zur Unterstützung des Verkaufs (B2B),...) - Erfassung des Problembereichs (z.b.: Interaktion zwischen Händler und Hersteller soll komplett über das Netz funktionieren....) - Machbarkeitsstudie (z.b.: Händler sind bereit, sich an das zu entwickelnde System anzupassen....) - Analyse des Ist-Zustandes (z.b.: Händler A bietet Interface X wohingegen Händler B Interface Z bietet. Es wird bereits teilweise bei Händler C über das Netz bestellt....) - Anforderungsspezifikation (Lastenheft) (z.b.: Einheitliche Oberfläche für alle Benutzer beim Hersteller, möglichst wenige Veränderungen für die Mitarbeiter (= schnelle Eingewöhnungsphase)...) - Systemspezifikation (Pflichtenheft) (z.b.: Der Ablauf eines Kaufvorgangs soll folgendermaßen aussehen: Händlerauswahl, Bestellung, Abrechnung... Die Benutzeroberfläche soll folgende Informationen anzeigen: Lieferstatus,...) Systementwurf - Systemarchitektur (z.b.: Klassendiagramm, Festlegung von Komponenten...) - Schnittstellen der Komponenten festlegen (z.b.: Datenbank, Middleware,...) - Modulkonzept (z.b.: Modulstruktur und Art der Module (funktional, prozedural, Objektorientiert) - Definition der Einzelschnittstellen (z.b. Interfaces und abstrakte Klassen in Java)

geschieht. Zu jeder Phase werden Teilschritte mit jeweiligen Beispielergebnissen angegeben. Problem- und Systemanalyse - Grobe Formulierung der Ziele (z.b.: Einsatzplattform Windows, einheitliche Software zur Unterstützung des Verkaufs (B2B),.

2 Implementierung - Strukturierung der Komponenten in Module (z.b. Klassenrümpfe) - Spezifikation einzelner Module (z.b.: Exakte Beschreibung eines Moduls) - Codierung, Generierung, Wiederverwendung einzelner Module (z.b.: Methoden in Klassen,...) Integration und Test - Integration von Modulen (z.b.: Zusammensetzen von Datenbank und Applikation zum Server) - Integration von Komponenten (z.b.: Einsetzen von Client und Server ins Gesamtsystem.) - Testen und Verifikation (z.b.: Testen, ob die Implementierung zusammen mit der Umgebung funktioniert. Zusichern, dass gewisse Eigenschaften gültig sind.) Wartung und Weiterentwicklung - Wartung (z.b.: Korrektur eines Fehlers im Programm, Portierung auf anderes Betriebssystem,...) - Erweitern der Funktionalität (z.b.: Einbeziehen einer neuen Option im Geschäftsprozess) - Anpassung der Funktionalität (z.b.: Anpassung an Änderung im Geschäftsprozess) b) Phasen des V-Modells Das V-Modell ist eine Erweiterung des Wasserfallmodells. In ihm wird speziell die Verifikation und Validierung berücksichtigt. Die Qualität einer zu erstellenden Software soll so erhöht werden. Analyse Grobentwurf (Komponenten) Feinentwurf (Module) Implementierung Modultest Integration und Integrationstest Der Integrationstest überprüft, ob die im Feinentwurf definierten Module wie gewünscht zusammenspielen. So können Fehler im Feinentwurf als auch Fehler in der Umsetzung des Entwurfes entdeckt werden. Systemintegration und Systemtest Der Systemtest zeigt Abweichungen bzw. Fehler auf, die bei der Umsetzung des Grobentwurfs entstanden sind. So könnte es zum Beispiel sein, dass im Laufe der Entwicklung eine Schnittstelle geändert werden musste und diese Änderung dann

) - Testen und Verifikation (z.b.: Testen, ob die Implementierung zusammen mit der Umgebung funktioniert. Zusichern, dass gewisse Eigenschaften gültig sind.

3 undokumentiert vergessen wurde. Der Test bzw. Vergleich mit der Grobspezifikation sollte dies nun melden. Als Konsequenz muss dann entweder der Grobentwurf oder, falls der Grobentwurf nicht änderbar ist, die Software angepasst werden. Abnahmetest Notwendig, um zu erkennen, ob das die erstellte Software den Anforderungen entspricht. Einige Abweichungen lassen sich oft erst am fertigen System erkennen, da Anforderungen nicht immer systematisch in Software umgesetzt werden können. z.b.: Wenig Einarbeitung für Mitarbeiter. ) c) Iterative Vorgehensmodelle Das V-Modell geht davon aus, dass zu Begin einer Entwicklung bereits alle Anforderungen bekannt sind. Im Falle des Werkzeugherstellers ist es jedoch nicht möglich in der Analysephase das Werkzeug komplett zu spezifizieren. Es können also zu Beginn nur die Kernaktivitäten definiert werden, und diese müssen dann im Verlauf der Entwicklung angepasst und erweitert werden. Für eine derartige Aufgabe eignet sich zum Beispiel das - Vorgehensmodell. Dabei wird der Kunde in die Entwicklung einbezogen und das Programm wächst in kleinen Schritten bis zum fertigen Produkt heran. Bei jedem Schritt werden die Anforderungen des Kunden mit der Software verglichen. Die starke Einbindung des Kunden hat zwei Vorteile: Zum einen kann das Programmiererteam die Software sehr gut an neue Kundenwünsche anpassen und zum anderen sieht der Kunde durch die vielen Iterationen schnell, ob die Software seinen Vorstellungen entspricht. Aufgabe 2 : Qualitätsmerkmale (Wasserfall, V-Model, Spiralmodel,, RUP) a) Größe des Entwicklerteams Wasserfall Das Wasserfallmodell diskutiert die Projektgröße nicht. V-Modell Geeignet für mittlere und große Teams. Spiralmodell Geeignet für mittlere Teams. RUP Geeignet für mittlere und große Teams Bis ca. 10 Mann Jeder Entwickler sollte die ganze Software überblicken können. Kommunikation steigt stark an. b) Komplexität des Projekts Wasserfall Geeignet für einfache Projekte mit stabilen Anforderungen. Bei komplexen Projekten fehlen Kontrollphasen des V-Modells. V-Modell Geeignet für komplexe Projekte. Bei einfachen Projekten relativ viel bürokratischer Overhead.

Abnahmetest Notwendig, um zu erkennen, ob das die erstellte Software den Anforderungen entspricht.

4 Spiralmodell RUP Siehe Wasserfallmodell. Anforderungen können jedoch in den Iterationen angepasst werden. Mittlere bis hohe Komplexität handhabbar. Bis zu mittlerer Komplexität Die Software sollte von allen Mitgliedern verstanden werden und es sollte noch aus dem Code ersichtlich sein, was im Programm geschieht. c) Bekanntheit der Anforderungen Wasserfall Alle Anforderungen müssen zu Beginn des Projekts bekannt sein. V-Modell Alle Anforderungen müssen zu Beginn des Projekts bekannt sein. Spiralmodell Es muss eine initiale Menge von Anforderung bekannt sein. Der Kunde kann die Anforderungen aber aufgrund von Prototypen erweitern. Kernanforderungen sollten bekannt sein. Die restlichen Anforderungen werden mit der Zeit erstellt oder angepasst. d) Änderungen der Anforderungen Wasserfall Schwer möglich. Durch den strikten Top-Down-Ansatz von der Anforderung hin zum Code zieht eine Änderung einen tiefen Eingriff in den Prozess mit sich. V-Modell Siehe Wasserfallmodell. Spiralmodell Gut möglich. In jeder Runde der Spirale können die Anforderungen neu definiert werden. Der -Prozess kann einfach auf Anforderungsänderungen eingehen, da immer nur bis zum nächsten (kleinen) Schritt geplant wird. e) Zeitspielraum (Time-To-Market, Was muss bis wann fertig sein.) Wasserfall Wenig Spielraum. Siehe V-Modell. V-Modell Wenig Spielraum. Üblicherweise muss der ganze Prozess durchlaufen werden. Es ist höchstens möglich, den Prozess zu beschleunigen, indem man Anforderungen streicht. Es wird also alles zum Schluss fertig. Spiralmodell Relativ flexibel. Sobald ein Prototyp existiert, der akzeptabel ist, kann dieser auf den Markt gebracht werden. Flexibel. Durch die kleinen Iterationen in Zusammenarbeit mit dem Kunden kann relativ schnell ein einfaches erstes Release herausgegeben werden. f) Dokumentation Wasserfall Viel Dokumentation Für jede Phase wird eine komplette Dokumentation erstellt. V-Modell Viel Dokumentation Gerade in den ersten Phasen wird sehr viel über die Software schriftlich festgehalten. Aber auch für die anderen Phasen wird eine Komplette Dokumentation erstellt. Spiralmodell Viel Dokumentation In jedem Zyklus werden alle Phasen (incl. Dokumentation) durchlaufen, aber nur im Umfang des Prototypen.

c) Bekanntheit der Anforderungen Wasserfall Alle Anforderungen müssen zu Beginn des Projekts bekannt sein. V-Modell Alle Anforderungen müssen zu Beginn des Projekts bekannt sein.

5 RUP Sehr viel Dokumentation Es werden alle Artefakte und Tätigkeiten dokumentiert. Kaum Dokumentation In geht man davon aus, dass sich der Code selbst dokumentiert. Zum Ende eines Projekts wird ein Dokument erstellt, welches die Architektur beschreibt. g) IT - Kenntnisse des Kunden Wasserfall Wenig Kenntnisse nötig. (siehe V-Model) V-Modell Wenig Kenntnisse nötig. Meistens schreibt der Kunde das Lastenheft, und der Entwickler versucht dieses dann in einem Pflichtenheft umzusetzen. Wenn das Lastenheft vom Entwickler als machbar befunden wird, bekommt der Kund das fertige Produkt. Spiralmodell Wenig Kenntnisse nötig. Kunde sieht immer nur die fertigen Prototypen und äußert dann seine Wünsche. Kunde braucht gute Kenntnisse über den Prozess, da er in den Entwicklungsprozess eingebunden wird. Idealerweise ist er sogar fähig, Tests für die Software zu entwickeln oder dabei zumindest gut mitzuhelfen. h) Durchschnittliche Anzahl der Iterationen Wasserfall (siehe V-Modell) V-Modell Nur lange Zyklen. Mit dem V-Modell sind nur sehr lange Zyklen handhabbar, da immer wieder der ganze Entwicklungsprozess durchlaufen werden muss. Spiralmodell ca. 3-5 Iterationen RUP ca Iterationen Sehr viele Iterationen lebt davon, viele kurze Zyklen zu haben, um so spontan auf Kundenwünsche reagieren zu können.

(siehe V-Model) V-Modell Wenig Kenntnisse nötig. Meistens schreibt der Kunde das Lastenheft, und der Entwickler versucht dieses dann in einem Pflichtenheft umzusetzen.

Ähnliche Dokumente

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was