First Edition. BachelorPraktikum. Hinweise für Teilnehmer. Dr. Michael Eichberg Johannes Lerch Joscha Drechsler

Transkript

1 First Edition BachelorPraktikum Hinweise für Teilnehmer Dr. Michael Eichberg Johannes Lerch Joscha Drechsler

2 Bachelor-Praktikum 1 Die wesentlichen Elemente des Bachelor-Praktikums am Fachbereich Informatik der Technischen Universität Darmstadt Dr. Michael Eichberg (Redaktion) eichberg@informatik.tu-darmstadt.de (Gesamtverantwortung) Johannes Lerch lerch@st.informatik.tu-darmstadt.de (Organisation und Ablauf) Joscha Drechsler drechsler@informatik.tu-darmstadt.de (Organisation und Ablauf)

3 Vorwort Das folgende Dokument beschreibt die wichtigsten Aspekte rund um das Bachelor-Praktikum des Fachbereichs Informatik der Technischen Universtität Darmstadt. Es dokumentiert insbesondere auch Erkenntnisse sowie Antworten auf Fragen, die im Laufe der Jahre aufgekommen sind. Das Dokument ist deswegen ein lebendes Dokument, das der ständigen Weiterentwicklung unterliegt. ii

4 Section 1 Struktur Das Bachelor-Praktikum des Fachbereichs Informatik der Technischen Universität Darmstadt gliedert sich auf in zwei Lehrveranstaltungen: Bachelor-Praktikum Ein Praktikum des Fachbereichs Informatik, bei dem über ein Zeitraum von 6 Monaten eine umfangreiche(re) Aufgabenstellung in einem Team von vier Studierenden bearbeitet wird. Die Aufgabenstellungen werden von den Fachgebieten der Technischen Universität Darmstadt gestellt. Die Organisation und fachliche Betreuung erfolgt durch den Fachbereich Informatik. Das Bachelor-Praktikum ist verpflichtend für Bachelor-Studierende des Studienganges Bsc Informatik. Bachelor-Praktikum (6CP) Projektbegleitung Projektbegleitung (3CP) Die Projektbegleitung ist eine integrierte Lehrveranstaltung zur Begleitung des Bachelor-Praktikums. Die Projektbegleitung ergänzt die Kanonik Einführung in Software Engineering und dient der Vermittlung / Wiederholung von Kenntnissen, die notwendig sind für die systematische Softwareentwicklung. Insbesondere wird auf die Darstellung von hilfreichen Werkzeugen zur Durchführung von Software Engineering Projekten eingegangen. Einen weiteren Schwerpunkt bildet die Erstellung des Qualitätssicherungsdokuments. Darüber hinaus werden im Rahmen der Projektbegleitung die Projektthemen durch die Studierendengruppen präsentiert. 3

5 Section 2 Ablauf Projektbegleitung (Sommersemester 14) Opt-in Deadline für Supervision Vorstellung HDA; QS-Dokument Tools Bachelor-Praktikum Start - jetzt D.h. der Teamleiter wird sich (sehr zeitnahe) bei seinen Gruppen melden, um ein erstes Treffen zu vereinbaren. Gemeinsam mit dem Teamleiter wird dann ein Treffen mit dem Auftraggeber vereinbart. (im Normalfall im Laufe der nächsten Woche; spätestens jedoch übernächste Woche) Ende Abgabe aller Dokumente und Beendigung der Implementierung (Dieser Termin ist strikt und unter keinen Umständen verhandelbar.) Anfang/Mitte Mai Abgabe der Vorversion der Qualitätssicherungsdokumente (Datum vorgegeben durch Teamleiter.) (Deckblatt + max. 2 Seiten; behandelt ausschließlich die Sicherung der Qualität des Codes) Besprechung der Vorabgaben der Qualitätssicherungsdokumente Tools , Projektbegleitungsvorlesung entfällt (HDA) 4.7., Präsentation der Projekte (Anwesenheit aller Teilnehmer ist gefordert) Mitte Juni/Anfang Juli - Abgabe der QS-Dokumente Abschluss der Projektbegleitung 4

