Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom

Transkript

1 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom Christoph Redl Quelle der Fragen: 1 SCRUM Prinzip + Vorteile + Phasen Phasen 1. Product Backlog wird vom Product Owner definiert (der Inhalt kann sich während dem Projektverlauf ändern) 2. Sprint Planning Meeting: Inhalt des Sprint Backlogs festlegen, Priorisieren, Scrum- Meeting-Termin, etc. planen 3. Sprint (üblicherweise ca. 3 Wochen) mit täglichen Scrum-Meetings: hier setzt das Team die Items des Product Backblogs selbstständig um 4. Am Ende des Sprints: Sprint Demo, bei der die neuen Features vorgestellt werden (auch der Product Owner ist dabei anwesend) 5. Sprint Retrospective: Sprint reflektieren: was kann im nächsten Sprint besser gemacht werden, was war gut, etc. 6. Zurück zu Schritt 2 bis alle wichtigen Features aus dem Product Backlog umgesetzt wurden Vorteile Es ist ein agiles Vorgehensmodell in der Softwareentwicklung. Vorteil im vergleich zu traditionellen Modellen ist, dass auf geänderte Anforderungen leicht Rücksicht genommen werden kann indem die Entwicklung in kurzen Phasen (Sprints) abläuft. 2 Was ist ein Sprint - wie läuft er ab Ein Sprint ist ein maximal einen Monat (empfohlen: 3 Wochen) lang dauernder Entwicklungsprozess in SCRUM, in dem bestimmte Anforderungen vom Scrum-Team realisiert werden. Vor dem Sprint werden im Sprint Planning Meeting die wichtigsten noch zu 1

2 realisierenden Features vom Product in den Sprint Backlog übertragen und dann vom Team umgesetzt. Die Auswahl der Features richtet sich dabei einerseits nach den Prioritäten und andererseits danach, was sich das Team im geplanten Zeitraum zutraut. Während des Sprints gibt es tägliche SCRUM Meetings die maximal 15 Minuten dauern. Darin wird besprochen was jeder seit dem letzten Meeting gemacht hat, ob es derzeit Probleme gibt die die Weiterentwicklung behindern und was jeder bis zum nächsten Meeting machen wird. Nach Ablauf des Sprints erfolgt eine Sprint-Demo bei der die umgesetzten Features präsentiert werden. Auch der Product Owner ist dabei anwesend und kann die neuen Features ausprobieren. Dabei sollte darauf geachtet werden dass nicht zu sehr auf technische Details eingegangen wird. Abschließend wird der vergangene Sprint reflektiert (Sprint Retrospective). Darin soll geklärt werden was gut war und was verbesserungswürdig ist. Die Erkenntnisse können im nächsten Sprint berücksichtigt werden. 3 Was ist ein Product Backlog und was ein Sprint Backlog. Was sind die Unterschiede und was steht drin In beiden stehen Anforderungen der Kunden. Im Product Backlock stehen dabei alle Anforderungen die noch umzusetzen sind, gereiht nach der vom Product Owner festgelegten Priorität. Im Sprint Backlock stehen die Anforderungen, die derzeit umgesetzt werden (im aktuellen Sprint). Sie entsprechen den wichtigsten noch umzusetzenenden Anforderungen aus dem Product Backlog. Im Unterschied zum Product Backlock dürfen die Anforderungen, die sich bereits im Sprint Backlock befinden, nicht mehr oder nur noch geringfügig geändert werden, da sie bereits umgesetzt werden. Die Anforderungen im Product Backlog können hingegen jederzeit geändert werden (genau das ist der Vorteil einer agilen Methode). 4 RUP Prinzip + Vorteile + Phasen + Einsatzgebiet 5 Was ist ein PERT Diagram? 2

