Dieser Beitrag beschreibt die Erfahrungen von Lehrenden, welche bei einem Einsatz eines projektbasierten Lehr- Lernarrangements im Bereich des Requirements Engineering mit Studierenden gesammelt werden konnten. Thematisiert werden, neben den Schwerpunkten des Projekts, die Ziele und Rahmenbedingungen der Umsetzung, sowie die eigentliche Durchfu¨hrung. Es folgt eine abschließende Zusammenfassung des Projekts, in der die gewonnenen Erkenntnisse aus Sicht der Studierenden und Lehrenden dargestellt werden.
Es besteht aus insgesamt 18 Regeln, welche allesamt das Ziel haben, auf ”definierte, systematische Art und Weise mehrdeutige, unvollsta¨ndige und widerspru¨chliche Aussagen in Anforderungsdokumenten zu finden“ [RS09, 125]. Das SOPHIST REgelwerk retrospektiv auf bereits erstellte Anforderungen anzuwenden, gestaltet sich in der Regel als a¨ußerst aufwa¨ndig [RS09, 160]. Deshalb schla¨gt Rupp weiterhin eine Qualita¨tssicherung durch sogenannte Anforderungsschablonen vor. Dabei handelt es sich um ”einen Bauplan, der die Struktur eines einzelnen Anforderungssatzes festlegt“ [RS09, 161]. Eine derartige Schablone dient als Unterstu¨tzung fu¨r Analysten, verschiedene Arten von Systemaktivita¨ten strukturiert zu erfassen und damit die Qualita¨t von Anforderungen zu steigern. Sowohl das SOPHIST REgelwerk als auch die Anforderungsschablonen sollen in einem Softwareprojekt umgesetzt werden. 3
3.1
Das Softwareprojekt ist im 6. Semester des Bachelorstudiengangs Informatik an der Hochschule Kempten angesiedelt. Studierende bearbeiten in Kleingruppen (in diesem Fall: 5 Personen) ein Semester lang selbst-koordiniert ein Thema, welches unter praxisnahen und mo¨glichst realen Bedingungen (beispielsweise definierte Rollen mit einschla¨gigen Methoden des Projektmanagements) vollzogen wird. In diesem Fall sollten die Studierenden eine Software fu¨r Requirements Engineering und Management entwickeln. Sie soll in der Lage sein, die Regeln des SOPHIST REgelwerks auf bestehende Anforderungen automatisiert anzuwenden und sie anhand von diesen zu bewerten. Ebenso sollen Benutzer der Software bei der Eingabe von neuen Anforderungen mittels Anforderungsschablonen unterstu¨tzt werden. 3.2
Seitens der Lehrenden werden bei diesem lernenden-zentrierten Ansatz die folgenden Ziele verfolgt: Studierende sollen lernen...
... Probleme in Teilprobleme zu strukturieren und damit beherrschbar zu machen. ... Entscheidungen zu treffen, daraus Ziele abzuleiten und Verantwortung fu¨r die Ergebnisse zu u¨bernehmen. ... mit der begrenzten Zeit umzugehen und das Spannungsfeld zwischen Zeit und Qualita¨t zu bewerten. ... bekannte Werkzeuge und Techniken aus dem Software Engineering und Projektmanagement anzuwenden und zu kombinieren. ... kollaborativ, kooperativ zu arbeiten, miteinander zu kommunizieren und durch gegenseitige Anregungen voneinander zu profitieren.
... (Zwischen-) Ergebnisse vor Kunden zu pra¨sentieren.
Ob und inwieweit die Studierenden diese Ziele erreichen, ist unter anderem abha¨ngig von ihrer motivationalen Ausrichtung. Unsere bisherigen Erfahrungen haben gezeigt, dass sich die Motivation von Studierenden durch Maßnahmen steigern la¨sst, welche sich auf den projektbasierten Ansatz anwenden lassen [FHB13]. Abbildung 1 zeigt vier Felder der Motivation von Studierenden, welche im Lehrkontext positiv beeinflusst werden ko¨nnen [FHB13].
Abbildung 1: Vier Felder der Motivation (nach [FHB13]) Da sich die Studierenden auf eigenen Wunsch hin fu¨r ein Projekt anmelden, kann davon ausgegangen werden, dass ein gewisses Maß an Grundinteresse fu¨r das zu bearbeitende Thema vorhanden ist. Die Unabha¨ngigkeit von Studierenden ist dadurch gegeben, dass diese frei entscheiden du¨rfen, wie das Projektziel erreicht werden soll. Beispielsweise werden Kommunikationsprozesse oder Entscheidungen fu¨r oder gegen eine Entwicklungssoftware oder ein Vorgehensmodell vollsta¨ndig in die Ha¨nde der Studierenden gelegt. Als Bedingung wird jedoch formuliert, dass jede getroffene Entscheidung begru¨ndet werden muss. Lehrende haben lediglich eine beratende Funktion. Es wird nur bei fachlichen Fehlern durch Lehrende eingeschritten. Die Schwierigkeit des Projekts la¨sst sich anpassen und es wird sich in zwei Stufen dem Projektziel gena¨hert: In der ersten Stufe soll die Eingabeassistenz in Form von Anforderungsschablonen im System umgesetzt werden. Anschließend soll eine Umsetzung des SOPHIST REgelwerks erfolgen, was den Schwierigkeitsgrad entsprechend steigert. Anreize werden auf verschiedene Art und Weise geschaffen. Da den betreuenden Lehrenden zu Beginn des Projekts kein derartiges Produkt bekannt ist, ko¨nnte das Projektergebnis auch außerhalb der Hochschule Kempten auf Interesse stoßen. Somit besitzt dieses Projekt eine gewisse Ernsthaftigkeit und Relevanz, was – sofern die Studierenden sich mit dem Projekt identifizieren – einer der maßgebenden Faktoren fu¨r eine erfolgreiche Umsetzung darstellt. Zudem handelt es sich um eine Studienleistung, welche mit 15 ECTS bewertet wird und damit einer Einzelleistung von umgerechnet 450 Personenstunden entspricht. 3.3
Wa¨hrend der Durchfu¨hrung des Projekts finden regelma¨ßige Lenkungsausschu¨sse mit den betreuenden Lehrpersonen statt, welche gleichzeitig als Kunden bzw. Auftraggeber auftreten. Ebenso gibt es projektinterne Treffen, an denen nur die Studierenden teilnehmen. Diese Art des Vorgehens ist orientiert an agilen Vorgehensmodellen wie Scrum. welche unterschiedliche Prozessaktivita¨ten (z.B. Daily-Scrums) mit unterschiedlichen Projektrollen vorsehen [SS11]. Dadurch ko¨nnen sowohl die fachliche Richtigkeit durch Lenkungsausschu¨sse als auch realita¨tsnahe Projektbedingungen geschaffen werden, indem beispielsweise gezielte Anforderungsa¨nderungen in einer fortgeschrittenen Phase des Projekts eingestreut werden. Bisherige Erfahrungen haben gezeigt, dass seitens des Kunden gea¨nderte Anforderungen einen großen Effekt auf das Versta¨ndnis der Studierenden in Bezug auf Vorgehensmodelle und erstellte Artefakte haben. In diesem Fall wurden konkret zwei A¨ nderungen festgelegt: 1. Die Studierenden waren dazu angehalten kurz nach Abschluss der Anforderungsanalyse eine Schnittstelle zu schaffen, welche fu¨r spa¨tere Weiterentwicklungen relevant ist. Hierbei war es unabdingbar bisher erstellte Artefakte entsprechend anzupassen, sodass die neu hinzugekommene Schnittstelle umgesetzt werden konnte. Neben den Abha¨ngigkeiten der Artefakte untereinander, konnten zudem wichtige Designprinzipien von Software-Architekturen verdeutlicht und angewendet werden. 2. Ebenso wurde nach Abschluss der Implementierung der Wunsch seitens des Kunden gea¨ußert, die schriftliche Dokumentation des Systems in einem anderen Format als urspru¨nglich vorgesehen auszuha¨ndigen. Dabei ging es nicht darum die Studierenden zu bescha¨ftigen, sondern vielmehr die Dynamik hin zum Kunden bzw. Auftraggeber aufzuzeigen und ein gewisses Maß an Flexibilita¨t einzufordern. Wa¨hrend der Durchfu¨hrung entwickelte das Projekt immer mehr Dynamik, da die Studierenden Gefallen daran gefunden haben. So wurden freiwillig weitere Zwischenergebnisse erstellt, wie beispielsweise ein entsprechender Webauftritt u¨ber welchen die Software benutzt werden kann. 3.4
Das Projekt konnte erfolgreich abgeschlossen werden. Das eingangs formulierte Thema wurde vollsta¨ndig bearbeitet. Lediglich wenige Einzelheiten wurden bewusst ausgelassen, da sich diese nicht programmiertechnisch abbilden ließen. Dafu¨r wurde die Software um weitere Funktionalita¨ten erga¨nzt. Diese wenigen inhaltlichen Anpassungen sprechen fu¨r die eingesetzte Methode, da dies die Wichtigkeit von Flexibilita¨t und Anpassungsfa¨higkeit betont, was auch in der Praxis relevant ist. Abbildung 2 zeigt beispielhaft einen Screenshot der Software. Dargestellt ist der Anforderungsschablonenmodus, in dem ein Benutzer Anforderungen mit Hilfe der genannten Schablonen erfassen kann (1), welche anschließend nach dem SOPHIST REgelwerk bewertet werden (2).
Abbildung 2: Screenshot - Schablonenmodus Die Abbildung 3 zeigt beispielhaft den Freitextmodus der Software. Hier ko¨nnen beliebige Anforderungen eingegeben werden (3) und nach ausgewa¨hlten Regeln des SOPHIST REgelwerks bewertet werden (4). Das Ergebnis der Bewertung wird dem Benutzer angezeigt (5). 4
Die Nachbesprechung dieses Lehr- Lernarrangements fand in Form eines Lessons Learned Meetings statt, an welchem die betreuenden Lehrenden und die Studierenden teilnahmen. Diese qualitative Herangehensweise schien aufgrund der geringen Grundgesamtheit (von N=5 Personen) angebracht. Hierbei konnten folgende subjektiven Einscha¨tzungen seitens der Studierenden festgehalten werden:
Das Versta¨ndnis des SOPHIST REgelwerks und damit fu¨r qualita¨tsgesicherte Anforderungen wurde erheblich gesteigert. Der praktische Einsatz wurde zuna¨chst selbststa¨ndig explizit von den Studierenden erlernt und wa¨hrend des Projekts implizit angewendet.
Abbildung 3: Screenshot - Bewertung von Anforderungen Weiterhin konnte ein iterativ-inkrementeller Prozess der stetigen Verbesserung angestoßen werden. Es war zu beobachten, dass Anforderungen an die Software, die zu Beginn des Projekts formuliert wurden, zunehmend qualitativ hochwertiger wurden. Dies weist darauf hin, dass das erworbene Wissen auf die erstellten Artefakte angewendet wurde, was nach Baddeley eine nachhaltigere Verinnerlichung von Wissensinhalten begu¨nstigt [Bad86, 183].
Die realita¨tsnahen Bedingungen mit einer festlegten Rollenverteilung, eingebettet in ein Vorgehensmodell, umgesetzt in einer Kombination aus Werkzeugen, sowie der geringe Grad an Steuerung durch die Lehrenden, wurden zudem als besonders positiv hervorgehoben. Auch die Wichtigkeit einer intakten Kommunikation zwischen den Teammitgliedern und mit den Lehrenden (in diesem Fall: Kunden), wurde durch die Studierenden erkannt und positiv bewertet.
Ebenso wurde von den Studierenden berichtet, dass als Nebeneffekt das Versta¨ndnis fu¨r die deutsche Grammatik verbessert wurde. Dies lag zum Großteil an der Entwicklung von Algorithmen fu¨r die Anwendung des SOPHIST REgelwerks auf einen deutschen Satz.
Abschließend kann festgehalten werden, dass die gesammelten Erfahrungen und die abschließende Evaluation des Projekts durchweg positiv ausfiel. Die Studierenden besta¨rken uns durch ihre A¨ußerungen dieses Lehr-Lernarrangement auch fu¨r zuku¨nftige Gruppen einzusetzen. Dabei soll auch fu¨r Folgesemester der Fokus auf der thematischen Ru¨ckkopplung wa¨hrend eines mo¨glichst realita¨tsnah durchgefu¨hrten Projekts liegen. Dies ko¨nnte zum Beispiel der Fall sein, wenn eine zuku¨nftige Projektgruppe an das Projektergebnis anknu¨pft, in dem sie die vorhandene Syntax durch die SOPHIST Schablonen nutzt, um daraus automatisiert, von einer schriftlichen zu einer grafischen Dokumentation in Form von Use Cases zu gelangen. Auch wa¨re es denkbar erweiterte und umfangreichere (Qualita¨ts-)Metriken zu entwickeln und diese zur automatisierten Bewertung von Anforderungen heran zu ziehen. Solche Metriken ko¨nnen beispielsweise logische bzw. kausale Abha¨ngigkeiten der Regeln des SOPHIST REgelwerks aufzeigen und entsprechend gewichten.
[Jac95] [RS09] [SS11]
Michael Jackson. Software requirements and specifications - a lexicon of practice, principles and prejudices. Addison-Wesley, University of Michigan, 1995.
Chris Rupp und die SOPHISTen. Requirements Engineering und Management. Hanser, Mu¨nchen, 2009.
Ken Schwaber und Jeff Sutherland. The Scrum Guide. scrum.org, 2011. URL: https://www.scrum.org/Portals/0/Documents/Scrum/Guides/ScrumGuide.pdf, letzter Zugriff: 03.01.2014.
Dieses Vorhaben wird aus Mitteln des Bundesministeriums fu¨r Bildung und Forschung unter dem Fo¨rderkennzeichen 01PL12022C gefo¨rdert.