6 Section 3 Abgaben Agiler Softwareentwicklungsprozess Sollte der agile Softwareentwicklungsprozess gewählt werden, dann sind folgende Artefakte abzugeben. Im Folgenden wird beschrieben welche Artefakte am Ende des Projektes abzugeben sind. Die Art der Dokumente, die abzugeben sind, richtet sich nach dem gewählten Softwareentwicklungsprozess und ist im Folgenden beschrieben. Das Dokumentenformat muss in allen Fällen PDF sein. Über die im Folgenden genannten Artefakte hinaus sind keine weiteren Dokumente (insbesondere kein Sourcecode oder vergleichbares) bei der Projektbegleitung abzugeben. Prozessunabhängig " Qualitätssicherungsdokument " Anhang zum Qualitätssicherungsdokument " User Stories bzw. erfasste Anforderungen " (ggf. Anhang zu den User Stories) Unified Process In diesem Fall ist ein Pflichtenheft zu erstellen, dass vom Auftraggeber abgenommen werden muss und alle wesentlichen Abschnitte aufweisen muss. Für die weiteren Details nehmen Sie bitte Kontakt zur Projektbegleitung auf. Am Ende des Projektes ist immer ein Projekttagebuch abzugeben. Dies gilt auch dann, wenn das Projekttagebuch leer ist. In diesem Fall sollte das Tagebuch lediglich den Eintrag keine Einträge enthalten. (Eine Abgabe ist deswegen gefordert, um unterscheiden zu können zwischen (a) die Abgabe wurde vergessen und (b) ein leeres Projekttagebuch wurde abgegeben.) 5

7 Section 4 Projekttagebuch ein Teammitglied hält sich (wiederholt) nicht an Absprachen bzw. Zusagen Das Projekttagebuch dokumentiert ausschließlich projektgefährdende Ereignisse. Im Regelfall enthält das Projekttagebuch deshalb auch keine Einträge. Beispiele für projektgefährdende Ereignisse sind: ernsthafte Erkrankungen der Teammitglieder/des Teamleiters/ des Auftraggebers der Auftraggeber hat Zusagen (zum Beispiel in Hinblick auf das zur Verfügung stellen von Hardware/Software oder Spezifikationen) nicht eingehalten der Auftraggeber (d.h. der Ansprechpartner) wechselt die Aufgabenstellung wird während der Projektphase grundlegend geändert (In diesem Fall nehmen Sie bitte auch umgehend mit der Projektbegleitung Kontakt auf.) ein Teammitglied verlässt die Gruppe 6

8 Section 5 Qualitätssicherungsdokument Überblick Das Ziel des Qualitätssicherungsdokuments ist es zu beschreiben, wie die Qualität des zu erstellenden Produktes im Rahmen des gewählten Projektes gesichert wird. Dies umfasst sowohl die (I) Beschreibung des Prozesses der Qualitätssicherung als auch (II) der Ziele und (III) der gewählten Maßnahmen. Darüber hinaus muss das Dokument den Qualitätssicherungsprozess beschreiben. D.h. wann wird welche Maßnahme durch wen durchgeführt und wie wird auf gefundene Qualitätsprobleme reagiert. Ist eine Erreichung der durch den Auftraggeber (explizit oder implizit) vorgegebenen Qualitätsziele im Rahmen des Projekts nicht (mehr) möglich, so ist zu begründen warum dies nicht mehr möglich ist und warum davon am Anfang davon ausgegangen wurde, dass die Ziele erreichbar und die Maßnahmen durchführbar sind. Weiterhin ist darzulegen, welche alternativen Qualitätsziele verfolgt wurden und welche Maßnahmen mit welchem Prozess durchgeführt wurden. Der mit Projektende abzugebende Anhang belegt, dass die Qualitätssicherung wie beschrieben durchgeführt wurde. Dabei ist ausgehend von den für das Projekt relevanten und im Idealfall mit dem Auftraggeber abgestimmten Qualitätszielen zu beschreiben, wie die entsprechenden Qualitätssicherungsmaßnahmen aussehen. Es ist darauf zu achten, dass alle im Dokument beschriebenen Prozesse, Ziele und Maßnahmen im Kontext des konkreten Projektes erreichbar und durchführbar sind. Eine mögliche Maßnahme, um zum Beispiel hohe Codequalität zu erreichen, ist die regelmäßige, strukturierte Durchführung von Code Reviews oder der regelmäßige Einsatz von Tools zur statischen/dynamischen Analyse. 7

9 Eine mögliche Vorlage (I) Beschreibung des projektspezifischen Qualitätszieles & kurze Begründung: Im Rahmen dieses Projektes hat die Sicherstellung der höchste Priorität, da. (II) Beschreibung der Maßnahmen, die durchgeführt werden, um das Erreichen des Zieles sicherzustellen: Um das Qualitätsziel zu erreichen, führen wir regelmäßig Tests/Studien/Code Reviews/Schulungen/ durch. [Aussagen, die die Maßnahme genau beschreiben.] Weiterhin setzen wir folgende Werkzeuge ein, die. (III) Beschreibung des Prozesses: Die Maßnahme wird alle durchgeführt. Die Ergebnisse werden... diskutiert und einem Entwickler zum Lösen zugewiesen. Für geänderten Code wird der selbe Qualitätssicherungsprozess angewandt wie für neuen. 8