3 6 Was ist Valdierung und was Verifikation. Verifikation meint die Überprüfung, ob die Ergebnisse einer Phase mit den Dokumenten, die in früheren Phasen angefertigt worden sind, übereinstimmen. Es geht also darum, ob das Produkt richtig umgesetzt wurden. Validierung ist dagegen die Überprüfung, ob ein erzeugtes (Zwischen)Produkt mit den Anforderungen des Kunden übereinstimmt. Das kann durch Verifikation nicht überprüft werden, da bereits die Software Requirements Specification falsch sein kann und sich dieser Fehler dann im Laufe des Projektes ausbreitet und verschlimmert (es würden dann also falsche Anforderungen richtig umgesetzt werden). Es geht dabei somit darum, ob das Richtige umgesetzt wurde. 7 Skiziieren sie Black Box und White Box testing Black Box Testing Man nutzt dabei das Wissen über den inneren Aufbau der Software nicht sondern spezifiziert die Testfälle anhand der Requirements-Dokumente. Ziel des Tests und nur die Überprüfung einer korrekten Input-Output-Relation. Die Eingabedaten werden dabei entsprechend den Use Cases in Äquivalenzklassen unterteilt. Werte, die aus Benutzersicht zu ähnlichen Ergebnissen führen kommen in eine Äquivalenzklasse. Die Abdeckung eines Tests richtet sich nach den abgedeckten Anforderungen. Das Lokalisieren von Fehlern ist dabei nicht oder nur eingeschränkt möglich. White Box Testing Hier wird das Wissen über den inneren Aufbau genutzt und ist auch notwendig da die Testfälle anhand der Implementierung spezifiziert werden. Die Eingabedaten werden entsprechend der Verzweigungen im Programm in Äquivalenzklassen unterteilt (Werte, die gleiche Pfade durchlaufen, kommen in eine Äquivalenzklasse). Zur Abdeckung: Ziel ist es, alle Knoten und Pfade (einer gewissen Länge entsprechend der Testintensität) abzudecken. Das Lokalisieren von Fehlern ist ziemlich genau möglich. 8 V-Modell Prinzip + Vorteile + welche zweige/ebenen gibt es Phasen, Zweige und Ebenen Voruntersuchung (Anforderungsanalyse, Systemspezifikation): Es wird ermittelt was überhaupt umzusetzen ist 3

4 Analyse (HW/SW-Anforderungsanalyse): Die Analyse wird verfeinert indem man benötigte Hard- und Softwarefragmente identifiziert Design: Die Komponenten des geplanten Systems werden (inklusive Schnittstellen) entworfen, wobei hier noch nicht auf Details bei der Implementierung eingegangen wird Implementierung (Feinentwurf, Implementierung im engeren Sinne): Für die einzelnen Module wird im Feinentwurf nun auch der innere Aufbau beschrieben und anschließend implementiert Test Integration (Systemintegration, Überleitung in die Nutzung): Die einzelnen Komponenten werden zusammengefügt und das System schließlich an den Kunden übergeben Die Punkte bis zum Feinentwurf bilden den ersten Zweig des V-Modells und sind der Spezifikation zuzuordnen, der Rest beschäftigt sich mit Implementierung, Test und Integration. Die 3 Ebenen des V-Modells sind die Benutzersicht (Voruntersuchung, Integration), die Designsicht (Analyse, Design, Test) und die Implementierungssich (Feinentwurf, Implementierung ies). Vorteile Das V-Modell legt viel Wert auf Dokumentation und ermöglicht daher genaue Vergleiche mit anderen Projekten und gute Aufwandsabschätzungen. Außerdem ist es aus diesem Grund gut geeignet um neue Mitarbeiter hinzuzuziehen. Der Projektfortschritt ist gut überwachbar. Es ist weiters das Basismodell für das V-Modell XT, das inzwischen in Deutschlang bei öffentlichen Auftraggebern verpflichtend ist. 9 V-Modell XT + tailoring + Einsatzgebiet Tailoring Tailoring bedeutet die Anpassung eines Softwareentwicklungs-Modells an einen konkreten Betrieb oder ein Projekt (komplett standardisierte Modelle passen nicht in jeder Situation vollständig). V-Modell XT XT steht für ëxtreme tailoringünd verdeutlicht wofür das Modell steht, nämlich für sehr gute Anpassbarkeit an konkrete Betriebe oder Projekte. 4

