M. Zeller HS Weingarten-Ravensburg 23. September 2014

Transkript

1 Å Ö Ð ØØ ÞÙÑ ÈÖ Ø ÙÑ ËÓ ØÛ Ö Ò Ò Ö Ò M. Zeller HS Weingarten-Ravensburg 23. September 2014 ÁÒ ÐØ Ú ÖÞ Ò ½ Ð Ö Î Ö Ò Ø ÐØÙÒ ¾ ¾ ÐÐ Ñ Ò ÞÙÑ ÈÖ Ø ÙÑ ËÓ ØÛ Ö Ò Ò Ö Ò ¾ ÒØÛ ÐÙÒ ÙÑ ÙÒ ÖÞ Ù Ò Ê Ú Û ÐÙ Ö Ø Ò ¹ ÎÓÖØÖ Ø ÖÑ Ò

2 ¾ º Ë ÔØ Ñ Ö ¾¼½ Ë Ø ¾ ½ Ð Ö Î Ö Ò Ø ÐØÙÒ Nach der Veranstaltung sollen die Teilnehmer in der Lage sein kleine Projekte selbstständig mit gutem Engineering-Niveau zu planen und zu bearbeiten. In größeren Projekten sollen Sie anspruchsvolle Teilaufgaben entsprechend qualifiziert bearbeiten können. Neben der Programmierung gehören dazu insbesondere folgende Tätigkeiten: Definition der Ziele, Anforderungen und Abnahmekriterien des Projekts Entwurf einer Systemarchitektur Projektplanung (wie werden alle notwendigen Schritte identifiziert?); Aufwandsschätzung für einzelne Softwarekomponenten und für die Integration Abhängigkeiten identifizieren (zeitliche und/oder technische Abhängigkeiten) Zusammenarbeit im Team (technisch und menschlich) Ebenfalls wichtig ist die Erfahrung, dass Schätzungen und Planungen i. Allg. nicht genau eingehalten werden können bzw. nicht immer geradlinig zum Ziel führen. ¾ ÐÐ Ñ Ò ÞÙÑ ÈÖ Ø ÙÑ ËÓ ØÛ Ö Ò Ò Ö Ò Ein Gruppe besteht aus vier bis sechs Personen. Jede Projektgruppe füllt während des Praktikums folgende Rollen aus: Anbieter eines SW-Systems X Kunde, der ein SW-System Y in Auftrag gibt QS für SW-System Y Bitte simulieren Sie die Rollenverteilung innerhalb des Projekts und beherzigen folgende Hinweise: Nehmen Sie sich nur ca. die Hälfte dessen vor, was Sie meinen, in einem Semester erreichen zu können. Gehen Sie mit Fragen aktiv auf die Betreuer zu, wir können nicht immer ahnen ob bzw. wo Sie Schwierigkeiten haben. Jede Gruppe sollte sich intern organisieren (Projektleiter/Product Owner/Scrum-Master wählen, Aufgaben verteilen, Kommunikationswege definieren etc.). Dabei sollte die Arbeit nicht rein nach Art der Tätigkeiten sondern mehr nach Teilsystemen aufgeteilt werden, so dass jeder Teilnehmer die Tätigkeiten Analyse, Design, Implementierung und Test durchführt. Die Rollen innerhalb der Gruppe können wechseln; dies gilt auch für den/die Projektleiter(in). Während des SWE-Praktikums erstellen die Teilnehmer verschiedene Erzeugnisse/Deliverables (z. B. Design-Dokumente, Quell-Code... ). Die Qualität dieser Erzeugnisse wird durch Reviews von der Kunden-Gruppe überprüft. Jede Abgabe besteht dann aus dem Erzeugnis und dem

