Agile Softwareentwicklung im Rahmen des Bachelor-Praktikums des Fachbereichs Informatik 17.04.12 In diesem Dokument 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.
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. Dies sind häufig Projekte, bei denen es um die Erstellung von Webanwendungen oder anderweitigen Geschäftsanwendungen geht. Informatikkenntnisse sind auf Seite des Auftraggebers nicht erforderlich - der Auftraggeber bzw. Kunde handelt aus seiner fachlichen Perspektive heraus. Die Wahl dieses Prozessmodells setzt das Einverständnis des Auftraggebers voraus. 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 einzusetzen, um ein breites Verständnis für die zu entwickelnde Anwendung zu bekommen. Mögliche Techniken sind zum Beispiel Anwendungsfälle (Use Cases), offene Interviews oder Szenariotechniken. Die daraus resultierenden Erkenntnisse sind elektronisch zu erfassen und als Anhang zu den User Stories mit abzugeben. Im Rahmen des (bzw. der) ersten Treffen(s) sind die wesentlichen Anforderungen an die zu entwickelnde Software in Form von User Stories zu erfassen. Darauf aufbauend wird eine grobe Releaseplanung durchgeführt (zwei bis drei Releases). Ein Release ist dadurch gekennzeichnet, dass es einen aus fachlicher Sicht sinnvollen Funktionsumfang umfasst. Während des Projekts Am Beginn jeder Iteration treffen sich der Auftraggeber und das Team und besprechen, welche User Stories im Rahmen der nächsten Iteration umzusetzen sind (Planning Meeting). 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. Es wird ggf. auch diskutiert, ob und wenn ja welche neuen Anforderungen aufgetaucht sind. Am Ende jeder Iteration stellt das Team eine funktionierende Software dem Auftraggeber vor. Auf Wunsch des Auftraggebers wird diese auch zu Verfügung gestellt, damit der 2
Auftraggeber diese testen kann, um ggf. die weitere Entwicklungsrichtung zu bestimmen. Weiterhin kann es ggf. auch während der Entwicklung notwendig sein zur Ermittlung bzw. Verfeinerung der Anforderungen andere Techniken zur Anforderungsermittlung einzusetzen. Aufgaben der Praktikumsteilnehmer Die Hauptaufgabe der Praktikumsteilnehmer ist die iterative und inkrementelle Entwicklung der Software. Während der Entwicklung muss das Team lückenlos dokumentieren, wer wann welche User Story umgesetzt hat, welcher Aufwand vorher geschätzt wurde (zum Beispiel mit Story Points 1 ), und welcher Aufwand (in Std.) aufgetreten war. Darüber hinaus sind alle Teammitglieder verpflichtet, die für das Projekt verbrauchte Realzeit, lückenlos zu erfassen. Dies umfasst neben der eigentlichen Zeit für die Entwicklung insbesondere auch Aufwände für die Einarbeitung und für Meetings. Im Allgemeinen gilt, dass alle Aufwände, die auch bei einem realen Projekt anfallen, zu erfassen sind. 2 Sollten während der Entwicklung unvorhergesehene Probleme und Fragen auftreten, die die Erreichung des Projektzieles gefährden, so sind diese im Projekttagebuch kurz und präzise zu dokumentieren. Es ist ein Glossar aufzubauen und zu pflegen, das alle wesentlichen fachlichen Begriffe definiert. Die Systematik mit der getestet wird, welche Programmierstandards einzuhalten sind, sowie welche weiteren Qualitätssicherungsmaßnahmen ergriffen wurden, ist in einem kurzen Qualitätssicherungsdokument festzuhalten. Um die Qualität der Software zu sichern, ist eine umfassende Testsuite zu erstellen 3. Die Testsuite muss alle wesentlichen Teile testen und die Gruppe muss die Systematik, nach der die Tests entwickelt wurden, angeben. Sollte umfassendes, automatisches Testen nicht möglich sein (Aufwand ist im Rahmen des BP nicht vertretbar (z.b. GUI Tests)), dann ist dies (a) ausführlich zu begründen und (b) ein Dokument hinzuzufügen, aus dem hervorgeht, wie, z.b., die GUI systematisch manuell getestet wird. Für alle anderen Teile muss eine Testsuite vorliegen, die die (von der Gruppe im QS Dokument 1 D.h. die Komplexität einer User Story im Vergleich zu den anderen User Stories ist zu bestimmen. Als Grundlage dient für gewöhnlich eine mehrstufige Ordinalskala. 2 Die Zeiten, die für den Besuch der Vorlesung zum Bachelor-Praktikum, sowie für die HDA Schulung und die Vorbereitung des entsprechenden Vortrags, der im Rahmen der Projektbegleitenden Vorlesung stattfinden wird, sind nicht zu erfassen. 3 Im Rahmen agiler Softwareentwicklungsprojekte wird häufig auf das Schreiben umfangreicher Dokumente verzichtet. Dem Testen kommt jedoch eine besondere Bedeutung zu und es ist die Aufgabe der Gruppe, eine Testsuite zu entwickeln, die alle wesentlichen Teile testet. 3
dargelegten) Qualitätsziele sicherstellt. Es ist darauf zu achten, dass im QS Dokument nur Dinge beschrieben werden, die auch real durchgeführt werden! Insbesondere ist darauf zu achten, dass die gesetzten Qualitätssicherungsziele mit den beschriebenen Maßnahmen auch erreicht werden können. Der Anhang, der dokumentiert, was wie getestet wurde, ist am Projektende nachzureichen. Optional können folgende Techniken eingesetzt werden: Gemeinsame Verantwortung für den Code (Collective Code Ownership) Programmierung in Paaren (Pair Programming) Weiterhin ist es Aufgabe der Gruppe stets darauf zu achten, dass das Design der Software so einfach wie möglich ist (Simple Design) in Hinblick auf die Anforderungen, die im Rahmen des aktuellen Releases umzusetzen sind. Das Design ist stetig zu verbessern (Refactoring). Am Ende jeder Iteration muss eine lauffähige Version der Software abgegeben werden und es muss eine kurze Retrospektive geben. Aufgaben der Teamleiter Die Hauptaufgabe ist die Überwachung des Projekts und Dokumentation des Projektfortschritts. Wesentliche Aspekte der Aufgabe des Teamleiters sind die Ermittlung der Geschwindigkeit (Velocity) des Teams und die Sicherstellung der Einhaltung der Iterationszyklen (zwei bis max. drei Wochen auch dann, wenn wenig Zeit aufgrund anderweitiger Prüfungen ist). Es ist hierbei immer darauf zu achten, dass die Gruppe davon überzeugt ist, dass die (gemeinsam mit dem Auftraggeber) ausgewählten Stories innerhalb der nächsten Iteration umgesetzt werden können. Es ist insbesondere darauf zu achten, dass die Dokumentation des Fortschritts erfolgt, d.h. in welcher Iteration wurden welche User Story umgesetzt bzw. versucht umzusetzen und welche Aufwände sind entstanden. Die Dokumentation, Überwachung und Anpassung des Release Plans, in Zusammenarbeit mit der Gruppe und dem Auftraggeber, ist Aufgabe des Teamleiters. Dies umfasst insbesondere auch die Kontrolle des Projekttagebuchs, welches zentrale Entscheidungen und Fragestellungen in Hinblick auf das Projekt enthält. Weiterhin ist der Teamleiter für die Sicherung der Qualität des Qualitätssicherungsdokuments zuständig. Die Moderation der Retrospektiven und das Einführen der Auftraggeber in den Prozess ist ggf. auch Aufgabe des Teamleiters. Die Teamleitersitzungen mit der Projektbegleitung sind durch die Teamleiter zu protokollieren (mit rollierender Verantwortung). 4
Anforderungen an die Auftraggeber Der Auftraggeber muss sich direkt am Anfang des Projektes hinreichend Zeit nehmen (ggf. mehrere Stunden), um die wesentlichen Anforderungen an das Projekt mit der Gruppe zu diskutieren und auch grob zu priorisieren. Es ist zu diesem Zeitpunkt weder erforderlich noch sinnvoll, zu versuchen, alle Anforderungen zu diskutieren oder zu ermitteln. Die Anforderungen sind jedoch soweit zu diskutieren, dass das Team eine sehr gute Vorstellung von dem Projekt bekommt. Die Anforderungen können jederzeit 4 während des Projekts geändert, ergänzt oder gestrichen werden. Damit dieser Prozess im Rahmen eines Projektes angewandt werden kann, ist es erforderlich, dass der Auftraggeber sich über die gesamte Projektdauer zu regelmäßigen Treffen (ideal alle zwei Wochen, maximal alle drei Wochen) verpflichtet. Es ist die Aufgabe des Auftraggebers, bei der Auswahl der Anforderungen (der umzusetzenden User Stories) für die nächste Iteration(en) mitzuwirken. Die Auswahl erfolgt unter fachlichen Gesichtspunkten. Es obliegt dem Auftraggeber sich regelmäßig mit der Software auseinanderzusetzen, um sicherzustellen, dass die Anwendung den Wünschen entspricht. D.h. vor dem Beginn einer jeden Iteration kann der Auftraggeber ggf. bestehende User Stories anpassen, löschen oder neue hinzufügen. Der Auftraggeber darf nicht mehr User Stories auswählen, als Zeit zum Umsetzen innerhalb der nächsten Iteration vorhanden ist. Er muss in der Lage sein regelmäßig qualitatives Feedback zu der Software zu geben. Die Information, wie viel Aufwand das Umsetzen einer Story verursacht und wie viel Zeit innerhalb der nächsten Iteration zur Verfügung steht, erhält der Auftraggeber vom Team. 5 Ist der eigentliche Auftraggeber am Ende einer Iteration verhindert und kann deswegen am Planning Meeting nicht teilnehmen, dann liegt es in der Verantwortung des Auftraggebers, einen qualifizierten Stellvertreter zu benennen. Wenn erforderlich, kann die Dauer einer Iteration auf eine, zwei oder drei Wochen geändert werden. 4 D.h. zum Zeitpunkt der Planung der nächsten Iteration. 5 Bei Meinungsverschiedenheiten in Hinblick auf die Leistungsfähigkeit und / oder das Potenzial der Gruppe, sollte der Auftraggeber dies in einem persönlichen Gespräch ausschließlich mit dem Teamleiter erörtern. Bei unüberbrückbaren Differenzen ist die Projektorganisation einzuschalten. 5
Glossar Iteration Planning Meeting Retrospektive Story-Card Task-Card User Story Relative Zeit fixer, kurzer Zeitraum (eine bis max. 3 Wochen), in der von der Gruppe ausgewählte User Stories implementiert werden. Treffen zwischen dem Team und dem Auftraggeber, in dem die umzusetzenden Anforderungen der nächsten Iteration besprochen werden. Kurzes Meeting des Teams am Ende einer Iteration (eines Releases), um zu besprechen, was gut lief und was verbesserungsfähig ist. Die Retrospektive findet ggf. mit Teamleiter, aber immer ohne Auftraggeber statt. Der wesentliche Inhalt einer Story-Card ist die User Story. Darüber hinaus ist die geschätzte relative Komplexität (zum Beispiel auf einer fiktiven Skala von eins bis max. fünf) vermerkt. Weiterhin kann die Story-Card folgende Elemente aufweisen: einen Titel, einen Autor (im Idealfall der Kunde/Auftraggeber, meist jedoch ein Mitglied des Teams in Zusammenarbeit mit dem Kunden), das Datum der Erstellung, den tatsächlichen (relativer) Aufwand, das Datum der Erledigung sowie den/die zuständigen Entwickler. Story-Card, die (von dem Team und unabhängig vom Kunden / Auftraggeber) in einzelne Tasks herunter gebrochen wurde, damit einzelne Entwickler diese dann innerhalb einer Iteration umsetzen können. Diese Karten sind elektronisch zu verwalten und dienen der Kontrolle des Projektfortschritts. Ein kurzer Text, der eine wesentliche (fachliche) Anforderung aus Sicht des Kunden erfasst. Diese Anforderung muss testbar sein und muss sich innerhalb einer Iteration umsetzen lassen. Ggf. ist die User Story aufzubrechen in kleinere Teile. Wenn möglich sollte pro User Story ein Akzeptanztest definiert sein. Angabe der (erwarteten) Komplexität einer User Story im Vergleich zu der Komplexität anderer User Stories. (Eine präzisere Angabe (zum Beispiel in Stunden bzw. Tagen) ist in der Regel nicht möglich und führt darüber hinaus potentiell zu unnötigen Diskussionen.) 6
Relevante Literatur K. Beck; extreme Programming explained - embrace change; Addison Wesley, 2000 K. Beck und M. Fowler; Planning Extreme Programming; Addison Wesley, 2001 H. Wolf, S. Rook und M. Lippert; extreme Programming, 2. Auflage; dpunkt.verlag, 2005 7
Information für die Bachelor-Praktikumsgruppen und Teamleiter Noten Die Endnote für die Bachelor-Praktikumsgruppe ergibt sich aus der Bewertung durch den Auftraggeber und aus der Bewertung durch die Projektorganisation. Letztere stützt sich insbesondere auf die erstellten und abgegebenen Dokumente (basierend auf den Besonderheiten der Projekte). Dies ist insbesondere das Qualitätssicherungsdokument inkl. Anhang, der belegt, dass die Qualitätssicherung wie beschrieben durchgeführt wurde. Darüber hinaus werden das Projekttagebuch und die vollständige Dokumentation der User Stories herangezogen. Weiterhin geht der Vortrag, der im Rahmen der Vorlesung zu halten ist, in die Endnote ein. 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. Die Benotung der Teamleiter ergibt sich aus dem Erfolg in der Leitung der Teams. Dies spiegelt sich unter anderem im Projekterfolg (gemäß Auftraggeber) und in der Qualität der abgegebenen Dokumente wieder. Sollte die Gruppe nicht in der Lage sein die Qualitätsanforderungen an die Dokumente umzusetzen, es gruppeninterne Probleme geben oder gar der Projekterfolg als solches auch nur möglicherweise in Gefahr sein, so ist der Teamleiter in direkter Verantwortung diese Probleme der Projektbegleitung unmittelbar mitzuteilen. 6 Es sind somit folgende Dokumente abzugeben: Projekttagebuch Qualitätssicherungsdokument Anhang zum Qualitätssicherungsdokument User Stories ggf. Anhang zu den User Stories Das Format muss in allen Fällen PDF sein. Darüber hinaus sind keine weiteren Dokumente abzugeben. 6 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. 8
User Stories Die wesentlichen Bestandteile einer User Story sind: 1. Die User Story als solche, die eine Anforderung des Auftraggebers beschreibt. User Stories werden später wenn die Story implementiert werden soll ggf. in Tasks (Aufgaben) weiter untergliedert. Die Aufteilung der User Story in Tasks liegt in der Verantwortung der Gruppe; der Teamleiter ist maximal moderierend tätig. Ein Format, das öfters für User Stories verwendet wird, ist: Als <Benutzerrolle> will ich <das Ziel>[, so dass <Grund für das Ziel>]. 2. Priorität der User Story und ob die User Story gerade in Bearbeitung ist 3. Ein Akzeptanzkriterium, dass es erlaubt zu beurteilen, ob die User Story vollständig und korrekt umgesetzt wurde. 4. Geschätzter Aufwand - Basis ist die erwartete Komplexität im Vergleich zu anderen User Stories; insbesondere im Vergleich zu bereits implementierten User Stories. 5. Tatsächlicher Aufwand in Zeitstunden, letzteres ist notwendig für die Berechnung der Geschwindigkeit. Abweichungen zwischen dem geschätzten Aufwand und dem tatsächlichen Aufwand sind zu erwarten in der Anfangsphase mehr als in der Endphase. Die Abweichungen sollten über den Verlauf des Projektes hinweg geringer werden. 6. Wer (Entwickler) hat die Verantwortlichkeit für die User Story wann übernommen und wann wurde die User Story abgeschlossen. Weiterhin kann die Rolle der Benutzer erfasst werden, für die die entsprechende User Story von besonderer Bedeutung ist. Im Allgemeinen bedarf die Erfassung von User Stories keiner besonderen Werkzeuge und die Verwendung von zum Beispiel Google Docs ist ausreichend. Es gibt jedoch im Internet auch (freie) Werkzeuge, die verwendet werden können (zum Beispiel: Redmine (http://www.redmine.org/) oder AgileZen (http://agilezen.com/)). 9
Beispiel einer User Story: ID Name Beschreibung Akzeptanzkriterium Geschätzter Aufwand (Story Points) Tatsächlicher Aufwand (h) Velocity (h/story Points) Umgesetzt in Iteration Entwickler Bemerkungen 2 Login Als Administrator muss ich mich am System mittels Benutzername und Passwort authentifizieren können, um Änderungen vornehmen zu können. Der Dialog zum Einloggen wird korrekt angezeigt und es ist möglich sich zu authentifizieren. 3 12 4 2 Max Mustermann / 10
Qualitätssicherungsdokument Überblick Das Ziel des Qualitätssicherungsdokuments ist es zu beschreiben, wie die Qualität des Produktes im Rahmen des gewählten Projektes gesichert wird. 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 Ziele und Maßnahmen im Kontext des konkreten Projektes erreichbar und durchführbar sind. Mögliche Maßnahmen, 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 Analyse. 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. Allgemeine Hinweise Es handelt sich um ein formloses Dokument im TU Darmstadt Design mit max. 10 Seiten (ohne Anhang). Auf dem Deckblatt sind zu vermerken: Das Projektthema/der Titel des Projekts Die vollständigen Namen der Teammitglieder Kontakt (EMail) Der vollständige Name des Teamleiters Name der Auftraggeber(in)/des Auftraggebers (inkl. Fachgebiet/Fachbereich) Gruppennummer Bitte beachten Sie, dass sofern der Auftraggeber nichts anderes wünscht das Qualitätssicherungsdokument unter keinen 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. 11
Qualitätsziele, die für das Projekt nicht relevant sind und Maßnahmen, die Sie nicht durchführen, gehören nicht in das Dokument. Sollte eine Erreichung der durch den Auftraggeber vorgegebenen Qualitätsziele im Rahmen des Projekts nicht möglich sein, so ist dies kurz zu begründen und anzugeben, wie versucht wurde möglichst nahe an die gewünschten Qualitätsziele heran zu kommen. Vermeiden Sie jede Form von nebulösen Aussagen. Machen Sie ggf. folgenden Test: Geben Sie das Dokument einem Kommilitonen, der mit dem Projekt nicht vertraut ist, und stellen Sie ihm nachdem er selbiges gelesen hat folgende Fragen: Welches sind die zentralen Qualitätsziele des Projekts? Warum sind dies die zentralen Ziele? Welche Maßnahmen werden durchgeführt? 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 reagiert? Ist die Häufigkeit, mit der die Maßnahmen durchgeführt wird angemessen? Beispiel Im Rahmen des Projekts wird eine Webanwendung entwickelt, auf die über das Internet zugegriffen wird. Da diese Anwendung relevante Daten verarbeitet und potentiellen Angriffen ausgesetzt ist, ist ein wesentliches Qualitätsziel, dass die Anwendung keine Sicherheitslücken aufweist. Im Rahmen dieses Projektes können wir jedoch nur gewährleisten, dass die Webanwendung keine Standardlücken (SQL Injection, Cross-site scripting (XSS)) 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 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. Gegenbeispiele Kein unmittelbarer Bezug zu Qualität: Inversion des Kontrollflusses: Durch den Einsatz des Frameworks wird erreicht, dass sich der Entwickler nicht mehr um den Kon- 12
trollfluss der Web-Anwendung kümmern muss. Das erledigt das Framework für ihn. Nicht projektspezifisch: Qualitätssicherung (QS) beschäftigt sich mit der Frage, wie man für ein zu entwickelndes Produkt garantieren kann, dass daran gestellte Anforderungen auch wirklich erfüllt werden und dass es nach der Entwicklung die gewünschten Qualitätsmerkmale hat.[ ] Bedeutung von Skype als QS-Werkzeug ist fraglich: 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. Formlos ist nicht gleich zu setzen mit umgangssprachlich : Hier beißt sich also die Katze in gewissem Sinne in den eigenen Schwanz. sollte so oder so ähnlich nicht im QS Dokument stehen. 13
Versionshistorie Datum Bearbeiter Kommentare 11.09.2010 30.09.2010 08.10.2010 25.11.2010 11.03.2011 18.04.2011 17.05.2011 01.08.2011 17.4.2012 erste Version Einarbeitung der Kommentare von Felix Kerger und Guido Rößling Einarbeitung von Kommentaren von Wolfgang Heenes Ergänzungen im Bereich User Stories, basierend auf Anregungen von Enno Deutschmann und Andreas Kaluza Der Abschnitt über das QS Dokument wurde präzisiert. Abschnitt über die Benotung hinzugefügt. allgemeine Überarbeitung - insbesondere im Hinblick auf die Ausgestaltung des QS Dokuments Hinweis bzgl. Gestaltung des Deckblatts des QS Dokuments hinzugefügt Einarbeitung der Erkenntnisse des WS11/12 14