10 Allgemeine Hinweise Es handelt sich um ein Dokument im TU Darmstadt Design mit max. 10 Seiten (ohne Anhang); die von der Projektbegleitung zur Verfügung gestellte Vorlage ist zu verwenden. Auf dem Deckblatt sind zu vermerken: Das Projektthema/der Titel des Projekts Die vollständigen Namen der Teammitglieder Kontakt ( ) nen Umständen eine Einführung (in welcher Hinsicht auch immer) in Qualitätssicherung enthält. Sollte der Auftraggeber dies explizit wünschen, so ist dies auch explizit auf dem Dokument zu vermerken. Vergessen Sie nicht die Qualität des Qualitätssicherungsdokumentes zu sichern! Stellen Sie insbesondere sicher, dass die folgenden Fragen in Ihrem Dokument beantwortet sind: Ergibt sich aus der Projektbeschreibung, warum die dargestellten Ziele, die essentiellen Ziele sind? Welches sind die zentralen Qualitätsziele des Projekts? Der vollständige Name des Teamleiters Warum sind dies die zentralen Ziele? Name der Auftraggeber(in)/des Auftraggebers (inkl. Fachgebiet/Fachbereich) Welche Maßnahmen werden durchgeführt? Gruppennummer Ein Qualitätssicherungsziel, dass von Seiten der Projektbegleitung gesetzt ist und dass alle Gruppen im Rahmen des Qualitätssicherungsdokumentes beschreiben müssen ist die Sicherung der Qualität des Codes im weiteren Sinn. Hierbei ist zu beachten, dass auch dieses Ziel auf das konkrete Projekt angepasst werden muss. Wie dienen die Maßnahmen dem Erreichen der gegebenen Ziele? Sind die Maßnahmen dafür geeignet die Ziele zu erreichen? Durch wen werden die Maßnahmen durchgeführt und wie wird auf Probleme bis wann reagiert? Ist die Häufigkeit, mit der die Maßnahmen durchgeführt wird angemessen? Bitte beachten Sie, dass sofern der Auftraggeber nichts anderes wünscht das Qualitätssicherungsdokument unter kei9

11 Qualitätsmerkmale Sicherheit (eng. Safety) Genauigkeit Angemessenheit Funktionalität Eigenschaft eines Systems weder Menschen, noch Sachen oder die Umwelt zu gefährden. Interoperabilität Sicherheit Reife Fehlertoleranz Zuverlässigkeit Wiederherstellbarkeit Verständlichkeit Datensicherheit (eng. Security) Eigenschaft eines Systems Informationsverluste und unbefugten Datenzugriff zu verhindern. Erlenbarkeit Software Qualitätsmerkmale Benutzbarkeit Bedienbarkeit Attraktivität (angelehnt an ISO 9126) Effizienz Zeitverhalten Verbrauchsverhalten Analysierbarkeit Wartbarkeit Änderbarkeit Stabilität Zuverlässigkeit Die Wahrscheinlichkeit des ausfallfreien Betriebs der (in diesem Kontext) Software über einen bestimmten Zeitraum bei einer definierten Betriebsweise. Testbarkeit Anpassbarkeit Portabilität Installierbarkeit Koexistenz Austauschbarkeit Korrektheit Grad der Konsistenz zwischen Spezifikation und Programm bzw. als Grad der Erfüllung der Benutzererwartung durch ein Programm (d.h. ohne Spezifikation ist keine Korrektheit nachweisbar). Verfügbarkeit Eigenschaft zu einem gegebenen Zeitpunkt funktionstüchtig zu sein. Robustheit Im Wesentlichen eine Eigenschaft der Spezifikation. Resultiert im Wesentlichen aus der korrekten Umsetzung einer Spezifikation, die auch ungewöhnliche Betriebssituationen erfasst. Vollständigkeit Alle geforderten Funktionen sind realisiert. 10