3 ¾ º Ë ÔØ Ñ Ö ¾¼½ Ë Ø Review-Protokoll (s. Abschnitt 5). Zusätzlich sollten Sie sich Notizen für den Abschlussbericht erstellen (s. Abschnitt 6). Die Projekte sollten gemäß dem Unified Process abgewickelt werden; alternativ ist auch agile Entwicklung nach Scrum möglich. Definieren Sie die Testfälle, bevor Sie mit der Implementierung beginnen (test-first Ansatz) Bei der Implementierung Kann/sollte das Pair-Programming angewendet werden (zwei Personen an einem Rechner, einer programmiert und erklärt, der andere reflektiert/korrigiert, Rollen und Zusammensetzung wechseln). Wenn Softwarekomponenten verschiedener Entwickler zusammenspielen müssen, so sollten die Komponenten möglichst frühzeitig integriert werden. Testen Sie bitte die Zusammenarbeit der jeweiligen Komponenten, sobald Sie lauffähige Versionen haben, nicht erst kurz vor Projektende (continous integration). Jede Gruppe führt eine Risiko-Liste, die mögliche Risiken für den Projekterfolg enthält. Die Reihenfolge der Arbeitsschritte wird dann u. a. durch diese Risikoliste bestimmt. Jeder Teilnehmer hält im Laufe des Praktikums einen Vortrag (Dauer ca Minuten). Näheres s.abschnitt 8. Achtung: An den Praktikumsterminen sollten Sie mit höchster Priorität (aber mit hoffentlich geringem Zeitaufwand) Organisatorisches klären. (Z. B. Wer macht was, wann ist welches Erzeugnis fertig, wer integriert und testet XY...) Entwerfen und Programmieren können Sie zu jeder Tages- und Nachtzeit. ÒØÛ ÐÙÒ ÙÑ ÙÒ Richten Sie sich eine Entwicklungsumgebung ein; Sie benötigen voraussichtlich: IDE im engeren Sinne: NetBeans, Eclipse, Visual Studio, KDevelop... UML-Tool: Plugin für IDE oder separates Tool (Argo-UML, Star-UML) Build-System: Ant, Maven, Jenkins... Versions-Kontroll-System: GIT, Subversion, Bazaar,... Unit-Test-System Bug-Tracker/Ticket-System: Bugzilla, Mantis, jira,... Für die Verteilte Arbeit können Cloud-Dienste nützlich sein, z. B. Dropbox, GoogleDrive, GitHub,... Beim Aufbau der Entwicklungsumgebung können Sie gerne mit den anderen Gruppen kooperieren. Die bishereigen Erfahrungen zeigen, dass einige Tools relativ viel Verwaltungsaufwand erfordern. Dazu gehören: IBM TEam Rational Concert, MS-Project mit MS-Sharepoint. ÖÞ Ù Ò Jede Projektgruppe führt einen Projekt-Ordner (Projekt-Handbuch). Alle Erzeugnisse sind in diesem Ordner abgeheftet, ggf. in mehreren Versionen.

4 º½ Ð ØØ Ö Ó ÙÑ ÒØ Bitte achten Sie darauf, dass jedes Dokument ein Deckblatt mit folgenden Layout besitzt. Erste Zeile: Gruppen-Nummer, Gruppen-Name, (alle) Teilnehmer mit -Adresse. Zweite Zeile: Titel, Datum, Version. Anschließend bitte 2 cm Platz lassen. Auf dem Rest des Deckblattes dürfen Sie Ihrer Kreativität freien Lauf lassen. º¾ Î ÓÒ Ä Ø Ò Øµ Das Lastenheft beschreibt was das System können soll und wie es sich entwickeln kann/soll einschließlich der Einbettung in die System-Umgebung. Es definiert also die Anforderungen an das System, allerdings noch eher abstrakt, wenig detailliert. º ÈÖÓ ØÔÐ Ò Falls Sie nach Scrum entwickeln, protokollieren Sie bitte fortlaufend Entscheidungen, Meilensteine, Ergebnisse, Ereignisse.... Beschreiben Sie auch die eingesetzen Werkzeuge und Bibliotheken z. B. Versions-Überwachung, Fehlerverfolgung, Kommunikation.... Netzplan/Gannt-Diagramm für die einzelne Arbeitspunkte. Sie müssen den Projektplan, Schritt für Schritt verfeinern und laufend mit dem Projektfortschritt abgleichen und aktualisieren. Speichern Sie bitte alle Versionen des Projektplans, so dass sich die Entwicklung nachvollziehen lässt. Für jede Aktivität im Projektplan sollten folgende Angaben vorliegen: Eingangsvoraussetzung (welche Arbeitspunkte müssen abgeschlossen sein, bzw. welche Ergebnisse müssen vorliegen) geschätzter Umfang in Personen-Tagen Anfangszeitpunkt, Endzeitpunkt, Zeitraum für Nacharbeiten Bearbeiter(in)/Verantwortliche(r) Abschlusskriterien: Das Ergebnis muss verifizierbar sein (z.b. Dokument X erstellt und gegengelesen ( gereviewed ) oder Software-Anteil Y Use Case Z Testfälle 3 bis 7 erfolgreich getestet) Jeder Teilnehmer führt Buch über seine Tätigkeiten: Arbeitspunkt, Zeitaufwand, Ergebnis. Der tatsächlich Aufwand pro Arbeitspunkt soll nachvollziehbar sein. Tools: MS-Project bzw. planner oder OpenXchange º Ò ÐÝ È Ø Ò Øµ Zielrichtung wie Lastenheft, aber strenger strukturiert. Aktoren Use Cases: Use Case Diagramm und Beschreibung der einzelnen Use Cases