5 Im Unterschied zum V-Modell 97 ist kein starrer Ablauf vorgegeben, sondern es kann flexibel ein Modell aus so genannten Grundbausteinen zusammengebaut werden, die je nach Projekttyp auch fehlen können (es gibt aber auch Grundbausteine, wie etwa das Qualitätsmanagement, die in allen Projekten vorgeschrieben sind). Der Ablauf eines Projektes ergibt sich konkret indem aus so genannten Entscheidungspunkten (das sind definierte Punkte im Projektverlauf, an denen bestimmte (Zwischen)Produkte vorliegen müssen und an denen eine Fortschrittsentscheidung getroffen wird, z.b. FFeinentwurf abgeschlossen sie entsprechen in etwa den Meilensteinen) verbindet und damit eine Projekt.Durchführungsstrategie zusammenstellt. Einsatzgebiet Das V-Modell XT kann für verschiedene Projekttypen eingesetzt werden. Derzeit unterstützt es Hard- und Softwareprojekte aus Auftragnehmer- und Auftraggebersicht. Außerdem werden Inhouse-Projekte (Auftraggeber- und nehmer ist die gleiche Firma) und die Einführung eines Prozessmodells selbst als Projekttypen unterstützt. Es eignet sich aber eher für größere Projekte und ist für kleinere - so wie das V-Modell 97 - überdimensioniert. Bei Projekten für öffentliche Auftraggeber ist das V-Modell XT in Deutschland inzwischen verpflichtend. 10 Welche Testarten gibts? Eine Unterscheidung kann man anhand des Wissens machen, das man bei der Testfall- Spezifikation nutzt (Black Box, White Box - siehe 7) oder anhand der Granularitätsebene: Unit Tests: Test von einzelnen Klassen und Modulen Integrationstest: Test des Zusammenspiels mehrerer Komponenten Systemtest: Test des Gesamtsystems Regressionstest: Test der geänderten Teile nach einer Änderung Akzeptanztest: Test, ob der Benutzer mit dem System zufrieden ist Installationstest: Test, ob das Rollout mit vertretbarem Aufwand möglich ist 11 Welche Integrationsarten exisiteren bzw. was ist Integration überhaupt? Integration meint die Zusammenfügung einzeln entwickelter Komponenten. Integrationsarten 5

6 Top-Down: Die Module werden von oberen Schichten der Softwarearchitektur nach unten zusammengefügt (z.b. zuerst das GUI, dann die Business Logic, dann der DA-Layer). Bottom-Up: Genau umgekehrt: von unten nach oben Build Integration: Es werden alle Komponenten auf unterschiedlichen Ebenen der Architektur, die gemeinsam für die Realisierung eines Use Cases benötigt werden, gleichzeitig zusammengefügt. Big Bang Integration: Das ganze System wird auf einmal integriert (nur bei sehr kleinen Projekten möglich) 12 Design prinzip system control 13 Wie kann man Anforderungen klassifizieren und jeweils 3 Beispiele nennen. Funktionale Anforderungen: Features, die das System haben muss, Korrekte Input- Output-Korrelation, Security (je nach Anwendung kann das auch ein Non-Functional Requirement sein) Nichtfunktionale Anforderungen: Benutzerfreundlichkeit, Skalierbarkeit, verfügbarkeit Design Constraints: Beziehen sich nicht auf das System aus Benutzersicht, sondern wie es realisiert wird: fokusierte Zielgruppe, Schnittstellen zu anderen Systemen, verwendete Datenformate Process Constraints: Beziehen sich auf Anforderungen an die Entwicklung selbst: z.b. welche Dokumentation anzufertigen ist, welche Resourcen zur Verfügung stehen, welches Know-How zur Verfügung gestellt wird 14 Wartung (welche Arten gibts, wie schauts im RUP aus) Arten der Wartung Corrective Maintanance: Bugs beheben Adaptive Maintanance: An geänderten Umgebungsbedingungen anpassen, z.b. an ein neues Betriebs- oder Datenbanksystem Perfective Maintanance: Verbesserungen aus Benutzersicht durchführen, z.b. neue Features einbauen 6

7 Preventive Maintanance: Soll die zukünftige Wartung vereinfachen, z.b. die Dokumentation verbessern Wartung im RUP 7