12 Beschreibung eines Qualitätszieles Beispiel Projektspezifische Motivation des Projektzieles Scope / Umfang/ Ziel Qualitätsziel: Vermeidung von Datenverlusten Im Rahmen des Projektes wird eine Webanwendung entwickelt, auf die über das Internet zugegriffen wird. Da diese Anwendung personenbezogene Daten verarbeitet und potentiellen Angriffen ausgesetzt ist, ist ein wesentliches Qualitätsziel, dass die Anwendung keine Sicherheitslücken aufweist über die Angreifer Daten anderer Benutzer abgreifen können. Im Rahmen dieses Projektes können wir jedoch nur gewährleisten, dass die Webanwendung keine Standardlücken wie zum Beispiel SQL Injection aufweist. Um dieses Ziel zu erreichen, setzen wir die folgenden Tools: ein. Darüber hinaus wurde ein Entwickler benannt, der sich maßgeblich um das Thema Sicherheit in Webanwendungen kümmert und Die automatisierte Analyse des Codes der Webanwendung erfolgt im Rahmen des regelmäßigen Nightly Builds. Sollte ein Problem gefunden werden, so geht eine Mail an alle Entwickler und im Rahmen des nächsten (gruppeninternen) Meetings wird dann ein Entwickler bestimmt, der den Fehler beseitigt. Wann und durch wen? Wie wird darauf reagiert? 11

13 Typische Probleme (Alle im Folgenden wiedergegeben Ausschnitte entstammen (Vorabgaben von) Qualitätssicherungsdokumenten der vergangen Jahre.) Durch eine Evaluation kann man die Benutzerfreundlichkeit ermitteln, aber nicht gewährleisten! Bindestriche werden wahllos platziert. Aussagen aus QS Dokumenten Qualitäts-Faktoren Umgangssprachlich Hier beißt sich also die Katze in gewissem Sinne in den eigenen Schwanz. Die Rechtschreibung insbesondere in Hinblick auf die Anwendung der Kommaregeln ist sehr schlecht. Tipp: Komm wir essen Opa (Satzzeichen retten leben) Die Struktur des Dokumentes hält sich nicht an die etablierten Regeln. Insbesondere gibt es Kapitel mit nur einem Unterkapitel statt mindestens zwei Unterkapiteln. Tipp: Nehmen Sie sich ein (ggf. elektonisches) Buch eines renommierten Verlages und strukturieren Sie das Dokument in vergleichbarer Weise. Eats(,) Shoots & Leaves Deutsch und Englisch werden wild gemischt. Einzelne Sätze machen schon für sich alleine genommen keinen Sinn. Außerdem soll eine Evaluation die Benutzerfreundlichkeit der Anwendung gewährleisten. Im Weiteren werden folgende Qualitätsfaktoren [...]: Correctness 12

14 Robustness Extendibility Es wird nicht präzise beschrieben, was getan wird. Statt dessen wird beschrieben, was möglicherweise getan werden könnte. Um dies zu beschleunigen, wollen wir eine Dokumentation über die Schnittstellen unserer Software bereitstellen. Der Qualitätssicherungsprozess ist nicht zu Ende gedacht bzw. nicht ausreichend beschrieben. Am Ende des Projektes führen eine Benutzerstudie durch, um [...] zu erreichen. Dinge, die am Ende des Projektes gemacht werden, können faktisch keine wesentliche Auswirkung mehr auf das Produkt haben und somit der Erreichung eines Qualitätszieles nicht mehr dienen. Tipp: Geben Sie immer (relativ) präzise an, wann Sie eine Maßnahme durchführen werden und überlegen Sie sich genau, ob der Zeitraum, der nach der Durchführung der Maßnahme noch zur Verfügung steht, ausreicht, um ggf. das Ziel noch (teilweise) zu erreichen. Es werden bei weiten zu viele Qualitätsziele und Maßnahmen beschrieben und verfolgt. Tipp: Fragen Sie sich genau was im Rahmen dieses Projektes am Wichtigsten ist, wie viel Sie zeitlich leisten können und an welchen Stellen die größten Risiken liegen bzgl. der Nichterreichung des Projektzieles. Der Abstraktionsgrad innerhalb eines Abschnitts springt wild hin und her. Es werden Qualitätsziele, die für das Projekt nicht relevant sind, und Maßnahmen, die nicht durchgeführt werden, beschrieben. Zu beschreiben, was nicht getan wird, macht fast ausschließlich nur dann Sinn, wenn Sie den Umfang einer Maßnahme begrenzen wollen auf ein für das Projekt sinnvolles Maß. Jedes eingesetzte Werkzeug wird als Qualitätssicherungswerkzeug betrachtet. Als integrierte Entwicklungsumgebung (IDE) wird Netbeans verwendet, wodurch Syntaxfehler vermieden werden. 13