5 Beschreibung der externen Schnittstellen (Funktionalität durch die Use Cases, Umsetzung durch GUI-Skizzen, Beschreibung von Protokollen und/oder durch Referenz auf entspr. Standard) Nicht-funktionale Anforderungen (Plattform, Robustheit, Performance) Annahmen und Einschränkungen Die Beschreibung sollte möglichst umfassend sein (in Richtung Idealsystem). Aus dieser Beschreibung wird ein Teil zur weiteren Realisierung ausgewählt. Das Pflichtenheft für das SWENP besteht also aus einer eher umfassenden Beschreibung des Wünschenswerten und einer Auswahl von Use Cases, die im Laufe des Praktikums realisiert werden. º Ò Ihre Design-Dokumente sollten folgende Punkte abdecken: Architekturentscheidungen Definition von Schichten bzw. Komponenten, Datenfluss und Kontrollfluss Parallelität (z. B. ein Prozess oder mehrere, single-threaded oder multi-threaded, Verteilung auf Knoten, etc.) Persistenz der Daten (z. B. Dateien oder DB) MMI (GUI oder Kommandozeile) Einsatz von Frameworks (z. B. EJB, QT,.net, JDBC, ODBC, Swing, MFC) Subsysteme/Funktionale Blöcke/Packages Klassendiagramm(e) Sequenz-Diagramme Activity-Diagramme weitere UML-Diagramme soweit sinnvoll º ËÝ Ø Ñ Das System das Sie erstellen umfasst folgende Komponenten Quell-Code Build-System Konfigurationsdaten ggf. Installations-Skript º Ì ØÔÐ Ò»Ì Ø Ö Ø Testfälle für die einzelnen Use Cases: Alle Varianten müssen abgedeckt sein. (Blackbox- Test) Unit-Tests: Test-Fälle für Subsysteme oder einzelne Klassen: Wichtige Einzelfunktionen werden separat getestet. (Whitebox-Test)

6 Test der nicht-funktionalen Anforderungen (Plattform, Robustheit, Performance) Zu jedem Testfall gehören folgende Angaben: a) Voraussetzungen (z. B. der Nutzer Admin ist angemeldet, das System ist im Zustand X) b) Nutzeraktion/Ereignis (z.b. Button X drücken, Timer Y läuft ab) c) Erwartetes Systemverhalten (z.b. Diagnose abspeichern, System geht von Zustand X in Zustand Y) d) Tatsächliches Systemverhalten (zunächst als Leerfeld) Die Punkte b), c) und d) kommen ggf. mehrfach vor. Die Testergebnisse sind immer auch anhand konkrete Werte darzustellen, nicht nur allgemein. º ÁÒ Ø ÐÐ Ø ÓÒ Dokumentation º À Ò Ù Ë ÙÐÙÒ Dokumentation Ê Ú Û Jeder Teilnehmer des Reviews begutachtet den Review-Gegenstand für sich. Anschließend findet eine Besprechung mit dem Hersteller des Review-Gegenstands statt, bei der die Einzelergebnisse zusammengefasst werden. Die Teilnehmer entscheiden dann das weitere Vorgehen. Das Protokoll des Reviews enthält folgende Angaben: Datum/Uhrzeit des Reviews Teilnehmer Gegenstand des Reviews Ergebnisse: keine Korrekturen notwendig Korrekturen notwendig (aufzählen) kein weiterer Review Korrekturen notwendig (aufzählen) und weiterer Review º½ ÉÙ Ð ØØ Ö Ø Ö Ò Ö È Ø Ò Ø alle Aktoren sind enthalten, aber keine Duplikate alle Use Cases sind enthalten, aber keine Duplikate jeder Use Case wird von genau einem Aktor angestoßen jeder Use Case erreicht ein Ziel für den Aktor