15 QS-Werkzeuge[ ] Skype [Sky] ist eine kostenlose Voice Over IP (VOIP) Software, welche zusätzlich noch die Funktionen zu Instant Messaging, Dateiübertragung und Videotelefonie bietet. Im Rahmen des Projektes wurde ein Chatraum in Skype eingerichtet, in welchem sich täglich über das Projekt ausgetauscht wurde. Skype unterstützte die Teamarbeit. jektbegleitung sein. Schreiben Sie also nichts, was Personen, die sich seit vielen Jahren mit Fragen der Softwaretechnik beschäftigen, auf jeden Fall wissen. Sollte der Auftraggeber Interesse an dem Qualitätssicherungsdokument zeigen und dieses (weiter)verwenden wollen, dann benennen Sie die Zielgruppen bitte am Anfang des Dokumentes. Integrierte Entwicklungsumgebungen, Versionskontrollsysteme, Projektmanagementsoftware und Chatclients dienen primär/ ausschließlich der Produktivität bzw. der Steuerung des Projektes jedoch nicht der eigentlichen Produktqualität. Inversion des Kontrollflusses: Durch den Einsatz des Frameworks wird erreicht, dass sich der Entwickler nicht mehr um den Kontrollfluss der Web-Anwendung kümmern muss. Das erledigt das Framework für ihn. Der Projektbezug ist nicht gegeben und es handelt sich um eine allgemeingültige Feststellung. Blah, Blah, Blah Unser Auftraggeber ist zufrieden, wenn unser Produkt am Ende eines Sprints die Akzeptanzkriterien der mit ihm im Gespräch entwickelten User Stories erfüllt. Wenn unser Auftraggeber zufrieden ist, sind wir zufrieden. [...] Tipp: Bedenken Sie immer die Zielgruppe, für die Sie ein Dokument erstellen. In diesem Fall dürfte es fast immer (nur) die Pro- Statt einem Qualitätsziel wird eine (nicht-)funktionale Anforderung beschrieben. Schwammige Aussagen Um möglichst fehlerfreien Code zu erreichen, werden wir umfangreiche Tests zusätzlich zum Code entwickeln. 14

16 Hier stellt sich unter anderem die Frage nach dem Umfang von umfangreichen Tests? Ähnliche Aussagen finden sich häufig auch in Hinblick auf die Dokumentation des Codes. Tipp: Es ist häufig hilfreicher/einfacher den Umfang einer Testsuite über die (Kern-)Komponenten bzw. über die umzusetzenden Features zu beschreiben. 15

17 Der Anhang des Qualitätssicherungsdokumentes quenzen gezogen wurden (z.b. durch Referenz auf zeitlich nachfolgende User Stories). Der Anhang muss dokumentieren, dass die beschriebenen Qualitätsmaßnahmen und Prozesse auch durchgeführt wurden. Es ist hierbei insbesondere darauf zu achten, dass erkenntlich ist, dass der Prozess eingehalten wurde (d.h. wann und wie häufig etwas getan wurde) und auch, dass die Maßnahmen im beschriebenen Umfang durchgeführt wurden. Dokumentation des Quellcodes Im Folgenden stellen wir für typische Maßnahmen bzw. Ziele dar, wie diese ggf. zu belegen sind. Lesen Sie auf jeden Fall alle Abschnitte, da viele Dinge ggf. auf Ihre Maßnahmen und Ziele übertragbar sind. Benutzerstudie Im Anhang muss dokumentiert sein, wann diese Studie(n) von wem und mit welchen Probanden durchgeführt wurde. Darüber hinaus sind die ausgefüllten Fragebögen und auch die entsprechenden aggregierten Ergebnisse anzuhängen. Wurden die Probanden beobachtet, dann sind die entsprechenden Protokolle anzuhängen. Insbesondere ist kurz zu dokumentieren, welche Ergebnisse aus der Benutzerstudie abgeleitet wurden und welche Konse- Ist eine Maßnahme, die versprochen wurde, dass der Code dokumentiert wurde, so ist hier ein Auszug des Codes abzugeben. Der Auszug muss aus mindestens drei verschiedenen Klassen, Headerfiles oder etwas vergleichbaren Bestehen. Die Dateien müssen von der Anzahl der Zeilen Code her repräsentativ für das Projekt sein. Die gewählten Dateien müssen weiterhin von herausgehobener Bedeutung für das Projekt sein und dies muss entweder aus der Dokumentation hervorgehen oder gesondert kurz dargelegt werden. Der Code ist direkt in den Anhang zu integrieren. Automatisierte Tests Sollte das QS Dokument angeben, dass die Software automatisiert getestet wurde, so ist die vollständige Liste der Tests abzugeben und es ist zu belegen welche Teile des Codes getestet wurden. Dies kann insbesondere dadurch geschehen, dass ein Auszug eines Codeabdeckungstools angehängt wird; dargestellt auf Klassen-/Dateiebene. Bitte geben Sie auf jeden Fall für die Tests auch an auf welche Anforderungen/User Stories/Funktionalität sich die Tests beziehen. Geht aus dem Namen des Tests hervor, worauf sich selbiger bezieht, so ist dies ausreichend. 16

18 Modularität bzw. Erweiterbarkeit Manuelle Tests Um zu belegen, dass das Ziel erreicht wurde sind die zentralen Schnittstellen inkl. der unmittelbaren Abhängigkeiten zu dokumentieren. In diesem Fall ist der Testplan anzugeben falls er nicht bereits im Hauptteil angegeben wurde. Aus dem Testplan muss hervorgehen, dass das beschriebene Qualitätsziel in vollem Umfang sichergestellt werden kann. Ein Testplan muss immer mind. folgende Informationen beinhalten: die durchzuführenden Schritte und die jeweiligen erwarteten Ergebnisse. Darüber hinaus sind die Abhängigkeiten zwischen den Klassen/ Modulen/Packages/Maven Artefakten/... genau zu dokumentieren. Abzugeben ist die Dokumentation des Standes der Erweiterbarkeit/Modularisierung am Ende des Projektes zuzüglich einer kurzen Übersicht, wann die Maßnahmen Analyse der Struktur, Definition und Besprechung der Schnittstellen, etc. durchgeführt wurden. Darüber hinaus sind die Protokolle abzugeben, welche die Ergebnisse der jeweiligen Durchführung und die ggf. gezogenen Konsequenzen angeben. Es ist auch anzugeben, wann die Tests von wem durchgeführt wurden. Code Reviews Diesbezüglich ist eine Checkliste anzuhängen falls diese nicht bereits im Hauptteil dargestellt ist aus der genau hervorgeht, was alles geprüft wird und wann die Prüfung als erfolgreich gilt. Es sind auch alle ausgefüllten Checklisten anzuhängen. Aus diesen muss jeweils hervorgehen, wann die Prüfung durch wen erfolgt ist und welche Teile einem Review unterzogen wurden. Etwaige gezogene Konsequenzen sind zu dokumentieren (analog zu Benutzerstudie ). 17

19 Ausgewählte Qualitätsmerkmale bzw. -maßnahmen. (Gut/Umfangreich/...) dokumentierter Code Documentation costs much time, usually more than actual implementation. That s the reason why people try to avoid documentation. (From: How Do Professional Developers Comprehend Software?; Tobias Boehm, Rebecca Tiarks, Rainer Koschke, Walid Maalej; ICSE 2012; IEEE) Falls Sie manuelle (GUI-)Tests durchführen, dann ist der Testplan einzureichen. Falls Sie automatisierte Tests durchführen, dann ist die vollständige Liste aller (Unit)Tests abzugeben. In allen Fällen muss erkenntlich sein, wann die Test durch wen und mit welchem Ergebnis durchgeführt wurden. Sollten Tests fehlgeschlagen haben, dann ist zu dokumentieren wann diese behoben wurden. Sollten Sie dieses Qualitätsziel gewählte haben, dann belegen Sie die gute/ausreichende Dokumentation Ihrer Software dadurch, dass Sie uns die generierte Dokumentation (HTML Seiten, PDF,...) zur Verfügung stellen. Im QS Dokument ist dann ggf. auf das/die PDFs bzw. die Hauptseite zu verweisen. (Gut/...) getesteter Code Um zu belegen, dass Sie Ihren Code getestet haben stellen Sie uns folgende Informationen zur Verfügung: Eine Analyse der Codeabdeckung (unabhängig davon ob Sie automatisierte oder manuelle Tests durchgeführt haben); spezifizieren Sie genau das zugrunde gelegte Codeabdeckungsmaß und das verwendete Werkzeug. Zum Beispiel mit ECL Emma (bei Javaprogrammen). 18