7 die externen Schnittstellen des Systems sind funktional beschrieben alle Beschreibungen sind für die Beteiligten klar und eindeutig die nichtfunktionalen Anforderungen sind beschrieben Annahmen und Einschränkungen für das System sind beschrieben º¾ ÉÙ Ð ØØ Ö Ø Ö Ò Ö Ò die Klassen sind nicht zu groß bzw. zu komplex jede Klasse ist notwendig bzw. sinnvoll jede Klasse hat ihren klar definierten Aufgabebereich die Mittel Vererbung und Assoziation (bzw. Aggregtion, Komposition) sind angemessen eingesetzt der Ablauf der verschiedenen Aktivitäten ist klar beschrieben das Zusammenspiel der Klassen bzw. Objekte ist klar beschrieben die externen Schnittstellen des Systems sind technisch beschrieben (z. B. GUI: Layout- Skizze, Datei: Datenformat, Interprozesskommunikation: Protokoll) Design Patterns sind sinnvoll eingesetzt alle Use Cases können abgearbeitet werden die nichtfunktionalen Anforderungen können erfüllt werden º ÉÙ Ð ØØ Ö Ø Ö Ò Ö Ò ÉÙ Ðй Ó Ñ Ø Ó ÙÑ ÒØ Ø ÓÒ Fehler im Quell-Code Einheitlichkeit aller Stil-Elemente Größe und Komplexität von Klassen Namen von Variablen und Funktionen Länge und Komplexität von Funktionen Code-Layout Übereinstimmung von Dokumentation mit Quell-Code Vollständigkeit der Dokumentation: Ist die Dokumentation ausreichend, um den Code und den Kontext zu verstehen? Notation der Dokumentation: Ist die Dokumentation in der festgelegten Notation (z. B. UML) abgefasst? Qualität der Kommentare: Erfüllen die Kommetare die formalen und inhaltlichen Anforderungen? Formale Anforderungen sind z. B.: Jede Funktion besitzt einen Header mit Autor, Change-History (wer, was, wann geändert), Aufgabe der Funktion, Eingabe, Ausgabe, Seiteneffekte,.... Inhaltliche Anforderungen: Sind die Angaben verständlich, vollständig und auf das Notwendige begrenzt?

8 ÐÙ Ö Ø Jeder Teilnehmer fasst seine Erfahrungen, Bewertungen und Erkenntnisse auf ca. 0,5-1,5 Seiten zusammen. Dabei sollten u. a. die folgenden Punkte berührt werden: Entwicklungsprozess und Planung, Zusammenarbeit und Organisation der Gruppe, Betreuung durch Dozenten, Überraschungen bzw. Aha-Erlebnisse (technischer und nicht-technischer Art). Den Abschlussbericht können Sie auch ganz oder teilweise anonym abgeben. Die Gruppe fasst die individuellen Abschlussberichte zu einem gemeinsamen Abschlussbericht zusammen; dabei sollen nicht einfach die Texte kopiert werden, vielmehr sollen die gemeinsamen Inhalte als solche dargestellt werden und ggf. individuelle Abweichungen beschrieben bzw. erklärt werden. (Auch diesen Bericht können Sie anonym abgeben.) Ò ¹ Am Ende des Praktikums gebe Sie bitte einen Ordner mit folgendem Inhalt ab: Projektplan (s. Abschnitt 4.3) Pflichtenheft/Anforderungen (s. Abschnitt 4.4) Design (System-Architektur) (s. Abschnitt 4.5) Benutzerhandbuch für Ihr Produkt Datenträger mit Quellcode (s. Abschnitt 4.6) Abschlussbericht (s. Abschnitt 6) Testat-Blätter von allen Mitgliedern der Gruppe ÎÓÖØÖ Jeder Teilnehmer hält im Laufe des Praktikums einen Vortrag von ca Minuten Dauer. Dabei sollen pro Gruppe folgenden Themen vorgestellt werden: Pflichtenheft/Anforderungen Design (System-Architektur) Technische Besonderheiten (z. B. Einsatz von Komponenten, DB, Multithreading) sonstige Besonderheiten (z. B. unerwartete Schwierigkeiten, Aha-Erlebnisse) Sie können sich selbst weitere Themen suchen oder aus den folgenden Vorschlägen wählen: Teamarbeit/Organisation/Planung GUI-Design Die Vorträge halten Sie bitte im Zeitraum KW 03/15 - KW 04/15; sprechen Sie die Termine bitte vorher mit mir ab.

9 Ø ÖÑ Ò Lastenheft KW 42/14 Pflichtenheft KW 44/14 Projektplan KW 44 u. 50/14 Testplan KW 46/14 Design KW 46 u. 50/14 Testbericht KW 04/15 Projektplan, aktualisiert KW 04/15 Dokumentation KW 05/15 Abschlussbericht KW 05/15