20 Werkzeuge Sprachunabhängig Im Folgenden sind einige wenige Werkzeuge aufgeführt, die im Rahmen einer systematischen Qualitätssicherung eingesetzt werden können. Gerrit (Code Review System) Java Selenium (Primarily, for testing web applications) Apache JMeter (Last- und Performancetests) Hammurapi (Verletzungen von Best Practices ) PMD (Verletzungen von Konventionen und Best Practices ) Checkstyle (Verletzungen von Konventionen) Findbugs (Verletzungen von Best Practices ) JLint (Verletzungen von Best Practices - mit Fokus auf nebenläufige Programme) (im Allgemeinen: x Lint.) ECLEmma (Abdeckung des Codes durch eine Testsuite) Java Path Finder (Software Model Checking and much more...) JDepend (Abhängigkeitsanalysen) Dependency Finder (Abhängigkeitsanalysen) Stan (Strukturanalysen) Cloc (Metriken) 19

21 Section 6 Benotung Die Bewertung der Gruppe ist vollständig unabhängig von der Benotung des Teamleiters und der Teamleiter wird auch nicht in die Notengebung der Gruppe eingebunden. Weiterhin geht der Vortrag, der im Rahmen der Vorlesung zu halten ist, in die Endnote ein. Die Endnote für die Bachelor-Praktikumsgruppe ergibt sich aus der Bewertung durch den Auftraggeber und aus der Bewertung durch die Projektorganisation. Beide Noten gehen zu 50% in die Endnote ein. Die Benotung der Projektorganisation stützt sich insbesondere auf die erstellten und abgegebenen Dokumente (basierend auf den Besonderheiten der Projekte). Sollte der agile Softwareentwicklungsprozess gewählt worden sein, dann ist dies insbesondere das Qualitätssicherungsdokument inkl. Anhang, der belegt, dass die Qualitätssicherung wie beschrieben durchgeführt wurde. Darüber hinaus wird die vollständige Dokumentation der Anforderungen herangezogen. Das Projekttagebuch dient - insbesondere für den Fall, dass es im Rahmen der Bearbeitung des Projektes zu Problemen, Verzögerungen oder Streitigkeiten (zwischen den Gruppenmitgliedern/mit dem Auftraggeber) gekommen ist - dazu, zu ermitteln woher die Schwierigkeiten kamen und ob diese (auch) in der Verantwortung der Studierenden lagen. Es dient ggf. als Basis für eine faire Benotung. In der Regel wird die Gruppe als Ganzes bewertet. Einzelnoten werden nur im Sonderfall und aufgrund des expliziten Wunsches der Gruppe bzw. bei besonderen Problemen vergeben. Im Falle des Unified Process wird insbesondere das Pflichtenheft bewertet. 20

22 Section 7 Agiler Softwareentwicklungsprozess Im Folgenden wird kurz beschrieben, wie sich ein von Extreme Programming und Scrum inspiriertes agiles Softwareprozessmodell im Rahmen des Bachelor-Praktikums umsetzen lässt. Insbesondere geht dieses Dokument darauf ein, an welchen Stellen Kompromisse eingegangen werden müssen, die sich aus der Besonderheit ergeben, dass es sich um eine Lehrveranstaltung handelt. anzuwenden, die die Software flexibel und anpassbar bzw. wartbar machen. Dazu muss man sich entsprechender Entwurfsmuster bewusst sein. Darüber hinaus ist es erforderlich Vorgehensweisen anzuwenden, die die nötige Disziplin sicherstellen und den Fortschritt zu ermitteln. Das wesentliche Ziel ist es, den Auftraggeber zu ermöglichen das Entwicklungsteam in die Richtung zu steuern, welche den höchsten Geschäftswert verspricht. Dazu ist es erforderlich, dass man auf Änderungen flexibel reagiert. Wesentliche Eckpunkte: Die regelmäßige und häufige Zusammenarbeit mit dem Kunden Der große Vorteil eines agilen Softwareentwicklungsprozesses ist, dass der Auftraggeber in einem kontrollierten Rahmen stets die Möglichkeit hat, das Projekt in die Richtung zu steuern, welche den höchsten Nutzen verspricht. Die häufige Auslieferung laufender Software, die einen Geschäftsnutzen hat; Fortschritt wird gemessen durch die Funktionalität, die umgesetzt wurde Grundlagen und Motivation Agiler Softwareentwicklungsprozesse Das Team reflektiert über die Entwicklungsprozesse Sich selbst organisierende Teams mit motivierten Individuen Streben nach technischer Exzellenz und einem guten Entwurf Das Ziel ist es Software zügig und zielstrebig zu entwickeln in der Gegenwart sich ständig ändernder Anforderungen. Um dieses Ziel zu erreichen ist es notwendig Entwurfsprinzipien 21

23 Geeignete Projekte Agile Softwareentwicklung eignet sich für Projekte, bei denen die Anforderungen bzw. die Prioritäten der einzelnen Anforderungen an die zu erstellende Software bei Beginn des Projekts nicht vollständig bekannt sind bzw. bei denen es Wahrscheinlich ist, dass sich die Anforderungen noch ändern werden. Informatikkenntnisse sind auf Seite des Auftraggebers nicht erforderlich - der Auftraggeber bzw. Kunde handelt aus seiner fachlichen Perspektive heraus. Dies sind häufig Projekte, bei denen es um die Erstellung von Webanwendungen oder anderweitigen Geschäftsanwendungen geht. Voraussetzungen auf Seiten des Projektteams Das Team sollte sich mit den Grundlagen agiler Softwareentwicklungsprozesse auseinandergesetzt haben. Darüber hinaus ist eine stetige Leistungsbereitschaft erforderlich, damit der Auftraggeber seiner Steuerungsfunktion nachkommen kann. Voraussetzungen auf Seiten des Auftraggebers Dieses Vorgehensmodell setzt voraus, dass sich der Auftraggeber zu regelmäßigen Treffen alle 2 bis 3 Wochen bereit erklärt. D.h. die Wahl dieses Prozessmodells setzt das Einverständnis des Auftraggebers voraus. 22

24 Ablauf während des Praktikums Start Im Folgenden wird davon ausgegangen, dass die einzusetzenden Technologien (Programmiersprachen etc.) bereits gesetzt sind falls dies nicht der Fall ist, dann kann bei Bedarf erst noch eine Explorationsphase vorangestellt werden. Gleiches gilt, falls das Team nicht über notwendige fachliche Kenntnisse verfügt, oder die Vorstellungen des Auftraggebers am Anfang noch sehr vage sind. In diesem Fall bietet es sich an weitere Techniken zur Anforderungsermittlung (z.b. Anwendungsfälle (Use Cases), offene Interviews oder Szenariotechniken) einzusetzen, um ein breites Verständnis für die zu entwickelnde Anwendung zu bekommen. Im Rahmen der regelmäßigen Treffen mit den Auftraggebern sind die Anforderungen an die zu entwickelnde Software in Form von (neuen) User Stories zu erfassen bzw. gegebene ggf. zu verfeinern. Im Rahmen des ersten Treffens sollte versucht werden auf einem hohen Abstraktionsniveau alle wesentlichen User Stories zu erfassen. Die User Stories, die im Rahmen der ersten Iteration umgesetzt werden sollen, müssen natürlich im Rahmen der ersten Iteration auch bereits passend herunter gebrochen werden. Aufbauend auf den erfassten User Stories wird eine Releaseplanung für das gesamte Projekt durchgeführt (zwei bis drei Relea- ses). Ein Release ist dadurch gekennzeichnet, dass es einen aus fachlicher Sicht sinnvollen Funktionsumfang umfasst. Diese soll dann im Rahmen des zweiten Treffens mit dem Auftraggeber vorgestellt werden. Während des Projekts Am Ende/am Beginn jeder Iteration treffen sich der Auftraggeber und das Team und besprechen die Ergebnisse der letzten Iteration. In diesem Rahmen stellt das Team die umgesetzten User Stories vor und der Auftraggeber nimmt diese ggf. ab. Auf Wunsch des Auftraggebers muss das Team in der Lage sein, am Ende jeder Iteration eine lauffähige Version zur Verfügung zu stellen, damit der Auftraggeber diese testen kann, um ggf. die weitere Entwicklungsrichtung zu bestimmen. Sollten neue Anforderungen aufkommen, so sind diese unmittelbar als neue User Stories zu erfassen. Weiterhin wird besprochen welche User Stories im Rahmen der nächsten Iteration umzusetzen sind (Planning Meeting). Es ist darauf zu achten, dass nur so viele User Stories durch den Auftraggeber gezogen werden, wie auch umgesetzt werden können. Falls die Geschwindigkeit des Teams noch nicht bekannt ist bzw. stark schwankt, dann ist es sinnvoll, dass der Auftraggeber den User Stories Prioritäten zuordnet, damit das Team eine genaue Vorstellung davon hat, in welcher Reihenfolge die User Stories umzusetzen sind. Insbesondere werden große User Stories herunter gebrochen, um diese durchführbar zu machen. 23