Home

Volltext - SE 2013

1. Vorbereitung des Materials zum Selbststudium Vorbereitung der Aufgdben zum Vor und Nachbereiten E Ver ffentlichung der Auf Studieren des Materials 3 ber Moodle Diskussion der Inhalte z b u u 2 Auswerten der abgelidfeykan a Ergebnisse kurz vor dd d1 704 Bearbeitung der Aufgabl v Lehrveranstaltung Vorbereitung der Lehrveranstaltung mit neuen Aufgaben mit Hilfe der Auswertung Vertiefung und Erkl rung des a Stoffes aufgrund der Ayswertung 3 u c N a Sellen mater Amgad m Diskussion peer instruc 5 Response System 5 v Vertiefung und Erkl rung 6 Stoffes aufgrund der Aus i FEEDBACK BearbeltungideniAufeah z Erna qi MOLT g 8 Diskussion peer instruc das Praxisprojekt o a 0 x Auswertung der erarbeif Bearbeitung der Aufgallen r Ergebnisse FEEDBACK Gruppe 4 Abb 3 JiTT mit dreifachem Feedback Umdenken in der Vorbereitung Fiir uns als Lehrende bedeutete diese Methode ein radikales Umdenken in der Vorbereitung der Lehr veranstaltungen Hesse 2000 Wahrend man frither seine Folien oder andere Materialien schon fr h zeitig fertigstellen konnte und in der direkten Vor bereitung kurz vor der Lehrveranstaltung noch mals dar ber schauen musste was in sehr kurzer Zeit erledigt ist fordert diese Art der Veranstaltung 22 mehr Flexibilit t und einen hohen Aufwand in der Vorbereitung je
2. 2 S mtliche Angaben in Prozent die fehlenden Prozent auf 100 gaben an Weiss nicht 3 Die Umfrage wurde auf Englisch durchgef hrt um alle Sprachregionen der Schweiz abdecken zu k nnen daher sind sowohl die Fragen als auch die Antwort Optionen auf Englisch 80 ATDD auch bei agilen Unternehmen noch relativ wenig im Einsatz sind wie sich bei der Umfrage gezeigt hat Bei den Management Practices wurden als wichtigste Aspekte Iterationsplanung 89 User Stories 83 und Release Planung 77 genannt dicht gefolgt vom Einsatz eines Task Boards 74 Aspect Release planning 3 18 37 40 Story mapping 4 26 41 21 On site customer 11 27 33 24 Iteration planning 0 7 36 53 User stories 0 10 40 43 Daily standup 4 25 32 33 Taskboard 2 20 45 29 Burndown charts 11 38 22 24 Retrospective 5 28 34 30 Open work area 12 25 40 11 Kanban Pull System Limited WIP 27 23 13 4 Tabelle 3 How important were the following agile management and planning practices for your successful agile projects Ein wichtiger Aspekt ist dass die Zufriedenheit der Unternehmen mit den agilen Methoden insgesamt A Spillner H Lichter Hrsg SEUH 13 deutlich h her ist als mit traditionellen plan getriebenen Vorgehen 84 vs 62 Anforderungen an agile Ausbildung Im Rahmen der Studie haben wir auch erhoben ob agile Methoden berhaupt auf universit
3. Code Anzahl Anteil Doku Codings an allen ku in mente Problembewusstsein 36 11 43 Verstehen komplexer 30 9 52 Prozesse Zusammenarbeit 28 8 89 T Kommunikation mit 18 5 71 5 anderen auch inter disziplin r Lernbereitschaft Ge 18 5 71 5 genteil Selbst ber sch tzung Probleml sungsf hig 16 5 08 4 keit Kreativit t Selbst etwas erarbei 16 5 08 6 ten k nnen Empathie 15 4 76 Offenheit f r Neues 14 4 44 Einf gen in Organisa 13 4 13 tionsstrukturen Praktische Anwen 12 3 81 3 dung Abstraktions 10 3 17 4 verm gen Tabelle 2 bersicht ber die 12 h ufigsten Codings f r berfachliche Kompetenzen 125 Unternehmen erwarten also fachlich gut ausgebil dete Absolventen die in der Lage sind komplexe Prozesse in Unternehmen zu verstehen Mitarbeiter im Bereich Software Engineering sollen ihre eigene Fachlichkeit realistisch einsch tzen Sie sollen zwar in der Lage sein sich mit ihrem Wissen im Unter nehmen zu verorten jedoch auch die Bereitschaft mitbringen sich in Aufbau bzw Ablauforganisati onen einzuf gen Gleichzeitig wird eine gewisse Aktivit t und Selbst ndigkeit vorausgesetzt Man erwartet keine genauen Vorgaben machen zu m s sen wie und wann etwas zu tun ist Vielmehr soll ein Software Ingenieur sich innerhalb eines Korri dors aktiv und eigenverantwortlich bewegen und seine Kompetenzen selbst ndig einbringen und auch weiterentwickeln Ebenso notwendig ist die Ber
4. teilweise enthalten Projektziele Tabelle 1 Vergleich von DGBL Anwendungen A Spillner H Lichter Hrsg SEUH 13 Die typische Aufgabe f r einen Spieler besteht in diesen Lernspielen i d R darin als Projektmanager simulierte Softwareentwickler erfolgreich durch ein simuliertes Softwareprojekt zu dirigieren Dazu werden Personen in das Projektteam aufgenommen oder aus diesem entfernt Den simulierten Figuren im Team werden dann verschiedene Aufgaben welche mit dem abgebildeten Softwareprozess korrespondieren zugewiesen Dabei entscheidet der Spieler wer wann welche Aufgabe im Soft wareprozess erh lt Die Aufgaben umfassen SE T tigkeiten die Auswirkungen auf den Fortschritt und die Qualit t eines Softwareprojekts haben Das eingesetzte virtuelle Personal wird virtuell ent lohnt Erfolgreich ist wer sein virtuelles Projekt fristgem und ohne Budget berschreitung in ak zeptabler Qualit t abliefert Abb 1 SimSE im Einsatz Program Action Rules Name 5 Type Timing IncCodeCompleteness Effect Rule Continuous a SetCodePercentErrone Effect Rule Continuous SetProgrammingProgra Effect Rule Continuous SetNotProgrammingPro Effect Rule Destroyer IncNumUsersStoriesimp Effect Rule Continuous View Edit Rule SetProgrammingProgra Effect Rule Trigger IncSumRepNumbersPr Effect Rule Continuous Rename R
5. 6 Die n chste Ausbaustufe bietet dem Benutzer auf der Startseite zwei Buttons an und er laubt so eine Auswahlm glichkeit Abbildung 10 Entsprechend wird das Aktivit tsdiagramm um die Konzepte der Fallunterscheidung und des Er eignisses erweitert Auch das Sequenzdiagramm wird um alternative Bl cke erg nzt 7 Das folgende Inkrement realisiert eine Login M glichkeit ber eine Gastkennung Dazu wird das System um eine neue Komponente erweitert die die Business Services kapselt Zur Qualit tssi cherung der Business Services wird deren Funk tionalit t mit Hilfe von Unit Tests abgesichert Die GUI erh lt als neues Element ein Passwort Feld Zu den bisher bekannten Notationselementen in Aktivit ts und Sequenzdiagrammen werden nun R ckkopplungen ber join Knoten bzw Wiederho lungsbl cke hinzugef gt 8 Weitere Ausbaustufen fokussieren Schritt f r Schritt die Realisierung von Entity Klassen deren Persistierung in einer Datenbank sowie die Um setzung von Men s zur Benutzerf hrung Parallel zu den Konzepten der technischen Umsetzung werden auch hier die ben tigten Modellierungs notationen sukzessive weiter ausgebaut Erste Erfahrungen Der hier vorgestellte Lehr Lernansatz wird in diesem Semester erstmals auf diese Weise an der Hochschule M nchen erprobt Die zentrale Herausforderung in der Vorbereitungs phase bestand darin in jedem Schritt jeweils nicht zuviel Lernstoff auf einmal anzugehen sondern stat
6. size breite hoehe background 230 stroke 95 2 17 4 123 5 public void draw if mousePressed line mouseX mouseY pmouseX pmouseY Abb 2 Malprogramm in Processing A Spillner H Lichter Hrsg SEUH 13 Sehr interessant ist aus didaktischer Sicht dass viele Studierende die sich bewusst f r einen k nst lerischen Studiengang entschieden haben durch Processing einen schnellen und oft begeisternden Einstieg in die Programmierung finden Es wird wieder auf die unmittelbare Visualisierung und recht einfache Interaktionsm glichkeiten gesetzt Anders als bei Spielsprachen findet die Pro grammierung im Wesentlichen in Java statt wobei die Entwicklungsumgebung es erm glicht den Objektbegriff in den Hintergrund zu stellen Dies soll mit dem vollst ndigen Programm in Abb 2 mit dem ein Nutzer mit gedr ckter Maustaste auf einer Fl che zeichnen kann veranschaulicht wer den 7 3 Zeichnen oa ET Abb 3 Malprogramm in Benutzung Abb 3 zeigt das entstehende Beispielfenster das auch leicht als ausf hrbares Programm Java Applet oder als auf Android lauff higes Programm exportiert werden kann Zentral nutzt Processing zwei Funktionen soge nannt im Processing Sprachgebrauch init und draw wobei init einmal am Programmanfang und draw danach in einer Endlosschleife aufgeru fen werden Zentral in Processing ist die gro e Menge von Funktionen die z
7. Abbildung 5 stellt einen anderen Entwurfsprozess f r derartige Simulationsmodelle dar In diesem mehrstufigen Modellierungsprozess werden in einem ersten Schritt Inhalte aus der EPF Bibliothek ausgew hlt bzw mit dem EPF Composer erzeugt In einem zweiten Schritt wird daraus ein noch unvoll st ndiges Simulations meta modell generiert Dazu werden Rollen Aufgaben Prozessschritte Artefak te Leitf den etc aus dem EPF Modell extrahiert In einem dritten Schritt wird ein passendes Szenario f r die Anwendung dieses Softwareprozesses aus gew hlt Dieses Szenario charakterisiert das simu lierte Projektumfeld und enth lt bspw Details ber verf gbare simulierte Softwareentwickler Im vier ten Schritt wird aus dem gew hlten Szenario und dem teilfertigen Simulations meta modell ein Si mulationsmodell und ein darauf basierendes Spiel generiert welches anschlie end f r den konkreten Einsatz konfiguriert und angepasst werden kann An dieser Stelle werden Parameter eingestellt oder Exkurse in Form von Minispielen in das Spiel inte griert Ziel dieses vorgestellten Entwurfsprozesses ist es den Aufwand des Lehrenden f r die Erstel lung eines Simulationsmodells gegen ber beste henden Ans tzen zu verringern Die T tigkeit des Modellerstellers wird sich dabei idealerweise auf das Mapping des gew hlten Softwareprozessmo dells auf das Anwendungsszenario und die Para metrisierung der Simulation bzw des Spiels be schr nken Nu
8. SEUH 13 standortunabh ngiger Form als auch illustriert an konkreten Beispielen Die Anwendung sollte zeigen wie das Muster das Problem l st Zusammenspiel mit anderen Mustern Voraussetzungen in Form von anderen Mus tern sowie Konflikte mit anderen Mustern sollten ebenfalls dokumentiert werden Folgen Was sind die Folgen dieses Musters Hier sind insbesondere unerwartete und negative Folgen gemeint die dem Leser bewusst sein sollten Tipps und Tricks In diesem Abschnitt k nnen Hil festellungen zur Umsetzung des Musters sowie gemachte Erfahrungen dokumentiert werden Bekannte Eins tze Dieser Abschnitt verweist auf die Veranstaltungen in denen das Muster um gesetzt wurde Die Wiki Eintr ge zu den Veran staltungen wiederum beschreiben die dort einge setzten Muster sowie ggf Kontaktpersonen und Webseiten mit weiterf hrenden Informationen Abbildung 1 zeigt eins der derzeit gut 50 Muster 2 Ein Wiki f r Erfolgsrezepte Auf www sewiki de haben wir unser internes loka les Wissen in Form von Mustern zu organisieren Wir m chten damit unser Wissen der Gemeinschaft bereit stellen es aber auch jedem Interessierten erm glichen sie mit eigenen Erfahrungen weiter zu verfeinern oder eigene Muster hinzuzuf gen Noch spiegeln diese Sei ten unsere eigenen Kochrezepte wieder die zudem stark lokal gepr gt sind Unsere Vision ist aber dass wir weitere solche Muster sammeln und weiter aus bauen k nnen
9. Weitere zu erhebende Daten sind die Erwar tungen Motivationen und Vorkenntnisse der Stu dierenden In diesem Kontext stellt sich unter ande rem die Frage ob Studierende die sich f r ein be stimmtes Fach entscheiden signifikante Eigen schaften aufweisen Auch das sind Faktoren auf die Lehr Lern Konzepte zugeschnitten werden m ssen K nnen sowohl bei den Lehrenden als auch bei den Studierenden gewisse Systematiken oder Muster erkannt werden die bei der Entwick lung didaktischer Konzepte ber cksichtigt werden m ssen und zumindest f r Software Engineering oder Teilbereiche davon signifikant auftreten So soll versucht werden die L cke zwischen den Soll und Ist Kompetenzen der Studierenden Schritt f r Schritt zu verringern und die Hoch schulausbildung im Software Engineering noch weiter zu verbessern Danksagung Wir danken den Gutachtern f r hilfreiche Anmer kungen zu einer fr heren Version dieses Beitrags Das Projekt EVELIN wird gef rdert durch das Bundesministerium f r Bildung und Forschung unter der Fordernummer 01PL12022A Literatur Abran A Moore J W Hrsg 2004 Guide to the Software Engineering Book of Knowledge Los Alamitos CA IEEE Computer Society Press Verf gbar unter http www computer org portal web swebok htmlformat Anderson L Krathwohl D Hrsg 2001 A tax onomy for learning teaching and assessing A revision of Bloom s taxonomy of educational objectives New York
10. Anwenden beinhaltet bef higt zu Abb 3 EVELIN Modell zur Beschreibung fachli cher Kompetenzen Erinnern sich an Informationen erinnern und sie wortge nau wiedergeben k nnen Verstehen den Sinn die Bedeutung von Informationen verstehen definieren k nnen implizites Wissen thematisch zugeh rige aber neue Informatio nen zuordnen k nnen Erkl ren Zusammenh nge Abh ngigkeiten und hn lichkeiten zwischen Informationen erkennen und in eigenen Worten erkl ren k nnen Ursache Wirkungs Zusammenhange tisch benennen k nnen Informationen strukturieren k nnen Vor und Nachteile erkennen bewerten und theoretisch analysieren Verorten von Informationen in Systemen sachliche Analyse begr nden theore Verwenden Anwenden in definiertem eingeschr nktem Kontext und oder unter Anleitung Umsetzung in kleinen Schritten oder mittels einer Schablone Kochen nach Rezept Verstehen muss keine Rolle spielen Anwenden selbst ndiges eigenverantwortliches Anwen den auch in schwierigem Umfeld und oder L sungswege situationsgerecht ausw hlen und umsetzen k nnen Verstehen spielt eine Rolle Weiter Entwickeln Nutzen von vorhandenem Wissen zur Entwick lung oder Weiterentwicklung von L sungen Schaffen von neuen Erkenntnissen Forschung Dabei sind Erinnern Verstehen und Erkl ren auf theoretischer Ebene angesiedelt w hrend Verwen
11. SEUA 2013 aachen Tagungsband 13 Workshop SEUH Software Engineering im Unterricht der Hochschulen 28 Februar 1 M rz 2013 RWTH Aachen Herausgeber Andreas Spillner Hochschule Bremen Horst Lichter RWTH Aachen http ceur ws org Vol 956 Vorwort Seit ber 20 Jahren wird auf den SEUH Workshops ber Schwierigkeiten und M glichkeiten diskutiert und beraten wie wir Studierenden die Vorgehens weisen bei der Softwareentwicklung am besten vermitteln Seit den ersten Workshops hat sich ei niges ver ndert es gibt aber auch vieles was un ver ndert geblieben ist Wenn wir Software Engineering unterrichten stehen wir immer wieder vor der Herausforderung wie wir den Studierenden auch in kleinen Projek ten die Vorteile von methodischem Vorgehen deut lich machen k nnen Da die meisten Studierenden keine Erfahrung mit gro en Softwaresystemen haben sehen sie nicht immer ein warum der durch ein methodisches Vorgehen begr ndete Aufwand auch bei kleinen Ausbildungsprojekten gerechtfer tigt und lohnend ist Diese Problematik hat uns bei der SEUH von Anfang an besch ftigt Studentische Ausbildungsprojekte waren ein Ansatz dieses Problem zu berwinden Die Beitr ge zur 13 SEUH haben wir in f nf Themenschwerpunkte gruppiert Im Schwerpunkt Just in Time Teaching greifen einige Autoren dieses SEUH Generalthema auf und stellen neue L sungsm glichkeiten vor Dabei soll den Studierenden durch schnelle R
12. arbeitung von Architektur und Design wenn eine Anforderungs nderung in das Projekt kam e die Erstellung einer Testsuite mit deren Hilfe der Compiler der zur Verf gung stehenden Entwicklungsumgebung auf die G te der C Unterstiitzung untersucht wird oder 27 e die Erstellung einer Simulation der Hardware wegen der Verz gerung ihrer Verf gbarkeit Diese zus tzlichen Abgaben erlauben die Variation des Projekts und die Anpassung an unterschiedli che Studieng nge mit unterschiedlichem zeitlichem Umfang f r die Studierenden Neben unterschied lichen Arbeitspaketen wird die Lehrveranstaltung abgewandelt durch die Verwendung von verschie denen Controllern oder durch abgewandelte An forderungen an das System Innerhalb der Teams erfolgen zu zwei Zeitpunkten gegenseitige Bewertungen Diese sind nur dem Dozenten bekannt Au erdem finden in dem Rah men kurze Einzelgespr che mit allen Teilnehmern statt Nat rlich ist dies bei Bedarf auch zu anderen Zeitpunkten m glich Ziele des Projekts Das Projekt hat mehrere Ziele die im Anschluss detaillierter beleuchtet werden e Verst ndnis der Besonderheiten eingebetteter Systeme bei den Studierenden e Begeisterung f r die Welt eingebetteter Systeme e Fachliche Weiterentwicklung der Studierenden durch einen Schritt von der Hochschulausbil dung hin zur Praxis e Pers nliche Weiterentwicklung der Studieren den durch bernahme von Eigenverantwortung e Spa am Lernen un
13. e der einf hrenden Program miermodule ausdr ckt H ufig sind es drei oder vier Veranstaltungen in den ersten drei bzw vier Semestern klassisch orientiert am fr heren Grund studium der Diplomstudieng nge Typisch sind Veranstaltungen mit zwei oder vier Semester wochenstunden SWS Vorlesung und zwei SWS bungen dazu Ist dieser Rahmen prinzipiell abgesteckt erge ben sich weitere modul bergreifende Fragen die in den folgenden Abschnitten dargestellt werden 2 1 Wahl und Reihenfolge der Paradigmen In der Programmierung unterscheiden wir hier imperative von deklarativen Paradigmen Zu den imperativen Paradigmen z hlen wir auch die ob jektorientierte Programmierung OOP denn fast alle objektorientierten Sprachen basieren auf einem imperativen Kern Beim deklarativen Paradigma unterscheiden wir in die Auspr gungen funktionale Programmierung und logische Programmierung Bei der Gestaltung von Studieng ngen gibt es je nach thematischem Schwerpunkt die M glichkeit eine oder mehrere dieser Auspr gungen auszulas sen An einigen Hochschulen wird beispielsweise die logische Programmierung nicht gelehrt teilwei se wird sich sogar auf die imperative Programmie rung beschr nkt Aus softwaretechnischer Sicht ist die Kenntnis imperativer Programmierung zwingend erforder lich um die Funktionsweise heutiger Computer verstehen zu k nnen Objektorientierte Program mierung ist aus softwaretechnischer Sicht vor allem deshalb
14. 2007 En hancing software engineering education using teaching aids in 3 D online virtual worlds In Proceedings of the 37th Annual Frontiers In Education Conference FIE 07 IEEE S T1E 8 T1E 13 DOI 10 1109 FIE 2007 4417884 Gee J P 2007 What Video Games Have to Teach Us About Learning and Literacy Palgrave Macmillan Hagel G Mottok J Ludewig Jochen B ttcher Axel Hrsg 2011 Planspiel und Brief methode f r die Software Engineering Ausbildung ein Erfahrungsbericht In SEUH 2011 Software Engineering im Unterricht der Hochschulen Jain A Boehm B 2006 SimVBSE Developing a game for value based software engineer ing In Proceedings of the 19th Conference on Software Engineering Education and Training S 103 114 Kritzenberger H 2005 Multimediale und interak tive Lernr ume M nchen Oldenbourg Lang J P 2012 Overview Redmine Abgeru fen am 14 11 2012 von http www redmine org Ludewig J Jaeger Ulrike Schneider Kurt Hrsg 2009 Erfahrungen bei der Lehre des Software Engineering In Softwareengineering im Unterricht der Hochschulen SEUH 11 Mittermeir R T Hochm ller E Bollin A u a 2003 AMEISE A Media Education Ini tiative for Software Engineering Concepts the Environment and Initial Experiences In Proceedings of the Interactive Computer aided Learning ICL 2003 International Work shop Villach
15. Als Zielsetzung gibt es die R ckmeldung an die Studieren den die R ckmeldung an die Lehrenden und die sys teminternen Nutzung zur automatischen Steuerung von Lernprozessen w hrend bei der Analysebasis zu unterscheiden ist ob Aussagen ber eine individuelle L sung oder die Gesamtheit der L sungen einer Auf gabe getroffen werden sollen Aus diesen Merkmalen lassen sich zahlreiche Kombinationen bilden z B e Durch die Analyse einzelner L sungen und die Aufbereitung der Ergebnisse f r die Studierenden k nnen Aussagen zum Verh ltnis von studenti 59 scher L sung und Musterl sung getroffen werden Studierenden kann so zum Beispiel der Hinweis gegeben werden dass ihre L sung zwar alle funk tionalen Anforderungen erf llt jedoch deutlich umfangreicher als die Musterl sung ist Dies muss nicht mit einer negativen Bewertung der L sung einhergehen sondern kann auch als Hinweis ver standen werden der die Studierenden zur Verbes serung ihrer L sung anregen soll e Durch die Analyse aller L sungen und die Aufbe reitung der Ergebnisse f r die Studierenden kann diesen angezeigt werden ob sie eine typische L sung gew hlt haben oder ob sie sich in bestimm ten Merkmalen deutlich von anderen L sungen unterscheidet Auch dies kann den Studierenden einen Hinweis darauf geben in welche Richtung sie ihre L sungen verbessern k nnen e Lehrende k nnen dieselben Daten nutzen um H ufungen bei L sungsmerkmalen z
16. Die Einf hrungsphase startete mit einem Multiple Choice Test ber 32 Fragen die eine breite Themen spanne des Software Engineerings abdeckten Ziel war einen berblick ber den Leistungsstand zu be kommen sowie Studierende zu identifizieren die sich bei der Themenwahl potentiell vergreifen konnten Es folgten einige Vorlesungseinheiten zu SWA und PSD sowie Einf hrungen in wissenschaftliches Schreiben Zitieren sowie die Wertigkeit und korrekte Angabe von Quellen In diesem Zusammenhang wurde auch das Thema Plagiate behandelt Des Weiteren bekamen die Studierenden einen Leitfaden der den groben Auf bau einer wissenschaftlichen Publikation beschrieb und gleichzeit als verpflichtende KIRX Vorlage diente sowie eine Leseliste zur Vorbereitung Im Folgenden wurden die Themen pr sentiert und zur Wahl gestellt Die Studierenden wurden mit kleinen Aufgaben lang sam an ihre gew hlten Projekte herangef hrt Zuerst sollten Sie ein einseitiges Proposal schreiben in dem Sie den Kontext sowie das Problem zusammenfassten und die angedachte L sung pr sentierten Anschlie end sollten Sie die wissenschaftliche Community analysieren und wichtige Konferenzen Personen und Literatur identifizieren Ihnen war im Zuge dieser Ar beiten einmalig erlaubt das Thema zu wechseln Die folgenden zwei Phasen waren von der Umset zung der Arbeit sowie der Verschriftung der Ergeb nisse gepr gt Aufgrund der vier SWS konnten wir w chentliche Gespr che
17. Konkretere Vorgaben werden somit ohnehin notwendig um die Verunsi cherung der Studierenden zu reduzieren und auch Tutoren und Mitarbeitern eine Orientierung zur Beantwortung entsprechender R ckfragen zu ge ben Das vorgestellte Bewertungsraster transpor tiert somit die Erwartungen des Pr fers an die Stu dierenden und erm glicht ihnen ihre Arbeits schwerpunkte entsprechend der gegebenen Ge wichtungen zu setzen F r fortgeschrittenere Studierende die bereits ein Anf ngerprojekt durchlaufen haben gibt das Ras ter in der gezeigten Form andererseits tats chlich zu viele Hinweise preis Es besteht nat rlich die M glichkeit beispielsweise nur f nf Hauptkatego rien wie Kontextmodellierung Anforderungen Analyse Entwurf und Sourcecode und ihre Ge wichtungen zu nennen nicht aber die konkret da rin erwarteten Modelle Ferner k nnte noch eine zus tzliche Bewertungskategorie zur Modellaus wahl etabliert werden die die Sinnhaftigkeit der gew hlten Modelle bewertet Die Gewichtung in nerhalb dieser Kategorie kann beispielsweise gleichm ig auf die gelieferten Modelle verteilt werden oder auch von den Studierenden vorge schlagen werden wenn sie mit einem entsprechen den Bewertungsschema bereits in einer Grundla genveranstaltung vertraut gemacht worden sind Ferner liegt es f r l nger laufende Projekte ohne feste Funktionalit tsvorgabe nahe auch einen ent sprechend hoch gewichteten Bewertungsfaktor f r die Menge
18. Longman Bender W Wie kann Qualit tsentwicklung aus dem P dagogischen heraus entwickelt werden P dagogische Reflexivit t In Dehn C Hrsg 2009 P dagogische Qualit t Hannover Ex pressum Verlag 69 77 Bloom B 1972 Taxonomie von Lernzielen im kognitiven Bereich Weinheim Beltz B ttcher A Thurner V M ller G 2011 Kompe tenzorientierte Lehre im Software Engineering In Ludewig J B ttcher A Hrsg 2011 SEUH 2011 33 39 Claren S 2012 Erhebung und Beschreibung von Kompetenzen im Software Engineering Mas terarbeit Hochschule Coburg Donabedian A 1980 Explorations in Quality Assessment and Monitoring The definition of quality and approaches to its assessment Ann Arbor MI Health Administration Press 1980 128 Erpenbeck J Hrsg 2007 Handbuch Kompe tenzmessung Erkennen verstehen und bewer ten von Kompetenzen in der betrieblichen p dagogischen und psychologischen Praxis 2 Aufl Stuttgart Sch ffer Poeschel Flick U von Kardorff E Steinke I 2000 Was ist qualitative Forschung Einleitung und berblick In Qualitative Forschung Ein Handbuch Reinbeck Rowohlt 13 29 Fuller U et al 2007 Developing a computer sicience specific Learning Taxonomy Verf gbar unter http www cs kent ac uk pubs 2007 2798 conte nt pdf abgerufen am 24 09 2012 Granzer D K ller 2008 Kompetenzmodelle und Aufgabenentwicklung f r die stan
19. Man kann so auch direkt in Processing neue Klassen selbst entwickeln die dann zu lokalen Klassen der gro en umgebenden Klasse werden und direkt auf die Processing Funktionen zugreifen k nnen Al ternativ kann man in Processing auch echte neue Klassen schreiben muss dann aber selbst eine Refe renz zur Nutzung der Processing Funktionen auf bauen Da Processing im Wesentlichen in Java geschrieben ist kann man die zugeh rigen Klassenbibliotheken auch in andere Programme einbauen In Kle12 wird technisch beschrieben wie man Processing aus Blue heraus nutzen kann wobei durch die besondere Art der Ausf hrung der Debugger nicht zur Verf gung steht Funktional muss der Entwick ler f r angeklickte Elemente selbst berechnen wel ches Element angeklickt wurde eine Funktionalit t die beim Interaktionsbrett schon gegeben ist Wei terhin unterst tzt Processing keine Eingabe in Kon solenfenstern Die vorherigen Abschnitte haben klar gezeigt wel che didaktischen Defizite Processing enth lt wes halb man es mit guten Gr nden nicht in einer Pro grammiereinf hrung einsetzen sollte Dem muss man die weite Verbreitung von Processing in krea tiven Bereichen gegen berstellen in denen es auch gelingt nicht programmieraffinen Personen die Begeisterung an der Entwicklung beizubringen Ob dieser Ansatz auch den systematischen sp teren Ein oder Umstieg in die objektorientierte Pro grammierung erlaubt m ssten l ngerfristige Un
20. SEUH 13 Welche Kompetenzen ben tigt ein Software Ingenieur Yvonne Sedelmaier Sascha Claren Dieter Landes Hochschule f r angewandte Wissen schaften Coburg sedelmaier sascha claren landes hs coburg de Zusammenfassung Software ist Teil der modernen Welt und nahezu berall zu finden Daher gewinnt Software Engine ering zunehmend an Bedeutung Um Software zu entwickeln oder weiterzuentwickeln sind vielfalti ge Kompetenzen und Kenntnisse n tig Das stellt auch die Hochschulausbildung und damit verbun den die didaktische Forschung im Software Engi neering vor gro e Herausforderungen In diesem Beitrag wird zun chst das For schungsinteresse beschrieben und begr ndet Dann wird der Kompetenzbegriff diskutiert und erl u tert Nachfolgend werden die methodischen Schrit te beschrieben mit denen das Kompetenzprofil eines Software Ingenieurs erhoben wird Dabei wird zun chst die Vorgehensweise beschrieben bevor erste Ergebnisse vorgestellt werden Zuletzt folgt ein Ausblick wie die Hochschulausbildung im Software Engineering noch besser auf Kompe tenzentwicklung ausgerichtet werden kann 1 Motivation Durch die stetig wachsende Komplexit t von Soft ware steigen auch die Anforderungen an Informa tiker die mit einer zunehmenden Anzahl von komplexen Rollen Schnittstellen und Aufgaben konfrontiert werden Software wird h ufig in gro en Teams mit ei ner Vielzahl fachlicher Rollen entwickelt Das reicht vom
21. Seiten 57 80 2011 RTH11 S Ruby D Thomas D Heinemeier Hans son Agile Web Development with Rails 4 Auf lage Pragmatic Programmers USA 2011 SZ07 A Schmolitzky H Z llighoven Einf hrung in die Softwareentwicklung Softwaretechnik trotz Objektorientierung In A Zeller and M Deininger Hrsg Software Engineering im Unterricht der Hochschulen Seiten 87 100 2007 Ull11 C Ullenboom Java ist auch eine Insel 9 Auflage Galileo Computing Bonn 2011 Wul0 C T Wu An introduction to object oriented programming with Java 5 Auflage Mc Graw Hill USA 2010 57 Analyse von Programmieraufgaben durch Softwareproduktmetriken Michael Striewe Michael Goedicke Universit t Duisburg Essen michael striewe michael goedicke s3 uni due de Zusammenfassung Der Einsatz von Softwareproduktmetriken zur Beob achtung und Beurteilung von Softwareprojekten ist ein oft diskutiertes Thema Es gibt vielfaltige Vor und Nachteile die beim Einsatz zu ber cksichtigen sind Der vorliegende Artikel diskutiert an Fallbeispielen wie Metriken zur Lehrunterst tzung in einer Lehr veranstaltung zur Programmierung genutzt werden k nnen Einleitung Softwareentwicklung kann ber Kennzahlen die durch den Einsatz von Metriken erhoben werden be obachtet und bewertet werden Dabei kann sowohl das entwickelte Softwareprodukt als auch der Entwick lungsprozess Ziel der Beobachtung und Bewertung sein Conte u a 19
22. Sequenz Kommunika Nachricht Alternative Schleifen diagramm tionspartner mit Metho Bl cke Block Lebens denaufruf linie Antwort Nachricht Aktionsse quenz Webtechni Webappli HTML CSS Tren Weiterleiten Konzept ken kation HTTP nung von auf Ant der Sessi Request Darstel wortseite on Daten Response lung und transfer Bedeutung Logik ber Sessi Servlet on Architektur Bedeutung Handler Schichten Listener Business Applica architektur Methode Service tion Server GUI Startseite Rendering Textfeld Passwort Framework Zusammen onInitQ Feld Apache spiel Klas Form Fehlermel Click se und Control dung Webseite Button Bindable Attribut Variable Unit Test Unit Tests fir den Business Service Tabelle 1 Wissenselemente die in den ersten Inkrementen der Systemfolge behandelt werden 76 A Spillner H Lichter Hrsg SEUH 13 Sharelt Who are you Willkommen bei Sharelt der Plattform f r die gemeinschaftliche Nutzung von Ressourcen Who are you Please enter your name Absenden Abbrechen Abbildung 10 Auswahlm glichkeit durch zwei But tons Thema mehrfach und in zunehmenden Detaillierungs stufen aufgegriffen wird Abhilfe l sst sich hier schaffen durch Bereitstellung entsprechender Begleitliteratur sofern diese themen weise aufgebaut ist Auch die Erstellung eines erg n zenden Skriptes w re nat rlich denkb
23. Team morale 0 4 25 42 24 Continuous delivery 12 23 38 17 Development cost 1 12 2 22 Tabelle 2 How important were the following agile Engineering discipline 0 42 42 engineering practices for your successful agile pro g 3 Management of distributed 0 42 19 jects teams Bei der Interpretation der Daten ist zu beachten Requirements management 0 2 29 51 13 dass gewisse agile Praktiken wie z B TDD BDD Tabelle 1 How has agile software development influ enced the following aspects Interessant an den Ergebnissen in dieser Tabelle ist dass mehr als die H lfte der Unternehmen ange ben dass sich die Wartbarkeit der Software sowie die Kosten nicht verbessert haben Aus Sicht der Ausbildung ist von Interesse welche Praktiken und Techniken entscheidend zum Erfolg in agilen Pro jekten beitragen da wir auf diese Techniken be sonderes Augenmerk legen sollten Bei dieser Frage haben wir nach Engineering Prac tices wie z B Unit Testing und Continuous Integra tion sowie Management Practices wie Daily Standup On Site Customer und Planung unterschieden Tabelle 2 gibt die detaillierten Resultate f r die Engineering Practices wieder Dabei geben die Spal tenwerte die Wichtigkeit f r den Erfolg von ganz unwichtig bis sehr wichtig wieder Als wichtige bzw sehr wichtige Engineering Practices 1 Die Bewertungskriterien gehen von Stark verschlech tert bis stark verbessert
24. Wedekind J Hrsg Information Science Ref erence Hershey New York S 181 190 Simkins S Maier M H Hrsg 2010 Just in Time Teaching Across the Disciplines Across the Academy New Pedagogies and Practices for Teaching in Higher Education Stylus Pub lishing 25 Simon B Kohanfars M Lee J Tamayo K Cutts O 2010 Experience Report Peer Instruction in Introductory Computing SIGCSE 2010 Mil waukee USA SMART www smarttech com Produktseite f r das SMART Response XE interactive response sys tem abgerufen 10 12 2012 Smith M K Trujillo C Su T T 2011 The Bene fits of Using Clickers in Small Enrollment Sem inar Style Biology Courses Cell Biology Educa tion Life Sciences Education Vol 10 14 17 Spillner A Linz T 2010 Basiswissen Software test Aus und Weiterbildung zum Certified Tester Foundation Level nach ISTQB Standard 4 Aufl dpunkt Verlag Stelzer R 2008 Kompetenzen in der Hochschul lehre R stzeug f r gutes Lehren und Lernen an Hochschulen Merkur Verlag Rinteln Welbers U Gaus O 2009 The Shift from Teach ing to Learning Bertelsmann Bielefeld W rner A 2008 Lehren an der Hochschule VS Verlag Wiesbaden 26 A Spillner H Lichter Hrsg SEUH 13 Software Engineering Projekte in der Ausbildung an Hochschulen Konzept Erfahrungen und Ideen Dr Jens Liebehenschel metio GmbH Liederbach Jens Liebehenschel me
25. Zweitens waren die unterschiedliche Gr en und Komplexit ten der Tickets ein Problem In Kanban soll ten idealerweise alle Tickets ungef hr gleich gro sein und lange brauchen Durch gemeinsame Sch tzungen der Tickets durch das Team konnten im sp teren Teil des Praktikums zu gro e Tickets identifiziert werden Zu Anfang des Praktikums fehlen im Normalfall die Er fahrungen zu pr zisen Sch tzungen Dozenten sollten in dieser Phase verst rkt dem Team mit ihrer Erfah rung helfen und Wert darauf legen ihr Wissen ber Sch tzungen an das Team zu vermitteln Drittens war die Anpassung der Arbeitsschritte oder der Limits eine Herausforderung Anpassungen sollten in kleinen Schritten erfolgen und man sollte einige Zeit abwarten ob die nderungen den gew nschten Effekt haben In unseren Praktika haben wir aber nur eine kurze Zeit zur Verf gung und die Studenten be n tigen unserer Erfahrung nach einige Zeit um sich an die Rahmenbedingungen des Teamentwicklung und der Technologien zu gew hnen Wenn man den Prozess einsetzen will sollte man sich als Lehrender dessen bewusst sein und in der Vorplanung bereits ber cksichtigen Ebenso empfehlen wir in so einer kurzen Zeitspanne entweder sich vorher zu berlegen ob die Arbeitsschritte ver ndert werden d rfen oder die Limits in den Arbeitsschritten angepasst werden sollen Wir hatten uns in dem Praktikum entschie den nur die Limits anzupassen und hatten damit gute Erfahrungen gesamm
26. der Entwickler Teams in der Industrie bei der Einf hrung von Kanban professio nell ber t Von ihm erhielten wir hilfreiches Feedback und wertvolle Tipps Schlie lich haben wir zudem die Studenten noch mit einem Fragebogen um ihre Einsch tzung gebeten In unserer Nachbereitung stellten wir aber fest dass es f r uns schwer war zu entscheiden ob uns das Dia gramm eine Aussage ber die Prozessqualit t machen kann Dies h ngt vor allem daran dass selten ein festes Paar ein Ticket durch den gesamten Prozess begleitet hat Daher h ngt die Dauer die ein Ticket in einer Phase verbracht hat nicht nur von den Eigen schaften des Tickets selber ab sondern auch von den 96 Entwicklern und der Kommunikation zwischen den Phasen Durch die kurze Zeit des Praktikums ist es darum schwer aus den wenigen Messpunkten herzu leiten ob Kanban rein objektiv zur Verbesserung des Gesamtprozesses beigetragen hat Als weiterer Kritikpunkt f gt unsere finale Priorisie rung von Analyse gt Review gt Development dem Ge samtprozess noch eine zus tzliche Komplexit t hinzu Diese Entscheidung sollte auf der einen Seite bewir ken dass dem Kunden m glichst z gig Tickets als fer tig vorgelegt werden konnten Auf der anderen Seite sollte es durch die Priorisierung immer fertig analy sierte Tickets geben die direkt in den Development Schritt gezogen werden konnten Diese beiden Schrit te waren gegeben trotzdem waren wir mit der re sultierend
27. des Workshops fiir Software Engineering im Unterricht der Hochschulen Hayes J H Lethbridge T C amp Port D 2007 Evaluating Individual Contribution toward Group Software Engineering Projects Proceed ings of the International Conference on Soft ware Engineering IEEE Iller C amp Wick A 2009 Pr fungen als Evaluati on der Kompetenzentwicklung im Studium Das Hochschulwesen Vol 6 Kerer C Reif G Gschwind T Kirda E Kurmanowytsch R amp Paralic M ShareMe 2005 Running a distributed systems lab for 600 students with three faculty members IEEE Transactions on Education Vol 48 No 3 Kultusministerkonferenz Landergemeinsame Strukturvorgaben fiir die Akkreditierung von Bachelor und Masterstudiengangen 2010 ver f gbar unter http www kmk org fileadmin veroeffentlichu ngen_beschluesse 2003 2003_10_10 Laendergemeinsame Strukturvorgaben pdf letzter Zugriff Juli 2012 Larman C amp Basili V 2003 Iterative and incre mental developments a brief history IEEE Computer Vol 36 No 6 Larman C 2004 Applying UML and Pattern 3 ed Prentice Hall Lindig C amp Zeller A 2005 Ein Softwaretechnik Praktikum als Sommerkurs Proceedings des Workshops f r Software Engineering im Unter richt der Hochschulen Ludewig J 1999 Softwaretechnik in Stuttgart ein konstruktiver Informatik Studiengang Soft waretechnik Spektrum Vol 22 No 1 Ludewig J 20
28. die Antworten stark jedoch jeweils mit leichter Tendenz zu Erkl ren 8 8 Projektmanagement Projektmanagement ist berwiegend durch ber fachliche Kompetenzen gepr gt z B Kommunika tions und Teamf higkeit Fachliche Kompetenzen spielen zun chst kaum eine Rolle da es eher un b lich ist dass ein Absolvent sofort ein Projekt leitet A Spillner H Lichter Hrsg SEUH 13 9 Welche berfachlichen Kompe tenzen ben tigt ein Software In genieur Wie bereits erl utert kann derzeit noch kein exaktes Schema angegeben werden das beschreibt in wel cher Auspr gung welche berfachlichen Kompe tenzen f r Software Engineering konkret erforder lich sind Es l sst sich jedoch ein erster Eindruck vermitteln welche Kompetenzen konkret f r den Bereich Software Engineering ben tigt werden und was darunter zu verstehen ist Derzeit handelt es sich um die Sichtweise von Software Ingenieuren und F hrungskr ften Es geht im Folgenden nicht darum die genannten Kompetenzen quantitativ aufzuz hlen sondern vielmehr zu verstehen was zentrale Anforderungen an einen Software Ingeni eur sind und was damit gemeint ist Dazu wurden in den Interviews insgesamt 306 Stellen codiert die R ckschl sse auf berfachliche Kompetenzen zulassen Insgesamt wurden 32 Codes vergeben wobei sich ber 70 der codier ten Stellen auf die 12 am h ufigsten genannten Codes verteilen vgl Tabelle 2
29. er Science and Computer Engineering Las Ve gas USA M ller Amthor M 2012 Eingereichter BMBF Einzelantrag zum Qualit tspakt der Lehre Kompetenzorientierte Adaption Innovativer interdisziplin rer und individueller Lehr Lernstrategien zur regenerativen Ordination im Studierenden Life Cylce KAIROS Projekt trager DLR Novak G M Patterson E T 1998 Just in Time Teaching Actice Learner Pedagogy with WWW IASTED International Conference on Computers and Advanced Technology in Edu cation Cancun Mexico Novak G M Patterson E T Gavrin A D Chris tian W 1999 Just in Time Teaching Blend ing Active Learning with Web Technology Prentice Hall Prince M Felder R 2007 The Many Faces of Inductive Teaching and Learning Journal of College Science Teaching Vo 36 Nr 5 Reich K 2008 Konstruktivistische Didaktik Lehr und Studienbuch mit Methodenpool 4 Auflage Beltz Verlag url http methoden pool uni koeln de Riegler P 2012 Just in Time Teaching Wer liest und wer lehrt an der Hochschule Im Tagungs band zum Forum der Lehre an der Hochschule Ansbach 24 Mai 2012 89 95 Rupp C die SOPHISTen 2009 Requirements Engineering und Management 5 Aufl Carl Hanser Verlag Schmolitzky A W Sch mer T 2011 Towards Pedagogical Patterns on Feedback in Investitag tions of E Learning Patterns Context Facotrs Problems and Solutions Education Kohls C
30. geben Unterst tzung bei auftretenden Schwierig keiten Sie versuchen auch den Teams einen Spie gel vorzuhalten damit sie ihre Entscheidungen reflektieren und dadurch die Konsequenzen der A Spillner H Lichter Hrsg SEUH 13 getroffenen und nat rlich auch der nicht getroffe nen Entscheidungen besser verstehen Der Wert dieses Scrum Projekts besteht in der Kombination der Engineering Practices mit den Ma nagement Practices in einer realistischen Projektsitu ation W hrend des Projekts gibt es auch oft Gele genheit f r den Coach die Werte der agilen Soft wareentwicklung einfliessen zu lassen Projekt und Bachelorarbeiten In den Projekt und Bachelorarbeiten ist es den einzelnen Dozierenden berlassen ob sie die Auf gabe mit einer agilen Projektmethode l sen lassen oder nicht Vor allem in der sogenannten Projektwoche in der die Projektteams einmal pro Semester eine gan ze Woche am St ck an ihren Projekten arbeiten k nnen wird insbesondere das Taskboard f r die intensive Teamarbeit genutzt Bei externen Projekten ist es eine Herausforderung auch die externen Auftraggeber f r das agile Vor gehen zu berzeugen da dies ein gr sseres Enga gement des Kunden erfordert Die Erfahrungen mit solchen Projekten sind jedoch mehrheitlich positiv Eine Schwierigkeit Projektarbeiten nach agilem Vorgehen zu organisieren ist dass in diesen Arbei ten die Teams aus Zeitgr nden in der Regel nur ein
31. higen Pro grammcode den ein Endbenutzer einsetzt sondern auch die zu seiner Erstellung notwendigen Anfor derungen daraus abgeleitete Analyse und Ent wurfsmodelle sowie Testf lle und weitere Doku mentation wie z B auch das Benutzerhandbuch Es ist daher bereits in mittelgro en Projekten not wendig eine ganze Reihe von Mitarbeitern mit verschiedenen Rollen miteinander zu koordinieren um ein System mit m glichst wenigen Reibungs verlusten entwickeln zu k nnen Dazu stehen in der Softwaretechnik verschiedene Vorgehensmodelle zur Verf gung vgl Bunse amp v Knethen 2008 von denen das Wasserfallmodell s z B Sommerville 2010 oder Larman amp Basili 2003 nach wie vor das bekannteste ist Modernere mo dellbasierte Ans tze wie das aus dem Unified Pro cess entstandene Agile Modelling vgl Larman 2004 arbeiten zumeist iterativ und schlagen die Erstellung verschiedener voneinander abgeleiteter UML Modelle f r die Systementwicklung vor Das Erlernen einer solchen modellbasierten und m glichst systematischen Vorgehensweise war das prim re Lernziel der vom Autor an der Universit t Mannheim angebotenen Softwaretechnik Projekte Der Bewertung der von den Studierenden erstellten Artefakten kommt daher im Folgenden eine zentra le Bedeutung zu M gliche Bewertungsverfahren Dieses Kapitel geht auf kurz g ngige Bewertungs verfahren an Schulen bzw Hochschulen ein und diskutiert ebenfalls in aller K rze m
32. hrend gelehrt alternative Paradigmen darauf aufbauend sp ter vermittelt Bei der Umstellung der Informatik an der Uni Hamburg auf das Bachelor Master System wurde 2005 auch die Programmierausbildung umgestellt In den ersten beiden Semestern aller Bachelor Studieng nge der Informatik wird die imperative und objektorientierte Programmierung themati siert Ab dem dritten Semester haben die Studie renden dann die M glichkeit Wahlpflichtmodule zur funktionalen und oder zur logischen Pro grammierung zu w hlen Erg nzend wird ein Wahlpflichtmodul zu Algorithmen und Daten strukturen angeboten Konsequenzen Ein Einstieg im ersten Semester mit imperativer Programmierung f hrt dazu dass es gro e Unterschiede bei den Vorkenntnissen der Teilnehmer gibt Einige Studierende k nnen bereits recht gut in Java programmieren weil sie Informa tik in der Schule belegt haben und oder in ihrer Freizeit oder sogar beruflich programmiert haben w hrend andere Studierende noch keinerlei Vorer fahrung haben Da die Veranstalter keine Vor kenntnisse voraussetzen d rfen muss die Erstse mesterveranstaltung inhaltlich bei Null beginnen Die Herausforderung besteht darin ein Tempo zu w hlen das einerseits die Anf nger nicht innerhalb k rzester Zeit abh ngt und andererseits Teilneh mer mit Vorkenntnissen nicht zu sehr langweilt In unserer einf hrenden Programmierveranstal tung SE1 derzeit ber 400 Teilnehmer aus allen Informatik Stud
33. in denen die Studierenden auf verschiedenen Ebenen innerhalb des Paares durch die Betreuer durch Pr sentationen vor der Gruppe unmittelbares Feedback zu ihrem Lerner folg erhalten Auch bei der inhaltlichen Gestaltung einer solchen zweisemestrigen Veranstaltung gibt es einige inte ressante Alternativen Zwei davon sollen hier dis kutiert werden Sammlungen vor Arrays und Inter faces vor Vererbung 4 1 Smarte Sammlungen vor Arrays Sammlungen von Objekten spielen in der Pro grammierung eine zentrale Rolle In Java gibt es zwei grunds tzliche Unterst tzungen f r Samm lungen den Sprachmechanismus f r Arrays und die Bibliotheksklassen und Interfaces des Java Coll ections Framework JCF Beide sollten in der Ausbil dung gr ndlich ber cksichtigt werden eine m gli che Frage dabei ist in welcher Reihenfolge Ein Ansatz Arrays werden relativ fr h vorgestellt das JCF deutlich sp ter In fast allen Lehrb chern zu Java wird diese Rei henfolge praktiziert siehe beispielsweise Barnes and K lling 2008 Schiedermeier 2010 oder das JCF sogar ausgelassen siehe Bell and Parr 2003 Arrays sind in Java ein expliziter Sprachmechanis mus der durch eine eigene Syntax unterst tzt wird A Spillner H Lichter Hrsg SEUH 13 und somit gef hlt zum Kern der Sprache geh rt Das JCF hingegen setzt in seinen Implementationen auf den Arrays von Java auf und erfordert f r eine sinnvolle Nutzung Kenntnisse von den I
34. ken zur Messung von Umfang und Gr e Metriken zur Messung von Struktur und Komplexit t sowie Metriken zur Messung von Anwendung und Nutzen unterschieden Die ersten beiden Kategorien lassen sich dabei den sogenannten internen Attributen von Softwareartefakten zuordnen w hrend die dritte Ka tegorie sogenannte externe Attribute ber cksichtigt Conte u a 1986 Fenton u Pfleeger 1998 Da in letzterer Kategorie die Interaktion eines Artefakts mit der Umwelt d h zum Beispiel die Nutzerfreundlich keit gemessen wird kann diese f r die automatisierte Generierung von Kennzahlen nur begrenzt verwendet werden Im Folgenden werden einige Softwareproduktmetri ken vorgestellt die f r die Anwendung auf Programm code in objekt orientierten Programmiersprachen ge eignet sind Dabei wird insbesondere untersucht ob sie speziellen Anforderungen aus dem Kontext von Lehrveranstaltungen gerecht werden e Dain bungsaufgaben h ufig Codevorlagen ein gesetzt werden muss der Einfluss des vorgegebe nen Programmcodes auf das Ergebnis der Metrik zuverl ssig bestimmt werden k nnen um eine Verf lschung oder Verw sserung der Ergebnisse zu verhindern e Die Metriken m ssen zudem geeignet sein die Verfolgung eines didaktisch sinnvollen Ziels zu unterst tzen d h Kennzahlen liefern die im Rah men der Lehre berhaupt relevant sind Anzahl der Anweisungen Die Z hlung der Anweisungen im Programmcode statements in Abgrenzung
35. llt werden sollte Jeweils der n chst auszuf llende Qua drant wird mit grauem oder schwarzem Hilfstext ge f llt Dies soll den Anwender durch den Ausf llprozess leiten Da es sich bei den Hilfstexten nur um Vorschl ge handelt kann der Anwender aber auch gegen diese Reihenfolge versto en und z B die voreingetragenen Werte entfernen Grauer Hilfstext Das Einblenden von grauem Hilfstext ist die erste Unterst tzungsstufe unseres GQM Editors und f r un erfahrene Anwender gedacht Der Hilfstext soll dem Anwender an geeigneter Stelle ins Ged chtnis rufen was in dem aktuellen Quadranten einzutragen ist Er 144 Qualit tsfaktoren Hilfestufe Grauer Text Welche Faktoren definieren den Qualit tsaspekt 1 Verzweigungstiefe Vorschlage 2 Was ist fiir einen Entwickler ein Merkmal fiir Verst ndlichkeit wenn es um Quellcode geht Vorschl ge Weiteres Eingabefeld Abbildung 4 Hilfestellung im Quadrant 1 dient als Gedankenst tze um die Aufgabe klar zu defi nieren Der Anwender wird explizit und angepasst an vorherige Eingaben nach dem einzutragenden Inhalt gefragt So erscheint der graue Hilfstext im ersten Quadranten sobald der Anwender das Mess ziel als Zielfacette eingetragen hat Die eingetragenen Werte werden dynamisch im Text verarbeitet und sind kontextualisiert Anhand der eingegeben Zielfacette in Abb 3 gelb unte
36. measurement the goal question metric paradigm College Park MD Maryland Univ 1992 Computer science technical report Series Basili u Weiss 1984 BASILI Victor R WEISS David M A Methodology for Col lecting Valid Software Engineering Data In Software Engineering IEEE Transactions on SE 10 1984 nov Nr 6 S 728 738 http dx doi org 10 1109 TSE 1984 5010301 DOI 10 1109 TSE 1984 5010301 ISSN 0098 5589 Birk u a 1998 BIRK A SOLINGEN R van JAR VINEN J Business impact benefit and cost of applying GQM in industry an in depth long term investigation at Schlumberger RPS In Software Metrics Symposium 1998 Metrics 1998 Proceedings Fifth International 1998 S 93 96 Chen u a 2003 CHEN T FAR B H WANG Y Development of an intelligent agent based GQM software measurement system In Proceedings of ATS 2003 S 188 Gantner u Schneider 2003 GANTNER Thomas SCHNEIDER Kurt Zwei Anwendungen von GQM Ahnlich aber doch nicht gleich In Metrikon 2003 2003 Hoffmann u a 1997 HOFFMANN M BIRK A ELS F van KEMPKENS R GQMaspect V1 O User Manual Fraunhofer IESE 1997 Kilpi 2001 KILPI T Implementing a softwa re metrics program at Nokia In Software IEEE 18 2001 nov dec Nr 6 S 72 77 http dx doi org 10 1109 52 965808 DOI 10 1109 52 965808 ISSN 0740 7459 Lavazza 2000 LAVAZZA L Providing automated support for the GQM me
37. rungsinhalte k nnte sich positiv sowohl auf Zeit und Gestaltungsressourcen in der JITT Vorbereitung als auch auf die Erfahrungskurve im Umgang auswirken Werden die erfassten Feedbacks auf einer Kol laborationsplattform anonym zur Verf gung ge stellt w re es auch m glich die Studierenden in eine weitere Feedbackschleife zu schicken in der ber die Gesamtergebnisse der zu einer Lehrveran staltungsstunde gesammelten Aussagen Stellung genommen werden kann Der Einsatz von strukturierten Dokumentati onsformen zur Erfassung praxisrelevanter Er kenntnisse zum pers nlichen Nachlesen und Re flektieren sollten ohne Medienbruch als Hilfe ange boten und jederzeit zug nglich sein Eine Pattern sammlung k nnte angelegt und dynamisch erwei tert werden Schmolitzky 2011 welche sowohl f r 24 Erfassung Beschreibung und Auswahl der jeweili gen Lehr Lernmethode als auch die unterschiedli chen Feedback Typen zur Verf gung steht M ller Amthor 2012 Weiter zu untersuchen ist ob diese Art der Lehrveranstaltung zu besseren Leistungen der Stu dierenden in Klausuren f hrt In einer JiTT basierten Lehrveranstaltung Software Engineering ver ndern die Studierenden ihr Verhalten von ei ner passiven hin zu einer aktiven Rolle indem sie im angebotenen Lernarrangement aktiv partizipie ren Danksagungen Die vorliegende Arbeit ist gef rdert durch das vom BMBF finanzierte Verbundvorhaben Experimen telle Verbesserung des Le
38. stehen 8 5 Design und Implementierung Hier lassen sich bei zwei Kompetenzen Aussagen ber die erwarteten Auspr gungen treffen Bei der Beherrschung objektorientierter Programmiertech niken sind sich die Befragten berwiegend einig dass sich ein Absolvent auf Anwendungsniveau befinden sollte Bei Design Patterns werden keine praktischen Kompetenzen erwartet Berufseinstei ger sollten nach Meinung der Befragten begreifen was hinter diesem Begriff steckt und die Prinzipien grundlegender Entwurfsmuster verstehen 8 6 Softwaretest Bei Kompetenzen im Bereich Softwaretest sind die Meinungen sehr unterschiedlich Lediglich bei Unittest und Testfallentwurf k nnen die Mehr zahl der Antworten mit Anwenden klassifiziert werden Au erdem wird erwartet dass Studienab solventen die grundlegenden Eigenschaften Unter schiede und Zusammenh nge verschiedener Test metriken verstanden haben 8 7 Konfigurationsmanagement Die Erwartungen im Bereich Konfigurationsma nagement lassen sich auf rein theoretische Kompe tenzen reduzieren Bei den Themen Change Ma nagement Build Management Continuous In tegration sowie Versionskontrollmechanismen k nnen alle Antworten den theoretischen Klassen Erinnern Verstehen und Erkl ren zugeordnet werden Die Erwartungen bei Build Management sind am geringsten da sich Absolventen nur an grundlegende Aspekte erinnern sollen Bei Chan ge Management oder Versionskontrolle variieren
39. tersuchungen zeigen Zwischenfazit zu Java In den letzten Abschnitten wurde der klassische imperative Lehrweg dem konsequenten Ansatz Objects First gegen ber gestellt und aus Sicht des Autors die Vorteile in der durchgef hrten Lehre vorgestellt Diese Sichtweise spiegelt sich in der neu entstehenden Literatur zu Java HMG11 Ull11 Far12 nur selten wieder Wul0 es wird maximal ein Ansatz Objects early versucht der schnell etwas zu Alternativen und Schleifen zei 55 gen will um dann in Objekte und Klassen einzu steigen Da hier auch am Anfang Programme mit Strukturen geschrieben werden die konsequent der objektorientierten Vorgehensweise widersprechen kann aus didaktischer Sicht hier kein Unterschied zum urspr nglichen Vorgehen gesehen werden Aus Sicht der doch recht kleinen Gruppe der Ob jects first Vertreter stellt sich die Frage ob der Ansatz ein Irrtum ist und man gegen Windm hlen k mpft oder ob man weiterhin bei der Behauptung die Erde ist rund bleiben soll Die weiteren Ab schnitte zu Java zeigen eventuell einen anderen Weg dass man den Spa an der Entwicklung herstellen soll und die Zeit mit den Folgeerfahrun gen den Weg zur guten Programmierung ebnet Zusammengefasst bietet Java sehr viele M glich keiten zu einem spannenden Einstieg in die Pro grammierung wobei man die anf nglich genann ten sprachlichen Probleme beachten und didaktisch umschiffen muss Fazit Etw
40. z B Kehrer et al 2005 An Hochschulen sind Kohorten hingegen oft um einiges kleiner so dass dort auch Projekte m glich sind in denen Professoren die Studierenden pers nlich betreuen und sich einen direkten Eindruck ber ihre Leis tungen verschaffen k nnen Eine weitere Schwierigkeit bei der Koordination und auch Bewertung von Projekten stellt die meist geringe Erfahrung der beteiligten Mitarbeiter und Tutoren dar Bedingt durch die naturgem sehr hohe Fluktuation innerhalb dieser Personengrup pen kommt es h ufig vor dass Mitarbeiter oder Tutoren die eine entsprechende Veranstaltung noch vor wenigen Monaten selbst besucht haben sich in einer betreuenden Rolle wieder finden das Wissen aus vorangegangenen Durchl ufen aber nicht schriftlich dokumentiert worden ist Sobald neue Tutoren bzw Mitarbeiter entsprechende Er fahrungen angesammelt haben schlie en sie ihr Studium oder ihre Promotion ab und wenden sich neuen Aufgaben zu Dieser Erfahrungsverlust gilt nat rlich auch f r den Bereich der Bewertung stu dentischer Abgaben so dass ein klar definiertes Bewertungsschema fraglos allen Lehrenden die Betreuung erleichtern und dadurch zu einer deutli chen Erh hung der Lehrqualit t f hren kann Anforderungen an die Benotung eines Softwareprojekts An dieser Stelle soll zun chst kurz auf die allge meinen G teanforderungen an Pr fungen einge gangen werden Die Literatur beispielsweise Ro loff 2002 oder M ller
41. zutreffend bewertet werden Alle vorgegebenen positiven u erungen zu den Quiz wurden im Mittel als weitgehend zutreffend bewertet Er freulich ist insbesondere die gute Bewertung der Aussagen dass die Quiz die in der Vorlesung be handelten Konzepte mit realen Systemen verbin den und dass die Quiz geholfen haben die Wich tigkeit des Vorlesungsinhalts zu verdeutlichen Dies zeigt dass das Ziel der Lehrinnovation weit gehend erreicht wurde Das Ergebnis der studen tischen Bewertung ist in Tabelle 2 dargestellt Die Zeile unter der zu bewertenden Aussage gibt pro zentual an wie oft die entsprechende Note von den Studierenden vergeben wurde Interne Evaluation Betrachtet man die Einf hrung der Quiz aus Sicht 13 der Lehrenden so f llt zun chst der gro e Auf wand zur Vorzubereitung der Quiz auf Der gr te Aufwand besteht darin ein zum Inhalt der Vor lesung passendes Softwaresystem zu finden Hat man das System gefunden so ist noch eine Anlei tung f r die Studierenden zu schreiben die sie zum betrachteten Teil des Systems f hrt Zum Abschluss der Vorbereitung m ssen noch Fragen zum System gestellt werden die die Studierenden an das in der entsprechenden Vorlesung behan delte Thema heranf hren Dieser Aufwand f llt aber nur bei der Einf hrung an da die gefunde nen Systeme und Fragen in den folgenden Semes tern wiederverwendet werden k nnen Aussage 1 2 3 4 5 k A Der Aufwand f r di
42. 18 behandelt Es hat sich als zweckm ssig erwiesen den ganzen Bereich der Software Konstruktion in einer eigenen Vorlesung zusammenzufassen Da Kenntnisse in Software Konstruktion eine wichtige Vorausset zung f r erfolgreiche Projekt und Bachelorarbeiten sind sollte die Vorlesung bereits im zweiten oder dritten Semester durchgef hrt werden Der nachhaltige Erfolg der fr hzeitigen Einf hrung dieser Praktiken zeigt sich unter anderem daran dass Studierende selbstst ndig eine solche Infra struktur f r ihre Projektarbeiten anfordern und einsetzen Pair Programming Pair Programming ben wir nicht speziell Es wird zusammen mit den anderen Engineering Practices eingef hrt und die Studierenden werden ermun tert Pair Programming bei Gelegenheit gezielt einzusetzen und f r sich zu entscheiden ob es f r sie eine Option darstellt oder nicht Wir haben die Beobachtung gemacht dass die meisten Studierenden ganz automatisch eine Form von Pair Programming einsetzten Sehr oft setzten sich zwei Studierende zusammen an einen Compu ter und l sen eine Programmieraufgabe gemein sam Es scheint also so etwas wie eine nat rliche Vorgehensweise beim Programmieren zu sein Automated Acceptance Testing Auf Automated Acceptance Testing gehen wir ebenfalls im Rahmen der Vorlesung Software Kon struktion ein Es wird ein berblick ber das Kon zept anhand des Test Frameworks Fit 13 vermit telt und Akzeptanztests geschrieben
43. 500 400 300 200 50 70 90 110 130 150 170 190 210 230 250 Komplexit t Bestanden Nicht bestanden 5 Verteilungsdiagramm f r 298 L sungen zu einer Pr fungsaufgabe Testat 4 Variante 2 Die Aufgabe griff die Aufgabenstellung aus Miniprojekt 4 siehe Abbildung 1 auf Zur Verteilung der ersten Aufga benvariante vgl Abbildung 4 A Spillner H Lichter Hrsg SEUH 13 65 Platzgr nden nicht dargestellt Es ist zu erkennen dass beide Varianten im Kern dieselbe Verteilung auf weisen Insbesondere gibt es in beiden Aufgaben einen sehr schmalen Korridor nicht bestandener L sungen im unteren Bereich und eine gr ere Anh ufung bestandener L sungen im oberen Bereich der Ver teilung Es kann daher davon ausgegangen werden dass die beiden Aufgaben zumindest im Bezug auf den Umfang und die Komplexit t der L sung identische Anforderungen an die Studierenden gestellt haben Wie oben bereits angesprochen kann diese Aussage nur dann auf das Aufgabenniveau insgesamt erwei tert werden wenn vorausgesetzt werden kann dass die Herleitung der L sung f r beide Gruppen gleich schwierig ist Bei der Interpretation der Verteilungen ist es also insbesondere als deutliches Warnsignal zu werten wenn bei als gleichwertig vorgesehenen Auf gaben deutliche Unterschiede in den Metriken auf treten Die Gleichheit von Umfang und Komplexit t muss dagegen nicht zwangsl ufig auch ein identisches Aufgab
44. Abreu u Carapuca 1994 Chidamber u Kemerer 1994 Da einige dieser Me triken so definiert sind dass sie vom Umfang eines Programms unabh ngig sind lassen sie sich zur Be wertung der Komplexit t und logischen Struktur eines Programms verwenden hnlich wie bei den oben diskutierten Halstead Metrik besteht die Schwierigkeit dass die ermittelten Merkmale bei Programmieraufgaben durch Codevor lagen weitgehend vorgegeben sein k nnten Gerade in Anf ngervorlesungen ist es blich z B Felder einer Klasse und Methodensignaturen vorzugeben und nur die Methodenr mpfe programmieren zu lassen Zu dem sind solche Aufgaben in der Regel so begrenzt dass die zu erstellenden Beziehungen zwischen Klas sen berschaubar sind und die Studierenden kaum Wahlm glichkeiten haben Erst bei Aufgaben mit deut lich mehr Freiheit f r die Studierenden k nnen diese Metriken daher sinnvoll angewandt werden Dann al lerdings lassen sie sich gut in Beziehung zu einzelnen Lernzielen setzen da zum Beispiel die Erzielung einer hohen Koh sion ein direktes Thema des objektorien tierten Designs sein kann Fallbeispiele Im Folgenden wird an einigen Fallbeispielen diskutiert wie konkrete Fragestellungen aus dem Aufgabenent 61 wurf f r eine Lehrveranstaltung durch den Einsatz von Metriken beantwortet werden k nnen Als Metri ken kommen dabei stets die zyklomatische Komple xit t und die Anzahl der Anweisungen zum Einsatz d h eine Kombinatio
45. Abschlussaufgabe in der mehrere Monster die eine Mauer erklimmen mit Steinen von einem auf der Burgmauer laufen den W chter abgewehrt werden m ssen S Interaktionsbrett Punkte 4 I 1 I I I84 II IT TT TI T TTI TI Abb 1 Interaktives Spiel mit Objekten Jedes der graphischen Elemente kann mit der Maus bewegt werden wozu auch etwas Magie notwen dig ist Wieder muss festgelegt werden welches Objekt informiert werden soll wenn eine Mausak tion stattfindet Weiterhin ist es sinnvoll dass meh rere Objekte ber einen Namen als String unter schieden werden k nnen wenn das gleiche Objekt informiert werden soll F r einen verschiebbaren Kreis mit x und y Koordinate sowie einem Radius sieht dann eine Methode zum Anmelden beim In teraktionsbrett wie folgt aus ib neuerKreis this Ball ib zufall 0 300 42 10 Hier wird das Objekt das diesen Befehl ausf hrt auch ber die Mausaktion die in angeklickt ver schoben und losgelassen unterschieden werden informiert Dazu muss zumindest eine der drei zu den Aktionen geh renden Maus Methoden reali siert werden die als Parameter den Namen des Objekts und seine neuen Koordinaten bermittelt bekommt public Boolean mitMausAngeklickt String name Integer x Integer y return versenkt Der Boolesche Ergebniswert legt fest ob die Aktion berhaupt erw nscht ist Will man z B einen Knopf realisieren muss er auf das Klicken mit de
46. Anforderungsanalysten ber den Software Ar chitekten und den Programmierer bis hin zum Software Tester In jeder dieser Rollen sind zum Teil sehr unterschiedliche Kompetenzen notwen dig Da Software normalerweise nicht f r Informa tiker sondern f r fachfremde Auftraggeber ent wickelt wird muss zum Beispiel derjenige der Anforderungen erhebt ber ein hohes Ma an in terdisziplin rer Kommunikationsf higkeit verf gen Ein Software Ingenieur im Bereich Anforde rungsanalyse muss in der Lage sein sich auf f r ihn fremde Denkmuster und Denkstrukturen ein zulassen sie zu verstehen und auch zwischen ihnen und der Informatik zu vermitteln Des Weite ren muss ein Anforderungsanalytiker mit einem A Spillner H Lichter Hrsg SEUH 13 gewissen Verst ndnis f r den k nftigen Anwen dungskontext der zu entwickelnden Software aus gestattet sein um funktionale und nichtfunktionale Anforderungen m glichst umfassend erheben zu k nnen Dies setzt ein gewisses Ma an Empathie und Weitblick voraus sich in die k nftige Anwen dungssituation und den Anwender hineinzuver setzen So birgt jede Rolle im Prozess des Software Engineering ihre besonderen Herausforderungen Software Ingenieure m ssen sich jedoch unab h ngig von ihrer Rolle in ein Entwicklungsteam eingliedern k nnen und ben tigen neben ihrem fachlichen Wissen auch eine Vielzahl weiterer Kompetenzen So m ssen sie etwa in der Lage sein Herausforderungen und Pro
47. Austria Navarro E 2006 SimSE A Software Engineer ing Simulation Environment for Software Process Education Irvine CA University of California Object Management Group 2008 OMG Soft ware amp Systems Process Engineering Meta Model SPEM v2 0 Abgerufen am 26 10 2011 von http www omg org cgi bin doc formal 2008 04 01 A Spillner H Lichter Hrsg SEUH 13 Pieper J 2012 Learning software engineering processes through playing games In 2012 2nd International Workshop on Games and Software Engineering GAS Zurich Swit zerland S 1 4 DOI 10 1109 GAS 2012 6225921 Prensky M 2007 Digital game based learning Paragon House Reich K 2008 Konstruktivistische Didaktik Lehr und Studienbuch mit Methodenpool Beltz Rieber L P 1996 Seriously considering play Designing interactive learning environ ments based on the blending of microworlds simulations and games In Educational Technology Research and Devel opment 44 2 S 43 58 DOI 10 1007 BF02300540 S Egenfeldt Nielsen 2007 Third generation edu cational use of computer games In Jour nal of Educational Multimedia and Hyperme dia 16 3 S 263 281 Sharp H Hall P 2000 An interactive multime dia software house simulation for post graduate software engineers In Software Engineering International Conference on Los Alamitos CA USA IEEE Computer Socie ty S 688
48. Diese Tests werden auch in den CI Build Prozess integriert Collective Code Ownership Ebenso wie Pair Programming wird auch das The ma der Collective Code Ownership nicht explizit unterrichtet Die Studierenden werden jedoch durch Verwendung von Versionskontrollsystemen Anwendung von Coding Standards und Wechseln der Verantwortlichkeiten in den Projekten dazu ermuntert diese Praktik auszuprobieren 85 Fortgeschrittene Engineering Practices Die weiteren Engineering Practices wie Continuous delivery Acceptance Test Driven Development ATDD oder Behavior Driven Development BDD sprengen unserer Ansicht nach den Rahmen eines Bachelor Studiums Denkbar und aus unserer Sicht auch sinnvoll w re es diese weiteren Engineering Practices zuk nftig im Master Studium zu behan deln da wir davon ausgehen dass diese Praktiken in Zukunft an Bedeutung gewinnen werden Management Practices Wie aus Tabelle 5 zu entnehmen ist sind bei den Management Practices diejenigen am weitesten ver breitet welche sich direkt mit der Projektplanung befassen Nicht unerwartet wird die Planung vor wiegend unter Verwendung von User Stories ge macht berraschenderweise sind Retrospektiven in der Praxis trotz deren unbestritten hohem Nut zen nicht sehr weit verbreitet Die Management Practices betreffen vorwiegend die Team Ebene Teamarbeiten sind im Gegensatz zu den Engineering Practices welche vorwiegend die Individuelle Ebene betreffen
49. Erfahrungen mit dem kon struktivistischen Methodenbaukasten im Ta gungsband des Embedded Software Enginee ring Kongress 2010 A Spillner H Lichter Hrsg SEUH 13 Helland P 2012 Idempotence Is Not a Medical Condition Communications of the ACM vol 5 no 5 May 2012 Henderson C Rosenthal A 2006 Reading Ques tions Encouraging Students to Read the Text Before Coming to Class Journal of College Sci ence Teaching July August 2006 Hesse F W Mandl H 2000 Neue Technik ver langt neue p dagogische Konzepte in Online Hochschulentwicklung durch neue Medien Verlag Bertelsmann Stiftung Siemens Nixdorf Stiftung Hrsg G tersloh S 31 49 Heyse V Erpenbeck J 2009 Kompetenztraining 64 Modulare Informations und Trainingspro gramme f r die betriebliche p dagogische und psychologische Praxis Sch ffer Poeschel Ver lag Stuttgart Knight J K Wood W B 2005 Teaching More by Lecturing Less Cell Biology Education Vol 4 298 310 Kortemeyer G Kashy E Benenson W Bauer W 2008 Experiences Using the Open Source Learning Content Management and Assess ment System LON CAPA in Introductory Phys ics Courses The American Journal of Physics Vol 76 438 444 Liggesmeyer P 2002 Software Qualitat Testen Analysieren und Verifizieren von Software Spektrum Akademischer Verlag LON CAPA The Learning Online Network with CAPA www lon capa org Ludewig J 200
50. Gavrin A Christian W 1999 Just in Time Teaching Blending active learning with web technology Upper Saddle River NJ Poth T 2009 Adressatengerechtes Unterrichten mit dem Just in Time Teaching Verfahren Diss W rzburg http kola opus hbz nrw de volltexte 2009 416 pdf DissertationPot h pdf Zugriff am 23 10 2012 Riegler P 2012 Just in Time Teaching Wer liest und wer lehrt an der Hochschule In Waldherr F Walter C Hrsg Wissen k n nen verantwortlich handeln Forum der Lehre 2012 Ansbach S 89 95 Siebert H 1997 Didaktisches Handeln in der Erwachsenenbildung Didaktik aus konstruk tivistischer Sicht 2 Auflage Neuwied u a Slunt K Giancarlo L 2004 Student centered learning a comparison of two different meth ods of instruction Journal of Chemical Educa tion vol 81 No 7 p 985 988 A Spillner H Lichter Hrsg SEUH 13 Drei Feedback Zyklen in der Soft ware Engineering Ausbildung durch erweitertes Just in Time Teaching Georg Hagel J rgen Mottok Martina M ller Amthor georg hagel martina mueller amthor fh kempten de juergen mottok hs regensburg de Zusammenfassung Das Konzept des Just in Time Teachings existiert seit Ende des 20 Jahrhunderts Novak 1998 und wird weltweit in vielen Bereichen erfolgreich prak tiziert Allerdings noch nicht im Bereich Software Engineering Es basiert auf gro en Selbststudiums Anteilen f r die Studierenden und zwei Feed
51. Interaktive Systeme 3 organisatorischer Art 3 1 Vorlesungen Folien vs Ausf hrung 3 2 bungen Heim vs Pr senzarbeit 4 inhaltlicher Art 4 1 Smarte Sammlungen vor Arrays 4 2 Interfaces vor Vererbung Tabelle 1 Diskutierte Alternativen 2 Alternativen auf Studiengangs ebene Im Zuge der Umstellung auf das Bachelor Master System an den deutschen Hochschulen sind etliche neue Studieng nge entstanden die im Kern Infor matik Inhalte vermitteln und dar ber hinaus un terschiedliche Ausrichtungen anbieten Auf dieser Ebene auf der strategische Entschei dungen f r ganze Studieng nge nicht nur in Be zug auf Module zur Programmierung getroffen werden stellt sich u a die Frage welche Schwer punkte gesetzt werden sollen Steht eine berufliche Qualifizierung im Vordergrund oder eine For schungsorientierung Bei einer Forschungs orientierung Welche Schwerpunkte werden be tont Je nach Forschungsschwerpunkt k nnen sich auch unterschiedliche Schwerpunkte im Studien 38 angebot ergeben f r Bildverarbeitung beispiels weise ist eine st rker formal mathematische Aus bildung notwendig w hrend f r Forschung zum Thema Softwarearchitektur eher praktische und konzeptionelle Inhalte im Vordergrund stehen sollten Aus diesen berlegungen ergibt sich auch der Umfang welcher der Programmierausbildung im Studienprofil zugestanden wird und der sich in Anzahl und Gr
52. Jaeger Hochschule Heilbronn Dieter Landes Hochschule Coburg Horst Lichter RWTH Aachen lokale Organisation Barbara Paech Universitat Heidelberg Lutz Prechelt Freie Universitat Berlin Kurt Schneider Leibniz Universitat Hannover Andreas Spillner Hochschule Bremen Vorsitz Andreas Zeller Universitat des Saarlandes Ana Maria Dragomir RWTH Aachen hat vielf lti ge Aufgaben in der Vorbereitung der SEUH ber nommen und dazu beigetragen dass das Konfe renzsystem EasyChair verwendet werden konnte Ferner hat sie aus den akzeptierten Beitr gen den Tagungsband zum Workshop erstellt Vielen Dank daf r Schlussendlich m chten wir den Sponsoren ANECON Software Design und Beratung G m b H und iSQI International Software Quality Institute GmbH f r die gro z gige Unterst tzung der 13 SEUH danken Wir freuen uns auf das gemeinsame Treffen spannende Vortr ge und anregende Diskussionen Bremen und Aachen Januar 2013 Andreas Spillner Horst Lichter Hochschule Bremen RWTH Aachen A Spillner H Lichter Hrsg SEUH 13 Inhaltsverzeichnis Eingeladene Beitr ge Neue Wege in Software Engineering Projektkursen 44444444Hnnnnnnn nennen 3 Bernd Br gge TU M nchen Software Engineering Curriculum Siemens 44444ssnnnnnnennnnnnnnnnnnnnnnn nenn 5 Peter Zimmerer Siemens AG Session 1 Just in Time Teaching Just In Time Teaching f r Software Engineering 44
53. Kernelemente einer neuen digitalen Spielumgebung f r Softwareprozesse Nach einer Analyse existierender Ans tze und Anwendungen wurde eine Reihe von Kernelemen ten identifiziert welche die Basis einer neuen web basierten Spielumgebung bilden Diese wird aktu ell im Rahmen des Forschungsprojekts Sim4SEEd Simulation and Digital Game Based Learning for Soft ware Engineering Process Education entwickelt Dabei werden zwei wesentliche Ziele verfolgt 1 Um Lernerfolg zu maximieren wird die Spiel umgebung die Anforderungen an konstrukti vistische Lernumgebungen umfassender als bisherige Ans tze unterst tzen Die Unterst t zung sozialer Interaktion fr hes Feedback als Anreiz f r Artikulation und Reflexion sowie die Bereitstellung multipler Perspektiven auf den jeweiligen Softwareprozess bilden hierbei Schwerpunkte 2 Auch gute L sungen finden nur dann ihren Weg in die Praxis wenn sich ihre Nutzung f r Anwender nicht unn tig kompliziert gestaltet Lehrende werden unter Ausnutzung von Sy nergien von der transparenten Erstellung des Simulationsmodells ber die Administration des Lernspiels bis hin zu kursweiten Auswer tungen unterst tzt Die nun folgenden Abschnitte beschreiben die Kernelemente welche zur Erreichung dieser Ziele beitragen werden A Spillner H Lichter Hrsg SEUH 13 Soziale Interaktion als Kollaboration und Wettbewerb Die Kombination aus Einzelspiel in dem alle Ent scheidungen selbs
54. Quiz Fragen zu Open Source Software zu stellen deren Beantwortung sie an das Thema der n chsten Vorlesung heranf hrt und nebenbei den A Spillner H Lichter Hrsg SEUH 13 Umfang des betrachteten Systems aufzeigt Der Einsatz von JiTT besteht aus den folgenden Kom ponenten einem w chentlich wechselnden Soft waresystem einem zweiteiligen Quiz und einer kurzen Einheit in der folgenden Vorlesung Die in den jeweiligen Vorlesungen behandelten Themen und die daf r verwendeten Softwaresysteme sind in Tabelle 1 angegeben Im Folgenden soll nun auf die Quiz im Detail eingegangen werden Vorlesungsthema Softwaresystem Software Prozesse Firefox Bugtracker Nichtfunktionale An LibreOffice Release No forderungen tes Spezifikation Aristotle Analysis Sys tem Spezifikation nebenl u Eclipse Deadlock figer Systeme Design STL Iteratoren Architekturen Diverse Systeme Objektorientiertes De ADT Queue sign Testen Mozilla Test Case Writ ing Primer Test berdeckung GCC libstdc Test Suite Wartung Diverse Programme Tabelle 1 Vorlesungsthemen und verwendete Soft waresysteme Quiz Jedes Quiz besteht aus zwei Teilen der Einlei tung die die ganze Zeit verf gbar ist und dem Fragenteil f r den es eine begrenze Bearbeitungs zeit gibt In der Einleitung wird das betrachtete System kurz vorgestellt und es wird beschrieben wo man das ben tigte Material fin
55. Semester erfolgreich unter Anleitung eigenst ndige Programmier und Analyseaufgaben in Forschungsprojekten als studentische Hilfskr fte bernehmen Zusammenfassend kann der Ansatz als sehr er folgsversprechend angesehen werden wird aber 51 nicht konsequent weiter betrachtet da die verant wortlichen Dozenten sich nicht auf diesen Weg einigen konnten Die folgenden Unterabschnitte analysieren einige weitere Faktoren die f r den Erfolg einer Pro grammierveranstaltung relevant sein k nnen was z B die Wahl der Entwicklungsumgebung betrifft Eclipse Eclipse Ecl ist eine m chtige Plattform die mit vielen Arten von Erweiterungen individuell an Projekte angepasst werden kann und deshalb in Unternehmen in den meisten Java Projekten gesetzt ist Neben Java ist die Entwicklungsumgebung auch f r weitere Programmiersprachen wie C und C effizient nutzbar F r absolute Programmieran f nger ist aber oft die gro e Vielzahl an angebote nen Arbeitsschritten sehr verwirrend Die Flexibili t t die Eclipse bei Entwicklern sonst sehr beliebt ist macht die Umgebung f r Anf nger schwer einsch tzbar Es gibt z B mindestens drei Wege eine Klasse anzulegen es gibt viele Sichten die konfiguriert werden k nnen und die Syntaxpr fung weist bereits beim Tippen auf potenzielle Feh ler hin Weiterhin werden f r Java viele vereinfa chende Schritte wie die Generierung von get und set Methoden sowie hashCode und equals ang
56. Sheets und Messpl nen Die Enwicklung von GQMaspect wurde an der Uni versit t Kaiserslautern begonnen und sp ter am Fraun hofer IESE Institut f r experimentelles Software Engi neering weitergef hrt Hoffmann u a 1997 Voigt laender 1999 GQMaspect unterst tzt die gesamte GQM Methode Aufnahme und Verwaltung der Goals Erstellen von Abstraction Sheet mittels Editor bis hin zur Verwaltung von Messpl nen Mit GQMaspect las sen sich Beziehungen zwischen einzelnen Produkten der Arbeitsphasen der GQM Methode herstellen Ein Goal wird einem AS zugewiesen etc und es k nnen Vollst ndigkeitsabfragen gemacht werden wurde je des definierte Goal mit einem AS weiterverfolgt Der Ansatz unseres GQM Editors unterst tzt hier lediglich 146 die Erstellung von Abstraction Sheets und Messpl nen Goals werden nicht nennenswert behandelt Im Ge gensatz zu unserem GQM Editor bietet GQMaspect dem Anwender jedoch wenig Unterst tzung wenn es um das eigentliche Erstellen von neuen GQM Inhalten geht Anwendergruppe von GQMaspect sind erfahre ne GQM User w hrend GQM Editor f r den Lehrge brauch bzw fiir unerfahrene Anwender konstruiert wurde GQM DIVA GQM Definition Interpretation Valida tion wurde im Rahmen einer Diplomarbeit an der Universitat Kaiserslautern entwickelt van Maris u a 1995 Das Tool berpr ft die Konsistenz der Eintr ge eines GQM Baumes hier genannt GQM Plan damit keine fehlerhaften Daten weite
57. Spalte Begrenzungen definiert und auf dem Board notiert Dies bedeutet dass sobald das Li mit in einer Phase erreicht ist nicht neue Tickets in diese gezogen werden d rfen sondern die Ressourcen genutzt werden m ssen um die in Arbeit stehenden Tickets fertig zu stellen 92 Kanban basiert auf dem so genannten Pull Prinzip d h dass die Entwickler ein Ticket selbstst ndig in eine Spalte ziehen solange die Arbeitslimits in der entsprechenden Phase noch nicht erreicht sind Sie bernehmen damit die Verantwortung f r den der Spalte entsprechenden Schritt in Bezug auf das gezo gene Ticket Des Weiteren werden h ufig die einzel nen Phasen in zwei Spalten unterteilt um zu visuali sieren was In Arbeit ist und welche Tickets Fertig sind Dies erlaubt es in den nachfolgenden Phasen zu sehen welche Tickets als n chstes gezogen werden d rfen Durch die explizite Visualisierung des Ist Zustandes ist es m glich den Gesamtprozess zu messen und zu analysieren wie schnell die einzelnen Tickets durch den Prozess wandern 4 Kerneigenschaft Ebenso werden Probleme in der Entwicklung sichtbar wenn man z B feststellt dass die Limits in einer Phase h u fig erreicht werden oder die Entwickler in einer Phase regelm ig auf Arbeit warten m ssen Diese Informationen k nnen mit genutzt werden um den Prozess kontinuierlich und gemeinsam zu verbessern 5 Kerneigenschaft Hier werden h ufig auch mathematische Modell
58. System out printIn val ist 1000 for int val 1 if val vgll System out printIn val ist 10 if val vgl2 System out printiIn val ist 1000 1 add nul Integer valn 1 get 2 System out printin valn valn int vali 1 get 2 System out printin vali vali Die Ausgabe liefert val ist 10 val ist 10 val ist 1000 valn null Exception in thread main java lang NullPointerException ein Ergebnis dass mit reiner Logik ohne zus tzli ches Wissen kaum verst ndlich ist Es ist m glich dieses Problem im Wesentlichen zu vermeiden indem konsequent nur die dazugeh rigen Klassen wie Integer und Double f r Variablen genutzt wer den Ein Ansatz der vom Autor erfolgreich genutzt wurde Leider kann man nicht vollst ndig in der Welt der Objekte und Klassen arbeiten da die Java A Spillner H Lichter Hrsg SEUH 13 Klassenbibliothek viel mit int Werten arbeitet Kri tisch ist weiterhin dass man sehr h ufig fr h in Programmen viele null berpr fungen einbauen muss und es faktisch kein begleitendes Lehrbuch gibt das diesen Ansatz auch verfolgt Java behandelt Zahlen und String Objekte wie f r Smalltalk bereits andiskutiert als immutable Ob jects was f r Anf nger nicht unmittelbar verst nd lich ist Objects First Trotz dieser M ngel wird Java oft und recht erfolg reich in der Programmiergrundausbildung einge setzt was auch auf die zweite di
59. Tests kennen und erleben nebenbei wie wertvoll Tests als Dokumentation sind Anschliessend wird das automatische Testen mit White Box Black Box Tests und quivalenzklassen formal eingef hrt Die Studierenden sind dann in der Lage einfache Testf lle selbstst ndig zu schrei ben In den h heren Semestern werden mit zuneh mendem Know how anspruchsvollere Testf lle mit Mock Objekten entwickelt und verschiedene Test muster eingef hrt Das automatische Testen sollte sich durch m glichst alle programmier nahen Vor lesungen durchziehen Ein anderer erprobter Weg ist dass die Studieren den schon vom ersten Semester an in den Pro grammier Modulen das Schreiben von einfachen Unit Tests mittels Unit Testing Frameworks ken nenlernen und in den Projekten anwenden An schliessend erhalten sie im zweiten Semester im Modul Software Konstruktion eine vertiefte Ein f hrung in das systematische Testen und fortge schrittene Themen wie Mock Testing kennen die sie dann wiederum in den Projektarbeiten f r das fortgeschrittene Testen einsetzen k nnen Refactoring Test Driven Development TDD baut auf automa tischen Unit Tests auf Neben Kenntnissen in Unit Testing brauchen die Studierenden auch Kenntnis se in Refactoring Mit anderen Worten sind gute Kenntnisse in Refactoring eine Voraussetzung f r TDD Die einfachsten Code Refactorings werden bereits am Anfang des Studiums zusammen mit den Coding Standards und der IDE Unterst t
60. Tickets angepasst haben Zur Evaluation des Praktikums haben wir die Stu denten am Ende gebeten einen Fragebogen auszuf l len Neben acht offenen Fragen enthielt der Fragebo gen Fragen die mit Werten auf einer Skala von 0 bis 6 zu beantworten waren Unter anderem baten wir die Studenten um ihre subjektive Einsch tzung ihrer Kompetenz vor und nach dem Praktikum Hier bedeu tete 0 keinerlei Wissen und 6 exzellentes Wissen In allen abgefragten Kompetenzen verbesserten sich 4Kanban Entwickler aus der Wirtschaft berichteten uns im per s nlichen Gespr ch dass man bis zu einem Monat warten muss um zu sehen ob eine Anderungen positive Auswirkungen hatte A Spillner H Lichter Hrsg SEUH 13 die Studenten im Mittel um mindestens 1 1 Punkte Den gr ten mittleren Zuwachs gaben die Studenten bei den technischen Fertigkeiten an Verst ndnis von Android 1 7 Prolog 1 9 Verwendung von Sub version 2 0 und Eclipse 2 1 Aber auch bei weichen Faktoren war der Zuwachs deutlich Kom munikation 1 5 Zusammenarbeit 2 0 Auch im Hinblick auf Kanban u erten sich die Studen ten eindeutig positiv So hat ihrer Meinung nach das Kanban Board die bersicht verbessert 5 0 und den Arbeitsfluss klar widergespiegelt 5 1 Zudem waren die Work in Progress Limits klar 4 7 Nicht ganz so zufrieden waren die Studierenden mit der eigenen Handhabung von Staus 3 0 Empfehlungen f r die Lehre Die Ev
61. Um die wichtigsten Herausforderungen eines Softwaretechnik Projekts aus verschiedenen Blick winkeln zu beleuchten sollen im Folgenden weiter f hrende Einblicke gegeben werden die nochmals die Notwendigkeit eines an der Aufgabenstellung orientierten Bewertungssystems unterstreichen sowie wichtige Hintergr nde n her erl utern An schlie end werden zentrale Anforderungen an ein solches Bewertungssystem zusammengetragen Didaktische Sicht Aus didaktischer Sicht springen zun chst die ho hen Anforderungen die sich an die Studierenden in einem Softwaretechnik Projekt auf Grund der zuvor formulierten Lern und Kompetenzziele er geben ins Auge Beispielsweise B ttcher et al 2011 halten eine detailliertere Aufschl sselung dazu notwendiger Kompetenzanforderungen aus den vier Bereichen Sach Methoden Selbst und Sozialkompetenzen bereit Grunds tzlich bleibt festzuhalten dass die hohe Komplexit t von Soft wareprojekten von den Teilnehmern ohne Zweifel ein tiefgehendes Verst ndnis zahlreicher Abl ufe und Techniken verlangt und Pr fer damit regel m ig vor die Herausforderung stellt etwas zu pr fen was sich nicht direkt lehren l sst vgl Ludewig 2011 sondern nur durch praktische An wendung erfahren werden kann In der Softwaretechnik wurde und wird f r eine solche Lehrform traditionell h ufig der Begriff Praktikum verwendet der damit allerdings nicht korrekt eingesetzt ist Ein Praktikum an einer Hochschul
62. Wissen zu festigen als neues Wissen zu vermitteln Wangenheim Shull 2009 Einige Projekte waren nicht in der Lage eine Wir kung von spielbasiertem Lernen nachzuweisen Andere ermutigende Studien zeigten dass der Einsatz von Lernspielen geeignet war auf Seiten der Studierenden Empathie f r die Notwendigkeit von Methoden und Prozessen im SE zu entwickeln Die Lernenden fanden eingesetzte Spiele fesselnd einfach zu benutzen und zogen sie traditionellen Lehrmethoden vor Die sorgf ltige Planung und Einbettung von Spielaktivit ten in das Curriculum ausreichende Anleitung detailliertes Feedback Diskussion sowie die gr ndliche Auswertung und Erkl rung der Spielresultate werden dabei als es sentiell wichtig erachtet Wangenheim Shull 2009 Die verwendete Methodik der Evaluierungen dieser spielbasierten Ans tze wird durchaus kri tisch bewertet Wangenheim Shull 2009 was auch in anderen Anwendungsdom nen von spiel basiertem Lernen der Fall ist Rieber 1996 S Egenfeldt Nielsen 2007 Das Potential ist bei weitem noch nicht ausgesch pft Die meisten verf gbaren digitalen Lernspiele sind ausschlie lich f r Einzelspieler konzipiert Als sol che fordern Sie von jedem Spieler die Auseinander setzung mit dem gesamten abgebildeten Software prozess f rdern also den Blick auf den Prozess als Ganzes Jedoch mangelt es bei einer isolierten Spielerfahrung an motivierender Zusammenarbeit und an motivierendem Wettbewerb
63. aller Kennzahlen f r eine gro e Menge von L sungen sind dagegen Aussagen ber die Aufgabe zu erwarten die beispielsweise auch zur Qualit tssicherung genutzt werden k nnen wenn Aufgaben zu einem sp teren Zeitpunkt erneut einge setzt werden sollen Bei der Analyse von gro en Mengen von L sungen wird durch diese in der Regel ein L sungsraum auf 60 gespannt der dann untersucht wird Die Analyse des Raumes kann dabei wie oben skizziert auf Software produktmetriken basieren oder aber auch auf hnlich keitsma en zwischen L sungen Ein m glicher Ein satzbereich ist dabei die Plagiatserkennung bei der es nicht um die Eigenschaften der L sungen selber geht sondern nur um die N he der L sungen zueinander Leach 1995 Die N tzlichkeit von Ma vergleichen in diesem Bereich ist jedoch strittig so dass es auch zahlreiche Ans tze gibt die Textvergleiche heranzie hen Der Einsatz von Softwareproduktmetriken zur Qua lit tssicherung und Unterst tzung der Benotung wur de ebenfalls schon in Ans tzen untersucht Mengel u Yerramilli 1999 R ckt die Kontrolle des Lernfort schritts oder die Generierung von R ckmeldungen in den Fokus k nnen auch komplexe mathematische Ver fahren oder maschinelles Lernen zum Einsatz kommen Martin u a 2009 Gross u a 2012 Im vorliegen den Beitrag werden jedoch einfachere Techniken der Datenanalyse eingesetzt Einige Metriken Bei Softwareproduktmetriken wird zwischen Metri
64. amp Bayer 2007 h lt dazu die folgenden Testg tekriterien bereit eine Pr fung bzw auch eine einzelne Pr fungsleistung sei objek tiv also unabh ngig sowohl von der Person des Pr fers als auch von der des Pr flings bewertbar Insbesondere gilt dabei dass beispielsweise Ausse hen oder Herkunft eines Pr flings die Note nicht beeinflussen d rfen Ferner soll ein Pr fungsver fahren zuverl ssig die tats chliche Leistungsf hig keit eines Pr flings erfassen und somit bei ver gleichbaren Pr fungsleistungen eine vergleichbare Benotung ergeben Eine valide Pr fungsform misst genau die Leistung die sie vorgibt zu messen und genau die die auch gemessen werden soll N tzlich ist eine Pr fung sobald sie eine sinnvolle Funktion erf llt im Allgemeinen werden in diesem Zusam 105 menhang beispielsweise eine R ckmeldefunktion f r Dozenten bzw Studierende oder auch Anreiz bzw Selektierungsfunktionen genannt Eine Pr fung gilt als konomisch wenn Nutzen und Auf wand in einem vern nftigen Verh ltnis zueinander stehen Aus den oben diskutierten Hintergr nden und Erfahrungen sowie den eben genannten Testg te kriterien ergeben sich folgende grundlegende An forderungen an die Benotung einer praktischen Softwaretechnik Veranstaltung die weitestgehend auf hnliche Veranstaltungen in anderen Teilgebie ten der praktischen Informatik bertragbar sind 1 Die Benotung muss sowohl f r Lehrende als auch f r Stud
65. auf den komme Darauf konnten wir in der Lehrveranstaltung aus f hrlich eingehen Auch die Frage Gibt es auch einen sog White Box Test leitete am Ende der Lehrveranstaltung sinnvoll auf das n chste Themengebiet ber Au er den in Abbildung 1 gezeigten Fragen wurde ein online zu bearbeitendes Beispiel zur strukturierten Testfallermittlung erstellt In der Vorbereitung der Lehrveranstaltung war die Durchsicht der Antworten zu diesem Beispiel sehr aufwendig da die verwendete Lehr und Lernplatt form Moodle keine Hilfsmittel anbot um die Ant worten automatisch zu beurteilen Allerdings konnte durch die Sichtung der Antworten erkannt werden wo die Studierenden in der Anwendung der strukturierten Testfallermittlung noch Schwie rigkeiten hatten A Spillner H Lichter Hrsg SEUH 13 Die Lehrveranstaltung zur strukturierten Test fallermittlung lief dann vollkommen anders ab als gewohnt Zun chst wurde auf die Schwierigkeiten der Studierenden und deren Fragen genau einge gangen Dann wurde ein weiteres Beispiel gemein sam in der Lehrveranstaltung erarbeitet Das Feedback der Studierenden war in der Mehrzahl positiv Auch in der Abschlussklausur wurde das Thema berwiegend sehr gut bearbeitet Daher beschlossen die Lehrenden das Just in Time Teaching weiter auszubauen Was haben wir aus der Testphase gelernt Die Beantwortung der Fragen muss motiviert werden Die Vorbereitung auf die Lehrver
66. auf den Erfolg eines didaktischen Ansatzes zu schlie en Im Kapitel zu Java werden weiterhin alternative Vorgehen zur Vermittlung und ihre Unterst tzung durch verschiedene Werkzeuge betrachtet Die Komplexit t des Aufbaus eines wirklich aussa gekr ftigen Messsystems das auch Vergleiche aus h lt wird auch in der Dissertation von Matthew C Jadud Jad06 deutlich in der versucht wird aus dem Verhalten wann Studierende was kompilie ren Schl sse ber ihren Lernfortschritt zu ziehen Die in der genannten Arbeit aufgeworfene Frage aus welchen Indikatoren z B die Messung von Zeiten die in einer Entwicklungsumgebung ben tigt wurden die Anzahl von Compiler Aufrufen oder die Anzahl gescheiterter zur Verf gung ste hender Tests man konkrete Schl sse ziehen darf stellt ein offenes spannendes Forschungsgebiet f r weitere Untersuchungen dar Smalltalk Smalltalk Bra08 ist die erste kommerziell einge setzte Sprache die konsequent und vollst ndig auf Objektorientierung gesetzt hat Alles also auch einfache Zahlen sind Objekte die mit Methoden bearbeitet werden k nnen Die Geschichte von Smalltalk zeigt deutlich wie ein hochinnovativer Ansatz historisch einfach v llig zu fr h stattgefun den hat Die Sprache pflegte immer das Image des besonderen und war ma geblicher Vorreiter in der Entwicklung der Fenster Technologien und der Maussteuerung Leider ben tigten diese Ans tze in den 1970er und 80er Jahren extrem t
67. dass die Studierenden Ergebnisse in der verf gbaren Zeit erreichen konnten Diese waren in Klammern die Anzahl der Arbeiten a Relation of SW Architecture and Organizational Structure 5 b De Port Shen to Clojure 1 c Reinvent Programming for iPads Tabs 4 d w Architecture Diagrams Supporting the Functional Paradigm 4 e Program Structure and Run Time Visualization of Algorithms 1 f Architecture and Scale Free Networks 0 g Concurrency and Architecture 1 115 Die Studierenden waren nicht an diese Auswahl gebunden und konnten ihre Arbeiten feiner auf be stimmte Aspekte ausrichten Mit den Themen a und b wurden zwei Notausg nge integriert falls Studie rende ihre St rke oder Schw che im Programmieren sahen Thema a hatte zwar konkreten Bezug auf Software Architektur im Fokus lag aber die Beziehung zu Unternehmensstrukturen Thema b war eine an spruchsvolle Programmieraufgabe sodass hier keine Ausarbeitung geschrieben werden musste Die The men a und e waren bewusst empirisch orientiert und wurden auch entsprechend vorgestellt Unsere Erwartung war aus den eingereichten Arbei ten eine nach eventueller berarbeitung publizieren zu k nnen sowie einige andere zu einer weiteren Ver ffentlichung zu verbinden Struktur und Durchf hrung Die Struktur des gesamten Semesters war grob in drei Phasen unterteilt Einf hrung die zeitlich l ngste Phase Forschung Schreiben
68. dem eigenen Benutzernamen in das verwendete Versionskontrollsystem hochzuladen Ferner soll ten alle Aktivit ten wie das Erstellen von Doku menten Modellen oder Quellcode aber auch Team Meetings o in sogenannten Timesheets gelistet werden hnlich wie es auch zu Abrech nungszwecken in Industrieprojekten praktiziert wird Nach etwa weiteren zwei Wochen wird ein erstes Kolloquium durchgef hrt um sicherzustellen dass jedes Teammitglied zum Projektziel beitr gt und alle Anforderungen vollst ndig verstanden wur den Um den Studierenden etwaige Ber hrungs ngste zu nehmen bietet es sich an dieses Kollo quium nicht zu benoten sondern nur eine rudi ment re Mindestleistung zum Bestehen zu verlan gen die ggf in einem Folgegespr ch nochmals nachgefordert werden kann Der Autor hat gute Erfahrungen damit gemacht bis zum Ende des Projekts noch zwei weitere benotete Kolloquien durchzuf hren eines nach etwa zwei Dritteln der Dauer eines in Form einer Systempr sentation bzw abnahme ganz am Ende des Projekts Systembewertung Die Benotung des Softwaresystems und der mitge lieferten Artefakte erfolgt auf Basis des im Folgen den vorgestellten Bewertungsrasters Dabei sind fett gedruckte Elemente zwingend zum Bestehen erforderlich d h eine nicht ausreichende Leistung in einem entsprechenden Bereich f hrt direkt zum Nicht Bestehen des gesamten Projekts Ohne Aus zeichnung gedruckte Kategorien werden vom Team veran
69. dem simu lierten Softwareprozess f hrt Die im Spiel gebote ne Transparenz geht ber die in vielen Projekten vorgefundene Realit t hinaus und ist im Idealfall ein Ansto f r das Hinterfragen von Intransparenz in erlebten oder noch folgenden Kurs Projekten der Lernenden Abbildung 3 zeigt einen Mockup Entwurf des webbasierten Spiels mit Kollaborationselementen Im Kopf der Seite ist erkennbar dass der Spieler Austin Mitglied des Teams 3 ist Auf der rechten Seite befinden sich Informationen ber das aktuelle Ranking ein Team Chat und Nachrichten vom Spielleiter Das Ranking stellt dar dass sich das Team 3 momentan an Platz 3 von 10 Teams befin Sim4SEEd SE winter course 2012 4 Ox A http fh stralsund sm seedorg se wnter 2012 Sim4SEEd SE winter course 2012 live game project staff ticketsystem statistics OpenUp Docs Hey Austin I just finished the implementation of ticket 111 Code is commited and ticket is closed What should I do next Cody Coder Developer see his profile Be you spent left 100 DI 8 200 000 O You are logged in as Austin Powers playing for Team 3 the early adopters logout Ranking You are 2 out of 4 team members Your team is 3 out of 10 teams complete course rankings Team Chat Bob your score is much better than mine what did you do Austin let s meet and discuss Joe s score is even better Joe should tak face2 face just
70. den Anwenden und Entwicklung mit praktischer Umsetzung verbunden sind 124 8 Welche fachlichen Kompetenzen ben tigt ein Software Ingenieur Wie in Abschnitt 6 3 beschrieben wurde eine Be fragung von Unternehmensvertretern durchge f hrt Da die Ergebnisse nur einen Baustein in Form einer ersten Datenerhebung zur Bildung von Hypothesen bei der Erstellung der Soll Kompetenzprofile darstellen k nnen die Aussagen zu einzelnen Kompetenzen auch noch nicht zu eindeutigen Auspr gungen verdichtet werden sondern zeigen Tendenzen auf Dazu tr gt auch bei dass Unternehmen wegen unterschiedlicher T tigkeitsschwerpunkte unterschiedliche Vorstel lungen von Software Engineering haben Die Ent wicklung von Software f r Banken und Versiche rungen hat etwa auch Auswirkungen auf die er warteten Kompetenzen im Bereich Softwaretest Nachfolgend werden wesentliche Ergebnisse der Untersuchung dargestellt eine detaillierte Diskus sion findet sich in Claren 2012 8 1 Vorgehensmodelle Bei Vorgehensmodellen gibt es eine Tendenz hin zu umfangreichen theoretischen Kompetenzen So erwarten die Befragten sowohl bei agilen als auch bei plan getriebenen Modellen eher Kompetenzen die sich mit Erkl ren klassifizieren lassen Eine gute theoretische Basis ist hier wichtig da die Vor gehensmodelle meist unternehmensspezifisch an gepasst sind und daf r bei Neueinsteigern eine Einarbeitung erforderlich ist Lediglich bei testge triebener En
71. den Vorteil dass man alle Variablen auch per Referenz int wert bergeben kann Da so leider auch Arrays bergeben werden k nnen geht der intuitive Vor teil schnell verloren Weiterhin kann in C auch auf eine Kopiersemantik gesetzt werden wenn z B Arrays in ein struct ein gebettet sind Dieser Ansatz wird zwar zun chst als intuitiver von Studierenden angesehen f hrt aber schnell zu Problemen wenn eine Verkn pfung mit der Referenzsemantik notwendig wird Generell sollte deshalb auf die Kopiersemantik in der Grundausbildung in C verzichtet werden Gerade in C ist die Verlockung sehr gro f r An f nger berfl ssige aus Sicht eines begeisterten C Nutzers aber sehr interessante Sprachkonzepte wie Funktionszeiger und Makros durchzunehmen was verpflichtend durchgef hrt f r viele Studierende im ersten Semester zu gro en Verst ndnisproble men f hrt Eine verbreitete besondere Lernumgebung f r C existiert nicht Mit der SDL Library SDL besteht zwar die M glichkeit sehr schnell Spiele zu entwi ckeln aber die Lernkurve ist beim Einstieg recht hoch Die hier dokumentierte Lehrveranstaltung wurde von vielen verschiedenen Lehrenden hintereinan der gehalten wobei die plumpe Aussage Beim ersten Mal h lt ein Dozent eine Lehrveranstaltung haupts chlich f r sich selbst einen Wahrheitswert enth lt da didaktische Erfahrungen aufgebaut werden m ssen Gerade die Beobachtung dass der bergang vom Lesen
72. der umgesetzten Funktionalit t also f r die Produktivit t einzuf hren Weiterhin besteht nat rlich die M glichkeit auch die Einhaltung des gew hlten Vorgehensmodells die Erstellung und Befolgung eines Projektplans oder auch Softskills wie z B die Teamf higkeit zu bewerten bzw letzte re evtl durch Peer Assessments Race et al 2005 bewerten zu lassen Insgesamt bietet das vorge schlagene Bewertungsraster gen gend Flexibilit t um mit wenig Aufwand an die Lernziele vieler Softwaretechnik Lehrveranstaltungen angepasst werden zu k nnen Betrachtung der Testg tekriterien Die in diesem Beitrag vorgestellte Kombination von Bewertungsverfahren erreicht eine gute berde ckung der eingangs genannten Testg tekriterien A Spillner H Lichter Hrsg SEUH 13 Da die Bewertung des vorgeschlagenen Program miertestats automatisiert ber die zu durchlaufen den Testf lle erfolgen kann ist es ein sehr objekti ves Verfahren Es misst zudem genau die Leistung die auch gemessen werden soll n mlich die F hig keit ein gegebenes Problem innerhalb eines be schr nkten Zeitraums in ein passendes Programm umzusetzen Es gibt sowohl Studierenden als auch Lehrenden ein hilfreiches Feedback bei der Ein sch tzung der Programmierkenntnisse und ist zu dem noch g nstig da automatisiert durchf hrbar Auch eine gewisse Skalierbarkeit ist gegeben so lange gen gend gleichzeitig verf gbare Arbeits pl tze in einem oder mehre
73. der unge bte Studierende als ersten Quali t tsaspekt m glicherweise einfach ein Synonym f r das Messziel eintragen z B Verst ndnis Damit ist in diesem Schritt jedoch nichts gewonnen Der Stu dierende f llt die nachfolgenden Felder aus und kommt dennoch nicht zum erwarteten Ergebnis und ist entt uscht Damit dieser Fall nicht eintritt bietet unser Editor dem Studierenden gezielte Hilfestellung A Spillner H Lichter Hrsg SEUH 13 Durch kontextabh ngige konkret formulierte Frage stellungen wird der Anwender durch das Abstraction Sheet gef hrt Auch wenn der Hauptgrund der nicht erfolgreichen Anwendung des Abstraction Sheets auf Unverst ndnis des zugrundeliegenden Konzeptes zur ckzuf hren ist so kann eine derart gef hrte wiederholte Anwen dung zur Durchdringung des Konzeptes f hren bzw beitragen Der smarte GQM Editor Die Inhalte der Quadranten 1 bis 4 sind abh ngig von einander Inhalte werden von Quadrant zu Quadrant weitergegeben und verarbeitet Z B Hat der Anwen der in Quadrant 1 das Qualit tsziel auf zwei konkrete Faktoren heruntergebrochen so tauchen diese beiden Faktoren mit einer zus tzlichen Statuseinsch tzung genauer Ausgangshypothese im zweiten Quadran ten wieder auf Dieses Beispiel zeigt zwei Ebenen auf denen der Anwender agieren muss um das AS aus zuf llen Zum einen muss er einen kreativen Schritt t tigen und das Q Ziel konkretisieren dabei muss er genau wissen was ge
74. die von den Studierenden bis etwa einen Tag vor der Lehrveranstaltung online zu bearbeiten sind Bei den Aufgaben handelt es sich um allge meine Verst ndnisfragen aber auch inhaltliche 18 Fragen so dass die Lehrenden merken ob die Stu dierenden die Texte tats chlich gelesen und die entsprechenden Fach Kompetenzen erworben ha ben Die Studierenden k nnen sich die Zeit f r die Erarbeitung des Stoffes und die Bearbeitung der Aufgaben frei einteilen Sie k nnen die Zeiten so w hlen dass sie den Stoff am besten aufnehmen k nnen Erstes Feedback der Studierenden Die Lehrenden erhalten durch die Beantwortung der Aufgaben ein Feedback ber die Punkte des Stoffes die die Studierenden verstanden haben aber auch ber die Themen die den Studierenden noch Schwierigkeiten bereiten Die Lehrenden schauen sich die L sungen der Aufgaben kurz vor der Lehrveranstaltung an und k nnen so Just in Time die Inhalte der Lehrveranstaltung dem Kenntnisstand der Studierenden anpassen Damit lehren wir nicht mehr was wir meinen lehren zu m ssen sondern unsere Studierenden teilen uns mit wo sie Lehre ben tigen Lehrveranstaltung In der Lehrveranstaltung gehen die Lehrenden auf die Fragen und Probleme der Studierenden ein Dabei k nnen Sie die Antworten der Studierenden verwenden so dass diese sich direkt angesprochen und in ihren Problemen ernst genommen f hlen Weitere Vorteile Antworten der Studierenden di rekt zu verwe
75. einer Objektleiste so dass ber einen Rechtsklick deren Methoden ausf hrbar sind Durch einen Doppel klick auf ein Objekt werden alle Objektvariablen mit Namen und Werten angezeigt nderungen ber Methodenaufrufe werden auch in die ange zeigten Objektvariablen bernommen Hat eine Objektvariable eine Klasse als Typ kann auch wei ter in diese Objekte hineingeschaut werden Blue bietet einen einfachen Debugger der wie blich ber Break Points die schrittweise Ausf hrung und berpr fung von Programmen erm glicht Als weitere Besonderheit bietet Blue eine Konsole das Code Pad mit dem Java als Skriptsprache ge nutzt werden kann Anweisungen werden hier direkt eingetippt und ausgef hrt Weiterhin sind Ausdr cke eingebbar deren Ergebnisse sofort aus gegeben werden Handelt es sich hierbei um Ob jektreferenzen k nnen diese in die Objektleiste gezogen und weiter analysiert werden Der Editor von BlueJ ist recht einfach gehalten unterst tzt aber die sinnvolle automatische Code Formatierung und die Generierung von Java Doc Alle nderungen werden unmittelbar abgespei chert Der Compiler gibt nur jeweils die erste Feh lermeldung aus um nicht mit teilweise unver st ndlichen Folgefehlern zu verwirren Zusammen mit Blue werden bereits einige Beispie le geliefert die den didaktischen Ansatz unterst t zen dass Anf nger zun chst spielerisch lernen Objekte zu erzeugen und deren Methoden auszu f hren Ein bek
76. einzelnen Spezialfall ganz feingranular zu be schreiben Daher sind die an der Entwicklung be teiligten Personen immer wieder in der Situation eigenverantwortlich die richtigen Entscheidungen zu treffen Das Vorgehen muss pragmatisch sein Einerseits muss im Sinne der Vorgaben gearbeitet werden andererseits sollte der Aufwand in einem vertretbaren Ma bleiben Diese Abw gung ist in der Praxis sehr wichtig Die Studierenden machen eine Projektplanung ohne dass zun chst detaillierte Vorgaben zu den erforderlichen Schritten wie die zu erstellenden und abzugebenden Arbeitsprodukte vorhanden sind Auch zu zeitlichen Zusammenh ngen im Projekt ist ihnen au er den Pr senzterminen und dem n chsten Abgabetermin nichts bekannt Nach der ersten Abgabe erhalten sie alle weiteren Abga betermine mit den Arbeitsprodukten Die manch mal dadurch notwendige berarbeitung der Pla nung wird zusammen mit den anderen Arbeits produkten nach der Anforderungs nderung abge geben Durch die geforderte Planung der Arbeitspakete ist eine intensive Besch ftigung mit Inhalt und Dauer der erforderlichen Schritte und deren Abh ngigkei ten unerl sslich Diese Herangehensweise erscheint vielen Studierenden zun chst sehr herausfordernd weil die Freiheitsgrade in vorherigen Studienab schnitten eher gering sind Durch diese Herausfor derungen haben die Studierenden die M glichkeit der Weiterentwicklung ihres Verst ndnisses der Software Entwic
77. entspricht drei Leistungspunkten beide Module haben dem nach einen Umfang von sechs Leistungspunkten Formal sind sie jeweils mit 2 SWS Vorlesung und 2 SWS bung ausgewiesen 2 3 Algorithmen vs Interaktive Systeme Einen imperativen Einstieg und eine Aufteilung der Sprachkonzepte von Java auf mehr als ein Se mester vorausgesetzt gibt es weitere Entwurfs m glichkeiten die ebenfalls die strategische Aus richtung mehrerer Module betreffen Ein Ansatz Die Programmierausbildung legt einen Schwerpunkt auf Algorithmen und Datenstrukturen A amp D die vor allem dazu bef higen soll beliebig gro e Datenmengen so effizient wie m glich verar beiten zu lassen Dieser klassische Ansatz setzt einen Schwerpunkt der vor allem f r die Systemprogrammierung n tz lich ist beispielsweise im Umfeld von Datenbanken und Betriebssystemen und bei der Entwicklung von Bibliotheken und Frameworks f r Server 40 Systeme Aber auch in Anwendungsfeldern wie beispielsweise der Klimasimulation oder der Mo dellierung und Verarbeitung von Proteinstrukturen fallen gro e Datenmengen an und erfordern ver tieftes Wissen zu A amp D Alternative Es wird ein fr her Fokus auf Schnitt stellen gelegt sowohl auf grafische Benutzungs schnittstellen als auch auf den Entwurf von Klas senschnittstellen die von Details einer Implemen tierung abstrahieren Kapselung Modularisierung Die meisten Anwendungssysteme mit denen Nicht Informatiker he
78. erfolgen Das gleiche A Spillner H Lichter Hrsg SEUH 13 Muster findet sich bei einer Frage zur Aufnahme eines neuen Testfalls in eine Testsuite siehe Bei spiel In einem anderen Quiz soll ein Vorschlag f r eine neue SIL Iterator Hierarchie begr ndet werden Dieses Quiz besteht nur aus einer Frei textfrage zur m glichen Begr ndung Beispiel Nachdem wir nun den allgemeinen Aufbau der Quiz beschrieben haben wollen wir ein Quiz ge nauer vorstellen Das Quiz bereitet die Vorlesung zum Thema Test berdeckung vor und als Soft waresystem kommt die C Standardbibliothek libstdc der Gnu Compiler Collection GCC zum Einsatz Die Einleitung zum Quiz stellt GCC und libstdc kurz vor und leitet die Studierenden dann zur Testsuite des find Algorithmus der libstdc Die dazugeh rige Frage stellt dann ei nen neuen Testfall vor und die Studierenden m ssen sich in einer Auswahlfrage entscheiden ob der neue Testfall in die Testsuite aufgenom men werden soll oder nicht In einer zweiten Fra ge muss diese Entscheidung dann begr ndet werden Um die Entscheidung zu treffen und zu begr nden ist es notwendig sich zu berlegen was die Kriterien f r die Aufnahme eines neuen Testfalls sind was von den vorhandenen Testf l len abgedeckt wird und was der neue Testfall tes tet Somit machen sich die Studierenden zum ei nen Gedanken ber die Kriterien f r eine gute Testsuite und zum anderen erleben sie durch das Nav
79. gliche positi ve und negative Aspekte bez glich der Anwend barkeit innerhalb von praktischen Softwaretechnik Lehrveranstaltungen Dazu fasst die folgende Ta belle neben den Bewertungsverfahren auch die jeweils wichtigsten positiven und negativen Aspek te zusammen Bewertungsver Kurzbeschreibung St rken Gefahren fahren Prakt Leistungs Die Studierenden bear Kleinere Aufgaben zu einer Meist kein unmittelbarer nachweise beiten vorgegebene spez Fragestellung mit Bezug zum Projekt erh hte bungsaufgaben bungsaufgaben meist berschaubarem Ar Gefahr des Abschreibens beitsaufwand gleicher Aufgaben Vortr ge Die Studierenden pr sen St rkung der Pr sentati Evtl berdeckt der Vor tieren ihr Vorgehen oder onskompetenz Vertiefung tragsstil inhaltliche St rken 106 A Spillner H Lichter Hrsg SEUH 13 ihre Ergebnisse des Fachwissens im entspr Themenbereich ggf Selbst reflektion durch Vergleich mit anderen Studierenden oder Schw chen hoher Zeitaufwand m gl Spezia lisierung auf das Themen gebiet Benotung und Nachfragen m glich Kolloquien Die Studierenden wer Nachhaken und Kl ren von Bei gro en Gruppen ent den von den Betreuern Verst ndnisfragen m glich sprechend hoher Zeitauf zu ihrem System befragt wand oft in Verbindung mit Vortr gen durchgef Bewertung des Das abgegebene System Direkter Bezug zum Lern Kriterienkata
80. hingegen kein gro er Mehraufwand Die Schwierigkeiten liegen haupts chlich bei der Auswahl der Softwaresysteme und Fragen Es ist nicht leicht zu einem bestimmten Thema oder Problem ein Softwaresystem zu finden das das Problem veranschaulicht und gleichzeitig nicht zu komplex ist um die Studierenden nicht zu ber fordern Das spiegelt sich auch in der unterschied lichen Qualit t unserer Quiz wieder Positiv f r die Lehrperson in der Vorlesung ist dass die Studierenden ein reges Interesse an den Antworten zum Quiz haben Gerade bei l n geren Vorlesungen wenn die Konzentration der Studierenden nachl sst hat das Besprechen der Fragen und Antworten einen positiven Effekt auf die Aufmerksamkeit Des Weiteren war es manchmal m glich verbreitete aber falsche Vor stellungen der Studierenden zu erkennen und entsprechend darauf einzugehen Schlussfolgerungen Es war unser Ziel die Studierenden Erfahrungen mit realen Softwareprojekten machen zu lassen damit sie die Sinnhaftigkeit der in der Vorlesung vorgestellten Methoden besser verstehen Dazu haben wir die Methode des JiTT in Form von Quiz eingesetzt Die gr te Herausforderung bei unserem Einsatz von JiTT ist das Finden von Softwaresystemen an denen man die in der Vor lesung vorgestellten Konzepte verdeutlichen kann Eine systematische empirische berpr fung dass die Studierenden mit Hilfe der Methode ge gen ber einer rein klassischen Vorlesung bessere Lerne
81. http developer android com guide practices performance html 93 Backlog Queue Analysis Development Review Live Maximum WIP i 1 2 1 i In Progress Done Todo In Prog ress Done In Pr Done u ei Abbildung 2 Schematische Darstellung des Kanban Boards des Praktikums mit den einzelnen Phasen und Limits Teamgr e von mindestens 10 Studenten f hrt dies zumindest vor bergehend zu einiger Passivit t Da Kanban weniger Wert auf Iterationen legt bzw sogar ganz ohne diese ausk me versprachen wir uns die initialen Besprechungen etwas entzerren zu k nnen Das Ende der Iterationen hingegen stellte den Kun den vor die Herausforderung Funktionalit ten in ei nem Umfang berpr fen zu m ssen den er nicht be w ltigen konnte Daher war das Feedback des Kun den ber die Qualit t des Geleisteten mitunter eher unscharf Durch einen gleichm igeren Fluss fertig gestellter Funktionalit t hofften wir dieses Problem entsch rfen zu k nnen Dieses konnten wir schlie lich durch vorhergehende Reviews durch Team und Teamleiter beheben Basierend auf den Erfahrungen bisheriger Praktika wurde der grunds tzliche Arbeitsfluss in einem in itialen Kanban Board festgehalten Das initiale Board enthielt die folgenden sechs Phasen Backlog Input Queue Analysis Development Review und Live Ab bildung 2 Das Backlog enth lt die Ideen des Kunden die in noch nicht ausreichend genauer Form
82. kann diese Vorlage verwenden um seine Ausgangshy pothese zu verfassen oder eine eigene formulieren s Abb 5 hnlich l sst sich mit Quadrant 3 verfahren siehe Abb 5 jedoch nicht mit Quadrant 4 Die Einflussfak toren zuverl ssig aus den resultierenden Einflusshypo thesen zu extrahieren ist aufgrund von sprachlichen Abweichungen und Eigenarten schwierig Letztendlich l sst sich diese zweite Unterst tzungs stufe nur f r den zweiten Quadranten Ausgangshy pothese und dritten Quadranten Einflusshypothese einschalten Quadranten 1 und 4 k nnen lediglich die erste Unterst tzungsstufe einsetzen A Spillner H Lichter Hrsg SEUH 13 Da m glicherweise die generierte Antwort nicht zu dem aktuellen Messprojekt passt l sst sich diese gene rierte Antwort wie ein normales Textfeld bearbeiten und auch l schen In Abb 5 hat der Anwender die zweite Ausgangshypothese angepasst Der Messplan Nachdem der Anwender mithilfe des Abstraction Sheets Einflussfaktoren der Qualit tsfaktoren und zu geh rige Einflusshypothesen aufgestellt hat folgt der Schritt der experimentellen berpr fung eines sol chen Zusammenhangs Der sogenannte Messplan for dert den Anwender auf verschiedene Auspr gungen des Einflussfaktors zu ermitteln und dann zu ber pr fen wie sich der Qualit tsfaktor verh lt Auf diese Weise soll die Einflusshypothese validiert bzw falsche Annahmen aufgedeckt werden Die beiden Faktoren werden automati
83. komplexes Zusammenspiel von statischen Konzepten zur bersetzungszeit und dynamischen Konzepten zur Laufzeit Da Folien eher statisch sind sind sie nicht gut geeignet die dynamischen Aspekte der Programmierung aufzu zeigen Animierte Folien k nnen diese Schw che teilweise mildern sind aber in ihrem Ablauf meist ebenfalls starr festgelegt Alternative Die Dozentin setzt neben ihren Folien auch eine Entwicklungsumgebung hier englisch abgek rzt mit IDE f r die behandelte Program miersprache ein die sie live in der Vorlesung be nutzt Idealerweise gibt es keinen Vorlesungster min in dem nicht live programmiert wird Ein entscheidender Vorteil einer fiir alle sichtbaren Programmierumgebung ist dass Fragen aus der Zuhorerschaft direkt mit lauffahigem Code beant wortet werden k nnen Dies erh ht den m glichen Interaktionsanteil einer Vorlesung erheblich Wenn die Studierenden h ufiger erfahren haben dass ihre Fragen bei Bedarf direkt per Live Programmierung beantwortet werden bekommen sie mehr Mut f r Verst ndnisfragen Das Konzept des Show Programming wird in Schmolitzky 2007 als ein Pedagogical Pattern beschrieben Konsequenzen Der Dozent sollte die Sprache und die IDE gut beherrschen muss aber nicht perfekt darin sein Die IDE muss f r den Einsatz in Vortr gen geeignet sein insbesondere sollte sie sowohl die statischen Programmtext als auch die dynami schen Aspekte Ausf hrung der Programmierung visu
84. letzte Rolle ist die eines technischen Experten Dieser ist Ansprechpartner bei Ein Beispiel f r ein entwickeltes Produkt http www3 uni bonn de Pressemitteilungen 299 2009 A Spillner H Lichter Hrsg SEUH 13 technischen Fragen des Teams und hat Wissen in den einzusetzenden Technologien und Projekten Anwendung von Kanban Das Thema des Praktikums in 2011 war die Entwick lung von Analysen ftir Designprobleme von Java Quell code f r die Android Plattform Insgesamt nahmen zehn Studenten an dem Praktikum tats chlich teil nachdem urspr nglich 16 Pl tze vergeben waren Als Basis gab es schon ein selbstentwickeltes Framework mit dem statische Codeanalysen f r Java geschrie ben werden konnten Dieses musste im Rahmen des Praktikums erweitert werden Ebenso mussten die Studenten erfassen was hinsichtlich vor allem Per formanz und Speicherbedarf problematischer Code auf der Android Plattform ist Daf r wurden im Laufe des Praktikums z B die Entwickler Richtlinien von Google zu Rate gezogen Zur Vorbereitung und Anwendung von Kanban als Entwicklungsprozess wurden die fr heren Arbeits schritte in fr heren Praktika analysiert und die Erfah rungen festgehalten Zu den Bestandteilen fr herer Praktika die wir f r erhaltenswert befunden haben geh ren wie bereits beschrieben das Pair Program ming die Rollenverteilung unter den Mitarbeitern sowie wie weiter unten beschrieben die Differenzie rung zwischen Stori
85. program quality Commun ACM 49 8 S 90 95 Schiedermeier R 2010 Programmieren mit Java Pearson Studium Schmolitzky A 2004 Objects First Interfaces Next or Interfaces Before Inheritance OOPSLA 04 Companion Educators Symposium Vancouver BC Canada ACM Press Schmolitzky A 2006 Teaching Inheritance Concepts with Java Principles and Practices of 45 Programming in Java PPPJ Mannheim Germany ACM Press S 203 207 Schmolitzky A 2007 Patterns for Teaching Software in Classroom EuroPLoP 2007 Irsee Germany UVK Konstanz Ventura P et al 2004 Ancestor worship in CS1 on the primacy of arrays OOPSLA 04 Companion Educators Symposium Vancouver BC Canada ACM Press Walker H M 2010 The role of programming in introductory computing courses ACM Inroads 1 2 S 12 15 Wegner P 1987 Dimensions of Object Based Language Design OOPSLA 87 Orlando Florida ACM SIGPLAN Notices Vol 22 12 46 A Spillner H Lichter Hrsg SEUH 13 Programmiergrundausbildung Erfahrungen von drei Hochschulen Stephan Kleuker Hochschule Osnabr ck s kleuker hs osnabrueck de Zusammenfassung Die Programmierausbildung bleibt ein Grundstein jedweder Informatik Ausbildung und bildet das Fundament der meisten weiterf hrenden Informa tik Themen ber die Art und Weise wie Pro grammierung am besten gelehrt werden kann wird wahrscheinlich seit Beginn dieser Lehre ges
86. referate pdf letzter Zugriff Juli 2012 Sommerville I 2010 Software Engineering 9th ed Addison Wesley Stangl W 2002 Lernen in Gruppen Werner Stangls Arbeitsbl tter verf gbar unter http www stangl taller at ARBEITSBLAETTER LERNEN Gruppenlernen shtml letzter Zugriff Juli 2012 Stoyan R amp Glinz M 2005 Methoden und Tech niken zum Erreichen didaktischer Ziele in Soft ware Engineering Praktika Lohr amp Lichter Hrsg Software Engineering im Unterricht der Hochschulen dpunkt van der Duim L Andersson J amp Sinnema M 2007 Good practices for Educational Software Engineering Proceedings of the International Conference on Software Engineering IEEE Wikstrand G amp B rstler J 2006 Success Factors for Team Project Courses Proceedings of Inter national Conference on Software Engineering Education and Training A Spillner H Lichter Hrsg SEUH 13 Forschung mit Master Studierenden im Software Engineering Marc Hesenius Universit t Duisburg Essen marc hesenius paluno uni due de Dominikus Herzberg Hochschule Heilbronn dominikus herzberg hs heilbronn de Zusammenfassung Master Studierende bringen oft viel Potential mit an die Hochschule Im Vergleich zu Bachelor Studierenden haben sie in der Regel vollig andere Sicht und Herange hensweisen entwickelt zum Teil aufgrund des h heren Alters aber ma geblich wegen der M glichkeit bereits einige Jahre aufse
87. rer Stufe unterrichtet werden sollten und wie die Kenntnis se der Bachelor und Master Absolventen von der Industrie beurteilt werden Dazu hatten die Fir menvertreter der teilnehmenden IT Firmen folgen de Aussage zu bewerten Agile development should be an integral part of the Computer Science curriculum Zur Auswahl standen folgende Antwort Optionen von Stimme vollstandig zu bis Stimme gar nicht n zu 95 der teilnehmenden Firmen stimmen der Aus sage zu Stimme zu 49 Stimme vollst ndig zu 46 Andererseits geben die Unternehmen auf die Frage ob die Studienabg nger auf Bachelor bzw Master stufe gen gend Kenntnisse in agilen Methoden mitbringen mit klarer Mehrheit an dass dies nicht der Fall ist Master Stufe 58 Bachelor Stufe 68 Somit sollte der Anspruch der Praxis an die Hoch schulen ernst genommen werden und die Ausbil dung an die neuen Anforderungen angepasst wer den Dabei stellt sich die Frage was die Hochschu len in der Ausbildung ndern m ssen um den neuen Anforderungen gerecht zu werden Dazu betrachten wir Anforderungen die agile Me thoden an den einzelnen aber auch an das Team und die Organisation stellt auf drei verschiedenen Ebenen 1 Individuelle Ebene Hier geht es vornehmlich darum welche agilen Engineering Practices ein Software Ingenieur beherrschen sollte Clean Code Test Driven Development Au tomation Craftsmanship um nur einige Beis
88. rigen Kapitel zu finden sind Letzten Endes ist dieser didaktische Ansatz analog zum Wasserfallmodell im Software Engineering mit vergleichbaren Vor und Nachteilen So erkauft man sich mit dem Vorteil der klaren Struktur den gewich tigen Nachteil dass Querbeziehungen zwischen Lern inhalten aus fr hen und aus sp ten Lehr Lernphasen erst sehr sp t aufgedeckt werden Des Weiteren blei ben bei der benden bzw praktischen Anwendung des Gelernten die Auswirkungen von Entscheidungen aus fr hen Phasen relativ lange unklar f r die Studieren den da der Round Trip ber den gesamten Software Life Cycle sich oft ber mehrere Wochen oder Mo nate hinzieht und die ausf hrbaren Ergebnisse erst entsprechend sp t vorliegen Iterativ inkrementelle Vermittlung von Software Engineering Wissen Aus diesem Dilemma heraus entstand die Idee den Grundgedanken der heute in der Praxis vorherrschen den Rupp u Joppich 2009 iterativen inkrementel len Entwicklung auch auf den Lernprozess f r ange hende Softwareingenieure zu bertragen Zur Umsetzung dieses didaktischen Ansatzes vermit telt der seminaristische Unterricht genau diejenigen theoretischen Grundkenntnisse die f r das jeweilge Inkrement erforderlich sind Jede Lehr Lerneinheit ber hrt somit die verschiedenen Kerndisziplinen der Entwicklung mit ggf unterschiedlicher Gewichtung also mehrere Entwicklungsschritte mehrere UML Diagrammtypen mehrere Implementierungskonzepte
89. sagt das Parametrisieren von Typen mit Typen im Falle von Sammlungen eben das Parametrisieren von Sammlungen mit ihren Elementtypen Tats ch lich ist eine vollst ndige Behandlung dieses The mas nicht n tig wenn der ben tigte Teilaspekt intuitiv verst ndlich ist dass f r eine Sammlung von Objekten der Typ der Elemente auch deklariert werden muss In SE1 lassen wir die Teilnehmer in der zweiten H lfte des Semesters kleinere Probleme mit Hilfe des JCF l sen ohne vorab explizit die Generizit t von Java einzuf hren In den bisherigen sieben Durchf hrungen des Moduls ist es dabei nicht zu Problemen gekommen Interfaces hingegen sollten f r eine kompetente Nutzung des JCF bereits bekannt sein Dies leitet ber zur n chsten inhaltlichen Alternative 43 4 2 Interfaces vor Vererbung Interfaces sind ein Sprachmechanismus in Java der es erm glicht Schnittstellen explizit zu beschreiben Schnittstellen spielen eine zentrale Rolle in der objektorientierten Programmierung und Modell ierung siehe u a die zentrale Aussage Program to an interface not an implementation im Buch der Gang of Four Gamma et al 1995 Aber Schnittstel len sind nicht nur f r die Objektorientierung zent ral sondern vielmehr ein Schl sselkonzept bei der Modularisierung gro er Softwaresysteme Weiter hin erlauben sie eine Diskussion dar ber dass eine Spezifikation lediglich einen Teil der zu erbringen den Dienstleistungen beschreib
90. und Lernen von Software Engineering in seiner gesamten Bandbreite besser verstehen zu k nnen und im Rahmen der Hochschullehre zielge richtet Rahmenbedingungen zu schaffen die das Trainieren von Kompetenzen optimal erm glichen Bevor es aber m glich ist sich dar ber Gedan ken zu machen wie man am besten Kompetenzen trainieren kann stellen sich folgende Fragen Was meint berhaupt Kompetenz Wozu dient eine Kompetenzbeschreibung Wie beschreibt man Kompetenzen sinnvoll Was genau kennzeichnet einen guten Software Ingenieur Welche Kompetenzen soll ein Soft ware Ingenieur haben 3 Was ist Kompetenz Der Kompetenzbegriff ist relativ unscharf Es gibt zahlreiche Definitionen was unter Kompetenzen verstanden werden kann Erpenbeck 2007 schl gt eine Einteilung in per sonale aktivit ts und umsetzungsorientierte fach lich methodische sowie sozial kommunikative Kompetenz vor Die Definition nach Erpenbeck erm glicht jedoch keine eindeutige Zuordnung einzelner Kompetenzen zu einer dieser Arten Spricht man allgemein von einer Kompetenz um z B eine bestimmte Problemstellung l sen zu k nnen treten verschiedene Kompetenzarten in Kombination auf Um etwa Anforderungen erfas sen zu k nnen bedarf es sowohl fachlich metho discher z B Anforderungen korrekt beschreiben als auch sozial kommunikativer Kompetenzen z B Kommunikationsf higkeit Teamf higkeit Auch Erpenbeck 2007 S XII kommt z
91. und erfordern gem Lehrerfah rungen weniger Unterst tzung Auch die eigentliche Durchf hrung und anschlie ende Interpretation wer den nicht von unserem GQM Editor unterst tzt Das Abstraction Sheet Das Abstraction Sheet AS bietet dem Anwender eine streng definierte Struktur um methodisch und zielsi cher charakterisierende Fragen zu einem gegebenen Messziel abzuleiten Dabei ist die Ausf llreihenfol ge der Quadranten vorgegeben und bildet ein U Je der Quadrant verlangt dem Anwender ab bestimmte Aspekte des Messziels anzugeben Auf diese Weise wird der abstrakte Qualit tsaspekt des Messziels in Qualit tsfaktoren konkretisiert beeinflussende Fak toren Einflussfaktoren identifiziert und zugeh rige Einflusshypothesen aufgestellt Begonnen wird ein AS mit dem Eintragen des Messziels in Facettenform obe rer Teil von 3 welche aus dem vorigen Prozessschritt 2 bernommen wurde Der Ablauf im Detail 1 Oben links Der Qualit tsaspekt wird auf konkre te Eigenschaften des Betrachtungsgegenstandes konkretisiert sogenannte Qualit tsfaktoren Wel che Merkmale machen den Qualit tsaspekt in die sem Projekt ganz konkret aus In Fall von Abb 3 Verst ndlichkeit von Quellcode bedeutet f r den Ausf llenden z B die Verzweigungstiefe 2 Unten links Zu jedem Qualit tsfaktor wird eine Ausgangshypothese aufgestellt wie es zu Messbe A Spillner H Lichter Hrsg SEUH 13 verfeinerte Ziele Legende Erge
92. und ggf mehrere Werkzeuge Daf r wird in einem In krement jeder dieser Lernbereiche jeweils nur um ein kleines St ckchen Information und Wissen erweitert Parallel dazu wird im Praktikum ein kleines System iterativ und inkrementell modelliert und entwickelt Jedes Inkrement deckt eine komplette Iteration durch den Software Life Cycle ab Die initialen Inkremen te sind zun chst sehr klein und einfach und mit viel detaillierter Anleitung hinterf ttert Je weiter das Pro jekt fortschreitet umso anspruchsvoller werden die Inkremente und die daf r ben tigten Werkzeuge und Technologien Essenziell dabei ist dass am Ende je der Iteration ein lauff higes System entsteht anhand dessen sich die Zusammenh nge zwischen den ein zelnen Disziplinen verwendeten Technologien und angewendeten methodischen Vorgehensweisen unmit telbar erkennen lassen Damit die Studierenden ein Verst ndnis daf r ent wickeln dass sie im Rahmen des Lehrkonzeptes le diglich eines von mehreren m glichen Vorgehensmo dellen durchf hren wurde entgegen der inhaltlichen Aufteilung in der Modulbeschreibung die Themen Pro 73 Use Case 1 Abl ufe 1 Abbildung 2 Einfaches Inkrement 1 zessmodelle und agile Vorgehensmodelle aus dem 4 Semester in das 3 Semester vorgezogen Im Gegen zug wurden die Themen der Aufwandssch tzung und des Projektmanagements vom 3 in das 4 Semester verlagert Struktur des zentralen Beispiels Kern des Lehrkonzeptes is
93. und in Hinblick auf die Lehre angepasst M gge u a 2004 In der Vergangenheit haben bis zu 16 Studenten in einem Team gearbeitet welches A Spillner H Lichter Hrsg SEUH 13 dazu von bis zu drei Lehrkr ften die ganze Zeit betreut wird Dem Praktikum unmittelbar vorgelagert ist ein klei ner Workshop von bis zu drei Tagen F r diesen vertie fen sich die Studenten in die einzelne Technologien die im Praktikum genutzt werden und arbeiten diese in Form von Seminarvortr gen und Ausarbeitungen auf Neben den Vortr gen wird dieser Workshop vor allem zur Teambildung genutzt Im Normalfall ha ben die teilnehmenden Studenten vorher noch nicht zusammengearbeitet Daher sind teambildende Ma nahmen in der Regel fest indem Workshop eingeplant Dieser Workshop hat sich im Laufe der Jahre als n tz lich erwiesen um im Praktikum direkt gemeinsam und produktiv als Team arbeiten zu k nnen Der Fokus des Blockpraktikums ist es einen Einblick in die reale Softwareentwicklung zu geben Dazu ist das Praktikum als Vollzeit Pr senzpraktikum ausge legt d h dass das Team f r vier Wochen mit je acht Stunden pro Arbeitstag zusammen arbeitet Dies hat f r die Studenten den Vorteil das neben dem norma len Arbeitstag keine berstunden oder Heimarbeiten anfallen Als eine wichtige Arbeitstechnik hat sich in diesen Praktika das Pair Programming aus dem eXtre me Programming Beck u Andres 2004 etabliert Pair Programming bedeutet
94. unserer Erfahrung sind die agilen Techniken der individuellen Ebene am einfachsten zu vermitteln Dies liegt unserem Ermessen nach daran dass jeder Studierende einzeln daran arbei ten kann Darauf aufbauend k nnen dann die Techniken der agilen Entwicklung auf der Team Ebene vermittelt und erworben werden die sich vor allem aus den Management Praktiken zusammensetzen Diese As pekte lassen sich aus unserer Erfahrung heraus sehr gut in Gruppen und Projektarbeiten vermitteln Die Konzeption Organisation und Durchf hrung solcher Arbeiten ist aufwendig Sozusagen die Spitze der Kompetenzen der Agilen Entwicklung bildet die Werte Ebene Diese agilen Wertehaltungen wie sie im Agile Manifesto 6 be schrieben werden sind naturgem ss am schwie rigsten zu vermitteln Wir versuchen die agilen Werte punktuell immer wieder in den Unterricht einfliessen zu lassen oder ganz bewusst auch vorzuleben Bachelor und Master Ausbildung Aufgrund der sich schon fr h abzeichnenden zu nehmenden Bedeutung der agilen Entwicklungs methoden haben wir begonnen die grundlegenden Methoden und Techniken der agilen Software Ent wicklung in Form der genannten Management und Engineering Praktiken in das Bachelor Programm zu integrieren 10 11 Dies wird im Folgenden noch genauer erl utert Auf Master Stufe behandeln wir in unserem ge meinsamen Kurs Software Engineering and Archi tecture fortgeschrittene Themen der agilen Soft ware Entwic
95. verstanden haben Ein weiterer Vorteil von Spielen ist die gesteigerte Motivation und Lernbereitschaft der Studierenden Die initiale H rde die genommen werden muss um sich qualifiziert mit der Aufgabenstellung auseinanderzusetzen und dar ber diskutieren zu k nnen ist relativ niedrig Unterschiede in der Vorbildung der Studierenden kommen wenig zum tragen Selten werden einzelne Gruppen Mitglieder abgeh ngt und au en vorgelassen Zu guter Letzt sind massenweise geeignete und interessante Spiele samt deren Anleitungen verf gbar Auf diesen Fundus zur ckzugreifen spart das komplette Konzipieren einer Aufgabenstellung und erlaubt es dem Veranstalter sich auf die Umsetzung zu konzentrieren Anwendung Die Umsetzung besteht im Wesentlichen aus folgenden Schritten 1 Auswahl eines geeigneten Spiels a Die Regeln des Spiels m ssen einfach zu verstehen also nicht zu komplex sein b Das Spiel sollte Multiplayer f hig sein Somit k nnen die Teilnehmer in einem finalen Turnier gegeneinander antreten c Kann das Spiel als Client Server Architektur umgesetzt werden kann der Veranstalter einen zentralen Spielserver stellen der von allen Teilnehmern w hrend der Veranstaltungsdauer genutzt werden kann um gegeneinander anzutreten und zu testen d Es sollte relativ einfach m glich sein f r das gew hlte Spiel eine einfache k nstliche Intelligenz zu schreiben e Es sollte m glich sein ein vern nftiges graphisches User Int
96. werden motiviert durch die mobilisierten studentischen Kreativit ts Leis tungs und Begeisterungspotenziale Der Vorteil aktivierender Lehre ist die aktive Wissenskonstruktion durch die eigene Erfahrung der Lernenden Dies ist dem klassischen rezeptiven Lernen berlegen Aktivierendes Lernen als selbstorganisiertes Lernen soll die Studierenden zu einem h heren Grad an Selbstbestimmung und Selbstorganisation verhelfen Damit wird aber auch die bernahme h herer Verantwortung f r die individuellen Lern prozesse impliziert Faulstich 2012 und die Grundlage f r Prozesse des lebenslangen Lernens geschaffen Der im Folgenden vorgestellte didaktische An satz Just in Time Teaching in Software Engineering tr gt die dargestellten Aspekte aktivierender Lehre Just in Time Teaching Oben behaupteten wir dass durch das Just in Time Teaching die Lehrveranstaltung auf den Kopf gestellt wird Wie kommen wir dazu Beim Just in Time Teaching wird die Aufgabe des Lesens der Lehrinhalte nicht mehr durch die Lehrenden vor genommen Vorlesung sondern an die Studie renden bergeben Die Erstvermittlung des Stoffes wird damit an die Studierenden bertragen Selbststudium und Aufgaben Die Lehrenden geben den Studierenden zun chst einen oder mehrere Texte die zu den Lernzielen der n chsten Lehrveranstaltung passen zum Selbststudium Die Aktivierung der Studierenden geschieht durch zus tzlich erstellte webbasierte Aufgaben
97. 012 http www omg org spec SysML UML 2012 http www omg org spec UML Vigenschow U et al 2007 Soft Skills fiir Soft wareentwickler Vliet H van 2008 Software Engineering Vogt C 2012 Nebenlaufige Programmierung Wikipedia Kritischer Pfad 2012 http de wikipe dia org wiki Methode_des_kritischen_Pfades Zorner S 2012 Software Architekturen Doku mentieren und Kommunizieren A Spillner H Lichter Hrsg SEUH 13 SS a1 12 1 0 WARE nn ae zZ Programmierausbildung Eine softwaretechnische Programmierausbildung Axel W Schmolitzky Universitat Hamburg schmolit informatik uni hamburg de Zusammenfassung Eine solide Programmierausbildung bildet die Grundlage jeder softwaretechnischen Ausbildung Art und Umfang der Programmierausbildung k n nen jedoch sehr unterschiedlich sein je nach Schwerpunkt des jeweiligen Studiengangs In die sem Artikel werden auf verschiedenen Ebenen Alternativen diskutiert die f r die Gestaltung der einf hrenden Programmierausbildung bestehen und mit den Anforderungen abgeglichen die sich bei einer Schwerpunktsetzung auf die Software technik ergeben 1 Einleitung Programmieren Codieren geh rt zum Hand werkszeug jedes Softwaretechnikers und jeder Softwaretechnikerin Ludewig 2010 blicher weise qualifizieren sich Studierende f r software technische Herausforderungen ber ein Studium der Informatik oder eines Faches
98. 11 Erfahrungen bei der Lehre des Software Engineering Ludewig und B ttcher Hrsg Software Engineering im Unterricht der Hochschulen CEUR WS org 114 Metzger A 2003 Konzeption und Analyse eines Softwarepraktikums im Grundstudium Sie dersleben amp Weber Wulff Hrsg Software En gin im Unterricht der Hochschulen dpunkt M ller F amp Bayer C 2007 Pr fungen Vorberei tung Durchf hrung Bewertung In Kr ning F rderung von Kompetenzen in der Hoch schullehre Asanger Pichler R 2007 Scrum Agiles Projektmanage ment erfolgreich einsetzen dpunkt Predoiu L 2010 Didaktik und Bewertung in l n gerfristigen Teamprojekten in der Hochschul lehre Proceedings des 6 Workshops der GI Fachgruppe Didaktik der Informatik Race P Brown S amp Smith B 2005 500 Tips on Assessment Routledge Rausch A Hohn R Broy M Bergner K amp H ppner S 2008 Das V Modell XT Grundla gen Methodik und Anwendungen Springer Roloff S 2002 Hochschuldidaktisches Seminar Schriftliche Pr fungen verf gbar unter http www lehrbeauftragte net documents_pu blic SchriftlPruef_Roloff pdf letzter Zugriff Ju li 2012 Schubert Henning 2004 S Empfehlungen zur Vorbereitung und zum Vortrag eines Referates Studienwerkstatt der Universit t Bremen ver f gbar unter http www philosophie uni bremen de fileadmin mediapool philosophie Formulare Informationen empfehlungen_
99. 444u4snnnnsn nn nnnnnnnennnnnnnnnnnnnnnn 9 Timo Kamph Peter Salden Sibylle Schupp Christian Kautz Drei Feedback Zyklen in der Software Engineering Ausbildung durch erweitertes Just in Time Teaching 4444444444B0nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 17 Georg Hagel J rgen Mottok Martina M ller Amthor Software Engineering Projekte in der Ausbildung an Hochschulen Konzept Erfahr ngen und ldeen uu ee en a ee 27 Jens Liebehenschel Session 2 Programmierausbildung Eine softwaretechnische Programmierausbildung r4444444444nnnnnnennnnnnn 37 Axel W Schmolitzky Programmiergrundausbildung Erfahrungen von drei Hochschulen 47 Stephan Kleuker Analyse von Programmieraufgaben durch Softwareproduktmetriken 59 Michael Striewe Michael Goedicke Session 3 Agile Methoden im Unterricht Iterativ inkrementelle Vermittlung von Software Engineering Wissen 77 Veronika Thurner Vermittlung von agiler Softwareentwicklung im Unterricht cccccceeeeeeeeeeeeeeeeeeeees 79 Martin Kropp Andreas Meier Kanban im Universitatspraktikum Ein Erfahrungsbericht 4444 91 Jan Nonnen Jan Paul Imhoff Daniel Speicher Session 4 Zur Diskussion gestellt Muster der Softwaretechnik Lehre 2u424444444R RR Rnnn nennen nennen nennen nn nnne nennen 101 Valentin Dallmeier Florian Gross Clemens Hamm
100. 86 Der Einsatz von Metriken wird vielfach kritisch diskutiert Auf der einen Seite steht die Aussage dass ohne Messung keine Kontrolle m glich ist z B DeMarco 1986 und auf der ande re Seite die Erkenntnis dass die Messung das Ergebnis selber beeinflussen kann und viele Metriken gar nicht das messen was sie zu messen vorgeben z B Kaner u Bond 2004 Insgesamt kann der Einsatz von Soft waremetriken aber als etabliert betrachtet werden Nicht nur in der industriellen Praxis sondern auch in der Lehre werden Softwareprodukte entwickelt Es handelt sich hierbei zwar nicht um Produkte im konomischen Sinne aber doch um Artefakte de ren Eigenschaften mit denselben Metriken messbar sind Zudem ist der Begriff der Kontrolle in Form von Lernfortschrittskontrollen ein zentraler Bestandteil der Lehre Es erscheint daher sinnvoll Werkzeuge zur Unterst tzung der Lehre zu konzipieren mit denen Kennzahlen automatisch gewonnen und analysiert werden k nnen Dies ist insbesondere in E Learning und Blended Learning Szenarien wichtig in denen ei ne teil automatisierte F hrung durch den Lernstoff angeboten werden soll und daher nicht immer ein Lehrender zur Verf gung steht der die Leistungsf hig keit seiner Studierenden einsch tzt und ihnen passen de bungsaufgaben zuweist Um hier eine Automa tisierung zu erreichen sollte untersucht werden wie A Spillner H Lichter Hrsg SEUH 13 Softwaremetriken zur Beobachtung des
101. 9 Erfahrungen bei der Lehre des Software Engineering in Jaeger U Hrsg und Schneider K Hrsg Softwareengineering im Unterricht der Hochschulen SEUH 11 Hanno ver 2009 dpunkt Verlag Macke G Hanke U Viehmann P 2009 Hoch schuldidaktik Lehren vortragen priifen Beltz Verlag Weinheim Mazur E 1997 Peer Instruction Upper Saddle River Prentice Hall Maier D 2000 Accelerated Learning Handbuch zum schnellen und effektiven Lernen in Grup pen managerSeminare Verlags GmbH Bonn Meyer H 2009 Was ist guter Unterricht Cornel sen Verlag Berlin Mottok J Hagel G Utesch M Waldherr F 2009 Konstruktivistische Didaktik Ein Re zept fiir eine bessere Softwareengineering Aus bildung im Tagungsband des Embedded Software Engineeing Kongress 2009 S 601 610 Mottok J Joas F 2010 Aktivierende Lehre in der Erwachsenenbildung Erfahrungen mit dem A Spillner H Lichter Hrsg SEUH 13 konstruktivistischen Methodenbaukasten in der Software Engineering Ausbildung Jahresta gung der Deutsche Gesellschaft fiir wissen schaftliche Weiterbildung und Fernstudium e V DGWF an der Hochschule Regensburg Mottok J Schroll Decker I Hagel G Niemetz M Scharfenberg G 2012 Internal Confer ences as a Constructivism Based Learning Ar rangement for Research Master Students in Software Engineering The 2012 International Conference on Frontiers in Education Comput
102. Beschreibung von Kompetenzen notwendig Kom petenzbeschreibungen bilden diese Vergleichs grundlage um sp ter in Experimenten zu evaluie ren wie sich die Soll von den Ist Kompetenzen Studierender unterscheiden und ob die gezielte Ver nderung einzelner Einflussvariablen auf den Lernprozess die Kompetenzentwicklung beg nstigt hat Die Beschreibung von Kompetenzprofilen stellt in diesem Zusammenhang eine Datenbasis zu ver schiedenen Zeitpunkten sowie verschiedener Ko horten und Studieng nge dar die dann miteinan der abgeglichen werden k nnen Fachliche und berfachliche Kompetenzen un terscheiden sich in ihrer Art Beschreibung F rde A Spillner H Lichter Hrsg SEUH 13 rung und auch Messung stark und werden daher zun chst separat betrachtet berfachliche Kompe tenzen sind sehr schwer zu fassen zudem kaum eindeutig definierbar und messbar Fachliche Kompetenzen werden mit einem ge eigneten Beschreibungsschema erfasst analysiert und beschrieben Eine Grundlage daf r bildet SWEBOK Abran et al 2004 das die fachlichen Kompetenzen eines Software Ingenieurs mit vier Jahren Berufserfahrung beschreibt F r berfachli che Kompetenzen im Software Engineering soll in EVELIN ein Schema zur Beschreibung entwickelt und mit konkreten Daten gef llt werden Das Er gebnis entspr che dem SWEBOK auf fachlicher Seite Die erforderlichen berfachlichen Soll Kom petenzen werden v llig offen und unvoreinge nommen ermittel
103. DOI http doi ieeecomputersociety org 10 1109 ICSE 2000 10053 Shaw K Dermoudy J 2005 Engendering an empathy for software engineering In Pro ceedings of the 7th Australasian conference on Computing education Volume 42 Darling hurst Australia Australia Australian Computer Society Inc ACE 05 S 135 144 Sommerville I 2010 Software Engineering 9th revised edition Addison Wesley Longman Amsterdam The Eclipse Foundation 2012 Eclipse Process Framework Project EPF Home Abge rufen am 26 10 2011 von http www eclipse org epf index php Wangenheim C G von Shull F 2009 To Game or Not to Game IEEE Software 26 2 S 92 94 139 Smarter GQM Editor mit verringerter Einstiegsh rde Raphael Pham Kurt Schneider Leibniz Universit t Hannover Raphael Pham Kurt Schneider inf uni hannover de Zusammenfassung Die GQM Methode ist bereits ausreichend definiert Man muss sie jedoch selbst einmal angewendet haben um sie durchdringen zu k nnen Dabei k nnen so genannte Abstraction Sheets unterst tzend eingesetzt werden In der Lehre an der Leibniz Universit t Han nover hat sich gezeigt dass das Ausf llen dieser For mulare vielen Studenten Probleme bereitet Sie sind von Abstraction Sheets berfordert oder erkennen den Sinn darin nicht Als Folge lehnen die Studenten die GQM Methode ab und erlernen sie nicht Wir stellen einen smarten Editor vor welche
104. Die Architekturen der Spiele erlauben es Leh renden nicht sich einen schnellen berblick ber den bisherigen Fortschritt aller Spieler im Kurs zu erhalten Die meisten verf gbaren Ans tze unterst tzen nur einen spezifischen Softwareprozess Angesichts aktueller Entwicklungen und der Vielfalt verf gba rer Prozesse erscheinen die Anpassungsf higkeit und die Auswahlm glichkeit verschiedener Pro zessmodelle u erst wichtig 134 Die Erzeugung und Anpassung von Simulati onsmodellen erfordern einen erheblichen Einarbei tungsaufwand der au erhalb der jeweiligen Spiel welt kaum direkt von Nutzen ist Es mangelt an einer Trennung von Software prozessmodell und dem konkreten Anwendungs szenario dieses Prozesses im Spiel was eine Wie derverwendung erschwert Visualisierungen der Softwareprozesse werden nicht angeboten Diese w rden die Validierung der schnell komplex wer denden Modelle enorm erleichtern und Transpa renz erzeugen Lehrende k nnten leichter berbli cken ob das Modell den Softwareprozess korrekt abbildet und die gew nschten Lerninhalte trans portiert Visualisierung in Kombination mit der Trennung von Softwareprozess und seinem An wendungsszenario im Spiel w re als unterst tzen des Lernmaterial auch f r die Studierenden hilf reich Die Einbindung von unterst tzendem Lern material ber den jeweiligen Softwareprozess in die Spielwelt wird in existierenden Ans tzen nicht unterst tzt Sim4SEEd
105. Die zweite Unterst tzungsstufe wendet sich an sehr unerfahrene Anwender Der GQM Editor generiert Teile des Eintrags als schwarzen Text vor und l sst gezielt L cken die der Anwender ausf llen soll Dies lenkt die Gedanken der Anwender in gezielte Bahnen und es werden konkrete Werte verlangt Das Ausf llen von Quadrant 1 bedarf eines krea tiven Schrittes der durch den grauen Hilfstext un terst tzt wird Teile von Antworten zu generieren ist hier nicht m glich Quadrant 2 Ausgangshypothese bietet jedoch die M glichkeit die Q Faktoren auto matisch in die rudiment re Form einer Hypothese zu berf hren Dabei kann der Aussagenkern der Hypo these nicht generiert werden da dies wieder eines kreativen Schrittes bedarf Jedoch wird das Eintragen dieses Aussagenkerns durch einen gezielten L cken text unterst tzt Bevor der Anwender in das Feld zum Eintragen der ersten Ausgangshypothese klickt hat der Editor dort in grau eingetragen Wie steht es momentan um die den Verzweigungstiefe Welche Erfahrungs werte Vermutungen und oder Messwerte gibt es zu diesem Qualit tsfaktor Dies erinnert den Anwender an die von ihm geforderte Ausgangshypothese So bald er in das Feld klickt erscheint die folgende vor generierte Antwort in schwarzem und editierbarem Text Verzweigungstiefe ist sind momentan zu lt bitte Eigenschaft eintragen gt Momentan betr gt Verzwei gungstiefe lt bitte Wert eintragen gt Der Benutzer
106. Einsatz von Zeit und Personal erfordert Wir hatten die M glichkeit viele gute Erfahrungen in un serer Lehre sammeln zu k nnen Allerdings hatten wir immer noch einige Schwierigkeiten den Studenten be stimmte Probleme w hrend der Entwicklung bewusst und sichtbar zu machen In dieser Arbeit berichten wir von unseren Erfahrung mit der Anwendung des Kanban Entwicklungsprozesses in einem agilen Block praktikum an der Universit t Bonn Tats chlich hat dieser einige dieser Schwierigkeiten deutlicher sicht bar machen k nnen Basierend auf unseren Erfolgen bew ltigten Herausforderungen und neu beobachte ten Schwierigkeiten geben wir abschlie end Empfeh lungen f r andere Lehrende Einleitung Agile Softwareentwicklung ist in den letzten Jahren mehr noch in der Wirtschaft als in der Lehre beliebt geworden und hat eine gro e Verbreitung erfahren Lindvall u a 2004 Dem muss auch die universi t re Softwaretechnik Lehre Rechnung tragen und sei es nur durch die Bef higung zur kritischen Reflexion Hier stellt sich aber eine besondere Herausforderung Agilit t m chte der oft erfahrenen Wirklichkeit Rech nung tragen dass sich Softwareentwicklung nur ein geschr nkt planen l sst Diese Erfahrung und wie sie sich durch agile Vorgehensweisen meistern l sst ist auf theoretischem Weg kaum vermitteln Daher haben einige Universit ten sp testens seit 2003 begonnen Praktika zu agiler Softwareentwicklung in ihre Lehr pl ne aufzu
107. Engineering vorgenommen In den Projekten und den sonstigen programmierlastigen Modulen wird darauf geachtet dass auch hier die vermittel ten agilen Praktiken zum Einsatz kommen In den folgenden Kapiteln beschreiben wir wie wir an beiden Fachhochschulen die verschiedenen Praktiken und Techniken im Unterricht vermitteln Engineering Practices Bei der Besprechung der Practices orientieren wir uns an der Liste aus Tabelle 4 Coding Standards Bereits im ersten Semester f hren wir Coding Stan dards in der Einf hrungsvorlesung ins Program mieren ein Wir kombinieren Coding Standards mit Clean Code 12 um so bei den Studierenden von Anfang an auch das Bewusstsein f r eine saubere Programmierung zu wecken Mit dem Einbezug von Clean Code haben wir sehr gute Erfahrungen gemacht da dies den konkreten praktischen Nut zen von Coding Standards sichtbarer macht Von nicht zu untersch tzender Wichtigkeit ist bei der Einf hrung der Aspekt des Feedbacks Das wird wie folgt gehandhabt Normalerweise geh rt zu jeder Vorlesung eine Programmieraufgabe Der Dozierende f hrt mit jedem Studierenden einen Code Review durch und gibt ein ausf hrliches Feedback Das Feedback ist im Allgemeinen m ndlich kann aber auch schrift lich erfolgen Das Feedbackgeben durch den Dozierenden ist zwar mit einen grossem Aufwand verbunden ist aus unserer Erfahrung aber entscheidend f r den Lernerfolg Coding Standards m ssen nat rlic
108. Fazit und Ausblick In diesem Beitrag wurde anhand von Fallbeispielen untersucht welche Aussagen ber Programmieraufga ben aus der Analyse ihrer L sungen mit Softwarepro duktmetriken gewonnen werden k nnen Es konnte festgestellt werden dass mithilfe von Metriken zum Umfang und zur Komplexit t von Programmen Aussa gen ber den Freiheitsgrad einer Aufgabe sowie das A Spillner H Lichter Hrsg SEUH 13 Anweisungen 800 700 600 500 400 300 200 100 50 70 90 110 130 150 170 190 210 230 250 Komplexit t Bestanden Nicht bestanden Abbildung 6 Verteilungsdiagramm f r 162 L sungen zu einer Pr fungsaufgabe Testat 5 Variante 3 Die Aufgabe griff die Aufgabenstellung aus Miniprojekt 5 siehe Abbildung 2 auf Anweisungen Abbildung 70 90 110 130 150 170 190 210 230 250 Komplexit t Bestanden Nicht bestanden 7 Verteilungsdiagramm f r 222 L sungen zu einer Pr fungsaufgabe Testat 6 Variante 1 Die Aufgabe griff die Aufgabenstellung aus Miniprojekt 6 siehe Abbildung 3 auf A Spillner H Lichter Hrsg SEUH 13 67 Niveau der Aufgabe im Vergleich zu anderen Aufgaben getroffen werden k nnen Daraus ergeben sich unmittelbare Einsatzm glich keiten in Werkzeugen zur Lehrunterst tzung sowie weitere Forschungsans tze Die gewonnenen Daten k nnen unmittelbar genutzt werden um Aufgaben zu klassifizieren und som
109. GUNG Der Autor m chte Melanie Klinger vom Referat f r Hochschuldidaktik sowie Colin Atkinson Werner Janjic und Marcus Schumacher von der Software Engineering Gruppe der Universit t Mannheim herzlich f r zahlreiche konstruktive Diskussionen und Anregungen im Zusammenhang mit dem vor gestellten Bewertungsschema danken Literatur ACM 2004 Software Engineering Curriculum Guidelines for Undergraduate Degree Pro grams in Software Engineering in Computing Curricula Series Beck K 1999 Extreme Programming Explained Embrace Change Addison Wesley B ttcher A amp Thurner V 2011 Kompetenorien tierte Lehre im Software Engineering Procee dings des Workshops f r Software Engineering im Unterricht der Hochschulen Brooks F 1995 The Mythical Man Month Essays on Software Engineering 2 Aufl Addison Wesley 113 Bunse C amp von Knethen A 2008 Vorgehens modelle kompakt 2 Aufl Spektrum Akade mischer Verlag Burnette E amp Staudemeyer J 2009 Eclipse IDE kurz amp gut 2 Aufl O Reilly Coldewey J 2009 Schlechte Noten f r die Infor matik Ausbildung in OBJEKTspektrum Aus gabe 05 Endres A amp Rombach D 2003 A Handbook of Software and Systems Engineering Empirical Observations Laws and Theories Addison Wesley Forbrig P 1997 Probleme der Themenwahl und der Bewertung bei der Projektarbeit in der Software Engineering Ausbildung Proceedings
110. IEWE Michael BALZ Mo ritz GOEDICKE Michael A Flexible and Modular Software Architecture for Computer Aided Assess ments and Automated Marking In Proceedings of the First International Conference on Computer Sup ported Eductation CSEDU 23 26 March 2009 Lisboa Portugal Bd 2 INSTICC 2009 S 54 61 A Spillner H Lichter Hrsg SEUH 13 Agile Methoden im Unterricht lterativ inkrementelle Vermittlung von Software Engineering Wissen Veronika Thurner Hochschule M nchen thurner hm edu Zusammenfassung Viele Ans tze der Software Engineering Lehre behan deln in sequenzieller Abfolge die einzelnen Wissensbe reiche nacheinander Sie verlaufen damit analog zum Wasserfallmodell bei dem ebenfalls einzelne Diszipli nen nacheinander ersch pfend abgearbeitet werden wobei die Sinnhaftigkeit und der Beitrag der dabei erzielten Zwischenergebnisse zum Gesamtergebnis oft erst relativ sp t im Projekt erkennbar wird In der Praxis komplexer Software Engineering Pro jekte haben sich heute iterativ inkrementelle bzw agi le Ans tze gegen ber dem Wasserfallmodell durchge setzt Dabei wird in kleinen in sich abgeschlossenen Zyklen in vielen berschaubaren Schritten und mit kurzen Feedback Zyklen nach und nach ein System weiterentwickelt Der hier vorgestellte Lehr Lernansatz greift diese Idee auf und bertr gt sie auf die Vermittlung von Software Engineering Wissen Dabei wird von der ersten Lehreinheit an mit ein
111. Implementie rungstechniken UML Continuous Integration u vgl Larman 2004 Bekanntlich existiert f r die Entwicklung von Soft waresystemen in verschiedensten Dom nen kein allgemein g ltiges Patentrezept No Silver Bullet vgl Brooks 1995 so dass erlernte Verfahren von den Ausf hrenden immer mit Augenma an die jeweiligen Umst nde angepasst werden m ssen sog Tailoring vgl z B Rausch et al 2008 Folg lich gibt es auch in praktischen Projekten an Uni versitaten oder Hochschulen nicht eine korrekte L sung sondern vielmehr eine Reihe von m sgli chen und sinnvollen L sungsstrategien Dar ber hinaus zielen entsprechende Teamprojekte darauf ab auch sogenannte Softskills wie Team Pr sen tations und Kommunikationsf higkeit der Teil nehmer zu schulen B ttcher amp Thurner 2011 weshalb sie zumeist in Kleingruppen von etwa drei bis sechs Personen durchgef hrt werden Gleich zeitig sehen einschl gige Pr fungsordnungen aber regelm ig eine individuelle Benotung aller Teil nehmer vor Weiter erschwerend kommt bei Soft waretechnik Projekten hinzu dass es praktisch unm glich ist die Studierenden best ndig unter Aufsicht arbeiten zu lassen wodurch ihre indivi duellen Beitr ge zur Gruppenarbeit nicht ohne weiteres einzuordnen und ggf auch T uschungs versuche nur schwer zu entdecken sind vgl z B Kehrer et al 2005 Eine objektive Bewertung der studentischen Leistungen ist unter di
112. Kurs im Spiel voranschrei ten So werden Verst ndnisprobleme fr hzeitig erkannt und durch Interaktionen zwischen Leh renden und Lernenden aufgel st Durch die standardisierte Struktur der Prozess beschreibungen f llt Studierenden die Erkundung eines zweiten oder dritten Softwareprozesses zu nehmend leichter Sie erhalten spielerisch Zugang zum Kennenlernen verschiedener Softwareprozes se in einem Industriestandard Effiziente Erzeugung transparenter Simula tionsmodelle Bisherige Ans tze verwenden eine Domain Specific Language DSL Drappa Ludewig 2000 oder ei nen Regeleditor mit grafischer Oberfl che Navar ro 2006 Die Entwicklung der Modelle erfolgt in den verf gbaren Spielumgebungen von Null an d h jedes einzelne Attribut einer jeden Entit t und jedes Element des Softwareprozesses muss aufs Neue modelliert werden Auch die Steuerung der zugrundeliegenden Simulation muss ber Regeln implementiert werden Ein Konzept der Wieder verwendung existiert hierbei nicht Erschwerend kommt hinzu dass in den Modellen nicht zwischen dem eigentlichen Softwareprozess und seiner An wendung in einem spezifischen Kontext Spielsze nario Simulationsexperiment unterschieden wird Simulationsmodell Spiel generieren Simulationsprozess Simulations Anwendungs aus EPF Meta modell szenario auswahlen generieren auswahlen und anpassen Abb 5 Erzeugung eines Simulationsmodells A Spillner H Lichter Hrsg SEUH 13
113. Lernprozes ses und der dabei erzeugten Produkte einsetzbar sind Der vorliegende Artikel stellt letzteres in den Fokus und befasst sich daher ausschlie lich mit Softwarepro duktmetriken Aus praktischen Erw gungen heraus beziehen sich die im Folgenden diskutierten Ans tze und Ergebnisse auf Anf ngervorlesungen zur Program mierung Eine Generalisierung auf fortgeschrittene Lehrveranstaltungen zur Programmierung sowie Soft ware Engineering im Allgemeinen bedarf zweifellos weiterer Forschungsarbeit die weit ber den Rahmen dieses Artikels hinaus geht Der Artikel ist wie folgt gegliedert Zun chst werden einige Szenarien skizziert in denen Metriken zur Lehr unterst tzung angewandt werden k nnen Im selben Abschnitt werden zudem grunds tzliche Analyseme thoden und existierende Ans tze genannt Anschlie end werden Metriken vorgestellt die bei der Analyse von Programmieraufgaben genutzt werden k nnen Danach werden mehrere Fallbeispiele diskutiert in denen eine Auswahl der Metriken auf tats chliche L sungen von Programmieraufgaben angewandt wur den Aus den daraus gewonnenen Erkenntnissen wird am Ende des Beitrags ein Fazit gezogen Szenarien Methoden und Verwandte Arbeiten Es sind verschiedene Einsatzszenarien denkbar in de nen Softwareproduktmetriken bei der Analyse von Programmieraufgaben und ihren L sungen zum Ein satz kommen k nnen Sie unterscheiden sich sowohl nach ihrer Zielsetzung als auch der Analysebasis
114. Prentice Hall 2008 13 R Mugridge W Cunningham Fit for Devel oping Software Framework for Integrated Tests Prentice Hall 2005 14 XP Game XP Game http www xpgame or 29 10 2012 15 Scrum Lego City Game http www agile42 com en training scrum lego city 29 10 2012 16 Checkstyle Homepage http checkstyle sourceforge net 31 10 2012 17 Ch Denzler http web fhnw ch plattformen swent 31 10 2012 18 W Cunningham The WyCash Portfolio Man agement System OOPLSA 1992 19 Modul Software Engineering amp Architecture Master Of Science of Engineering http www msengineering ch fileadmin user u load modulbeschreibungen de TSM_SoftwEn g de pdf 18 12 2012 20 D F Rico H H Sayani Use of Agile Methods in Software Engineering Education Agile Conference 2009 AGILE 09 vol no pp 174 179 24 28 Aug 2009 21 A Shukla L Williams Adapting extreme programming for a core software engineering course Software Engineering Education and Training 2002 CSEE amp T 2002 Proceedings 15th Conference on vol no pp 184 191 2002 A Spillner H Lichter Hrsg SEUH 13 89 Kanban im Universit tspraktikum Ein Erfahrungsbericht Jan Nonnen Paul Imhoff und Daniel Speicher Universit t Bonn nonnen imhoffj dsp cs uni bonn de Zusammenfassung Agile Softwareentwicklung praxisnah und erlebbar zu lehren ist eine Herausforderung die einen deut lichen
115. Problemstellungen entwickeln diese als relevant erkennen und selbst nach M glichkeiten und Al ternativen der L sung suchen W rner 2008 Ausblick Um die Zeit der Bearbeitung der ersten Feedback Runde zu verk rzen und diese Methode auch f r Lehrveranstaltungen mit mehr als 50 Studierenden allein durchf hrbar zu machen bieten sich Systeme f r die online Aufgaben an die Fragen automatisch auswerten k nnen Zu diesen geh rt LON CAPA Kortemeyer et al 2008 LON CAPA hinter dem ein Computeralgebra System verborgen ist Damit eignet es sich hervorragend f r alle mathemati schen und physikalischen Aufgaben Diese k nnen von dem System sogar automatisch randomisiert werden so dass die Studierenden je unterschiedli che Fragen bekommen k nnen Dies ist ein wesent licher Grund warum das Just in Time Teaching in Mathematik und Physik Lehrveranstaltungen schnell Fu gefasst hat Auf dem Gebiet der auto matischen Auswertung von L sungen m ssen wir im Software Engineering noch einiges an Arbeit investieren Existiert au erdem ein Pool an Fragen und Antworten auf den die Lehrenden zugreifen k nnen verringert sich auch der Aufwand f r die Erstellung der Fragen f r die Selbststudiumsphase Aber schon wenn ein paar Aufgabentypen automa tisierbar w ren kann sich das Just in Time Teaching auch in dieser Disziplin durchsetzen Das Design einer geeigneten Dokumentations form f r Feedback Ergebnisse und passender Er kl
116. Schweiz weiten gemeinsamen Masterausbildung Master of Science in Enginee ring MSE der Schweizerischen Fachhochschulen 3 Die gemeinsame Masterausbildung betrachten die Autoren als eigentlichen Gl cksfall da dadurch Dozierende von verschiedenen Hochschulen zu sammen lehren und ihre Erfahrungen austauschen k nnen Wir haben festgestellt dass die Studierenden noch relativ wenig Wissen ber agile Softwareentwick lungsmethoden mitbringen wobei sich der Wissen stand in den letzten Jahren leicht verbessert hat aber je nach Fachhochschule sehr unterschiedlich ist Daf r beobachten wir jedoch dass das Interes se der Studierenden an dem Thema umso gr sser ist In unserer gemeinsamen Vorlesung haben wir den Fokus ganz gezielt auf agile Softwareentwicklung gelegt Unter anderem unterrichten wir agile Soft ware Entwicklungsmethoden wie Scrum eXtreme Programming oder Kanban Dabei haben wir die Erfahrung gemacht dass viele Studierende das Programmier Handwerk welches eine der Vo raussetzungen f r die erfolgreiche Durchf hrung agiler Projekte darstellt nicht beherrschen resp nie im Bachelor Studiengang gelernt hatten Unter Programmier Handwerk verstehen wir das Be herrschen von agilen Praktiken wie zum Beispiel Clean Code Refactoring Test Driven Development oder Continuous Integration Weiter halten die Autoren jeweils an ihrer Fach hochschule 4 5 verschiedene Vorlesungen in Pro grammieren und Software En
117. Software Engineering zugrunde liegen Dieses Ver st ndnis ist Voraussetzung f r die kompetenzf r dernde Gestaltung der Lernprozesse Den Ausgangspunkt der Grounded Theory bil den nicht theoretische Vorannahmen Vielmehr handelt es sich um einen zirkul ren Analysepro zess der zugleich induktive und deduktive Vorge henselemente beinhaltet Ausgangspunkt ist eine A Spillner H Lichter Hrsg SEUH 13 erkl rende Hypothese die versucht von einer Fol ge auf Vorhergehendes zu schlie en Abduktion Dann wird ein Typisierungsschema f r Hypothe sen entwickelt Deduktion das mit Forschungsda ten abgeglichen wird Induktion Flick et al 2000 Grounded Theory besitzt unter anderem fol gende wesentliche Merkmale Eine Theorie wird aus Daten generiert statt nur verifiziert Der Fokus liegt auf der Entde ckung und Einbeziehung neuer Erkenntnisse nicht auf der Verifizierung denn das w rde neu auftauchende Perspektiven unterdr cken Folglich kann eine Theorie nie fertig sein da jederzeit neue Aspekte auftauchen k nnen Ziel ist es durch das Vergleichen von Gruppen zum einen Kategorien zu bilden und zum an deren bestehende Beziehungen zwischen die sen Kategorien an den Tag zu bringen Nach Glaser et al 1998 S 48f muss unterstri chen werden dass die Hypothesen zun chst einen vorl ufigen Status haben Sie beschreiben mutma liche nicht getestete Zusammenh nge zwischen den Kategorien und ih
118. Studierenden einen we sentlich h heren Aufwand betreiben Durchf hrung Es ist wichtig dass die Studierenden den Zeit punkt der Bearbeitung flexibel w hlen k nnen um Konflikte mit anderen Veranstaltungen zu vermeiden Da die Aufgaben von jedem Studie renden individuell zu bearbeiten sind haben wir als Rahmen nur vorgegeben dass das Quiz nach dem Ende der vorherigen Vorlesung ver ffent licht wird und bis zum Tag vor der n chsten Vor lesung bearbeitet sein muss Das l sst dem Dozen ten bzw der Dozentin dann noch Zeit die Ant worten auszuwerten und in der Vorlesung ent sprechend darauf zu reagieren Im Einzelnen sehen die Schritte wie folgt aus Am Nachmittag nach der Vorlesung wird der ers te Teil die Einleitung ins Netz gestellt Sobald die Teilnehmenden ihre Vorbereitungen abgeschlos sen haben und denken dass sie sich im betroffe nen Teilsystem ausreichend gut auskennen star ten sie mit dem zweiten dem Fragenteil In dem Moment in dem sie auf den Start Knopf klicken werden ihnen die Fragen gezeigt und die Bearbei tungszeit beginnt zu laufen Wir haben uns ent schlossen die Bearbeitungszeit auf 60 Minuten zu begrenzen um zu verhindern dass zu viel Zeit in die Beantwortung investiert wird Die Fragen selbst sollten allerdings in unter 30 Minuten zu beantworten sein und wurden von den Studie renden in der Regel auch in dieser Zeit beantwor tet Um die Studierenden zur Teilnahme anzure gen haben wir di
119. Systeme nach haltig zu entwi ckeln Dazu kombinieren wir in einem holistischen Ansatz verschie dene Qualifizierungsma nahmen zu unterschiedlichen Themengebie ten mit praktischen bungen und konkreter Anwendung innerhalb der Projekte der Teilnehmer Das Curriculum umfasst mehrere Work shops und Projektarbeitsphasen die sich ber einen Zeitraum von mehreren Monaten erstrecken und wird durch eine Reihe von Assessments der technischen und sozialen F higkeiten begleitet Inhalts bersicht e Hintergrund und Motivation e Curriculum f r Senior Software Architekten SSWA e Curriculum f r Software Architekten SWA e Erfahrungen und Ergebnisse o Herausforderungen in Ausbildung und Training o Praxistransfer o Zertifizierung e Siemens Guiding Principles e Erfolgsfaktoren e Zusammenfassung und Ausblick Literatur Paulisch F Stal M Zimmerer P 2009 Software Curriculum Ar chitektenausbildung bei Siemens SIGS DATACOM OBJEKTspekt rum Heft Nr 4 Juli August 2009 Paulisch F Zimmerer P 2010 A role based qualification and certi fication program for software architects An experience report from Siemens ACM IEEE 32nd International Conference on Software Engineering ICSE Cape Town South Africa May 2 8 2010 A Spillner H Lichter Hrsg SEUH 13 a N Session1 w u zu gt Just in Time Teaching Just in Time Teaching f r Software Engineering Timo Kamph Peter Salden Sibylle Schup
120. U Fernando B CARAPUGA Rogerio Object Oriented Software Engi neering Measuring and Controlling the Development Process 1994 Chidamber u Kemerer 1994 CHIDAMBER Shyam R KEMERER Chris F A metrics suite for object oriented design In IEEE Transactions on Softwa re Engineering 20 1994 jun Nr 6 S 476 493 http dx doi org 10 1109 32 295895 DOI 10 1109 32 295895 ISSN 0098 5589 Conte u a 1986 CONTE Samuel D DUNSMORE Hubert E SHEN Vincent Y Software enginee ring metrics and models Redwood City CA USA Benjamin Cummings Publishing Co Inc 1986 ISBN 0 8053 2162 4 DeMarco 1986 DEMARCO Tom Controlling Soft ware Projects Management Measurement and Esti mates Upper Saddle River NJ USA Prentice Hall PTR 1986 ISBN 0131717111 68 Fenton u Pfleeger 1998 FENTON Norman E PFLEE GER Shari L Software Metrics A Rigorous and Practical Approach 2nd Boston MA USA PWS Publishing Co 1998 ISBN 0534954251 Gross u a 2012 Gross Sebastian MOKBEL Bas sam HAMMER Barbara PINKWART Niels Feed back Provision Strategies in Intelligent Tutoring Sys tems Based on Clustered Solution Spaces In DESEL J rg Hrsg HAAKE Joerg M Hrsg SPANNAGEL Christian Hrsg DeLFI 2012 Die 10 e Learning Fachtagung Informatik Hagen Germany 2012 ISBN 978 3885796015 S 27 38 Halstead 1977 HALSTEAD Maurice H Elements of software science Els
121. UI Storyboard 1 Spezifikationsdokument 11 Lesbarkeit und Aufbau 1 12 Konsistenz der enthaltenen Modelle 2 Source Code 13 Ausfithrbarkeit lauffahiges JAR File 1 14 Korrektheit 2 15 Einhaltung von Coding Guidelines 2 16 Verwendung von Javadoc und Kommen tierung 1 17 Konsistenz mit der Spezifikation 2 Testfalle 19 Uberdeckung 4 Benutzerschnittstelle 20 Ergonomie Bedienbarkeit 3 21 Reaktivit t 1 Insgesamt besteht das vorgestellte Bewertungs schema aus zwanzig Einzelleistungen n bis nz die alle auf einer vierstufigen Skala mit 0 bis 3 Punkten wie folgt bewertet werden 109 e 0 Punkte und ungen gend werden ver geben wenn ein Element komplett fehlt oder grob fehlerhaft bzw unvollst ndig ist e 1 Punkt gibt es f r Kategorien die sinnvol le Inhalte haben die aber noch deutlich fehlerhaft bzw l ckenhaft sind e 2 Punkte gibt es f r weitgehend vollst ndi ge und berwiegend korrekte Elemente e 3 Punkte werden f r vollst ndige korrekte und sehr sorgf ltig erarbeitete Artefakte vergeben Der Multiplikator am Ende jeder Bewertungskate gorie gibt die vorgesehene Gewichtung wi inner halb des gesamten Rasters an so dass eine Ge samtpunktzahl leicht nach folgender Formel be rechnet werden kann 20 87 yin W i l In der vorgestellten Form werden teambasierte Bewertungsanteile 18 fach gewichtet individuelle Bewertungsanteile 27 fach so dass sowohl die Teamarbeit gef rdert als auch in
122. ab dem dritten Semester dann in der Lage sein sich selbst ndig in neue nicht intensiv geschulte Pro grammiersprachen einzuarbeiten Dies wird dadurch gef rdert dass oft in weiteren Lehrveran A Spillner H Lichter Hrsg SEUH 13 staltungen weitere Programmiersprachen einge f hrt werden die f r praktische bungen unerl ss lich sind Beispiele sind JavaScript f r Web Technologien und Sprachen zur Erstellung von Triggern und Stored Procedures wie PL SQL und Transact SQL fiir Datenbanken Im Mittelpunkt der nachfolgenden Analyse steht dabei der Erfolg der Masse der Studierenden also nicht die Anzahl der Studierenden die zu sehr guten Ergebnissen kommen Dieser Ansatz ist ge rechtfertigt da sich alle Hochschulen zwangsweise der Forderung der Politik stellen miissen dass m glichst viele Studienanf nger in relativ kurzer Zeit zum Studienerfolg gef hrt werden m ssen Eine Forderung die teilweise zu politisch diktier ten Selbstauflagen von Studieng ngen oder ganzen Hochschulen f hrt dass 90 der Studierenden zum Studienerfolg gebracht werden Diese Forde rung wird hier als Grundlage genommen wobei sie nat rlich hinterfragt werden muss da sich gerade in der Informatik immer wieder die Frage stellt wieviel Prozent der Studienanf nger wirklich rea listisch f r das Themengebiet Informatik geeignet sind Nat rlich darf die Motivation und F rderung guter Studierender nicht vernachl ssigt werden die im konkrete
123. abei die eigentliche Nutzung nicht beeinflussen Vor diesem Ansatz ist aber dann zu kl ren ob die Indikatoren wirklich geeignet sind Der Erfahrungsbericht bietet einige Fragen und Hypothesen die genauer zu untersu chen sind e Da die am meisten angewandten Sprachen objektorientiert sind stellt sich die Frage ist ein Start mit C noch sinnvoll e Wenn man objektorientiert beginnt sollte man dann rigoros auf Objects first setzen e Ist Java als Einf hrungssprache geeignet obwohl sie nicht konsequent objektorien tiert ist e Welchen Motivationsschub kann aus der M glichkeit schnell einfache Animationen zu erstellen gezogen werden Gibt es ver gleichbar erfolgreiche Ans tze wie der Einsatz von kleinen Robotern e Welche Bedeutung hat die Auswahl von Entwicklungsumgebungen e Wie sieht eine kontinuierliche Integration der Programmierausbildung in die weite ren Lehrveranstaltungen der ersten Semes ter aus Ist es z B sinnvoll parallel eine weitere Sprache wie JavaScript in einer Ein f hrung zur Web Technologie zu lehren A Spillner H Lichter Hrsg SEUH 13 e Welche Bedeutung hat das Engagement der Lehrenden Ketzerisch formuliert sind die vorherigen Fragen nachrangig wenn das echte Bem hen die Programmierung n her zu bringen deutlich wird Zusammengefasst wird die Suche nach dem richti gen Weg in der Programmierausbildung sicherlich wie in der Vergangenheit auch zu mehrfach neu gefundenen und dann
124. ache deren Gro teil aus der konsequen ten Nutzung von Klassen besteht die allerdings auf einfachen Basistypen aus C wie int und char basie ren Diese Problematik spiegelt sich in verschiede nen didaktischen Ans tzen wider Der klassische Ansatz besteht darin zun chst den imperativen Teil der Programmiersprache zu lehren die auf if und while fokussieren und danach zur Objektorien tierung berzugehen Dieser Ansatz wurde lange Zeit auch in imperativen Sprachen wie Basic Pascal und C verfolgt wo der zweite Teil sich auf die Entwicklung komplexerer Datenstrukturen meist zusammen mit ihrer Verlinkung in Listen fokussiert Didaktisch steht man dann am Anfang vor dem Problem dass man bei public static void main String s mit public static und String drei Sprachanteile vorstellen muss deren genauer Sinn erst viel sp ter in der Lehrveranstaltung vermittelt werden kann Gerade dieses magische Verhalten f hrt aber bei Programmieranf ngern oft zur verst ndlichen Idee dass diese Magie auch f r andere Sprachanteile gilt Ein Beispiel ist der Konstruktor public Punkt int x int y bei dem vermutet wird dass eine Zuweisung zur Objektvariablen gleichen Namens this x x nicht programmiert werden muss Der klassische didaktische Ansatz ist anfanglich durchaus erfolgreich f hrt aber beim bergang zu Klassen oft zu Problemen da diese dann analog zum struct in C als reine Daten Container ohne eigene F
125. acher Matthias H schele Konrad Jamrozik Kevin Streit Andreas Zeller Transparente Bewertung von Softwaretechnik Projekten in der Hochschullehre 103 Oliver Hummel Forschung mit Master Studierenden im Software Engineering 44 gt 115 Marc Hesenius Dominikus Herzberg Welche Kompetenzen ben tigt ein Software Ingenieur uuuusssssssnnnnnnnennnnnnnnn 117 Yvonne Sedelmaier Sascha Claren Dieter Landes A Spillner H Lichter Hrsg SEUH 13 iii Session 5 Werkzeuge in und f r die Ausbildung Alles nur Spielerei Neue Ans tze f r digitales spielbasiertes Lernen von Softwareprozessen J ran Pieper Smarter GQM Editor mit verringerter Einstiegsh rde Raphael Pham Kurt Schneider A Spillner H Lichter Hrsg SEUH 13 Eingeladene Vortr ge Neue Wege in Software Projektkursen Bernd Br gge Technische Universit t M nchen bruegge in tum de Zusammenfassung Projektkurse mit realen Kunden aus der Industrie sind ein wichti ger Bestandteil vieler Software Engineering Vorlesungen da sie es erm glichen relevante Konzepte und Praktiken gr ndlich zu vermit teln In meinem Vortrag zeige ich wie man solche Kurse mit bis zu 100 Bachelorstudenten innerhalb eines Semesters durchf hren kann Die Studenten arbeiten in Teams mit mehreren Kunden aus der Industrie bekommen reale Probleme die mit agilen Methoden innerhalb eines Semesters zu l sen sind wobei alle Phasen des Softwarelebenszy
126. alisieren A Spillner H Lichter Hrsg SEUH 13 Wir setzen seit ber zehn Jahren Blue BlueJ in der Lehre ein eine IDE die explizit zum Lernen und Lehren objektorientierter Programmierung entwi ckelt wurde K lling et al 2003 Blue bietet eine gute Visualisierung der statischen Konzepte der Programmierung ein Klassendiagramm des aktuel len Paketes wird automatisch generiert siehe Ab bildung 2 der Editor hebt Sichtbarkeitsbereiche im Quelltext farbig hervor Au erdem ist Blue hoch gradig interaktiv von jeder beliebigen Klasse in ei nem Java System kann interaktiv ein Exemplar erzeugt siehe die rot dargestellten Objekte in der Objektleiste unten in Abbildung 2 und seine Me thoden interaktiv aufgerufen werden Der Debug ger erlaubt auch die Visualisierung von Pro grammausf hrungen beispielsweise der Stackfra mes bei Rekursion All diese Aspekte machen Blue auch f r den Einsatz in Vorlesungen sehr gut ge eignet In Bezug auf die Visualisierung von Objektin teraktion ist Blue allerdings eher schwach Projekt Bearbeiten Werkzeuge Ansicht Hilfe Neue Klasse J J J gt Ubersetzen i i TitelBibliothek gt lt o arrayTitt titelBib1 Torg 9 TitelBibliothek fitel4 Titel Abb 2 Die Oberfl che von Blue an einem Beisp
127. aluation ergab dass der Kanban Entwicklungs prozess f r die Studenten n tzlich war Au erdem hat der Prozess Probleme verringert die wir in fr heren Praktika erlebt haben Zum Beispiel hatten wir erlebt dass blockierende Tickets fr her nicht immer allen sichtbar und bewusst waren und zus tzlich von dem Prozess nicht explizit behandelt wurden Zu diesem Zweck hat das Kanban Whiteboard in dem Prakti kumsraum eine essentielle Rolle als Mittel f r Diskus sionen geboten Dieses hat auch den Studenten gehol fen den Gesamt berblick zu behalten und ihnen die M glichkeit gegeben selbst ihre eigenen Leistungen zu reflektieren Wir w rden daher trotz digitalen M g lichkeiten empfehlen ein physisches Kanban Board zu nutzen und es zentral in den t glichen Arbeitsalltag zu stellen In Scrum Schwaber u Beedle 2001 gibt es feste Iterationen die im vorhinein geplant werden Dem Kunden ist es dabei nicht m glich den Fokus der Entwicklungs dynamisch w hrend einer Iteration an zupassen Durch die flexible Input Queue in unserem Praktikum war es dem Kunden jederzeit m glich den aktuellen Fokus anzupassen Dies ist in einem For schungsprojekt wichtig da auf aktuelle Erkenntnisse und Entwicklungen reagiert werden kann Die Fortbildungsm glichkeiten f r Studenten w h rend des Lehrlaufes waren unserer Meinung nach sinn voll wurden aber nicht gut genug kommuniziert Die Arbeit an diesen Aufgaben entsprach auch nicht dem allgemei
128. andes beginnt der erste Schritt Auswahl eines geeigneten Spiels etwa f nf Monate vor Praktikumsbeginn Zusammenspiel mit anderen Mustern Ein Spiel als Aufgabenstellung eignet sich sehr gut f r ein abschlie endes Turnier Folgen Abbildung 1 Muster Spiel als Aufgabenstellung aus www sewiki de gek rzt 102 A Spillner H Lichter Hrsg SEUH 13 Transparente Bewertung von Softwaretechnik Projekten in der Hochschullehre Oliver Hummel Karlsruher Institut f r Technologie KIT hummel kit edu Zusammenfassung Die Informatik Curricula an Hochschulen und Universit ten sehen neben Softwaretechnik Vor lesungen h ufig auch praktische Projekte vor in denen Studierende die Herausforderungen bei der Erstellung eines nicht trivialen Softwaresystems in einem Team erfahren sollen Sp testens seit der Bologna Reform sind auch solche praktischen Stu dienleistungen zu benoten was eine nicht unerheb liche Herausforderung f r die Betreuer darstellt da hochkomplexe und entsprechend unterschiedliche Arbeitsergebnisse transparent und nachvollziehbar bewertet werden m ssen Im vorliegenden Beitrag wird aus Kolloquien einem Programmiertestat und der direkten Bewertung eingereichter Artefakte ein transparentes und verh ltnism ig einfach an wendbares System zur Bewertung von Software entwicklungsprojekten an Hochschulen und Uni versit ten entwickelt und von seiner praktischen Erprobung an der Universit t Mannhe
129. ang ist die Wahrung der not wendigen Distanz wichtig dies ist immer wieder eine Gradwanderung Feedback der Studierenden Letztendlich ist es nicht nur notwendig dass die richtigen Dinge vermittelt werden sondern auch eine m glichst gro e Nachhaltigkeit erreicht wird Das Projekt soll den Studierenden den Einstieg ins Berufsleben vereinfachen Dies ist nur m glich wenn die Studierenden meinen etwas aus der Ver anstaltung mitzunehmen Daher wird regelm fig im Projekt um Feedback gebeten auch nach der Bekanntgabe der Endnote um ein m glichst ehrliches Feedback zu erhalten Die folgenden u erungen von Studierenden wer den sinngem und verk rzt wiedergegeben Zu n chst eher allgemeine Punkte zum Projekt und im Anschluss ein paar Punkte zu inhaltlichen Aspek ten e Das Projekt hatte einen hohen Praxisbezug das gab es sonst im Studium nicht e Es war gut ein komplettes Projekt von Anfang bis Ende zu machen e Es war gut dass keine Prozessanforderungen vorgegeben waren e Die Arbeit im Team mit der eigenen Teamorga nisation war gut e Das Ziel war klar aber der Weg nicht Dennoch gab es viel Unterst tzung beim Finden des rich tigen Wegs e Oft wurden nicht alle Informationen gegeben aber am Ende war doch alles rechtzeitig da e Die Praxisn he war gr er als bei allen Veran staltungen vor dem Projekt e Es ist schwierig vom Kunden gute Anforderun gen zu erhalten e Die Rollenspi
130. anntes Beispiel shapes erlaubt es verschiedene graphische Elemente auf einer Can vas Oberfl che zu platzieren und diese zu ver schieben und umzuf rben Dieses prinzipiell sehr sch ne Beispiel hat allerdings sp ter den Nachteil dass an zentraler Stelle eine Klassenmethode ge nutzt wird ein Konzept dass man erst sp t in einer Einf hrung in die objektorientierte Programmie rung vorstellen sollte da sonst die zun chst zu erlernende Grenze zwischen einer nicht ausf hrba ren Klasse und Objekten mit denen Programmcode ausf hrbar ist wieder verschwimmt Generell ist die Idee m glichst einfach graphische Ausgaben oder sogar Interaktionen mit der Ober fl che zu erlauben sehr sinnvoll da man als Ler nender schnell zu anschaulichen Programmen kommt was oft auch den Spiel und den f r das Lernen dringend ben tigten Probier Trieb an spricht F r das gezeigte Beispiel und auch einige Anfangsprogramme in BK09 gilt leider dass ge gen die konsequente Objektorientierung versto en und schnell z B zu System out printin gegriffen wird A Spillner H Lichter Hrsg SEUH 13 Um auch bei Ein und Ausgaben konsequent auf Objekte zu setzen ist es sinnvoll diese Funktionali t t in einer Klasse mit Objektmethoden zu kapseln Dies l st aber das Problem nicht vollst ndig da es typischerweise trotz mehrfacher Konstruktornut zung jeweils nur ein Objekt dieser Klasse gibt Greenfoot Die aus der graphischen Au
131. anstaltung war sehr aufwendig In der Lehrveranstaltung gab es ausgiebige Diskussionen zu dem dort behandelten Bei spiel _ ich kann die Strukturierte Testfallermittiung erkl ren Nicht ausgew hlt vol eher eher berhaupt wei nicht nicht nicht n Ich kann die Strukturierte Testfallermittiung anwenden Nicht ausgew hlt voll eher eher berhaupt wei nicht nicht nicht w Was fanden Sie schwierig a Was haben Sie nicht verstanden n Folgende Fragen habe ich zum Text Was finden Sie an der Strukturierten Testfallermitiung gut Abb 1 Allgemeine Verst ndnisfragen In Kempten haben wir weiterhin versucht inner halb der Vorlesung Softwarearchitektur fiir den Master Studiengang Angewandte Informatik 19 einen Reading First Ansatz zu w hlen Die Stu dierenden bekamen einen aktuellen Artikel zur Softwarearchitektur ber das Thema Messaging und idempotente Nachrichten den sie bis zur n chsten Lehrveranstaltung lesen sollten Helland 2012 Ziel war es dass die Studierenden das The ma idempotente Nachrichten und ihren Einsatz in der Softwarearchitektur verstehen sollten In der Lehrveranstaltung haben wir diesen Text ausf hr lich besprochen und diskutiert Dadurch dass die Studierenden jedoch keine Fragen zur online Beantwortung bekamen hatte der Lehrende keinen Einblick wie viel tats chlich vom Thema verstan den wurde Durch die lebhaft
132. aphische Grenzen hinweg weit verbrei tet Poth 2009 7 Auch in Deutschland ist Just in Time Teaching angekommen allerdings mit noch recht geringer Verbreitung zu nennen sind insbe sondere die TU Hamburg Harburg und die nie ders chsische Ostfalia Hochschule siehe aber auch Hagel et al in diesem Tagungsband Einge setzt wird es in mittleren und auch gro en Veran staltungen so z B an der TU Hamburg Harburg in Vorlesungen mit ber 600 Studierenden A Spillner H Lichter Hrsg SEUH 13 Der vielversprechende Ansatz von JiIT hat auch das Interesse an der Frage geweckt inwie weit sich ein Erfolg der Methode wissenschaftlich belegen l sst Hierzu liegt inzwischen eine ganze Reihe k rzerer Studien vor die berwiegend von Lehrenden mit Datenmaterial aus ihrem eigenen Unterricht durchgef hrt worden sind das in Amerika verbreitete scholarship of teaching and learning vgl Huber 2011 118 Luo 2008 beispielsweise weist nach dass die regelm ige Bearbeitung von JiTT Aufgaben ei nen deutlich positiven Einfluss auf die Ab schlussnoten seiner Studierenden hatte Slunt und Giancarlo 2004 wiederum vergleichen JiTT mit dem Erfolg sog Concept Checks d h struktu rierter Feedbackfragen im laufenden Unterricht die Vorwissen oder Verst ndnis von Studieren den pr fen Gemessen anhand von durchschnitt lichen Endnoten f llt das Ergebnis deutlich zu gunsten von JiTT aus Slunt Giancarlo 2004 986 f Die
133. ar war jedoch aus Zeitgr nden vor dieser ersten Umsetzungsphase noch nicht m glich Statt dessen werden die Studie renden dazu angeleitet sich als Nachschlagewerk ei gene Zusammenfassungen zu den einzelnen Themen gebieten zu erstellen und diese semesterbegleitend kontinuierlich auf und auszubauen Diese d rfen auf 5 beidseitig beschriebene A4 Bl tter beschr nkt dann als Hilfsmittel in die Pr fung mitgenommen werden Die obigen Aussagen spiegeln ausschlie lich den Eindruck wider den die Dozentin in den Lehrveran staltungen und aus Gespr chen mit den Studierenden gewonnen hat Pr fungsergebnisse die als Kennzahl f r die Bewertung des Lernerfolgs herangezogen und mit den Ergebnissen anderer Ans tze verglichen wer den k nnten liegen zum aktuellen Zeitpunkt jedoch noch nicht vor In vergangenen Durchf hrungen der Lehveranstal tung Software Engineering 1 lag der Fokus berwie gend auf der Modellierung und den fr hen Phasen wie in der Modulbeschreibung vorgegeben Durch das iterativ inkrementelle Lehrkonzept sind Aspekte der Implementierung st rker in den Vordergrund ger ckt Dies wird sich in der Gestaltung der Pr fung entspre chend widerspiegeln um dadurch die von den Stu dierenden erworbenen Kompetenzen im Bereich des Zusammenspiels von Modellierung und Implementie rung zu bewerten Bei der initialen Umsetzung des Lehrkonzeptes er wies sich die Granularit t der einzelnen Inkremen te immer wieder als zentral
134. ar das Zustandekommen der Note f r die Teilnehmer vollkommen intransparent sie setzte sich irgendwie aus der Leistung im Projekt und dem Abschlusskolloquium zusammen im letztge nannten Fall haben gar die studentischen Hilfskr f te eigene Ma st be zur Bewertung von Anforde rungs und Designdokumenten die sich haupt s chlich auf die Z hlung von offensichtlichen Feh lern beschr nkten entwickelt und eingesetzt Ziel dieses Beitrags ist es daher ein nachvollzieh bares und dennoch einfach handhabbares Bewer tungsverfahren f r praktische Softwareentwick lungsprojekte das eine individuelle und transpa rente Bewertung der Studierenden erm glicht vorzustellen und von Erfahrungen aus seiner prak tischen Erprobung an der Universit t Mannheim zu berichten Dazu werden im folgenden Abschnitt zun chst wichtige didaktische und organisatori sche Rahmenbedingungen vorgestellt bevor in aller gebotenen K rze einige ben tigte Hinter gr nde der Softwaretechnik dargelegt werden Danach werden g ngige Bewertungsverfahren auf ihre Verwendbarkeit in einem Softwaretechnik Projekt analysiert In den darauf folgenden Kapi teln werden das in diesem Beitrag thematisierte Bewertungsverfahren im Detail vorgestellt und aus ersten Erprobungen gewonnene Erkenntnisse dis kutiert Ein Vergleich mit anderen in der Literatur ver ffentlichten Verfahren und eine Zusammenfas sung runden diesen Beitrag schlie lich ab 104 Grundlagen
135. as verallgemeinert kann man die dargestellten Erfahrungen in der Form zusammenfassen dass die Auswahl der ersten Programmiersprache im Studium wahrscheinlich kein wesentlicher Faktor f r den Studien und den Berufserfolg von Studie renden ist Begeisterte und begeisternde Dozenten mit guter fachlicher Unterst tzung und einfach zu nutzenden Werkzeugen k nnen als Erfolgsfaktoren bestimmt werden Dies bedeutet auch dass Dozen ten zumindest in den ersten Semestern ein gemein sames Konzept in der Anwendung von Program miersprachen finden sollten was h ufiger nicht der Fall ist M chte man nach dem ersten Semester eine Pro grammiergrundlage legen die recht einfach erwei tert werden kann und Studierenden nebenbei recht viele Nebent tigkeiten in Hochschulen oder Unter nehmen erm glicht sollte die Auswahl auf eine objektorientierte Sprache fallen Dabei gibt es Indi katoren auf Basis der Literatur und der gemachten Erfahrungen dass ein konsequenter Einstieg mit dem Erlernen von Objekten und Klassen den Vor teil hat dass diese Abstraktionsebene sehr fr h einge bt wird Eine wirkliche fundierte Untersuchung zeigt sich als schwierig da hier mehrere Herausforderungen der empirischen Sozialforschung zusammenkom men um m gliche Hypothesen berpr fen zu k nnen Oftmals haben Studierende bereits Kennt nisse der Programmierung aus der Schule oder haben sich diese teilweise selbst beigebracht Dabei zeigt sich immer wieder das
136. assen kann In unserem Fall konnte Kanban die hartn ckigen Schwierigkei ten aufgeschobener Fertigstellung fast fertiger Stories und ungen gender Reviews aufgrund auf das Iterati onsende konzentrierter Fertigstellungen aus der Welt schaffen sowie den Besprechungsaufwand deutlich reduzieren Danksagung Wir m chten uns bei Matthias Bohlen f r seinen exter nen Review unseres Kanban Prozesses w hrend des Praktikums bedanken Wir haben wertvolle Tipps er halten die unser Verst ndnis von Kanban vertieft und unseren Prozess verbessert haben Literatur Anderson 2010 ANDERSON D Kanban Successful Evolutionary Change For Your Technology Blue Hole Press 2010 Beck u Andres 2004 BECK K ANDRES C Extreme programming explained embrace change Addison Wesley Professional 2004 Goldratt u a 1984 GOLDRATT E M Cox J OUT PUT C The goal Excellence in manufacturing Bd 262 North River Press New York 1984 Lindvall u a 2004 LINDVALL M MUTHIG D DA GNINO A WALLIN C STUPPERICH M KIEFER D May J KAHKONEN T Agile software deve lopment in large organizations In Computer 37 2004 dec Nr 12 S 26 34 Melnik u Maurer 2004 MELNIK G MAURER F In troducing agile methods three years of experience In Euromicro Conference 2004 Proceedings 30th 2004 S 334 341 98 M gge u a 2004 M GGE H SPEICHER D KNIE SEL G Extreme Programming in der I
137. asurement process In 148 Software IEEE 17 2000 may jun Nr 3 S 56 62 http dx doi org 10 1109 52 896250 DOI 10 1109 52 896250 ISSN 0740 7459 van Maris u a 1995 MARIS M van DIFFERDING D I C GIESE D LP Ein Werkzeug zur Definiti on Interpretation und Validation von GQM Planen 1995 Parviainen u a 1997 PARVIAINEN P JARVINEN J SANDELIN T Practical experiences of tool support in a GQM based measurement programme In Software Quality Journal 6 1997 Nr 4 S 283 294 Schneider 2007 SCHNEIDER Kurt Abenteuer Soft warequalit t Grundlagen und Verfahren f r Quali t tssicherung und Qualit tsmanagement Dpunkt 2007 Van Latum u a 1998 VAN LATUM F VAN SO LINGEN R OIvo M HOISL B ROMBACH D RUHE G Adopting GQM based measure ment in an industrial environment In Softwa re IEEE 15 1998 jan feb Nr 1 S 78 86 http dx doi org 10 1109 52 646887 DOI 10 1109 52 646887 ISSN 0740 7459 Van Solingen u Berghout 1999 VAN SOLINGEN R BERGHOUT E The Goal Question Metric Method a practical guide for quality improvement of software development McGraw Hill 1999 Voigtlaender 1999 VOIGTLAENDER und Kemp kens R C GQMaspect II System Documentation Fraunhofer IESE 1999 Werner 2012 WERNER Florian Entwurf eines regel basierten GQM Editors mit geringer Einstiegshiirde Leibniz Universitat Hannover Fachgebiet Software Engineerin
138. auch wieder konsequent verworfenen Wegen f hren Der Autor dankt Dr Cheryl Kleuker und Prof Dr Frank Thiesing f r die Diskussion und Kommentie rung einer Vorversion dieses Artikels Literatur Web Seiten vom Stand 1 11 2012 betrachtet Blu Blue http www bluej org Ecl Eclipse http www eclipse org Gre Greenfoot http www greenfoot org door Int Interaktionsbrett http home edvsz hs osnab rueck de skleuker querschnittlich Interaktionsb rettMID index html Kara Programmieren lernen mit Kara http www swisseduc ch informatik karatojav a index html Karo Java Karol http www schule bayern de karol jdownload htm Pro Processing http processing org Scr Scratch http scratch mit edu SDL Simple DirectMedia Layer http www libsdl org BK09 D J Barnes M K lling Java lernen mit BlueJ Eine Einf hrung in die objektorientierte Programmierung 4 Auflage Pearson Studium 2009 Boe07 J Boerstler Objektorientiertes Program mieren Machen wir irgendwas falsch Didak tik der Informatik in Theorie und Praxis 2007 http subs emis de LNI Proceedings Proceedin gs112 html Seiten 9 20 2007 Bol08 D Boles Programmieren spielend gelernt mit dem Java Hamster Modell 4 Auflage Vieweg Teubner Wiesbaden 2008 Bol09 D Boles Threadnocchio Einsatz von Vi sualisierungstechniken zum spielerischen Er lernen der parallelen Programmie
139. back Zyklen durch die die Lehrenden zeitnah eben Just in Time auf Probleme der Studierenden eingehen k nnen Wir setzten diese Lehr und Lerntechnik erstmals in unseren Software Enginee ring Kursen f r Master und Bachelorstudieng nge ein und schildern unsere Erfahrungen mit dieser Technik Au erdem erweitern wir sie durch einen weiteren Feedback Zyklus den wir im Bereich Software Engineering f r unabdingbar halten Einf hrung Die klassische Vorlesung in der die Lehrenden versuchen die Lehrinhalte durch Vorlesen eines Manuskripts den Studierenden zu vermitteln ge h rt zumindest in der Informatik Ausbildung gl cklicherweise l ngst der Vergangenheit an Aber auch beim heute blichen Vortrag mit Powerpoint Unterst tzung stellen wir fest dass mit der ber mittlung des Lernstoffes auf diese Weise nicht das gew nschte Ma des Lernens desselben stattfindet Den Lehrenden stehen mit den konstruktivisti schen Methodenbauk sten Methodenpool Reich 2008 und der Methodensammlung Macke 2009 Ideenquellen zur Ausgestaltung eines aktivie renden Lernprozesses zur Verf gung Erste positi ve Versuche im Einsatz dieser Methoden findet man beispielsweise in Mottok 2009 2010 2012 und Hagel 2010 Ein weiterer aktivierender Ansatz der die klas sische und auch die heute h ufige Vorlesung quasi auf den Kopf stellt ist das Just in Time Teaching Es wird seit Ende des vergangenen Jahrtausends in wec
140. benden Arbeitsprodukte durch den Dozenten erge ben sich bei den Studierenden Fragen Es werden nicht direkt Antworten gegeben welche Schritte in welcher Reihenfolge durchgef hrt werden m ssen Jedoch merken sie schnell dass die Antworten sie A Spillner H Lichter Hrsg SEUH 13 in die richtige Richtung leiten Wenn die Studie renden gute Fragen zu stellen erhalten sie vom Dozenten immer mehr Information Dies ist auch ein Lernziel Fragen zu stellen wenn Dinge nicht komplett verstanden sind Vertiefung spezieller Themen bei Bedarf Bei Bedarf werden im Projekt spezielle Themen vertieft zum Beispiel bei Fragen der Studierenden oder durch den Dozenten erkannten Unklarheiten Die Erfahrung zeigt dass manche Themen in jedem Projekt diskutiert werden m ssen Dies liegt zum Teil an speziellen Eigenschaften von eingebetteten Systemen aber auch zu allgemeinen Begriffen der Informatik besteht oft Kl rungsbedarf Beispielsweise werden meistens die Begriffe Archi tektur und Design Goll 2011 Starke 2008 Safety und Security L w 2010 synchrone und asyn chrone Kommunikation Bengel 2008 Nebenl u figkeit und Synchronisation Vogt 2012 und kriti scher Pfad Wikipedia Kritischer Pfad 2012 an hand von Beispielen diskutiert um ein besseres Verst ndnis bei allen Studierenden zu erreichen Oft werden verschiede Entwicklungsans tze vom Wasserfallmodell bis hin zu agilen Ans tzen Summerville 2007 Vliet 2008
141. bgaben Folien zu erstellen sondern die Pr sentation basierend auf den abge gebenen Arbeitsprodukten zu gestalten So werden die Anforderungen anhand eines Textdokuments oder die Architektur anhand von Architektursich ten in Architektur Werkzeugen oder in anderen Dokumenten vorgestellt In der Praxis werden Themen oft anhand der Arbeitsprodukte bespro chen ohne aufw ndige Pr sentationen zu erstellen An diesen Stellen werden die Studierenden immer wieder angeleitet Dokumentation im sinnvollen Umfang anzufertigen Sie soll der Kommunikation dienen und verst ndlich sein Schlie lich ist f r die Projekte in der Praxis gegen ber den kleinen Projekten im Studium an den Hochschulen die Teamarbeit sehr viel wichtiger Dies wird den Studierenden nahe gebracht in dem einerseits die Aufteilung der Arbeit in parallel zu erstellende Arbeitspakete notwendig ist anderer seits aber die Arbeitspakete auch voneinander ab h ngen so dass Abh ngigkeiten der verschiedenen Mitglieder in den Teams bestehen und eine gute Zusammenarbeit unerl sslich ist berraschendes Ein weiterer wichtiger Baustein ist das Erzeugen von Aha Effekten Dabei wird das Ziel verfolgt bei A Spillner H Lichter Hrsg SEUH 13 den Studierenden wichtige Aspekte im Ged chtnis zu verankern weil sie diese nicht nur erz hlt be kommen sondern selbst erleben Dies geschieht zum Beispiel durch starke bertreibung bewusste Fehlinterpretationen oder das Vo
142. bleme rechtzeitig zu erkennen und einzusch tzen ben tigen also ein gewisses Problembewusstsein um im richtigen Moment angemessen agieren und reagieren zu k nnen Software Ingenieure m ssen ihr erworbe nes Wissen st ndig auf neue Situationen anpassen und erlernte Methoden selbst ndig anwenden Dieser Artikel konkretisiert und strukturiert den Kompetenzbegriff im Kontext von Software Engineering und stellt ein Modell zur Beschreibung von Kompetenzen vor Er beleuchtet wie es entwi ckelt wurde und welche Anforderungen es erf llen soll Er zeigt auf Grundlage des vorgeschlagenen Beschreibungsmodells erste Ergebnisse zu Soll Kompetenzen eines Software Ingenieurs 2 Forschungsinteresse Ein Software Ingenieur ben tigt neben einer Viel zahl an fachlichen auch berfachliche Kompeten zen damit er sein fachliches Wissen in komplexen Situationen berhaupt erfolgreich umsetzen kann Da es in Lernprozessen keine direkten und klaren Ursache Wirkungs Zusammenh nge gibt k nnen Kompetenzen lediglich trainiert und gef rdert jedoch nicht direkt vermittelt werden Das stellt die Hochschulausbildung im Software Engineering vor gro e Herausforderungen Sie m chte sowohl fach liche als auch berfachliche Kompetenzen im Soft ware Engineering trainieren Daher starteten sechs bayerische Hochschulen das Projekt EVELIN Ex 117 perimentelle VErbesserung des Lernens von Soft ware EngINeering um genau hier anzusetzen und das Lehren
143. bnis bergabe m m L l Unterziel 1 1 a Unterziel Unterziel 1 1 1 1 1 2 rn N zugeschnittene Metriken Fragen Abbildung 2 bersicht ber die GQM Methode Einordnung der Prozessschritte und Formulare ginn darum steht Alternativ k nnen auch nachge messene Werte eingetragen werden 3 Unten rechts Der Anwender stellt Einflusshypo thesen f r jeden Qualit tsfaktor auf Wie k nnte der Qualit tsfaktor zu beeinflussen sein 4 Oben rechts Aus den Einflusshypothesen werden Einflussfaktoren extrahiert Abb 3 zeigt ein ausgef lltes AS Obwohl die Anfor derungen an den Inhalt eines Quadranten klar defi niert sind bereitet es Studenten fter Schwierigkeiten korrekte und brauchbare AS zu produzieren Auf einen Studierenden der das Konzept des Ab straction Sheets noch nicht vollst ndig durchdrungen hat kann dieses Formular abschreckend und komplex wirken Z hlt man das Eintragen des Messziels mit so werden mehr als vier verschiedene Abfragen an den Studierenden gestellt Hinzu kommt dass die se Felder konzeptbedingt jeweils eng gefasste Ziele verfolgen und korrekte Antworten f r die erfolgrei che Anwendung voraussetzen Werden z B im ersten Quadranten die Qualit tsfaktoren nicht mit konkre tisierenden Attributen belegt sondern bleiben so abstrakt wie das Messziel so f hrt das Abstraction Sheet nicht zu dem gew nschten Ergebnis In Abb 3 w rde
144. cht n her auf die Benotungskriterien ein es werden nur Kol loquien und automatisierte Systemtests als Pr fkri terien genannt Ein wenig detaillierter berichtet Metzger 2003 der in seinem Projekt zu 50 die Individualleistung und zu 50 die Gruppenleistung bewertet hat Zur Gruppenleistung tragen die Abgaben zu den 112 einzelnen Aufgaben und die Abschlusspr sentation bei In die Individualbewertung flie t die Leistung w hrend der Pr senzzeiten und die Qualit t des Einzelvortrags ein Konkrete Bewertungskriterien f r die Leistungen der Studierenden werden aller dings wiederum nicht genannt Predoiu 2010 hat j ngst ein Konzept vorgestellt in dem Artefakt Bewertungen durch einen Betreuer mit Peer Asses sments der Studierenden kombiniert werden um eine individuelle Benotung zu erm glichen Dazu werden zu Beginn eines Projekts Artefakte von Seiten des Betreuers den Meilensteinen zugeordnet jeder Studierende muss pro Meilenstein mindes tens ein Artefakt bearbeiten und wird zeitnah nach der Abgabe in einer Assessmentsitzung benotet Vorteile dieses Vorgehens sind sicher die kontinu ierliche Bewertung der Teilnehmer und der enge Kontakt zwischen Studierenden und Betreuer letz terer kann sich aber z B hinsichtlich Skalierbarkeit bei vielen Studierenden auch als nachteilig erwei sen Erprobt wurde das System in einer Kleingrup pe mit weniger als zehn Teilnehmern Zudem gibt es in Predoius Vorschlag keine teambasie
145. ckkopplung und Diskussion die Problematik verdeutlicht und n her gebracht werden Dass die Ausbildung in den Bereichen Pro grammierung und Software Engineering viele Schnittstellen hat ist unbestritten Diesem Thema widmen sich die Beitr ge unter dem Stichpunkt Programmierausbildung Sie diskutieren wie diese Schnittstellen zum Vorteil von beiden Ausbil dungsschwerpunkten genutzt werden k nnen und wie die enge Verzahnung vorteilhaft umgesetzt werden kann Agile Methoden haben in den letzten Jahren ih ren Weg in die Praxis gefunden sie werden dort erprobt und eingesetzt Die SEUH greift dieses Thema im Schwerpunkt Agile Methoden im Unter richt auf Es werden erste interessante Erfahrungen berichtet ber die auf dieser SEUH sicherlich in tensiv diskutiert werden wird Werkzeuge spielen in der Ausbildung eine we sentliche Rolle entweder zur Entwicklung von Software oder aber als Mittel um Lerninhalte effi zient und effektiv vermitteln zu k nnen Dieses spiegeln die Beitr ge zum Thema Werkzeuge in und f r die Ausbildung wider Dort werden ein Werk A Spillner H Lichter Hrsg SEUH 13 zeug zur spielerischen Vermittlung von Entwick lungsprozessen und ein Werkzeug zur Auswahl und zum Einsatz von Metriken vorgestellt Daneben gibt es auch in diesem Jahr wieder neue Ideen wie wir unser Wissen im Software En gineering besser und nachhaltiger an Studierende vermitteln k nnen Unter dem Punkt Zur Diskussi on gestellt
146. come over News from your lecturer course meeting 12 00 room 15 Send a message to your lecturer Abb 3 Mockup mit Kollaborationselementen Dazu bietet das Spiel die M glichkeit einzelne Spielabschnitte zu wiederholen Wiederholbarkeit in Kombination mit verf gbarer Orientierung un terst tzt die Analyse und Reflexion get tigter Schritte und f rdert somit die Anwendung des im Spiel erworbenen Wissens Gleichzeitig st rkt Sie das Gef hl der Selbststeuerung control der Spielenden und steigert damit deren Motivation An dieser Stelle zeigt sich eine Qualit t welche in Kursprojekten in dieser komprimierten Form A Spillner H Lichter Hrsg SEUH 13 det Auf das Team bezogen dr ckt es aus dass Austin innerhalb seines Teams von vier Teammit gliedern am zweitbesten agiert hat Ein Teammit glied hat bisher also noch bessere Entscheidungen getroffen Dies ist in diesem Beispiel Anlass f r eine kleine Diskussion im Team Chat Die Team mitglieder verabreden sich zu einem pers nlichen Treffen in welchem Entscheidungen analysiert und optimiert werden 135 Eine Architektur welche Lehrenden einen schnellen berblick ber den Spielfortschritt des gesamten Kurses bietet unterst tzt die gezielte Interaktion bei Verst ndnisproblemen sowie die kursweite vergleichende Auswertung und reflek tierende Nachbesprechung der Spielergebnisse Nutzung von Synergien mit Industriestan dards Der einheitliche Zugang zu Sof
147. d Apply Analyze Evaluate Create A Factual Knowledge B Conceptual Knowledge C Procedural Knowledge D Metacognitive Knowledge Abb 1 Lernzieltaxonomie nach Anderson und Krathwohl 2001 Eine weitere nderung ist der Verzicht auf die kumulativen Eigenschaften der Klassen Bei der Anwendung dieser Taxonomie zeigen sich jedoch grundlegende Probleme Lehrziele bzw Kompetenzen m ssen in diesem Schema immer sowohl einer Wissenskategorie als auch einer Kate gorie in der kognitiven Dimension zugeordnet werden Dabei soll die Formulierung der Lehrziele einen Hinweis f r die Einordnung in das Schema geben was auch die eigentliche Intension des Mo dells erkennen l sst Es soll in erster Linie ein Pla nungs und Kontrollwerkzeug f r den Unterricht sein und geht davon aus dass bereits formulierte Lehrziele existieren Anderson und Krathwohl 2001 Im Rahmen von EVELIN sollen Soll Kompe tenzprofile f r Software Engineering entstehen aus denen erst sp ter Lehrziele abgeleitet werden Ge nerell erh ht die Aufteilung in ein zweidimensio nales Schema die Komplexit t da sich f r jede zu beschreibende Kompetenz 24 Klassifizierungsm g lichkeiten ergeben Zu diesem Schluss kommen auch Fuller et al 2007 Aufgrund der Tatsache dass h here Klassen in diesem Modell die darun terliegenden Klassen nicht subsumieren erlaubt das Modell die berlappung von Klassen Ein Lehrziel ka
148. d Ausblick Wie unsere und auch internationale Studien zeigen sind agile Software Entwicklungsmethoden in der Praxis sehr stark im Kommen In der Ingenieur Ausbildung m ssen wir uns den ge nderten Kom petenzanforderungen stellen und unsere Ausbil dungskonzepte entsprechend anpassen und erwei tern Im vorliegenden Artikel haben wir beschrieben wie wir die Vermittlung von agilen Softwareent wicklungsmethoden an unseren Fachhochschulen integriert haben Die Erfahrungen damit sind sehr positiv und die erzielten Erfolge stimmen zuver sichtlich Erste Feedbacks aus der Praxis ber die Kompetenzen der Abg nger best tigen unseren eingeschlagenen Weg Eine generelle Herausforderung bleibt die agilen Konzepte nicht nur in einzelnen Modulen zu unter 88 richten sondern diese in m glichst vielen pro grammier nahen Modulen anzuwenden und zu vermitteln was generell ein Wechsel des Unter richtskonzept der isolierten Fachmodule hin zu einem integrativem Gesamtstudienkonzept bedeu tet Auf Master Stufe wollen wir die Vermittlung fort geschrittenen Engineering und Management Practices weiter ausbauen da diese in Zukunft eine zuneh mende Bedeutung erlangen werden Zum Schluss sei angemerkt dass auch die agilen Softwareentwicklungsmethoden nicht das Ende der Entwicklung der Softwareprozesse darstellen Die Informatik ist immer noch eine sehr junge Diszip lin deren Entwicklungsprozessmodelle sich stetig weiterentwickeln werd
149. d an der Wissensvermittlung Eingebettete Systeme und deren Entwicklung ha ben viele Gemeinsamkeiten mit nicht eingebetteten Systemen aber auch einige Unterschiede In erster Linie sind es oft harte Echtzeit Anforderungen begrenzte Ressourcen und eine starke N he zur Hardware Barr 1999 Kienzle 2009 Die Entwick lung orientiert sich meist stark an den Qualit ts merkmalen Verf gbarkeit Sicherheit Betriebssi cherheit und Angriffssicherheit Kosten und Ma nagement der Varianten und Versionenvielfalt In der Realisierung kommen h ufig zeitgesteuerte Systeme zur Anwendung und die erstellte Software l uft nicht auf dem Computer auf dem sie entwi ckelt wurde Diese Unterschiede und deren Aus wirkungen f r die Entwicklung sind insbesondere Studierenden der Informatik h ufig nicht bewusst Das Projekt schafft dieses Bewusstsein In der Praxis werden im Zeitalter einer immer h heren Durchdringung der Welt mit Computern Mattern 2012 noch mehr Personen f r die Ent 28 wicklung eingebetteter Systeme ben tigt Das Pro jekt zielt darauf ab bei den Studierenden Begeiste rung f r dieses interessante Themengebiet zu we cken Die Begeisterung resultiert auch aus dem zu entwickelnden Endprodukt Die Ampeln leuchten und lassen sich durch Kn pfe beeinflussen und der Aufzug bewegt sich Am Ende der Hochschulausbildung ist es notwen dig den Einstieg der Studierenden in die Praxis zu erleichtern Dazu gibt es in vielen I
150. daktische Heran gehensweise Objects first BK09 zur ck zu f h ren ist bei der von Anfang an auf die Entwicklung von Objekten und Klassen gesetzt wird Die Grundidee besteht darin sich m glichst fr h mit den zentralen Strukturen der Objektorientie rung auseinander zu setzen Der Objektbegriff selbst ist intuitiv und Studierende finden ihn oft in ihrer realen Welt wieder sei es selbst als Student Objekt in der Software der Hochschulverwaltung oder als Kundin die ein Konto Objekt nutzt Gene rell bietet sich hier die Hochschule zur Modellie rung an da Studienanf nger neu in diesem System sind in das sie sich f r drei oder mehr Jahre einar beiten sollen So kann z B der Modul Begriff und sein Zusammenhang zur konkreten Vorlesung genauer analysiert werden Setzt man den Objekt Begriff an den Anfang spie len Begriffe wie Objekt Objektvariable auch Exemplarvariable Instanzvariable oder Attribut genannt konkrete Werte der Variablen Objekte die andere Objekte als Eigenschaft haben und Sammlungen von Objekten zun chst die zentrale Rolle In Java st t man dann schnell auf den Typ Begriff da jede Variable einen Typen haben muss was entweder ein elementarer Typ aus der C Welt oder wieder eine Klasse sein kann Im n chsten Schritt werden Methoden und Parameter betrach tet wobei hier der leider inkonsistente Ansatz von Kopien bei elementaren Typen und Referenzen bei Objekten zum ersten Bruch f hrt Die eigentl
151. dardi sierte Leistungsmessung im Fach Deutsch In Bremerich Vos A Granzer D K ller O Hrsg 2008 Lernstandsbestimmung im Fach Deutsch Gute Aufgaben f r den Unterricht Weinheim Beltz 10 49 Glaser B Strau A 1998 Grounded theory Strategien qualitativer Forschung Bern Hans Huber Sedelmaier Y Landes D 2012 A research agenda for identifying and developing required competencies in software engineering Proc Int Conference on Interactive Collaborative Learn ing 2012 Weinert F 2001 Leistungsmessung in Schulen 2 Auflage Weinheim Beltz A Spillner H Lichter Hrsg SEUH 13 ee ca Tie a Session5 i Br Pi Werkzeuge in und fur die Ausbildung Alles nur Spielerei Neue Ans tze f r digitales spielbasiertes Lernen von Softwareprozessen J ran Pieper Institute for Applied Computer Science FH Stralsund Joeran Pieper fh stralsund de Zusammenfassung Softwareprozesse beschreiben Ans tze f r die Pro duktion und Evolution von Software Sie geh ren zu den Wissensgebieten des Software Engineering SE die sich weniger gut allein durch klassische Vorlesungen vermitteln lassen Kursprojekte die Vorlesungen h ufig begleiten werden durch aka demische Rahmenbedingungen begrenzt Simulation und Digital Game Based Learning DGBL werden gro e Potentiale bei der Erweite rung der Lernerfahrung ber Vorlesungen und Kursprojekte hinaus zugesproc
152. das Studierende ber verschiedene Pfa de erreichen k nnen Dabei bewegt sich der Lern prozess vom Startpunkt aus sequenziell entlang der Ebenen zum n chsth heren Level Im Lernprozess kann kein Feld bersprungen werden und es ist immer nur eine Bewegung von links nach rechts bzw von unten nach oben m glich Im Normalfall beginnt der Lernprozess dabei in REMEBER NONE Hier wird deutlich dass eine andere Zielset zung als die unseres Projektes vorliegt Bei Fuller et al liegt der Fokus auf der Beschreibung Beobach tung und Planung von Lernpfaden einzelner Stu dierender oder homogener Studierendengruppen Wahrend Fuller et al Prozesse analysieren beab sichtigt EVELIN zun chst Zust nde zu beschrei ben 7 4 Das EVELIN Modell zur Beschreibung von fachlichen Kompetenzen Keines der analysierten Modelle eignet sich unein geschr nkt f r eine Kompetenzbeschreibung im Rahmen von EVELIN F r fachliche Kompetenzen wurde daher ein eigenes Modell entwickelt das bewusst wesentliche Elemente bestehender Taxo nomien aufgreift um sie im Hinblick auf die bereits genannten Anforderungen sinnvoll zu kombinieren und zu erweitern Das EVELIN Modell vgl Abbildung 3 besteht aus den Klassen Erinnern Verstehen Erkl ren Verwenden Anwenden und Weiter Entwickeln die sich wie folgt charakterisieren lassen 123 o S 3 u Verstehen Erkl ren 2 f Pa 2 g e 2 Erinnern Entwickeln 2 3 Q 2 2 3 Verwenden
153. dass Testat 5 ein h heres Niveau aufweist als Testat 4 Da die Lehrenden nicht zwangsl ufig dasselbe Be wertungsschema f r Miniprojekte und Testate anleg ten lassen sich diese Annahmen nicht unmittelbar ber die im Mittel erreichten Punktzahlen best tigen oder widerlegen Im Miniprojekt 4 wurden im arith metischen Mittel 71 29 von 100 m glichen Punkten erreicht im Testat 4 ber alle drei Varianten im arith 66 metischen Mittel 63 38 Punkte Im Miniprojekt 5 wur den im arithmetischen Mittel 48 57 Punkte erreicht in allen drei Varianten der Testate im arithmetischen Mittel 45 28 Punkte Das vermutete h here relative Aufgabenniveau bei Testat 5 im Vergleich zu Minipro jekt 5 spiegelt sich also nicht in der Ver nderung der Punktzahlen wider Lediglich im Vergleich der beiden Testate untereinander tritt die erwartete Punkte nde rung auf Die Schwierigkeit der Bestimmung des relativen Aufgabenniveaus unterstreicht auch Abbildung 7 die die Verteilung f r die erste Variante von Testat 6 wi dergibt Bei den Komplexit tswerten liegt diese in der Mitte des Bereichs f r Miniprojekt 6 bei der Anzahl der Anweisungen im unteren Bereich Im Vergleich mit Testat 4 weist sie insbesondere eine h here Kom plexit t aber einen geringeren Umfang der L sungen aus Im Bezug auf Miniprojekt 6 kann also ein leichte res Niveau angenommen werden w hrend im Bezug auf Testat 4 unklar ist ob die h here Komplexit t oder der geringere Um
154. dass diese Umgebungen die Einbettung von Lern Fie Edit Search Configuration Window Help Geen Ort 0 0 I iii 5 E Browsng mi Au SS gt intheir daily activities tion 1 n 1 Li s Milestone 6 ff Elaboration iteration 1 n S This deineny process defines an end to end software development lifecycle that supports the core principles of OpenUP R is designed to support small codocated teams Work Breakdown Structure Steps Index Predecessors Model Info Type Expand All Sections Collapse All Sections Planned Repeatable Multiple Occurrences Ongoing Event Driven Optional Team Activity v Milestone v Activity v v Activity v Activity v Activity v Activity v v Task Descriptor Task Descriptor Task Descriotor Abb 4 EPF Composer im Einsatz EPF stellt ber diese Werkzeuge hinaus bereits eine umfangreiche Bibliothek von Softwareprozess inhalten bereit Die Nutzung dieser Industriestandards zur Ge nerierung von Teilen der Simulationsmodelle als Basis digitaler Spiele bietet eine Reihe von Vortei len Rollen Phasen Aufgaben Prozessschritte Artefakte Templates und Leitf den k nnen extra hiert und in die Simulations und Spielwelt einge bettet werden Bereits vorhandene Inhalte der EPF Bibliothek werden dabei effizient genutzt Neue 136 material nicht unterst tzen Die Verwendung des Eclipse Process Framework EPF bietet sich auch an um Ler
155. dass immer zwei Studen ten ein Ticket gemeinsam an einem Rechner bearbei ten Damit sich Wissen zwischen m glichst vielen Teil nehmern gut verteilt ermutigen wir die Studenten zu regelm igem Wechsel des Programmierpartners Wir halten daf r in einer Matrix fest wer schon mit wem zusammen entwickelt hat Dieses Verfahren wurde aus fr heren Praktika ohne nderung bernommen Allgemein beinhaltet der t gliche Arbeitstag ein Stand up Treffen am Morgen und am Abend sowie ein gemeinsames selbstorganisiertes Teamfr hst ck vor Beginn der Arbeit W chentlich gibt es eine Re trospektive Beck u Andres 2004 in der reflektiert wird was in der Woche erreicht wurde und was man verbessern k nnte Die drei Lehrkr fte ben w hrend des Praktikums feste aber verschiedene Rollen aus Wie bereits in M gge u a 2004 ausgef hrt hat sich die Dreitei lung Kunde Teamleiter und technischer Experte am bes ten bew hrt Der Kunde legt fest was er als Produkt entwickelt haben m chte und welche Funktionalit ten er sich w nscht Das resultierende Produkt kann entweder etwas sein was in der Forschung genutzt wird oder was von der Industrie an uns herangetragen wird Der Kunde ist auch in den t glichen Entwick lungsprozess eingebunden wie im Extreme Program ming blich Das t gliche Projektmanagement des Teams wird von der Rolle des Teamleiters ausge bt Dieser stellt die Br cke zwischen dem Entwicklerteam und dem Kunden dar Die
156. deckung des fachlichen Spektrums und unterschiedliche Perspektiven Folgt man der Grounded Theory gen gt dies um erste Annah men und Hypothesen zu bilden die dann den Ausgangspunkt f r die weitere Forschung bilden jedoch noch nicht den Anspruch haben eine bereits vorhandene These zu validieren 7 Wie kann man Kompetenzen sinnvoll beschreiben Zun chst sind Kompetenzen mittels eines geeigne ten Modells zu analysieren und beschreiben Dazu wurden existierende Klassifikationsschemata auf ihre Eignung im EVELIN Kontext berpr ft 7 1 Generelle Anforderungen an ein Be schreibungsmodell Die Untersuchung vorhandener Schemata ergab ein klares Bild der Anforderungen an ein geeignetes Beschreibungsmodell im EVELIN Kontext Ein Kompetenzprofil f r Software Engineering ist keine rein inhaltliche Sammlung von Stichworten denn aufgrund der Anwendung in verschiedenen Fach disziplinen soll es auch ausdr cken k nnen wie gut Studierende die jeweilige Kompetenz beherr schen Auch darf ein Kompetenzprofil nicht auf Lehrzielebene formuliert sein denn hier muss auf grund der verschiedenen Schwerpunkte einzelner Studieng nge und der Vorstellungen und Priorisie rungen der Lehrenden eine gewisse Flexibilit t vorhanden sein Gleichzeitig muss ein Beschrei bungssystem auch die Beschreibung Strukturie rung und Einordnung von Lehrzielen unterst tzen so dass es als Kompass f r die Lehr Lern Planung anwendbar ist Die Lehrziele leite
157. deen f r die Zukunft Das Projekt hat sich ber die Jahre immer weiter entwickelt Drei kombinierbare Ideen f r die zu k nftige Entwicklung werden kurz aufgelistet e Ein Roboter ist anzusteuern dies erfordert in der Software gegebenenfalls ein Umweltmodell e Die Steuerung erfolgt ber eine ebenfalls zu erstellende App Dazu w rden neue Controller mit entsprechenden Schnittstellen ben tigt e Der Teambuilding Aspekt wird in das Projekt eingebracht angelehnt an Schmedding 2011 Checkliste als Zusammenfassung Das Ziel dieser Arbeit ist es die Konzepte hinter dem mehrfach durchgef hrten und verbesserten Projekt offen zu legen und von den Erfahrungen zu berichten Daher werden als Zusammenfassung abschlie end die aus Sicht des Autors wesentlichen Erfolgsfaktoren aufgelistet um Projekte mit gutem Lernerfolg f r die Studierenden durchzuf hren O Ist das zu l sende Problem nicht zu komplex O Werden essentielle Schritte der Software Entwicklung im Kleinen erlebt O Sind die Ziele und nicht die Wege vorgegeben O Werden die Studierenden beim Finden guter Wege hinreichend unterst tzt O Pr sentieren die Studierenden ihre Ergebnisse O Gibtes eingeplante Fallstricke O Werden elementare Aspekte durch Konzepte wie Rollenspiele nachhaltig vermittelt O Werden die Studierenden angeregt ber ihr Vorgehen nachzudenken O Sind die Dozierenden f r notwendige Unter st tzung gut erreichbar O B
158. definiert sind oder die noch nicht realisierbar sind Dies entspricht dem Backlog des Scrum Prozesses mit dem Unter schied dass die Tickets noch nicht von dem Team gesch tzt wurden und sie noch in Bearbeitung sind Die Input Queue Phase wird von dem Kunden kon trolliert und bestimmt welches das n chste zu entwi ckelnde Feature ist In der Analyse wird mit dem Kunden zusammen festgelegt was alles zu der Realisierung des Tickets geh rt d h es werden Akzeptanzkriterien festgelegt Au erdem nimmt das Team in der Analyse eine Zerle gung des Tickets in kleinere sogenannte Tasks vor Die se Unterscheidung von Tickets die einen durch den Kunden wahrnehmbaren Funktionalit tsfortschritt ha ben User Stories und den dazu n tigen Arbeits schritten Tasks haben wir aus den vorhergehenden Praktika bernommen Dadurch wird es m glich ei nerseits die Teilschritte genau zu beschreiben und auf 94 unterschiedliche Entwicklerpaare zu verteilen und an dererseits bleibt der angestrebte Fortschritt sichtbar und verschwindet nicht hinter technischen Details Die Implementation findet in der Development Phase statt Anschlie end werden sowohl ein Team interner Codereview als auch ein gemeinsamer Review mit dem Kunden durchgef hrt Nach erfolgreichem Ab schluss der Reviews ist ein Ticket in der Live Phase angelangt Zur Visualisierung der Phasen auf einem White board wurde je Phase eine Spalte verwendet siehe Abbildung 2 D
159. den anderen Aufgaben den geringsten Freiheitsgrad aufweist Fast alle L sungen liegen in einem kompakten Bereich zwischen 200 und etwas mehr als 300 Anweisungen und weisen einen Komplexit tswert zwischen knapp 70 und 100 auf Die untere Grenze des Bereichs ergibt sich dabei automa tisch aus Umfang und Komplexit t der bereitgestellten Codevorlage Einen deutlich h heren Freiheitsgrad weist Minipro jekt 5 Abbildung 2 auf Umfang und Komplexit t der Codevorlage entsprachen zwar in etwa den Werten aus Miniprojekt 4 aber die L sungen verteilen sich in einem deutlich gr eren Raum Bis zu einem Umfang von 700 Anweisungen und einem Komplexit tswert von 200 ist der gesamte L sungsraum abgedeckt je doch in einem hnlich schmalen Band wie bei Mini projekt 4 Dass es sich bei beiden Aufgaben um echte Freiheitsgrade und nicht nur die notwendige Differenz zwischen unvollst ndiger Codevorlage und minima ler korrekter L sung handelt zeigt sich dadurch dass es in beiden Aufgaben bereits im unteren Drittel der gemessenen Werte bestandene L sungen gibt Dieselbe Beobachtung gilt auch f r Miniprojekt 6 Abbildung 3 auch wenn hier weniger hohe Werte f r die Zahl der Anweisungen erreicht werden Bemer kenswert ist hier jedoch die etwas breitere Streuung des Korridors in dem die L sungen liegen W hrend in den ersten beiden betrachteten Aufgaben also eine recht starke Korrelation zwischen Umfang und Kom plexit t galt l sst diese Au
160. der holbar genau die Leistung eines Studierenden oder eines Teams bei der Erstellung des Systems bewer tet die bewertet werden soll Somit ergibt sich auch ein hoher Nutzen f r Pr fer und Studierende da beide ein gutes Feedback ber den tats chlichen Leistungsstand der Studierenden erhalten Einzig signifikante Schw che des Verfahrens ist der recht hohe Bewertungsaufwand der sich bei einem ein semestrigen Projekt mit ca vier Studierenden pro Team schnell auf vier und mehr Stunden pro Team belaufen kann Legt man ca f nf ECTS und damit insgesamt rund 600 Stunden Arbeitslast f r eine Viergruppe von Studierenden zugrunde relativiert 111 sich diese Zahl allerdings wieder wie auch im Ver gleich zu einer Klausur die oft einen noch h heren Korrekturaufwand ben tigt Zudem l sst sich durch klare Vorgaben f r die geforderten Abgaben z B direkt ausf hrbares System Quellcode mit klarer Struktur in einem Versionierungssystem Dokumente mit einer gewissen Struktur und klare Benennung der Urheber signifikant Zeit bei der Bewertung einsparen Verwandte Arbeiten In der Literatur ist zwar eine erkleckliche Menge von Berichten ber Softwareentwicklungsprojekte an Hochschulen verf gbar die dort gemachten Aussagen ber das verwendete Bewertungsverfah ren beschr nken sich aber meist auf wenige S tze Systematische Vergleiche verschiedener Ans tze finden sich daher leider ebenso wenig wie auch empirische Studien zur Zufri
161. der Lehrveranstaltung der nicht im Voraus erbracht werden kann vgl hierzu auch Fleischer 2004 Durch die Interaktion mit den Stu dierenden und das direkte Anpassen der Lehrin halte an deren Vorwissen kann eine Vorbereitung erst in letzter Minute Just in Time eben erfol gen Gerade bei Lehrveranstaltungen mit 50 Studie renden und mehr ist der Ansatz ohne eine automa tische Auswertung der Fragen nicht realistisch Just in Time durchf hrbar Peter Riegler weist jedoch in Riegler 2012 darauf hin dass die Ant worten bei vielen Studierenden auch mit der Un terst tzung von Hilfslehrenden gesichtet werden k nnen Wird die gleiche Lehrveranstaltung zum wie derholten Male gehalten geht der Aufwand jedoch zur ck Die Fragen f r die Studierenden f r den Selbststudiumsanteil k nnen beibehalten werden Auch wird man mehr und mehr feststellen dass die Studierenden h ufig mit den gleichen Inhalten der Veranstaltung Probleme haben so dass die Vorbereitung der Lehrveranstaltung zu einem er heblichen Anteil identisch ist Die Just in Time Komponente bleibt mit ihrem Aufwand jedoch erhalten Eine weitere Herausforderung f r die Lehren den sind die zu erstellenden Fragen f r den online Teil aber auch f r die Lehrveranstaltung Es sollen ja nicht nur die Kernaussagen der B cher abgefragt werden sondern auch Konzepte verstanden und Methoden gelernt und angewandt werden Denkbar w re auch eine echte Firmenpr sen
162. der ersten Umsetzung des neuen Ansatzes waren relativ schlecht da es durch einen doppelten Abiturjahrgang und Wie derholer die diese neue Veranstaltung auch h ren mussten zu einer sehr hohen Teilnehmerzahl mit anf nglich schlechter r umlicher Ausstattung kam Statistiken zeigen dass dieser erste Ansatz trotz schlechter Rahmenbedingungen nicht schlechter abgeschlossen hat als der vorherige Weg Weiter hin zeigte die Analyse eine Herausforderung dass alle an einer Lehrveranstaltung Beteiligten das Konzept der Vorlesung verstehen und aktiv f r dern m ssen Dies ist gerade wichtig da es dauert bis die Welt aus Objekten Klassen und Methoden in den K pfen verankert wird was den zweiten Teil einer Lehrveranstaltung mit den Ablaufsteue rungen dann aber deutlich vereinfacht da sich hier die objektorientierten Strukturen festigen Da im konkreten Fall nicht gen gend Zeit zur Schulung der Beteiligten vorlag und diese auch ihre eigenen Vorstellungen vom Programmieren vermitteln wollten konnte der Weg in den zugeh rigen Prak tika nicht immer konsequent beschritten werden Die Wiederholung der Veranstaltung hatte mit deutlich geringeren Studierendenzahlen bessere Voraussetzungen wobei sich dann klar die Vorteile des Ansatzes mit einer geringeren Durchfallquote die von 32 2 auf 20 9 sank wobei die Quote bei den Erstsemestern von 16 9 auf 12 zur ckging zeigten Im Folgeverlauf konnten einige Studierende bereits im zweiten
163. ders also Tritt brettfahrer dadurch zu erkennen dass die Studie rende Stundenzettel zu f hren und einen vordefi nierten Prozess zu verwenden haben ferner sind w chentliche Feedback Gespr che mit den Betreu A Spillner H Lichter Hrsg SEUH 13 ern vorgesehen konkrete Nachweise der Pro grammierf higkeiten werden aber wiederum nicht verlangt ZUSAMMENFASSUNG Der vorliegende Beitrag beschreibt eine neuartige Zusammenstellung von Bewertungsverfahren zur Benotung von Softwareentwicklungsprojekten an Hochschulen und Universit ten Durch die Kombi nation eines automatisierten Programmiertestats mit mehreren Kolloquien und einem gewichteten Bewertungsraster f r im Verlauf des Projekts er stellte Artefakte erm glicht es die Komposition von teambasierten und individuellen Benotungsantei len sowie eine effektive Erkennung von sogenann ten Trittbrettfahrern Somit wird im Vergleich zu bisherigen Bewertungsans tzen eine wesentlich objektivere Bewertung m glich zudem wird die Nachvollziehbarkeit der Benotung durch die Stu dierenden deutlich verbessert Das vorgestellte Bewertungsraster f r in der Soft wareentwicklung erstellte Artefakte ist sicherlich die Kerninnovation dieses Beitrags die zuvor nur in der Arbeit von Wikstrand und B rstler 2006 in ann hernd hnlicher Form vorgeschlagen wurde Es bewertet im Gegensatz zu zahlreichen anderen Verfahren wie Klausuren bungsaufgaben oder auch Kolloquien direkt di
164. des Konzeptes ist die Fo kussierung auf die Praxisn he In der Umsetzung wird die zur Verf gung stehende Zeit weniger f r ein schwierig zu erstellendes System verwendet Vielmehr soll ein Verst ndnis f r die Phasen im Projekt die notwendigen Arbeitsprodukte und Ihre A Spillner H Lichter Hrsg SEUH 13 Abh ngigkeiten geschaffen werden Am Anfang des Studiums liegt der Fokus eher auf einzelnen Bausteinen am Ende des Studiums sollten sie ge eignet zusammengesetzt werden Das zu l sende Problem und die Implementierung sind wenig komplex aber doch nicht trivial Dies zeigt sich sowohl bei der Anforderungsanalyse als auch im weiteren Projektverlauf wenn im Team festgestellt wird dass die Anforderungen doch nicht eindeutig oder komplett waren Wie schon eingangs beschrieben werden die typi Schritte in der Embedded Software Entwicklung von der Anforderungsanalyse mit schen dem Kunden bis hin zur Implementierung und zum Test abgedeckt Realistische Projektsituationen werden partiell durchlebt Dazu m ssen entspre chende Arbeitspakete bearbeitet und vor der Ab gabe durch die Studierenden aus dem Team einem Review unterzogen werden Dies dient dem Ver st ndnis des Inhalts von Arbeitsprodukten und zeigt den Studierenden den Zusammenhang der in Entwicklungsprojekten ben tigten Dokumentation Die Ergebnisse m ssen durch die Ersteller vor allen Gruppen pr sentiert werden Dabei ist nicht unbe dingt das Ziel aus den A
165. det Dabei kann es sich um einen bestimmten Eintrag im Bugtracker des Projekts handeln oder um ein Ar chiv mit dem Quelltext der Software Dar ber hinaus erhalten die Studierenden Hinweise wel che Stelle des Systems relevant ist So ist sicherge stellt dass den Teilnehmenden beim Fragenteil der in begrenzter Zeit zu bearbeiten ist das ben tigte Material zur Verf gung steht und sie sich schon etwas mit dem System vertraut machen k nnen Dar ber hinaus werden die Studierenden motiviert sich Gedanken zu den m glicherweise im Fragenteil gestellten Fragen zu machen und 11 sich ein wenig im System umzusehen Das Ziel ist den Studierenden die Komplexi t t der Entwicklung realer Softwaresysteme zu verdeutlichen und sie anzuregen sich eigene Ge danken zum Thema der n chsten Vorlesung zu machen Dabei kommt es nicht darauf an die ge stellte Frage exakt zu beantworten Oftmals ist das auch gar nicht m glich da die Fragen be wusst so gestellt werden dass es mehrere rationa le Antworten gibt die nur entsprechend begr n det werden m ssen Eine solche Frage ist zum Beispiel ob bei Kenntnis eines bestimmten Fehlers im Softwaresystem die Ver ffentlichung verschoben werden soll Das Lernziel wird also schon durch das Bearbeiten der Aufgabe erreicht Die Aufgaben sind so gestellt dass das Bear beiten etwa 30 Minuten dauern sollte Durch die zeitlich begrenzte Freischaltung der Bearbeitung wird verhindert dass die
166. die Entwicklungsschritte wie z B Analyse oder Done In Kanban wird diese Praxis weiter verwendet und angereichert durch die in den f nf Kerneigen schaften genannten Imperative In Abbildung 1 sieht man ein Bild von einer Kanban Tafel aus dem hier vorgestellten Praktikum Diese Visualisierung wurde mit Stickern Whiteboard Stiften und Klebeband reali siert Die Verwendung dieser Materialien erlaubte uns flexibel das Board an das Entwicklerteam und andere Einfl sse anzupassen und so die Entwicklungsschritte f r das Team zu individualisieren Diese Flexibilit t ist wichtig da Kanban auf die Bed rfnisse zugeschnitten werden sollte und sich diese nderen k nnen Es sollte daher auch mit dem Team diskutiert werden was die Phasen bisher Entwicklungsschritte sind durch die die Tickets bisher User Stories bis zur Fertigstellung wandern Abbildung 1 Im Praktikum verwendetes Kanban Board Das weiter unten referenzierte Video bietet zus tzlich eine dynamische Perspektive auf das Board Im Folgenden verwenden wir allgemeine Kanban Konventionen und orientieren uns an Kanban Boards welche wir selber eingesetzt und entwickelt haben siehe Abbildung 2 Die Stories oder Tickets laufen in der Regel von links nach rechts auf dem Kanban Board und durch laufen dabei die Entwicklungsphasen bis sie fertig done sind Nachdem durch die 2 Kerneigenschaft die Tickets die in Arbeit sind begrenzt werden soll ten werden je
167. difiziert und die studentischen Ist Kompetenzen zu einem sp teren Zeitpunkt erneut erhoben Zuvor definierte Messkriterien zeigen ob und in welchem Ma sich die Kompetenzen ver n dert haben und lassen R ckschl sse auf die ver n derten Einflussvariablen zu Diese Messkriterien werden ber konkrete auf die Rahmenbedingun gen angepasste Lehrziele aus den Soll Kompeten zen abgeleitet Dieser Prozess wird mehrfach durchlaufen um ein besseres Verst ndnis ber die Einflussfaktoren auf das Lernen von Software Engineering zu erhal ten und um so den Lernprozess m glichst kompe tenzf rdernd gestalten zu k nnen Ausgehend von ersten Hypothesen und Daten sollen gezielte Ver nderungen und Modifikationen an den Lehr Lern Prozessen vorgenommen und dokumentiert werden so dass Schritt f r Schritt bestehende Lehrveranstaltungen weiterentwickelt werden k nnen Dabei werden wie bereits be schrieben Messkriterien festgelegt anhand derer Kompetenzentwicklung zu verschiedenen Zeit punkten ablesbar und vergleichbar sein soll Diese Daten werden dann zu verschiedenen Zeitpunkten erhoben Aus dem Vergleich der ver nderten Ein 120 flussvariablen und den Messwerten der Soll und Ist Kompetenzen zu verschiedenen Zeitpunkten werden so R ckschl sse auf m gliche lernf rdern de Einflussfaktoren gezogen die dann gezielt mo difiziert werden Somit gliedert sich das Vorgehen in zwei we sentliche Schritte Das Strukturieren und gez
168. dividuelle An strengungen ber cksichtigt werden und somit die geforderte individuelle Benotung sichergestellt ist Zusammenfassung des Schemas Da auch bei Verwendung des gerade vorgestellten Bewertungsschemas T uschungsversuche der Stu dierenden durch Abschreiben erfahrungsgem nicht ausgeschlossen werden k nnen empfiehlt es sich das Bestehen des Projekts bzw seine Gesamt note nicht alleine von der Artefakt Bewertung ab h ngig zu machen Die vom Autor eingesetzte Kombination mit anderen bereits angesprochenen und vorgestellten Bewertungsverfahren gestaltet sich im Detail wie folgt e bungsaufgaben mit direktem Projektbezug unbenotet nur abzugeben e Programmiertestat am Rechner unbenotet aber zu bestehen e 1 Kolloquium unbenotet nur zu bestehen e 2 Kolloquium 15 der Endnote e Abschlusspr sentation und kolloquium 25 der Endnote e Bewertung des Systems wie oben gezeigt 60 der Endnote Stundenzettel unbenotet glaubhaft und nach vollziehbar gef hrt abzugeben Durch dieses Bewertungsmodell wird gew hrleis tet dass jeder Teilnehmer zumindest ber grundle gende Programmierkenntnisse verf gt die ihn in 110 die Lage versetzen konstruktiv zur Arbeit seines Teams beizutragen Durch die Kolloquien wird ferner das Verst ndnis der geleisteten Arbeit ber pr ft und eine soziale Kontrollinstanz eingef gt wodurch letztlich mit gro er Wahrscheinlichkeit davon ausgegangen werden kann da
169. dung scheint uns erfolgver sprechender 3 Organisatorische Alternativen Nach den m glichen Alternativen bei der modul bergreifenden Gestaltung von Programmierver anstaltungen werden in diesem und dem folgenden Abschnitt Alternativen diskutiert die sich inner halb eines Moduls ergeben in diesem Abschnitt organisatorische im folgenden inhaltliche Alterna tiven A Spillner H Lichter Hrsg SEUH 13 Aus organisatorischer Sicht sind sowohl bei den Vorlesungen als auch den bungen einf hrender Programmierveranstaltungen alternative Herange hensweisen m glich 3 1 Vorlesungen Folienfilme versus Live Programmierung Aus didaktischer Sicht sind Vorlesungen eine we nig geeignete Lehrform unter anderem weil fron tale Wissensvermittlung die Lernenden zu wenig einbezieht Aus Ressourcensicht hingegen sind sie die kosteng nstigste Form der Weitergabe von Wissen denn die Zahl der Teilnehmer kann fast beliebig skaliert werden eine entsprechende H r saalausstattung vorausgesetzt Da aus letzterem Grund mit einer Abschaffung der Veranstaltungs form Vorlesung in n herer Zukunft nicht zu rechnen ist soll hier ihr Optimierungspotenzial f r Programmierveranstaltungen diskutiert werden Ein Ansatz Der Dozent zeigt in einer anderthalb st ndigen Vorlesung je nach Folienstil ca 20 bis 100 Folien die er mehr oder weniger frei interpretiert vortr gt und gegebenenfalls mit Anekdoten wiirzt Programmieren ist ein
170. e Validiert wird die Fairness der individuellen Benotung durch eine gegenseitige Bewertung der Teammitglieder die zwei Mal durchgef hrt wird in der Mitte und am Ende der Lehrveranstaltung Diese liefert dem Au tor fast immer eine Best tigung dass die Sicht im Team auf die Leistungen der einzelnen Mitglieder sich mit seiner deckt Der Lernerfolg kann nur dann sichergestellt wer den wenn die Studierenden die Aufgaben selbst bearbeiten und dadurch ihre eigenen Erfahrungen machen Da oft Arbeitsergebnisse in der Studieren denschaft weitergegeben werden ist es erforder lich jedes Semester nderungen am Projekt zu machen Diese nderungen sind zum einen unter schiedliche Themen aber auch f r jedes Thema unterschiedliche Anforderungen und immer wie der andere abzugebende Arbeitsergebnisse Die Variationsm glichkeiten wurden eingangs bereits beschrieben Das komplette Material f r die Veranstaltung er halten die Studierenden nach dem ersten und zwei ten Pr senztermin das Evaluationsboard gegebe nenfalls sp ter je nach Ausgestaltung des Projek tes Literaturverweise gibt der Autor ausschlie lich nach Bedarf aus A Spillner H Lichter Hrsg SEUH 13 Schlie lich soll ein Punkt nicht unerw hnt bleiben Der Dozent f hrt die Lehrveranstaltung mit viel Freude durch Auch bei den Studierenden soll der Spa an der Arbeit nicht zu kurz kommen Aber trotz eines guten Arbeitsklimas und einem freund schaftlichem Umg
171. e werden den bestehenden Ans tzen die Ziele des Projekts Sim4SEEd gegen bergestellt Incredible Manager Barros u a 2006 SESAM Drappa Ludewig 2000 AMEISE Mittermeir u a 2003 m SimSE Navarro 2006 tm SimjavaSP Shaw Dermoudy 2005 m OSS Sharp Hall 2000 lt MO SEProcess En Ye u a 2007 m SimVBSE Jain Boehm 2006 lt Sim4SEEd Pieper 2012 Einzel E Mehrspieler M Spiel les en Zusammenarbeit und Wettbewerb unter Spielern 1 1 N 1 t Dashboards fiir Team Kurs und Lehrende Spieler in der Rolle eines Projektmanagers Spieler mit verschiedenen Aufgaben Wiederholbarkeit von Spielabschnitten Erm glicht Abbildung verschiedener Softwareprozesse Anzahl verf gbarer Softwareprozesse Domain Specific Language DSL f r die Prozessmodellierung Regeleditor f r die Prozessmodellierung Trennung von Softwareprozess und Anwendungsszenarios Integration von Industriestandards f r die Beschreibung des a eis Be Se ee PE Softwareprozesses Grafische Repr sentation der Nicht Spieler Figuren of of of mit welchen interagiert wird Nutzung echter Werkzeuge aus der Softwareentwicklung In Komponenten fiir teilweise Wiederverwendung entworfen Offentlich verfiigbar lee oa Ge Sp ja enthalten nein nicht enthalten o
172. e Bemerkung einiger Studierender dass das Verhalten in der Rolle des Kunden w hrend der Anforderungsanalyse absurd sei Dies wurde vom Autor abgeschw cht nat r lich hatte er aus didaktischen Gr nden bertrieben Erstaunlicherweise berichteten andere Studierende mit bereits vorhandener Praxiserfahrung dass ge nau solche Situationen so oder so hnlich wirklich in der Praxis vorkommen In einem Projekt gab es in einem Team sehr gro e Probleme so dass diese trotz mehrerer Gespr che mit einzelnen Personen und im Team nicht gel st werden konnten In diesem Fall musste der Autor eingreifen um den Projekterfolg nicht zu gef hr den und allen Beteiligten realistische Noten geben zu k nnen Der Dozent schl pfte dazu in die Rolle des Managers und unterteilte das Team Zwei neue Teams mussten nur noch einen Teil der Aufgaben bearbeiten Die Kommunikation Schnittstelle wur de auf das absolut notwendige Ma reduziert Eigenverantwortung In vielen Firmen existieren f r System und Soft ware Entwicklungs Projekte sehr detaillierte Rege lungen und andere Vorgaben welche Arbeitspro dukte wie aussehen welche Inhalte vorhanden sein m ssen wie sie ineinandergreifen usw Dennoch ist es oft nicht klar wie genau ein zu erstellendes Arbeitsprodukt aussieht oder wie an die Erstellung eines Arbeitsprodukts herangegangen werden kann Es ist in der Praxis nicht sinnvoll wenn nicht sogar unm glich das Vorgehen in jedem 30
173. e Diskussion entstand der Eindruck dass das Thema beherrscht w rde Die Klausur am Ende des Semesters zeigte jedoch dass lediglich 10 der Studierende noch die Kernaussagen kannten Daraus schlie en wir dass die online zu beantwortenden Fragen und die Just in Time Lehrveranstaltung im _Just in Time Teaching die zentrale Rolle spielen Eine ganze Lehrveranstaltung durch Just in Time Teaching Um das Just in Time Teaching einmal in einer ge samten Lehrveranstaltung anzuwenden w hlte man in Kempten die Lehrveranstaltung Require ments Engineering und Management im Master Studiengang Angewandte Informatik die sich um ein Spezialgebiet des Software Engineerings dreht Die Veranstaltung wurde durchgehend von 15 Studierenden besucht Die Lehrenden berlegten sich von Woche zu Woche welcher Teil des Lehrbuches dem Stan dardwerk von Chris Rupp und den SOPHISTen Rupp 2009 bearbeitet werden sollte Dazu erhiel ten die Studierenden jede Woche die folgenden drei Standardfragen Riegler 2012 ber die Lehr und Lernplattform Moodle e Was fanden Sie schwierig oder haben Sie nicht verstanden Es mag sein dass Sie hier nichts angeben k nnen Dann antworten Sie bitte mit nichts Beschreiben Sie was Sie am interessantesten oder gewinnbringend fanden e Welche Ankn pfungspunkte sehen Sie zwi schen diesem Stoff und dem was Sie bereits wissen Bei der Beantwortung der ersten Frage
174. e Ergebnisse der Projekt arbeit und damit die Erreichung der Lernziele und versucht nicht eine Benotung ber Umwege sicherzustellen Somit wird die Motivation und Konzentration der Studierenden auf die wesentli chen Ziele des Projekts gerichtet und sie werden in einem ohnehin schon komplexen Lernumfeld nicht zus tzlich mit weiteren Aufgaben wie der Vorbe reitung auf eine Klausur belastet Durch die Bewer tung teambasierter und individueller Leistungsan teile wird sowohl die Zusammenarbeit im Team gef rdert als auch den Anspr chen von Pr fungs ordnungen und Akkreditierungsagenturen nach einer individuellen Benotung gen ge getan Ferner wird durch die Kombination mit einem automati siert auswertbaren Programmiertestat und zwei Kolloquien sichergestellt dass Trittbrettfahrer fr h zeitig entdeckt werden und die Leistungen ihrer Teamkollegen nicht nachhaltig negativ beeinflus sen k nnen Insgesamt ist die Bewertung der abge lieferten Systemartefakte allerdings mit einem recht hohen Bewertungsaufwand verbunden nach bis herigen Erfahrungen ca 4 5 h pro Team dieser liegt allerdings in der Regel unter einem Prozent des auf Seiten der Studierenden geleisteten Ge samtaufwands und ist somit der Komplexit t der Aufgabenstellung angemessen und auch mit dem Aufwand beim Einsatz einer Klausur vergleichbar Ein weiterer Vorteil ist die hohe Flexibilit t des vorgestellten Bewertungsrasters da abweichende A Spillner H Licht
175. e Lehrinnovation lohnt sich 14 38 24 14 7 3 Die Innovation wurde erfolgreich umgesetzt 31 34 21 7 7 0 Insgesamt w rde ich diesen Kurs weiterempfeh len 28 45 21 3 3 0 Die Quiz haben die in der Vorlesung pr sentierten Konzepte mit realen Softwaresystemen in Verbin dung gebracht 38 48 7 7 0 0 Die Quiz haben mir geholfen die Bedeutung der Vorlesungsinhalte f r reale Software Engineering Aufgaben zu verstehen 21 45 24 3 7 0 Die Auswahl der Softwaresysteme war angemes sen 24 55 10 7 0 0 Die Aufgaben waren interessant und haben mich angeregt mir das verf gbare Hintergrundmaterial anzusehen 21 31 31 7 10 0 Tabelle 2 Bewertung der Quiz durch die Studierenden Nachdem die Quiz einmal vorbereitet wur den m ssen sie in die Online Plattform eingepflegt werden Gerade beim ersten Einsatz 14 eines Online Systems sollten der Aufwand und eventuelle technische Probleme nicht untersch tzt werden Vor jeder Vorlesung m ssen die Antwor ten der Studierenden ausgewertet werden Durch das Verwenden von Freitextfragen kann die Auswertung nicht automatisiert werden Bei un serer Veranstaltung mit durchschnittlich 51 Teil nehmern hat die Auswertung etwa zwei Stunden in Anspruch genommen Das Einbinden der Antworten in die Vorlesung ist
176. e Quiz in ein Bonussystem inte griert das auch die erfolgreiche Teilnahme an den bungen belohnt Die durch alle Quiz insge samt zu erreichenden Bonuspunkte entsprechen allerdings nur 2 der in der Klausur zu errei chenden Punkte Der Anreiz ist also eher symboli 12 scher Natur hat aber trotzdem im Durchschnitt mehr als 70 der Vorlesungsteilnehmerinnen und Vorlesungsteilnehmer zum Mitmachen motiviert Wir halten die Bewertung einfach Entweder die Antwort ist ausreichend f r einen Teilnahme punkt oder nicht Entscheidend f r die Bewertung ist haupts chlich ob die Antwort den Schluss zu l sst dass die Teilnehmerin oder der Teilnehmer sich mit der Fragestellung besch ftigt hat Nachdem die Studierenden die Fragen be antwortet haben ist der letzte Schritt dass die Fragen und insbesondere die Antworten in der n chsten Vorlesung aufgegriffen werden Hierf r hat es sich als sinnvoll erwiesen bei der internen Auswertung die Antworten in verschiedene Ka tegorien einzuteilen z B daf r und dagegen oder das ist immer ein Problem das ist nur unter Voraussetzung A ein Problem das ist nur unter Voraussetzung B ein Problem und das ist nie ein Problem F r viele Studierende ist es inte ressant zu erfahren wie viele ihrer Kommilito ninnen und Kommilitonen ihre berlegungen teilen Aber auch die Lehrenden k nnen daraus ablesen ob ein bestimmter Aspekt h ufig genannt wird und ein ande
177. e auf Basis der Theory of Constraints Goldratt u a 1984 angewandt um Engp sse Bottlenecks in dem Prozess fr hzeitig zu erkennen Diese Modelle geben auch die M glichkeit objektiv ber den Prozess zu diskutieren Neben den Limits kann es noch andere Regeln geben die die Bear beitung von einem Ticket verhindern oder priorisieren z B bestimmte Kartenfarben signalisieren Dringlich keit Damit solche Konventionen nicht zu Fehlern durch Vergessen f hren ist es n tzlich alle Konventionen die sich im Lauf der Entwicklung ergeben explizit aufzuschreiben und allen Entwicklern bewusst zu ma chen 3 Kerneigenschaft Dieses kann zum Beispiel durch ein Poster mit den Konventionen neben dem Whiteboard geschehen Dieses f rdert analog zu der Verbesserung des Flusses die gemeinsame Diskussion und Verbesserung der Konventionen und Regeln Aufbau des Praktikums Das dieser Arbeit zugrundeliegende Praktikum fand f r vier Wochen als Vollzeit Blockpraktikum im Sep tember 2011 w hrend der Vorlesungspause zwischen Sommer und Winteresemester statt Blockpraktika dieser Art finden j hrlich im Rahmen des Internatio nal Program of Excellence in Computer Science IPEC am Bonn Aachen International Center for Informati on Technology B IT statt und bieten den Studenten die M glichkeit Erfahrungen als Softwareentwickler in einem realen Kontext zu sammeln Seit 2001 wer den in den Praktika agile Softwareprozesse gelehrt angewandt
178. e bei dieser Art der Veranstaltung h ufiger zu erwarten sind hal ten die Veranstaltung f r den Lehrenden inte ressant F r Veranstaltungen in denen unter 50 Studieren de erwartet werden kann das Just in Time Teaching sehr gut durch einen Lehrenden durchge f hrt werden Bei mehr Studierenden wird die Un terst tzung von Hilfslehrkr ften ben tigt Stellen sich die Lehrenden auf die andere Herangehens weise der Vorbereitung auf eine Lehreinheit um k nnen sie mit motivierten aktiven und wissens durstigen Studierenden rechnen Durch die Einf h rung der dritten Feedback Schleife k nnen ausf hr lichere Themen des Software Engineerings an gr Geren Beispielen direkt in der bung in Form von Teamwork erarbeitet werden Ein R cklauf von ca 50 in der Beantwortung von Fragen in der der von JiTT genutzten Lern plattform Moodle kann erh ht werden wenn f r die studentische Mitarbeit in Just in Time Teaching Anreizsysteme geschaffen werden So k nnen bei spielsweise 10 Bonuspunkte f r die Klausur durch kontinuierliche Beitr ge der Studierenden in JiTT von den Studierenden gesammelt werden Hierf r 23 ist allerdings eine nderung der Studienpl ne n tig Dies ist in Regensburg erstmals im WS 2012 2013 umgesetzt Zusammenfassend l sst sich sagen dass quali tativ hochwertiges Lernen vor allem dann stattfin det wenn sich die Lernenden unter sinnvoller An leitung die Dinge selbst aneignen selbst Frage und
179. e elektronisch an die Lehrperson idealerweise mittels einer Technik die die studentischen L sungen automatisch auswertet bzw strukturiert Lehrende haben dann die M glichkeit genau rechtzeitig just in time einen berblick ber den Wissensstand ihrer Studierenden zu gewinnen und z B miss verst ndliche intuitive Auffassungen eines Stoffs Pr konzepte zu erkennen Sie k nnen entspre chend in ihrer Veranstaltung bereits verstandenen Stoff verk rzt behandeln daf r aber gezielt auf vorliegende Verst ndnisschwierigkeiten einge hen Wie genau dies geschieht liegt frei in der Hand der Lehrenden So k nnen sie die aus den Einstiegsaufgaben gewonnenen Informationen lediglich zur Pr zisierung ihrer eigenen Vortrags teile nutzen und z B kurzfristig in ihre Pr senta tionen einzelne Folien einbauen die typische oder besonders interessante studentische L sungen oder Probleme zeigen Alternativ k nnen die In formationen aus den Einstiegsaufgaben aber auch zum roten Faden der zugeh rigen Veranstal tung gemacht werden indem beispielsweise ge zielt an auff lligen Pr konzepten gearbeitet wird strittige Fragen per Partnerdiskussion o in der Vorlesung weiter vertieft oder ber Classroom response Systeme Clicker nochmals f r alle Studierenden zur Disposition gestellt werden Luo 2008 166 Entscheidend ist in jedem Fall dass die Leh renden fr hzeitig eine R ckmeldung zu den Lernbed rfnissen ihre
180. e fiir das Korrigieren der Bearbeitungen anf llt nach Erfahrungswerten ca vier bis f nf Stunden pro Woche verbringt ein Betreuer diese A Spillner H Lichter Hrsg SEUH 13 Zeit in zwei Laborterminen von je drei Zeitstunden In jedem Termin hat er demnach rechnerisch Kon takt mit sieben bis acht Studierenden also maximal vier Paaren Insgesamt ergibt dieses Konzept mehr direkte Kontaktzeit zwischen Studierenden und Be treuern und erm glicht somit einen intensiveren Austausch der insbesondere bei Programmierauf gaben hilfreich ist Dieser intensivere Austausch ist allerdings auch kraftraubender au erdem kann ein Betreuer sich seine Zeit nicht mehr frei einteilen w hrend die Korrektur von bungsbl ttern auch zuhause bei einer Tasse Tee m glich ist Es gab durchaus wissenschaftliche Mitarbeiter die das Konzept im Prinzip gut gehei en haben es aber aus pers nli chen Gr nden abgelehnt haben 4 Inhaltliche Alternativen Wenn wir bis zu diesem Punkt der Diskussion je weils den vorgeschlagenen Alternativen gefolgt sind dann betrachten wir nun einen Einstieg in die objektorientierte Programmierung interaktiver Systeme mit Java der innerhalb von mindestens zwei Semestern vorgenommen wird die Mecha nismen von Java nicht vollst ndig im ersten Semes ter vermittelt und bei dem der Dozent viel live in den Vorlesungen programmiert Die bungen werden als intensiv betreute Pr senz bungen mit Paararbeit durchgef hrt
181. e oder Universit t ist zwar ebenfalls eine praktische Unterrichtsform in dieser setzen sich Studierende allerdings mit vorgegebenen und klar umrissenen Aufgaben die innerhalb weniger Stun den zu bearbeiten sind auseinander vgl Iller amp Wick 2009 Da diese Lehrform haupts chlich in klassischen Naturwissenschaften wie Chemie oder Biologie Verwendung findet bedeutet das zu meist dass Aufgaben nur vor Ort in einem entspre chenden Labor bearbeitet werden k nnen Als La borumgebung in der Informatik und speziell in der Softwaretechnik ist heute allerdings in der Re gel ein handels blicher Laptop ausreichend mit dem bequem an beinahe jedem beliebigen Ort ge arbeitet werden kann Auch bei den Aufgabenstel lungen in der Softwaretechnik die zumeist das selbstst ndige Durchlaufen des kompletten Ent wicklungszyklus einer Software vorsehen passt obige Begriffsdefinition nicht vielmehr ist hier aus Sicht der Didaktik von einem praktischen Projekt mit entsprechend h heren Anforderungen an die Eigenverantwortung der Teilnehmer auszugehen weshalb im Folgenden dieser Begriff Verwendung finden soll A Spillner H Lichter Hrsg SEUH 13 Studentische Perspektive Aus studentischer Sicht erfahren Softwareentwick lungsprojekte h ufig eine komplett kontr re Ein sch tzung Zum einen gibt es die leistungsstarken Vollblut Informatiker die gerne gut und viel programmieren und oft privat bereits eigene kleine Softwa
182. e softwaretechnische Programmieraus bildung erfordert dar ber hinaus dass die Studie renden Software nicht nur neu entwickeln lernen sondern auch lernen bestehende zu warten Dies schlie t mit ein kompetent ber Software kommuni zieren zu k nnen Es schlie t auch ein Software selbst so zu gestalten dass andere sie gut berar beiten k nnen Dazu sollten das automatisierte Tes ten von Software und das f r die Softwaretechnik so zentrale Konzept der Schnittstelle u a f r Spezi fikationen aber auch Quelltextkonventionen fr h zeitig bei der Programmierung thematisiert wer den Die F higkeit zum Programmieren und zum Kommunizieren ber Software ist blicherweise auch die Voraussetzung f r eine erfolgreiche Teil nahme an dedizierten Modulen zum Software Engi neering die h ufig erst ab dem 3 Semester angebo ten werden Informelles Feedback von Lehrenden solcher Veranstaltungen deutet an dass bei den Teilnehmern h ufig nicht die notwendigen grund legenden Programmierkenntnisse vorhanden sind Der Einfluss dieser Dozenten auf die Programmier ausbildung ist h ufig gering da selten dieselben Personen sowohl Programmierung als auch Soft ware Engineering lehren 1 3 Aufbau Dieser Artikel thematisiert die Gestaltung der einf hrenden Programmierausbildung in Informatik studieng ngen deutscher Hochschulen indem er auf verschiedenen Ebenen Alternativen ihrer Ge staltung diskutiert Dabei orientiert er sich a
183. eboten Gerade bei diesen Methoden ist es sinnvoll dass Anf nger sie f r sich durch die eigene Erstellung entdecken um gerade das sehr gute aber nicht einfache Konzept der Basisklasse Object zu verste hen Man kann zwar die Nutzung von Eclipse auf weni ge Klicks reduzieren die f r erste Programme wirklich ben tigt werden benutzt allerdings ein Nachbar bei der Programmentwicklung ihm schon bekannte Features w chst schnell ein innerer Druck dies auch beherrschen zu wollen Ein Einstieg in Eclipse ist zumindest optional si cherlich im Laufe der ersten Programmiererfah rungen sinnvoll und kann zum Selbststudium in der vorlesungsfreien Zeit vorgeschlagen werden Eclipse unterst tzt nicht vollst ndig den Objects First Ansatz da zumindest eine main Methode in einer Klasse existieren muss BlueJ BlueJ Blu ist gegen ber Eclipse eine wesentlich einfachere Entwicklungsumgebung mit wesentlich weniger M glichkeiten Ein einfaches Googeln nach BlueJ mit der Erg nzung filetype pdf zeigt dass BlueJ an vielen Schulen aber auch Hochschu len in der Programmierausbildung genutzt wird Blue erm glicht es einfach Objekte gegebener Klassen zu erzeugen und mit diesen Objekten ber deren Methoden zu interagieren Dazu werden die 52 verf gbaren Klassen in einem Klassendiagramm angezeigt von denen dann ber einen Rechtsklick Objekte erzeugt und Klassenmethoden aufgerufen werden k nnen Die Objekte liegen unten in
184. edenheit der Beteilig ten mit den folgenden Bewertungsans tzen bisher nicht verf gbar sind Kerer et al 2005 verwendeten f r ihr Entwick lungsprojekt mit ca 600 Studierenden eine Kombi nation aus kleineren bungsaufgaben sog As signments und einer Klausur mit projektbezoge nen Fragen und Programmieraufgaben Interessant ist bei dieser Ver ffentlichung speziell die offenbar hohe aber nicht n her spezifizierte Zahl von auf gedeckten Plagiatsf llen sowohl bei den Assign ments als auch bei den abzugebenden Program men die nochmals die Notwendigkeit einer indivi duellen Bewertung unterstreicht Ludewig 2011 hingegen kritisiert das blo e Ab fragen von Fakten z B mit Hilfe einer Klausur zur Bewertung einer praktischen Lehrveranstaltung als nicht zielf hrend und benennt die aus seiner Sicht recht einfache Bewertung der Gruppenleistung also des erstellten Systems als Alternative Krite rien f r deren Bewertung werden aber leider nicht genannt Von der Pr fungsordnung verlangte indi viduelle Noten wurden in Ludewigs Veranstaltun gen f r Teilnehmer die positiv oder negativ auffielen durch ein angemessenes Delta aus der Gruppennote abgeleitet Dieses Verfahren wurde nach Kenntnisstand des Autors erstmals von For brig 1997 vorgestellt und beispielsweise auch von Stoyan amp Glinz 2005 angewendet Lindig und Zeller 2005 gehen in ihrem Bericht ber ein sechsw chiges Vollzeitprojekt ebenfalls ni
185. ehr Lern Konzepte f r Software Engineering und der Ein flussvariablen auf die Lernprozesse statt Die fach lichen Inhalte von Lehrveranstaltungen werden wiederum in die Weiterentwicklung von Soll Kom petenzprofilen einflie en Zudem ist bei der Ent wicklung didaktischer Konzepte eine detaillierte Ber cksichtigung der zu vermittelnden Inhalte un umsg nglich Sobald konkretere Soll Kompetenzprofile vor liegen ist die Sichtweise der Lehrenden st rker ein zubinden Die Lehrenden nehmen im Lernprozess der Studierenden eine Schl sselposition ein und pr gen besonders auch durch ihre Vorstellungen und Definitionen gelungenen Lernens Bender 2009 das Lehren und Lernen ma geblich Daher ist es sinnvoll diese Sichtweisen zun chst separat mit der erforderlichen Sorgfalt zu ber cksichtigen So sollen nicht nur inhaltlich fachliche Lehrinhalte mit in die Bildung von Soll Kompetenzprofilen einflie en sondern auch Erwartungen Motive Werthal tungen Menschenbild und personenbezogene Merkmale etc Welche Vorstellungen Ideale Ziele und Wertvorstellungen haben die Lehrenden Da rauf aufbauend werden zusammen mit den Leh renden aus den Soll Kompetenzprofilen konkrete kompetenzorientierte Lehrziele abgeleitet und Messkriterien f r deren Erreichung definiert Auch dieses Vorgehen ist wiederum ausgerichtet auf die jeweiligen Lehrenden und die Lehrveranstaltun gen denn Lehrziele k nnen nicht allgemeing ltig formuliert sein 127
186. ehr viel schneller helfen In unseren beiden einf hrenden Modulen sind die Laboreinheiten drei echte Zeitstunden lang um gen gend Zeit f r die Interaktion mit den Studie renden zu erm glichen Die Studierenden m ssen dabei im Extremfall die L sungen nicht unbedingt selbst erstellt haben solange sie bei der Abnahme die L sung gut darstellen k nnen Denn in den Abnahmen besteht durch die direkte Kommunika tion ausreichend Gelegenheit das Verst ndnis der Studierenden f r die zu vermittelnden Konzepte und Begriffe zu berpr fen Konsequenzen Ein Pr senzbetrieb bei den bun gen hat mehrere Konsequenzen 42 e Die Pr senzaufgaben f r einen betreuten Labor betrieb m ssen anders konzipiert werden als Aufgaben f r die Heimarbeit e St rkere Studierende mit Vorerfahrung k n nen ihren Vorsprung nutzbringend einsetzen indem sie im Paar mit Programmieranf ngern zusammenarbeiten e Die Betreuer insbesondere die wissenschaftli chen Mitarbeiter m ssen bereit sein diese Art des bungsbetriebs mitzutragen Pr senzaufgaben Mehrere Jahre Erfahrung mit die sem Konzept haben bei uns dazu gef hrt dass die Aufgaben eng gef hrt und kleinschrittig sind Dies liegt auch daran dass wir aufgrund der hohen Teilnehmerzahl gezwungen sind in gro em Ma e studentische Hilfskr fte f r die Betreuung einzu setzen Diese sind blicherweise nicht erfahren in der Betreuung von Kommilitonen und brauchen entsprechend detai
187. eignete Merkmale Simulation er ffnet Wege relevante Aspekte einer fast realen Welt mit den flexiblen F higkei ten von Simulationsexperimenten zu verbinden Zu F higkeiten geh rt die M glichkeit Zeit zu komprimieren oder auszudehnen Quellen von Variationen gezielt zu steuern Experimente zu beliebigen Zeitpunkten anzu halten und zu analysieren Systemzust nde wieder herzustellen um Ex perimente zu wiederholen sowie den Detaillierungsgrad zu definieren Erg nzt man Kursprojekte um Lernformen mit diesen Merkmalen so l sst sich ein hohes Ma an Flexibilit t gewinnen Studierende und Lehrende sind in diesem Fall nicht an das operative Erfor dernis gebunden tats chlich Software zu produzie ren um den damit verbundenen Prozess lebhaft zu erfahren Die gezielte Erkundung verschiedener Softwareprozesse in verschiedenen Szenarien wird damit auch in einem begrenzten Zeitfenster m g lich Da keine Ergebnisse in einem echten Kurspro jekt gef hrdet werden kann ungezwungenes spie lerisches Experimentieren Teil der Lernerfahrung werden Studierende k nnen auch in simulierten Situationen agieren welche aufgrund begrenzter Ressourcen real nicht denkbar w ren Simulations are most engaging when made in to games Prensky 2007 S 225 Spiel und Nach ahmung bleiben als natiirliche Lernstrategien le benslang wichtige Akkommodations und Assimi lationsstrategien Rieber 1996 Der fesselnde und moti
188. eines Programms zur Erstel lung eines Programms selbst mit einfachen if An weisungen ein enormer Schritt sein kann oder dass die didaktische H rde zwischen einer einfachen Schleife und geschachtelten Schleifen sehr gro ist muss oft in Selbsterfahrungen erworben werden Als Fazit eignet sich C wohl dann als Anf nger sprache wenn viele sprachliche Besonderheiten wie die Kopiersemantik Zeiger Arithmetik und Makros nicht behandelt werden Ob solch ein kon sequenter Ansatz schon umgesetzt wurde ist leider unbekannt Weiterhin zeigen Erfahrungen in h he ren Semestern deutlich dass zumindest bei aktuell nicht sehr leistungsstarken Studierenden die Ideen der Objektorientierung durch eine sp tere Einf h rung nicht verinnerlicht werden Die urspr nglich mit C C und Java dreisemes trige Programmierausbildung mit je f nf Leis tungspunkten wurde in der Reakkreditierung des Bachelors nach sehr kontroversen Diskussionen durch eine zweisemestrige Programmierausbil 49 dung mit jeweils 10 Leistungspunkten mit Schwer punkt in Java erg nzt um eine kompakte Einf h rung in C ersetzt HSRM10 Java Java verbreitet sich seit seiner Einf hrung Mitte der 1990er Jahre kontinuierlich in Unternehmen und in der Hochschulausbildung In diversen Statistiken ist Java die am meisten benutzte Programmierspra che wenn es um Programme im Business Bereich wie ERP geht Java ist aus Sicht der Objektorientierung eine hy bride Spr
189. eitschaft sich st ndig auf Neues und Unvorher gesehenes einzulassen Es wird erwartet dass Ab solventen sich selbst und ihre Position im Unter nehmen realistisch einsch tzen k nnen und so im Team und mit ihren Vorgesetzten konstruktiv zu sammenarbeiten und dabei ihren Platz und ihre Rolle finden Dies ist eng verkn pft mit drei zentra len Anforderungen die am h ufigsten in den Inter views genannt wurden Problembewusstsein und das Verstehen komplexer Prozesse gepaart mit dem Faktor Zusammenarbeit Kommunikation Zu ei nem hnlichen Ergebnis kommen auch B ttcher et al 2011 Als zentrale Anforderung wird von einem Software Ingenieur ein ausgepr gtes Problembe wusstsein erwartet Problembewusstsein meint sich in einem komplexen Prozess zurechtzufinden und zu erkennen wann welche Kompetenzen wie ben tigt werden und wann und wie sie zusam menh ngen Ein Interviewpartner beschreibt dies folgenderma en das ist auch so ein Thema das wurde auch in meinem Studium behandelt das kann man aber auch erst sozusagen verstehen und adaptieren wenn man das Problembewusstsein hat weil man vielleicht schon das eine oder andere Problem wirklich erlebt hat dass man sagt o k ich habe jetzt eine gewisse Problemstellung und die muss ich irgendwie l sen und dann eben auch dieses Aha Erlebnis gehabt hat Ein anderer Interviewpartner formuliert die Si tuation so Das Problem ist ja man h rt im Studi um viele Sac
190. ekte und Perspektiven zu ber cksichtigen Simulation und Digital Game Based Learning DGBL k nnen neben Kursprojek ten einen wichtigen Beitrag dabei leisten Software prozesse kennenzulernen Simulation und digitale Spiele in der Software Engineering Ausbildung Ziel der SE Ausbildung sollte es sein ein tiefes Verst ndnis von Inhalten und deren Aufnahme in den eigenen Wertekanon zu f rdern Ludewig 2009 Folgende Aussage zeigt wie dies gelingen kann Jeder Sinn den ich selbst f r mich einsehe jede Regel die ich aus Einsicht selbst aufgestellt habe treibt mich mehr an berzeugt mich st rker und motiviert mich h her als von au en gesetzter Sinn den ich nicht oder kaum durchschaue Reich 2008 S 95 Folgt man diesem idealtypi schen Grundsatz konstruktivistischer Didaktik so besteht die Aufgabe einer geeigneten Lernumge bung darin die Eigenaktivit ten der Lernenden anzuregen um die aktive Konstruktion von Wissen bei der Bearbeitung komplexer authentischer Situa tionen und Probleme zu unterst tzen Die Betrach tung des Lerngegenstands aus verschiedenen Per spektiven Artikulation und Reflexion im sozialen Austausch tragen grundlegend zum erfolgreichen Lernen bei Kritzenberger 2005 Verschiedene Ans tze aus dem konstruktivistischen Methoden baukasten finden in der SE Ausbildung bereits Anwendung Hagel Mottok 2011 Simulationen 132 und digitale Spiele bieten in diesem Umfeld beson ders ge
191. ele waren sehr interessant zum Beispiel die andere Sprache des Kunden e Die Einstiegsschwelle in das Thema war niedrig weil das System einfach ist und keine komple xen Anforderungen besitzt e Inhaltlich war das Thema gut Zun chst einfach und sp ter kamen dann doch noch viele Details und Unklarheiten zu Tage A Spillner H Lichter Hrsg SEUH 13 e Die Anforderungs nderung war gut die Aus wirkungen auf das Design wurden klar e Die Arbeit an der Architektur war gut ein Mit telweg zwischen zu viel und zu wenig Architek tur musste gefunden werden Anhand des Feedbacks und vor allem der Diskus sionen mit den Studierenden erh lt der Dozent den Eindruck dass der Ansatz zielf hrend ist Die Stu dierenden k nnen die im Studium gelernten Inhal te kombinieren lernen etwas ber deren Abh n gigkeiten und erhalten so einen Einblick in die Pra xis Au erdem kann aus dem gro en Engagement vieler Studierender geschlossen werden dass auch die Begeisterung f r die Welt eingebetteter Systeme gelungen ist Ein letzter Punkt soll nicht unerw hnt bleiben Das Projekt ist erfahrungsgem sehr schnell ausge bucht Dies gibt dem Autor das gute Gef hl mit dem Projekt auf dem richtigen Weg zu sein Die Teilnehmenden entscheiden sich aktiv f r das Pro jekt um mehr ber eingebettete Systeme zu lernen und bringen daher auch eine hohe Motivation f r das Themengebiet mit Auch diese Tatsache kann ein Grund f r das posit
192. elt Praktikum 2012 Aufgrund unserer guten Erfahrungen wurde auch im Praktikum im Jahr 2012 der Kanban Prozess einge setzt Als Basis wurde das hier vorgestellte Kanban Board genutzt Dieses musste nicht weiter angepasst werden so dass die Dozenten eine geringere Vorberei tungszeit ben tigten Im Laufe des Praktikums wurden auch nur wenige und erwartete Anpassungen an den Limits der Prozessschritte vorgenommen Diese An passungen wurden n tig da die problematische Prio risierung des vorherigen Praktikums entfernt wurde Weiterhin mit Problemen behaftet waren wiederum 97 unterschiedlich komplexe Tickets und ihr Einfluss und Aussagekraft auf den Gesamtfluss Durch die Arbeitsli mits bedingt konnten aber auch schwierige Aufgaben fokussierter bearbeitet werden Zusammenfassung In dieser Arbeit haben wir von unseren Erfahrung mit der Anwendung des Kanban Entwicklungsprozesses in einem Blockpraktikum an der Universit t Bonn be richtet Neben den Vorteilen des Prozesses und den L sungen fr herer Probleme wurden auch neue Pro bleme aufgezeigt In einem k rzlich durchgef hrten Praktikum konnten diese teilweise auch schon bew l tigt werden Als wichtigste Erkenntnis w rden wir jedem Leh renden der Kanban einsetzen m chte empfehlen zu Anfang den bisher eingesetzten Prozess und dessen Schwierigkeiten schriftlich festzuhalten Auf Basis des sen kann man dann berlegen ob Kanban sinnvoll ist und wie man den Prozess anp
193. en was genau im Kontext von Software Engineering darunter zu verstehen ist Als erster Schritt zu einem Beschreibungssche ma f r berfachliche Kompetenzen wurden die vorhandenen Interviews zun chst im Hinblick auf A Spillner H Lichter Hrsg SEUH 13 jegliche berfachliche Aussagen codiert Es ent standen 32 Codes die unterschiedlich h ufig auf traten Diese Codes deuten auf ein Schema zur Beschreibung berfachlicher Kompetenzen hin sind jedoch noch weiter zu clustern und zu struktu rieren Gem Grounded Theory geschieht dies parallel mit der Erhebung und Auswertung weite rer Daten In diesem iterativen Prozess entsteht somit neben dem Beschreibungsschema f r ber fachliche Kompetenzen zeitgleich auch die inhaltli che Beschreibung berfachlicher Kompetenzen die ein Software Ingenieur ben tigt Vorgehen bei fachlichen Kompetenzen Aufgrund anderer Voraussetzungen und Vor kenntnisse wurde bei fachlichen Kompetenzen zuerst top down ein theoretisches Modell entwi ckelt und in einem zweiten Schritt mit konkreten Daten also Kompetenzen gef llt und validiert Das vorgeschlagene Modell zur Beschreibung fach licher Kompetenzen wurde so in einer Pilotstudie auf seine Verwendbarkeit berpr ft Dazu wurden mittels halbstrukturierter Interviews fachliche Soll Kompetenzen erhoben und klassifiziert die Unter nehmen von Absolventen im Bereich Kern Infor matik erwarten Als Grundlage f r m gliche Inhalte und so
194. en Aus Sicht der Ingenieur Ausbildung ist es daher zentral sich abzeichnende Entwicklungen in der Ausbildung vorwegzuneh men und damit einen Beitrag dazu zu leisten dass moderne Entwicklungsmethoden ihren Einzug in die Praxis halten Referenzen 1 Kropp M Meier A Swiss Agile Study Ein satz und Nutzen von Agilen Methoden in der Schweiz www swissagilestudy ch 2012 Ber icht in Bearbeitung 2 Version One State of Agile Development Sur vey results http www versionone com state of agile de velopment survey 11 20 10 2012 3 Software Engineering and Architecture http www msengineering ch fileadmin user uplo ad modulbeschreibungen de TSM SoftwEng de pdf 29 10 2012 4 http www zhaw ch 29 10 2012 5 http www fhnw ch technik 29 10 2012 6 Agile Manifesto http agilemanifesto org 29 10 2012 7 K Schwaber M Beedle Agile Software De velopment with Scrum Prentice Hall 2001 8 K Beck Extreme Programming Explained Embrace Change Addison Wesley 2009 9 M und L Poppendieck Lean Software Devel opment An Agile Toolkit Addison Wesley 2003 10 S Hauser M Kropp Software Projekt Ma nagement http web fhnw ch plattformen spm 29 10 12 A Spillner H Lichter Hrsg SEUH 13 11 Ch Denzler M Kropp Software Construction http web fhnw ch plattformen swe 29 10 2012 12 R C Martin Clean Code A Handbook of Agile Software Craftsmanship
195. en inkrementellen Prozess zu vermitteln An schlie end wird das Beispiel erl utert anhand dessen die einzelnen Lerninhalte schrittweise eingef hrt und von den Studierenden in die Praxis umgesetzt wer den Fine Analyse der ersten mit diesem Lehrkonzept gewonnenen Erfahrungen runden die Arbeit ab 71 Problemstellung Den groben Rahmen der Antwort auf die Wo fange ich an Frage definieren im Hochschul Kontext in der Regel die Studienpl ne Einbettung in das Curriculum Wir betrachten hier als konkretes Beispiel den Studien gang Bachelor Wirtschaftsinformatik an der Hochschu le M nchen der f r den Bereich Software Engineering den folgenden Ausbildungspfad vorsieht e 1 Semester Softwareentwicklung 1 Einf hrung in das objektorientierte Programmier paradigma und die Grundz ge der Programmie rung am Beispiel der Sprache Java e 2 Semester Softwareentwicklung 2 Vertiefung der Programmierkenntnisse und Ein satz fortgeschrittener objektorientierter Program mierkonzepte am Beispiel der Sprache Java e 3 Semester Software Engineering 1 Objektorientierte Analyse und Entwurf mit UML Architekturauswahl Aufwandssch tzung Qualit ts und Projektmanagement e 4 Semester Software Engineering 2 Werkzeuge zur Automatisierung der Entwicklung modellgetriebene Entwicklung Konfigurationsma nagement Verifikation und Test Softwarearchi tekturen Prozessmodelle und agile Vorgehensmo delle Jede dieser Veranstaltun
196. en und Datenstrukturen Verkettete Listen Array 39 Listen B ume Hash Verfahren und Sortierverfah ren an denen die objektbasierten Elemente gut ge bt werden k nnen ohne diese mit der Komple xit t von Vererbungsmechanismen zu belasten Konsequenzen Eine Verteilung der Sprachkonzep te von Java auf zwei konsekutive Module f hrt zu einer st rkeren Kopplung zwischen diesen Modu len Sie sollten deshalb aus einer Hand gelehrt werden um Reibungsverluste zu minimieren An der Uni Hamburg haben wir das Gl ck beide einf hrenden Programmierveranstaltungen gestal ten zu d rfen Dies hat uns die M glichkeit gege ben Inhalte anders zu schneiden und zu verteilen Die Kehrseite ist dass wir f r diese beiden Module aufgrund der seit Jahren sehr gro en Teilnehmer zahl regelm ig einen hohen Betreuungsaufwand leisten m ssen u sei ssi SE2 s3 Abb 1 Anteil der einf hrenden Pflichtmodule zur Programmierung in den Bachelorstudieng ngen der Universit t Hamburg mit hohem Informatik Anteil Insgesamt stellt sich der Anteil der einf hrenden Programmierveranstaltungen SE1 und SE2 in unse ren Curricula schematisch wie in Abbildung 1 dar Eine Zelle des unterliegenden Rasters
197. en Nutzen der Build Automatisierung zu erfah ren bauen die Studierenden anhand einer konkre ten Case Study ber ein ganzes Semester ein Au tomatisierungsskript kontinuierlich aus so dass das Kompilieren Testen Code Analysieren als auch das Packaging der Software vollst ndig au tomatisiert durchgef hrt werden kann Automated Builds sind eine Voraussetzung f r Continuous Integration und werden im n chsten Kapitel genauer angeschaut Continuous Integration CI Automated Builds und Continuous Integration werden mittels einer konkreten Fallstudie in einer Gruppenarbeit vermittelt und ebenfalls schon fr h zeitig im Studium eingef hrt z B im Rahmen des Moduls Software Konstruktion im 2 Semester In einem ersten Schritt wird das Beispielprojekt in ein Code Versioning System importiert Im zweiten Schritt werden die Build Skripts entwickelt damit das Beispielprojekt automatisiert gebaut werden kann Im dritten Schritt Konfigurieren die Studie renden den Cl Server Jenkins Im vierten Schritt A Spillner H Lichter Hrsg SEUH 13 werden verschiedene Jenkins Erweiterungen be sprochen und ausprobiert Dabei werden verschie dene Metriken wie Code Coverage Bindungsst rke von Klassen Code Complexity aber auch Lines of Code LOC behandelt Fortgeschrittene Metriken werden in h heren Se mestern Bewertung einer Software Architektur im 4 Semester Software Entwurf 17 oder im Master Studiengang Technical Debit
198. en Priorisierung nicht gl cklich da es eine h here Aufmerksamkeit auf Seiten der Studenten for derte Durch den ungewohnten Entwicklungsprozess und das Umfeld waren die Studenten anfangs eher passiv in dem Prozess Mit steigender Erfahrung mit Kanban und steigendem Selbstbewusstsein im Team fingen die Studenten an Verbesserungsvorschl ge zu ma chen Durch eine bessere und l ngere Einf hrung von Kanban in dem Workshop k nnte man diese Hemm schwelle vermutlich verringern und fr here Verbes serungsvorschl ge erleichtern Wie so oft in unseren Praktika war das Team in der letzten Woche erst auf voller Produktivit t Eine Schwierigkeit in der Anpassung des Prozesses w hrend des Praktikums ist der kurze Zeithorizont Man kann entweder zur Optimierung Arbeitsschritte und Puffer hinzuf gen oder entfernen oder an den Li mits in jedem Schritt drehen Wenn man eines von bei den anpasst soll man laut Literatur Anderson 2010 einige Zeit warten bis sich der Prozess auf die neu en Rahmenbedingungen eingependelt hat Ebenso sollte man nur eine Schraube in jedem Schritt ver n dern Dies bedeutete aber f r unser Praktikum dass es schwer war den Fffekt abzusch tzen Wir hatten uns daher auch entschieden w hrend des Praktikums keine Arbeitsschritte anzupassen und nur die Limits der Schritte zu justieren Davon haben wir auch in der ersten Woche Gebrauch gemacht indem wir die Limits in der Development Phase von sechs Tasks auf zwei
199. en erfasst und dann erst struk turiert Es wurde ohne ein vorhandenes Schema zur Beschreibung der Kompetenzen begonnen Dieses entsteht erst parallel mit der Datenerhe bung Die Entwicklung eines Beschreibungsmo dells f r berfachliche Kompetenzen ist einer ers ten Datensammlung nachgelagert berfachliche Soll Kompetenzen werden aus Sicht unterschiedlicher Stakeholder und zun chst in einem ersten Schritt aus Sicht von Unternehmen f r den Bereich Kerninformatik ermittelt Dazu wurden Interviews die zu den fachlichen Kompe tenzen gef hrt wurden siehe unten nochmals im Hinblick auf berfachliche Kompetenzen ausge wertet Durch die N he zur Datenbasis der Inter views entsteht in diesem bottom up Prozess ein Verst ndnis f r die berfachlichen Kompetenzen und ihre Auspr gung Dieses Vorgehen erm glicht einen unverstellten Blick auf die tats chlichen Er fordernisse im Berufsleben und erzeugt schon w h rend des Forschungsprozesses ein Gef hl daf r was etwa mit Teamf higkeit gemeint ist Sonst h ufig wenig aussagekr ftige Worth lsen wie z B Teamf higkeit erfahren durch dieses bottom up Vorgehen eine Konkretisierung f r den Bereich Software Engineering Dies ist auch der Grund warum es in einem ersten Schritt nicht sinnvoll ist Stakeholder direkt danach zu fragen welche ber fachlichen Kompetenzen ben tigt werden Als Antwort w re prim r eine Aufz hlung dieser Worth lsen zu erwarten es bliebe jedoch off
200. en fehlt deshalb der Ein blick in gro e Softwareprojekte und die damit einhergehenden Herausforderungen z B dass viele Entwickler an einem Projekt beteiligt sind keine Person alle Einzelheiten des Gesamtsystems im Detail kennt und das System auch nach Jahren noch zu warten sein muss Ohne diesen Einblick f llt es vielen Studierenden schwer den Sinn der in der Vorlesung behandelten Konzepte und Me thoden zu verstehen Ein Ansatz den Studierenden die fehlende Er fahrung zu vermitteln ist die Vorlesung um ein A Spillner H Lichter Hrsg SEUH 13 begleitendes Softwareprojekt zu erg nzen Dies erfordert allerdings die nderung des Curricu lums f r die betroffenen Studieng nge und war studiengangstechnisch nicht m glich Wir haben stattdessen versucht die fehlende Erfahrung zu simulieren indem wir den Studierenden vor jeder Vorlesung Aufgaben gestellt haben die die Not wendigkeit des behandelten Themas verdeutli chen und hierzu reale Open Source Software projekte verwenden Die Methode den Studie renden bereits vor der Vorlesung den Einstieg in das Thema im Selbststudium zu erm glichen wird h ufig als Just in Time Teaching bezeich net In diesem Artikel beschreiben wir unseren Einsatz von JiIT im Bereich der Veranstaltung Software Engineering ein Konzept das in Zu sammenarbeit des Instituts f r Softwaresysteme mit dem hochschul und fachdidaktischen Zent rum f r Lehre und Lernen an der TUHH e
201. en fr hzeitig im Team verteilt werden konnte Die Stu denten hatten bei Leerlauf die freie Wahl aus diesen auf Karten beschriebenen Fortbildungen zu w hlen Neben diesen Karten konnten die Studenten auch jederzeit Vorschl ge oder Ideen einbringen wie man den Gesamtprozess oder das Board verbessern k nnte Ein Vorschlag war zum Beispiel dass nicht immer klar war welche Studenten an welchen Tickets arbeiteten Nachdem die Tickets in der Development Phase in meist mehrere Tasks unterteilt und mit je einem Paar weiterentwickelt wurden war es wichtig dass sich diese Studenten ber den Zustand austauschen da es h ufig Abh ngigkeiten zwischen den Tasks gab In diesen Schritten ist es daher wichtig zu wissen wer an welchen Tasks arbeitet um sich z B r umlich nebeneinander zu setzen Als L sung des Problems wurde ein Bild von jedem Entwickler und Dozenten gemacht und auf dem Board befestigt Jeder hatte dann die Aufgabe sein Bild auf das Ticket oder den Bereich zu verschieben an dem er arbeitete Da es diese Bilder auch f r Teamleiter und Kunden gab half diese einfache Idee als Nebeneffekt auch den Paaren die in der Analyse oder dem Review arbeiteten visuell zu erfassen ob der Kunde verf gbar war Fazit Um zu bewerten wie gut unser Prozess im Praktikum funktionierte wurde das Cumulative Flow Diagramm siehe Abbildung 3 herangezogen Au erdem hatten wir an einem Tag w hrend des Praktikums einen ex ternen Prozess Reviewer
202. en ging es nicht nur um Fachwissen sondern auch um prakti sche Anwendung des Gelernten Insgesamt muss ten bei jeder Fragerunde 10 Fragen beantwortet werden Die Studierenden hatten meist 5 Tage Zeit sich das Thema anzueignen und die Fragen zu beantworten Einige Studierende bearbeiteten den Stoff gemeinsam und diskutierten ber die Inhalte andere w hlten das Selbststudium alleine F r die Bearbeitung der Aufgaben wurde grunds tzlich ein Stichtag festgesetzt so dass sichergestellt war dass alle Antworten kurz vor der Vorlesung vorlagen Dies war in der Regel etwa 1 Tag vor der Vorle sung Die Fragen wurden seitens der Studierenden zu einem sehr gro en Prozentsatz beantwortet Das lag daran dass wir entgegen den letzten Versuchen mit der Methode einen Prozentsatz beantworteter Fragen als Pr fungsvorleistung erbringen lie en Die Antworten waren meist 2 10 Zeilen lang F r manche Fragen mussten auch Diagramme erstellt werden die in Dateiform abgegeben wurden Erstes Feedback Die Lehrenden sichteten die Antworten und er kannten an Hand der Antworten Schw chen der Studierenden Dieser Teil des Just in Time Teachings war stets sehr aufw ndig 4 10 Stunden manchmal auch mehr da die Antworten gr ten teils nicht automatisch ausgewertet werden konn ten Allerdings bereitete es viel Freude die n chste Lehrveranstaltung kundengerecht also studie A Spillner H Lichter Hrsg SEUH 13 rendengerecht zu
203. en in der Praxis zu ermitteln und hat sich dabei als sehr zweckm ssig erwiesen wir ver wenden sie daher auch in diesem Artikel als Grundlage f r die folgende Diskussion ber die agile Ausbildung Tabelle 4 gibt die Verbreitung der vor allem von XP definierten konkreten Programmierpraktiken in den befragten agilen Unternehmen wieder w h rend Tabelle 5 die Verbreitung der Management Praktiken aufzeigt Besonders erw hnenswert da bei ist dass diese entsprechenden Werte bei plan getrieben arbeitenden Unternehmen zwischen 10 30 tiefer liegen Dies ist doch umso bemer kenswerter als es sich bei vielen Engineering Prac tices eigentlich nicht um spezielle agile Praktiken sondern um allgemeine Best Practices handelt Es l sst sich also sagen dass die Anwendung von agilen Methoden auch zur verst rkten Anwendung von allgemeing ltigen Best Practices f hrt 82 Engineering Practices Verbreitung Coding standards 75 Unit testing 70 Automated builds 63 Continuous integration 57 Refactoring 51 Test Driven Development TDD 44 Pair programming 31 Collective code ownership 30 Continuous delivery 30 Automated acceptance testing 24 Acceptance Test Driven Development 18 ATDD Behavior Driven Development BDD 15 Tabelle 4 Engineering Practices in der Praxis Management Practices Verbreitung Release planning 75 Iteration plan
204. en kann Wenn ein expliziter Sprachmechanismus zur Beschreibung von Schnittstellen zur Verf gung steht sollte dieser intensiv in einer softwaretech nisch orientierten Programmierausbildung genutzt werden Aber wann kann dieser Mechanismus eingef hrt werden Ein Ansatz Interfaces werden nach Vererbung und abstrakten Klassen thematisiert Diese Reihenfolge die in praktisch allen Java Lehrb chern verfolgt wird orientiert sich an der historischen Entwicklung von Interfaces In den vor Java entworfenen objektorientierten Sprachen wie beispielsweise C m ssen reine Schnittstellen mit vollst ndig abstrakten Klassen beschrieben werden Die Argumentation lautet verk rzt Klassen k nnen von anderen Klassen erben wenn nicht alle Methoden in der Superklasse implementiert sind wird diese zu einer abstrakten Klasse wenn alle Methoden nicht implementiert nur deklariert sind wird eine abstrakte Klasse zu einem Interface Diese Argumentation scheint zwingend zu erfor dern f r das Einf hren der Interfaces in Java den Umweg ber Vererbung und abstrakte Klassen gehen zu m ssen Alternative Interfaces werden zur expliziten Mo dellierung von Schnittstellen sehr fr h eingef hrt w hrend das komplexe Thema Vererbung deutlich sp ter thematisiert wird Schmolitzky 2004 Schmolitzky 2006 Die Interfaces von Java k nnen benutzt werden um Schnittstellen explizit zu beschreiben Insbe sondere kann demonstriert werden das
205. ender wie z B Studierende Der GQM Editor verarbeitet vorhergegangene An wendereingaben um kontextualisierte Hinweistexte an passenden Stellen einzublenden Z B wird der An wender in jedem Quadrant eines Abstraction Sheets explizit und individualisiert nach den einzutragenden Inhalten gefragt Diese Hinweistexte sollen als Denk ansto dienen und dem unsicheren Studierendem helfen diese Formulare zu verstehen Zus tzlich kann der smarte GQM Editor Antwort teile im Abstraction Sheet auf Wunsch anhand vor heriger Eingaben generieren Antwortteile die nicht automatisch generiert werden k nnen werden durch 147 L ckentexte repr sentiert Diese sollen den Anwender anregen passende Antworten einzutragen Die generierten Texte erscheinen in der angedach ten Ausf llreihenfolge Sie k nnen vom Nutzer ange passt gel scht bzw ausgeschaltet werden Die erstell ten Abstraction Sheets und Messpl ne k nnen vom Anwender gespeichert und verwaltet werden Eine umfangreiche Evaluierung des vorgestellten smarte GQM Editor in der universit ren Lehre wird vorbereitet Dabei soll die Akzeptanz der GQM Metho de und der zugeh rige Wissensgewinn bei Studieren den gemessen werden Die Konzepte des smarten GQM Editors sind als Initiative zu verstehen komplizierte Techniken besser zu erlernen und vermitteln Tool basiert kann die SE Lehre damit unterst tzt werden Literatur Basili 1992 BASILI Victor R Software modeling and
206. enniveau bedeuten Die Frage nach dem Verh ltnis der Testataufgaben zum Miniprojekt kann durch einen Vergleich mit Ab bildung 1 beziehungsweise durch einen Vergleich der Kennzahlen beantwortet werden Der Komplexit ts wert liegt mit 70 bis 90 nahezu mittig in den Grenzen des Miniprojektes und die Zahl der Anweisungen mit Werten zwischen 230 und 270 ebenfalls mittig im Rahmen des Miniprojektes Es kann daher davon aus gegangen werden dass die Testataufgaben bezogen auf Umfang und Komplexit t sehr genau das Aufga benniveau des Miniprojektes getroffen haben F r das Testat 5 Abbildung 6 hier betrachtet an der dritten Aufgabenvariante dieses Testats l sst sich eine leicht abweichende Beobachtung treffen Der von der Verteilung abgedeckte Bereich liegt zwar im Korridor von Miniprojekt 5 und wei t bei deutlicher kleiner Gr e eine hnliche Form auf liegt aber nicht mit tig innerhalb der Werte des Miniprojektes sondern deutlich nach oben verschoben Relativ zur Schwie rigkeit des Miniprojektes kann hier also ein h heres Aufgabenniveau angenommen werden Auch der Vergleich der Testate 4 und 5 unterein ander kann unter dem Gesichtspunkt des relativen Aufgabenniveaus angestellt werden Die Verteilungen beider Testate weisen im Diagramm eine hnliche Form auf und decken in etwa dieselbe Fl che ab wo bei Testat 5 etwas breiter gestreut ist Aufgrund des deutlichen Abstands der Cluster kann trotzdem ange nommen werden
207. er Hrsg SEUH 13 Schwerpunkte in der Lehre durch ver nderte Ge wichtungen oder eine ver nderte Zusammenset zung relativ leicht abgebildet werden k nnen So sind beispielsweise Aspekte des Projektmanage ments wie ein Projekt oder Iterationsplan und dessen Einhaltung in fortgeschrittenen Lehrveran staltungen problemlos bewertbar Insgesamt er scheint das vorgestellte Bewertungsschema damit so flexibel dass es prinzipiell auch f r Projekte in anderen Fachgebieten der Informatik anwendbar sein sollte Bis dato wurde das Verfahren in jeweils leicht ab gewandelter Form in drei Projekten an der Univer sit t Mannheim mit insgesamt gut 100 Studieren den erprobt Die Benotung und im Extremfall auch ein Durchfallen lassen von Studierenden waren insbesondere durch die angewendete vierstufige Systembewertung gut begr ndbar und letztlich auch f r die Studierenden nachvollziehbar so dass sich Detaildiskussionen ber die Bewertung subjek tiv deutlich reduzieren lie en entsprechende Pa rameter wurden leider nicht systematisch erfasst Neben kleineren Verbesserungen wie einer weite ren Verfeinerung der Abgaberichtlinien oder even tuellen Anpassungen der Gewichtungsfaktoren soll bei zuk nftigen Projekten auch eine systemati sche Befragung der Projektteilnehmer durchgef hrt werden um St rken und Schw chen des Verfah rens aus Sicht der Studierenden zu erkennen und gegebenenfalls identifizierte Probleme zu beheben DANKSA
208. er Vorlesung pr sentiert Evaluation Die Bewertung des Einsatzes von JiTT in der Ver anstaltung Software Engineering erfolgt aus zwei Perspektiven zuerst aus Sicht der Studierenden und dann aus Sicht der Lehrenden Grundlage sind die Daten aus dem Sommersemester 2012 Studentische Evaluation Die Quiz wurden von den Studierenden gut an genommen Von insgesamt 70 Teilnehmenden an der Veranstaltung haben durchschnittlich 51 an den Quiz teilgenommen Das entspricht einer Quote von 72 Allerdings hat die Beteiligung zum Ende des Vorlesungszeitraums abgenom men nachdem die Studierenden die maximal er zielbaren Bonuspunkte erreicht hatten Die durch schnittliche Bearbeitungszeit des Fragenteils lag bei 17 25 Minuten Dazu kam noch die Zeit f r die Vorbereitung also das Lesen der Einleitung das Herunterladen des Quelltextes und das erste Um sehen im behandelten System die nicht vom On linesystem erfasst werden kann Insgesamt er scheint der zus tzliche Zeitaufwand f r die Quiz aber vertretbar Erfreulich ist weiterhin dass im Schnitt 90 der Teilnehmenden eine Antwort ge geben haben die zeigt dass sie sich ernsthaft mit dem Thema auseinandergesetzt haben Vom Zentrum f r Lehre und Lernen der TUHH ZLL wurde am Ende des Semesters ein Bewertungsbogen an die Studierenden verteilt um ihre Einsch tzung des JiTT Ansatzes zu erfra gen Dabei sollten bestimmte Aspekte mit einer Note zwischen 1 voll zutreffend und 5 nicht
209. er Knackpunkt War die Menge an neuen Konzepten klein genug und deren Anbindung an bereits erarbeitetes Vorwissen ausrei chend so erforderte die anschlie ende Betreuung der Studierenden in den Praktika in etwa vergleichbaren Aufwand wie in den Vorjahren Erwies sich die Granu larit t bzw Komplexit t des Inkrementes dagegen als zu hoch schnellte der Betreuungsaufwand extrem in die H he Des Weiteren war zu beobachten dass die Motivati on der implementierungsstarken Studierenden in der A Spillner H Lichter Hrsg SEUH 13 Veranstaltung durch die enge Verzahnung zwischen Modellierung und Umsetzung erheblich gestiegen ist ebenso wie deren Verst ndnis f r die Notwendigkeit und die Aussagekraft der bunten Bildchen Die Teilkohorte der implementierungsschw cheren Studierenden hatte dagegen teilweise erhebliche Pro bleme mit der Bew ltigung der Praktikumsaufgaben Durch die Notwendigkeit die erstellten Modelle un mittelbar in ein lauff higes System umzusetzen wur den L cken aus den implementierungsnahen Grundla genf chern erneut evident Dar ber hinaus erzwang die drohende Umsetzung der Modelle bereits eine hohe Sorgfalt und Pr zision in den Diagrammen wel che bei einer reinen Modellierungsaufgabe nicht im gleichen Ma e zweifelsfrei offensichtlich geworden w re Es war daher aufgrund dieser engen Verzah nung weniger leicht m glich sich durch die Aufgaben irgendwie durchzuwursteln was bei einigen Studie
210. er inkrementellen Folge von Beispielsystemen gearbeitet die quasi bei null anf ngt und sukzessive immer komplexer wird Jedes der enthaltenen Systeme spiegelt dabei eine kleine aber vollst ndige Iteration durch den Software Life Cycle wider von der Anforderungsskizze ber Entwurf und Implementierung bis hin zum Test Motivation Software Engineering ist heute eine komplexe und sehr vielschichtige Disziplin Entsprechend hoch sind die Anforderungen die an ihre Ausf hrenden gestellt werden So sind beispielsweise bereits f r die Bewalti gung kleiner berschaubarer Projekte Kenntnisse und Kompetenzen in so unterschiedlichen Bereichen wie Analyse oder Implementierung erforderlich verbun den mit Modellierungssprachen Architekturprinzipien und aktuellen Frameworks f r die konkrete Umset zung Neben diesen eher technischen Kerndisziplinen und Wissensbereichen werden dar ber hinaus F hig keiten in Projektmanagement Vorgehensmodellen etc ben tigt sowie diverse grundlegende berfachliche Kompetenzen Selbst Sozial und Methodenkompe tenzen Einen guten berblick ber das Lernspektrum f r angehende Softwareingenieure vermittelt der Softwa A Spillner H Lichter Hrsg SEUH 13 re Engineering Body of Knowledge Abran u a 2005 der nach den 11 identifizierten Wissensbereichen der Version von 2004 in der aktuell entwickelten Version 3 auf 15 Wissensbereiche ausgebaut werden wird IE EE 2012 Diese Erweiterung d
211. erface zu implementieren das die Teilnehmer nutzen k nnen um ihre Implementierung zu testen und zu debuggen f Ist das Spiel geeignet um von Menschen gespielt zu werden kann der Mensch gegen seine eigene KI antreten was zus tzlich motiviert g Die Spielregeln sollten genug Raum f r eine kreative Umsetzung geben Auch die Implementierung einer Strategie in der KI sollte genug M glichkeiten der Differenzierung zwischen den Teilnehmern bieten h Die Implementierung des Spiels sollte einige algorithmische M glichkeiten bieten i Soll die Aufgabenstellung modifiziert werden Modifikation der Aufgabenstellung sollten die Regeln des Spiels dies erlauben Es sollten keine Implementierungen des Spiels frei verf gbar sein die die Studierenden einfach kopieren k nnen Ist die Spielidee rechtlich gesch tzt sollten die Rechteinhaber kontaktiert werden um die Bedingungen der Benutzung zu kl ren 4 Erstellen der Aufgabenstellung Ist eine sp tere Modifikation der Aufgabenstellung vorgesehen so kann diese Erweiterte Aufgabenstellung bereits mit erdacht werden Implementieren der vom Veranstalter vorgegebenen Teile Testbarkeit pr fen Anfertigen einer Referenz Implementierung der von den Studierenden zu implementierenden Teile BO yg Infrastruktur aufsetzen F r die einzelnen Schritte sollte ausreichend Zeit eingeplant werden Zum Vergleich Im Software Praktikum an der Uni versit t des Saarl
212. erreichte den zweiten Platz Der Titel dieses Beitrags ist bewusst mit einem Fragezeichen formuliert das unterschiedlich wie von einem der Gutachter angemerkt gedeutet A Spillner H Lichter Hrsg SEUH 13 werden kann Ist die hier beschriebene Program mierausbildung tats chlich eine softwaretechni sche Oder Was hei t eigentlich softwaretechni sche Programmierausbildung Oder Wollen wir berhaupt eine softwaretechnisch gepr gte Pro grammierausbildung Alle drei Deutungen sind sinnvoll und sollten zuk nftig ausf hrlicher disku tiert werden dies w rde jedoch den Rahmen dieses Beitrags sprengen der prim r als Erfahrungsbe richt fungieren soll Eine softwaretechnische Programmierausbil dung muss vor allem effektiv in Hinsicht auf nach folgende Module sein Sie muss unter anderem dazu f hren dass die Teilnehmer anschlie end kompetent Fragen des Software Engineering disku tieren k nnen Als zentrales Mittel die Effektivit t zu erh hen sehen wir unsere Pr senz bungen an Betrachtet man die reine Kontaktzeit zwischen einem Betreu ern und seinen Studierenden f hrt das Konzept zu ihrer Vervierfachung 90 Minuten klassischer bung stehen zweimal drei Stunden im Labor ge gen ber Unabh ngig von der vorgeschriebenen Gruppengr e 15 20 oder 25 Personen je nach Hochschule erh ht dies erheblich die M glichkeit zu individuellem Feedback und zur direkten Kommuni kation ber den Stoff bei gleiche
213. erung erkannt werden In der aktuellen Lehrpraxis wird daher mitunter bereits im modellierungslastigen Semester zus tzlich zur Erstellung eines komplett ausmodellierten Pflich tenheftes nebst vollst ndigen Entwurfsmodellen we nigstens eine rudiment re Umsetzung von Teilen der Systemfunktionalit t gefordert auch wenn ein gro er Teil der daf r ben tigten Kenntnisse erst ein Semester sp ter systematisch in der Lehrveranstaltung behan delt wird Insbesondere implementierungsschw chere Studierende sind damit in der Regel v llig berfor dert Die potenziellen Programmiergurus schaffen es da gegen bis zu einem gewissen Grad sich durch ent sprechende Rechere und Selbststudium die erforderli chen Implementierungstechniken anzueignen Daf r machen sie aber im Gegenzug zum Teil erhebliche Abstriche bei der Modellierung welche jedoch das eigentliche offizielle Lernziel der ersten Software Engineering Lehrveranstaltung gewesen w re Au er dem wird Software Engineering 2 von diesem Perso nenkreis dann gerne als langweilig empfunden weil die ben tigten Inhalte ja schon zum gro en Teil in Software Engineering 1 autodidaktisch erschlossen wurden A Spillner H Lichter Hrsg SEUH 13 Software Engineering Lehre nach dem Wasserfallmodell ber ein ganzes Semester hinweg betrachtet sind viele Software Engineering Lehrveranstaltungen so aufge baut dass sie zun chst einen sehr groben berblick ber den Stoff des ge
214. es SWEBOK ist eines von vielen Indizien daf r dass mit einer gravieren den Vereinfachung des Software Engineerings bis auf Weiteres erst mal nicht zu rechnen ist Den Lehrenden stellen der Umfang und die Komple xit t der zu vermittelnden Dom ne vor zwei zentrale Fragen Die eine angesichts der in der Regel streng be grenzten verf gbaren Ausbildungszeit unvermeidliche lauet e Was lasse ich weg Oder positiver formuliert e Was ist die Essenz die ich vermitteln muss will Die andere bei diesem Meer von untereinander ab h ngigen Wissensbereichen hnlich dr ngende Frage ist e Wo fange ich an Zur ersten Frage existieren bereits diverse allge meinere und konkretere berlegungen welche die zugrunde liegende Problematik zwar vielleicht noch nicht endg ltig l sen aber zumindest Handlungsspiel r ume aufzeigen Lehner 2009 Systematische berlegungen zur zweiten Frage nach dem richtigen Einstiegspunkt und einer sinn vollen Vermittlungs bzw Lernreihenfolge stehen im Fokus der vorliegenden Arbeit Hierf r wird zun chst die aktuelle Verteilung der Lerninhalte auf die einzelnen F cher im Software Engineering Lernpfad dargestellt und beleuchtet wel che Probleme sich in der Lehr Lernpraxis aus der derzeit etablierten am Wasserfallmodell orientierten Reihenfolge der inhaltlichen Vermittlung ergeben Dar auf aufbauend wird kurz die Idee vorgestellt die Lerninhalte des Software Engineerings nach einem iterativ
215. es und Tasks und ein starker Fokus auf die Selbstorganisation des studentischen Entwick lerteams Letztere haben wir unter anderem durch die Anleitung zu Stand Up Treffen und Retrospektiven unterst tzt ber die Jahre sind wir in den Praktika jedoch auch auf wiederkehrende Schwierigkeiten gesto en So ist es immer wieder vorgekommen dass fast fertige Sto ries nicht endg ltig fertiggestellt wurden Die letzten integrierenden Arbeitsschritte wurden von den Stu denten sowohl als unerfreulich als auch als technisch anspruchsvoll wahrgenommen Daher wurden andere Arbeiten der Fertigstellung vorgezogen auch wenn sich das Team bereits dieses Problems bewusst war Sicherlich h tte sich dieses Problem durch Zuordnung einzelner zu diesen Arbeitsschritten l sen lassen aber das h tte dann unser Bem hen das Team in seiner Selbstorganisation zu unterst tzen deutlich konterka riert Mit Kanban erhofften wir uns dass durch die Kombination des Pull Prinzips mit strikten Limits f r die einzelnen Phasen die Sichtbarkeit des Problems so deutlich w rde dass sich das Team seiner annehmen w rde Eine weitere Herausforderung die von den Studen ten deutlicher wahrgenommen wurde als von uns war den Aufwand f r Besprechungen insbesondere zum Anfang einer Iteration zu reduzieren In nicht wenigen Praktika verbrachten die Studenten einen Tag oder sogar etwas mehr damit in die Produkt w nsche des Kunden eingef hrt zu werden Bei einer
216. esen Gege benheiten offensichtlich nicht trivial vgl z B Hayes et al 2007 aber nichtsdestotrotz kritisch da sie ma geblich ber das Fortkommen der Stu dierenden entscheidet und letztlich auch ihre Moti 103 vation stark beeinflusst Dabei schr nken zahlrei che u ere Zw nge wie Zeitvorgaben oder Budge trestriktionen die M glichkeiten zur Bewertung ein so dass es nicht verwunderlich ist wenn in der Lehrpraxis f r gro e Kohorten h ufig auf Ersatz priifungsverfahren wie Kolloquien Lern tageb cher oder gar Klausuren zur ckgegriffen wird vgl Kehrer et al 2005 um praktische Stu dienleistungen zu bewerten Je nach Ausgestaltung dieser Bewertungsarten ergibt dies einen nicht un erheblichen Mehraufwand f r alle Beteiligten der auf Seiten der Studierenden zudem leicht zu einem Motivationsverlust bei der Entwicklungsarbeit f hren kann da diese berhaupt nicht oder nur in sehr begrenztem Umfang in die Benotung einflie t Soweit letzteres berhaupt der Fall ist existiert in der Literatur und nach Kenntnisstand des Autors auch in der Praxis bisher selten ein differenziertes und transparentes Bewertungssystem wie es in diesem Beitrag vorgestellt wird Eigene Erfahrungen des Autors der im Verlauf seines Studiums zwei Mal selbst an einem entspre chenden Projekt teilgenommen und einmal als stu dentische Hilfskraft an der Betreuung mitgewirkt hat waren hnlicher Art In den ersten beiden F l len w
217. eses Muster ist typisch nicht nur f r Program mierveranstaltungen es ist aber in vielerlei Hin sicht unbefriedigend siehe auch Altenbernd Giani et al 2009 Erstens bewirkt es einen sehr gro en Abstand von der Aufgabenstellung bis zum Feed back das bei den Lernenden ankommt mindestens zwei Wochen Zweitens ist das Feedback meist nur sehr d nn im schlechtesten Fall besteht es aus der erzielten Punktzahl im besten Fall aus einem Text der nicht nur die Bewertung erl utert sondern Hinweise auf Verbesserungsm glichkeiten gibt Letztere sind insbesondere bei Programmierl sun gen h ufig sinnvoll oder sogar notwendig Drittens ist es aus Kapazit tsgr nden meist nicht m glich dass ein Tutor von jedem Studierenden eine Ein zelabgabe erh lt deshalb kommt es zu so genann ten Arbeitsgruppen von zwei bis vier Personen die eine gemeinsame Bearbeitung abgeben H ufig sieht diese leider so aus dass ein Student die Bear beitung vornimmt und ein oder zwei weitere Stu dierende lediglich ihren Namen mit auf das Blatt setzen Alternative Die Studierenden bekommen spezielle Pr senzaufgaben die sie in Laborr umen der Hoch schule unter Betreuung in Paaren bearbeiten und auch direkt am Rechner durch Betreuer wissen schaftliche Mitarbeiter und studentische Hilfskr fte aus h heren Semestern abnehmen lassen Die Be treuer k nnen den Studierenden unmittelbares und pers nliches Feedback geben und insbesondere bei Problemen s
218. esteht ein Team aus drei oder vier Personen O M ssen die Teams das Projekt im Wesentlichen eigenverantwortlich durchf hren O Erfolgt die Benotung individuell O Macht die Veranstaltung allen Spa 34 Literatur Automotive SPICE Prozessassessment 2007 http www automotivespice com AutomotiveS PICE_PAM_v23_DE pdf Barr M 1999 Programming Embedded Systems in C and C Bass L et al 2003 Software Architecture in Prac tice 2nd edition Bengel G et al 2008 Masterkurs Parallele und Verteilte Systeme Goll J 2011 Methoden und Architekturen der Softwaretechnik Hruschka P et al 2002 Agile Softwareentwick lung fiir Embedded Real Time Systems mit der UML Kienzle E et al 2009 Programmierung von Echt zeitsystemen Kleuker S et al 2011 Vier Jahre Software Engineering Projekte im Bachelor ein Status bericht SEUH 2011 L w P et al 2010 Funktionale Sicherheit in der Praxis Mattern F GI Webseite 2012 http www gi de service informatiklexikon detailansicht article pervasiveubiquitous computing html metio Webseite mit Bildern der Modelle 2012 Ampel _ http www metio de ger ampel html Aufzug http www metio de ger aufzug html Pohl K 2007 Requirements Engineering Schmedding D 2011 Teamentwicklung in stu dentischen Projekten SEUH 2011 Sommerville I 2007 Software Engineering Starke G 2008 Effektive Software Architekturen SysML 2
219. eure Hard ware so dass Smalltalk zwar in einigen Unterneh men wie z B dem Versicherungsbereich in Deutschland in der Entwicklung eingesetzt wurde aber nie einen echten Durchbruch schaffte Teil dieser Problematik ist die zun chst gew hnungs bed rftige Syntax in der z B Parameter in Mixfix Notation in den Methodennamen integriert wer den Die folgenden Befehle erzeugen ein Objekt vom Typ Dictionary das Paare von Werten verwal ten kann f r die dann ein erstes Paar eingetragen wird 48 d Dictionary new d at Smalltalk put irgendwie spannend Bemerkenswert ist dass auch diese Schreibweise wesentliche Vorteile hat da man so genau wei wozu die Parameter eingesetzt werden Smalltalk wurde und wird in der Programmierein f hrung im Studiengang Wirtschaftsinformatik an der privaten Fachhochschule Nordakademie in Elmshorn genutzt Die Fachhochschule bietet duale Studieng nge an wobei Unternehmen Studierende aussuchen und deren Studiengeb hren bezahlen Die Studierenden arbeiten zwischen den Vorle sungsbl cken in den Unternehmen Bemerkenswert ist dass auch die Unternehmen die Auswahl von Smalltalk als Lernsprache mittragen was damit zusammenh ngt dass in h heren Semestern kon sequent Java eingesetzt wird Die Voraussetzungen f r die Programmiereinf h rung unterscheiden sich damit deutlich von denen an ffentlichen Hochschulen Die Studierenden haben sich bewusst f r den dualen Studiengang en
220. evier 1977 Kaner u Bond 2004 KANER Cem BOND Walter P Software Engineering Metrics What Do They Mea sure and How Do We Know In In METRICS 2004 IEEE CS Press 2004 Leach 1995 LEACH Ronald J Using metrics to evaluate student programs In SIGCSE Bull 27 1995 S 41 43 http dx doi org 10 1145 201998 202010 DOI 10 1145 201998 202010 ISSN 0097 8418 Martin u a 2009 MART N David CORCHADO Emi lio MARTICORENA Ra l A Code comparison of Student Assignments based on Neural Visualisation Models In CORDEIRO Jose A M Hrsg SHISH KOV Boris Hrsg VERBRAECK Alexander Hrsg HELFERT Markus Hrsg INSTICC Veranst Proceedings of the First International Conference on Computer Supported Eductation CSEDU 23 26 March 2009 Lisboa Portugal Bd 1 INSTICC IN STICC Press 2009 ISBN 978 989 8111 82 1 S 47 54 McCabe 1976 MCCABE Thomas J A Complexity Measure In IEEE Transactions on Softwa re Engineering 2 1976 Nr 4 S 308 320 http dx doi org 10 1109 TSE 1976 233837 DOI 10 1109 TSE 1976 233837 ISSN 0098 5589 Mengel u Yerramilli 1999 MENGEL Susan A YER RAMILLI Vinay A case study of the static analysis of the quality of novice student programs In The pro ceedings of the thirtieth SIGCSE technical symposium on Computer science education New York NY USA ACM 1999 SIGCSE 799 ISBN 1 58113 085 6 S 78 82 Striewe u a 2009 STR
221. ezeigt und Vor und Nachteile der Methode beschrieben Aktivierende Lehre Aktivierende Lehre ist ein wichtiger Bestandteil um nachhaltiges kompetenzorientiertes Lernen zu f rdern Aktivierende Lehre und aktives Lernen h ngen unmittelbar zusammen Mottok 2010 Lehrende geben Studierenden Raum mitzudenken und mitzuarbeiten Dieses Miteinander l sst sich sowohl innerhalb als auch au erhalb von Vorle sungen und bungen gestalten Dabei vollzieht sich ein Perspektivwechsel von der Inhaltsorientie rung in der Lehre hin zur Orientierung an Lerner gebnissen bzw Kompetenzen der Studierenden 17 Lernen entspringt aus dem Verrichten der ei gentlichen Arbeit mit Feedback Maier 2000 Stu dierende lernen am besten in Kontexten also situa tiv Isoliert Gelerntes ist schwer erinnerbar und schnell entschwunden Wenn Aktivit t von Beginn an in den Lernprozess integriert wird dann steigt die Wahrscheinlichkeit f r gelingendes Lernen im Sinne einer Initiierung neuer Handlungsweisen Stelzer Rothe 2008 Entdeckung und Motivation spielen eine gro e Rolle bei aktivierender Lehre Die Studierenden entdecken ihre eigenen F higkeiten und M glich keiten Probleme zu l sen Es entsteht Handlungs kompetenz bei den Studierenden Diese zeigt sich in der F higkeit Lerninhalte sowohl in Routinesi tuationen als auch in neuen nie zuvor erlebten und durchdachten Situationen zielorientiert zu erfassen Meyer 2009 Auch die Lehrenden
222. fang mehr zum Niveau der Aufgabe beitr gt In Miniprojekt 6 wurde im arithmetischen Mittel 50 84 Punkte erreicht in allen Testatvarianten zusammen im arithmetischen Mittel 65 34 Punkte Dies legt nahe dass das Testat wie erwartet ein niedri geres Niveau hatte als das Miniprojekt und im brigen in etwa gleichwertig zu Testat 4 war Aus diesen berlegungen l sst sich also festhalten dass die Messung der Zahl der Anweisungen und der zyklomatischen Komplexit t es erlaubt Aussagen ber das relative Niveau einer Aufgabe zu machen Dies k nnte in E Learning Systemen beispielsweise genutzt werden um automatisch den Schwierigkeitsgrad von Aufgaben zu bestimmten und Studierenden damit ge zielt schwierigere oder leichtere Aufgaben anbieten zu k nnen Noch einmal sei an dieser Stelle darauf hingewiesen dass es andere Einflussfaktoren auf das Niveau einer Aufgabe gibt die sich ber die disku tierten Metriken nicht abbilden lassen so dass die Verwendung von Softwareproduktmetriken trotz ihrer N tzlichkeit nicht als alleiniges Mittel zum Einsatz kommen sollte Naheliegend ist beispielsweise die Er weiterung des Ansatzes auf Softwaremetriken die nicht das Produkt sondern den Erstellungsprozess messen und somit beispielsweise Auskunft dar ber geben k nnen ber welchen Zeitraum hinweg oder in welchen Einzelschritten eine L sung erstellt wurde Auch aus diesen Metriken kann eine Aussage ber das Niveau einer Aufgabe erwartet werden
223. fgabe den Studierenden mehr Freiheiten zu umfangreicheren aber weniger komplexen L sungen beziehungsweise kleineren aber komplexeren Ans tzen Bis hierhin kann also festgehalten werden dass die Messung der Zahl der Anweisungen und der zyklo matischen Komplexit t es erlaubt Aussagen ber den Freiheitsgrad einer Aufgabe zu treffen und somit ge gebenenfalls gezielt Aufgaben auszuw hlen Als Nebenbemerkung ist in allen drei F llen zu be obachten dass es in der oberen H lfte der Verteilung d h in der jeweils oberen H lfte des Wertebereichs der beiden verwendeten Metriken je einen Punkt mit einer besonders hohen Zahl von L sungen gibt der bis zu knapp 20 aller L sungen repr sentiert F r diese auff llige H ufung konnten zwei Ursachen ermittelt werden Zum einen konnten sich Studierende w h rend der Bearbeitungsphase der Aufgabe Ratschl ge und Hilfestellung von Tutoren holen die sich ihrer seits an der Musterl sung einer Aufgabe orientierten Die Merkmale dieser Musterl sung lassen sich in der Verteilung der studentischen L sungen entsprechend A Spillner H Lichter Hrsg SEUH 13 Anweisungen 70 90 110 130 150 170 190 210 230 250 Komplexit t Bestanden Nicht bestanden Abbildung 1 Verteilungsdiagramm f r 1309 L sungen zu einer Ubungsaufgabe Miniprojekt 4 Gr ere Kreise bedeuten mehr L sungen mit denselben metrischen Kennzahlen Es wurden maximal 43 L s
224. g Bachelor s Thesis 2012 A Spillner H Lichter Hrsg SEUH 13
225. g konnte die GQM Me thode erfolgreich in verschiedenen Industrieprojekten eingesetzt werden Van Latum u a 1998 und Birk A Spillner H Lichter Hrsg SEUH 13 u a 1998 beschreiben den Einsatz bei Schlumberger RPS Gantner u Schneider 2003 haben den GQM Prozess in zwei F llen aus der Automobilindustrie angewendet und beschreiben eingehend den Einsatz von Abstraction Sheets Kilpi 2001 setzt eine ange passte GQM Variante bei Nokia ein Van Solingen u Berghout 1999 bietet eine eingehende Betrachtung von GQM samt Fallbeispielen Dem Erfolg von GQM in der Praxis folgend wird die GQM Methode auch an der Leibniz Universit t Hannover gelehrt Dem Thema GQM ist ein Kapitel der Vorlesung zur Software Qualit t gewidmet und es wird auch im dazugeh rigen bungsbetrieb be handelt Erfahrungsgem l sst sich ein besserer Ler nerfolg erzielen wenn GQM praktisch angewendet wird Das Konzept von Abstraction Sheets und deren korrekte Erstellung bereitet den Studierenden jedoch fter Schwierigkeiten obwohl der Prozess zum Er stellen eines Abstraction Sheets klar vorgegeben ist Studierende zeigten wiederholt Schwierigkeiten Ab straction Sheets korrekt auszuf llen Das m hsame Aufzeichnen der Formulare per Hand k nnte eine zu s tzlich H rde darstellen In dieser Arbeit stellen wir einen Editor f r Abstraction Sheets vor der Studieren de mit Hilfsmechanismen aktiv beim Anwenden der GQM Methode unterst tzt Der
226. ge wie es die eigene Arbeitskraft nicht berlastet sobald aber ihre Belas tungsgrenze erreicht wird sind entsprechende Konflikte bis hin zu auseinanderbrechenden Teams vorprogrammiert Organisatorische Sicht Die im Folgenden beschriebenen Softwaretechnik Lehrveranstaltungen an der Universit t Mannheim waren nach einem verbreiteten Muster organisiert ein Professor trug als Pr fer die Hauptverantwor tung f r die Veranstaltung und vermittelte in Vor lesungen die theoretischen Hintergr nde Wissen schaftliche Mitarbeiter bernahmen die Aufgabe den Studierenden den Lehrstoff an Hand von ein zelnen bungsaufgaben mit direktem Projektbezug auch praktisch n her zu bringen Die wissenschaft lichen Mitarbeiter waren ferner f r die Steuerung des eigentlichen Projekts ebenso zust ndig wie f r die Kl rung von offenen Fragen z B bzgl der An forderungen Die direkte Betreuung der Entwick lungsteams oblag auf Grund der recht hohen Teil A Spillner H Lichter Hrsg SEUH 13 nehmerzahlen von anfangs teilweise deutlich ber f nfzig Studierenden einer Reihe von studenti schen Tutoren Diese hatten in der Regel bei min destens w chentlichen Treffen der Teams direkten Kontakt mit den Studierenden und trafen sich ebenso regelm ig mit den Mitarbeitern um ber die Fortschritte ihrer Teams zu berichten Von an deren Universit ten sind hnliche Konstellationen mit teilweise noch weit h heren Teilnehmerzahlen bekannt
227. gegeben jedoch nicht der Weg dorthin Dies wird den Studierenden am Anfang der Veran staltung auch mitgeteilt damit sie von Anfang an Klarheit ber den Ablauf des Projektes haben Den Studierenden werden immer wieder auch angeregt durch Abgaben oder Fragen Denkanst e zum Weg der Probleml sung gegeben Einige Beispiele dazu sind im n chsten Abschnitt zu fin den Durch Hinterfragen der gegangenen Schritte werden die Studierenden an strukturierte Heran gehensweisen an Probleme herangef hrt Sie erhal ten Anregungen f r m gliche L sungswege Diese k nnen im Projekt zu einem sp teren Zeitpunkt noch genutzt werden zum Beispiel bei der berar beitung der Arbeitsprodukte nach einer Anforde rungs nderung Den Studierenden werden auf diese Weise immer wieder Anregungen zur Selbst reflektion gegeben um Vorgehen und Verhalten zu analysieren und zu verbessern In der Praxis werden Arbeitsergebnisse immer wieder Reviews unterzogen Auch dies wird im Projekt ge bt Zu jeder Abgabe ist vom gesamten Team ein Review durchzuf hren Neben den Ab gaben sind zus tzlich die im Review gefundenen Aspekte mit abzugeben Damit kann fr hzeitig ge bt werden von anderen Personen erstellte Ar beitsprodukte zu verstehen und Fehler aufzude cken Auch wird klar dass ein Review auf das Aufdecken von Fehlern zielt und nicht etwa den Ablauf oder Inhalt der Arbeitsprodukte beschreibt Bei der Kurzpr sentation der einzelnen abzuge
228. gen deutlich dar ber liegen wird der Aufwand f r andere Aufgaben wie beispielsweise Anforderungsanalyse oder nde rungsmanagement erl utert Insbesondere f r Studierende ohne vorherigen Kontakt mit der Entwicklung eingebetteter Systeme ist die Erfahrung interessant dass die Arbeit mit Evaluationsboards sehr zeitraubend sein kann Die Ausf hrungsumgebung f r die Programme ist auf einem vom Entwicklungs PC getrennten Compu ter der in Betrieb genommen werden muss Au erdem muss die Software geladen werden und dar ber hinaus ist die Dokumentation oft unvoll st ndig oder fehlerhaft 29 Rollenspiele Das Projekt lebt von Rollenspielen Der Dozent schl pft wie im vorherigen Abschnitt beschrieben beispielsweise in die Rolle des Kunden erl utert immer zu geeigneten Zeitpunkten was gerade pas siert ist und gibt L sungsm glichkeiten vor die dann im weiteren Verlauf erprobt werden k nnen Eine wichtige Erfahrung bei den Rollenwechseln ist den Studierenden jederzeit klar zu machen in welcher Rolle man sich gerade befindet da es sonst verwirrend ist Gerade in der Rolle eines Kunden kann bewusst eine ganz andere Sprache verwendet werden Damit kann den Studierenden aufgezeigt werden dass es oft nicht m glich ist sich mit Kunden ber das System mit den technischen Begriffen der Ent wickler zu unterhalten sondern die Unterhaltung in der Sprache des Kunden gef hrt werden muss Ein Erlebnis des Autors war di
229. gen ist verpflichtend und umfasst je zwei Semesterwochenstunden seminaristi schen Unterricht und zwei Semesterwochenstunden Praktikum An den Praktikumsgruppen nehmen in der Regel ca 20 Studierende teil Der seminaristische Un terricht ist auf ca 40 50 Studierende ausgelegt wobei hier bedingt durch die aktuellen starken Jahrg nge zum Teil erheblich nach oben abgewichen werden muss Erg nzt werden diese Pflichtf cher durch ein um fangreiches Angebot an Wahlf chern deren Spektrum von Personalf hrung bis Webtechniken reicht und die ab dem 4 Semester besucht werden k nnen Auftretende Schwierigkeiten Obiger Studienplan legt also fest dass nach einer Grundausbildung in objektorientierter Programmie rung in den Software Engineering Veranstaltungen zu n chst im 3 Semester die fr hen eher modellierungs orientierten Disziplinen sowie Management Themen behandelt werden w hrend die eher technischen im plementierungsnahen Disziplinen sowie Vorgehens modelle erst im 4 Semester auf der Tagesordnung stehen Diese Aufteilung bewirkt dass die Studierenden also ein Semster lang Anforderungen erfassen und analysieren daraus Entw rfe ableiten und all das mit umfassenden UML Modellen konkretisieren Wie sich 72 die dabei gef llten Entscheidungen und erstellten Spe zifikationen letztendlich auf den Quelltext und das zu entwickelnde System auswirken bleibt dabei zun chst eine rein theoretische berlegung da der Round Trip
230. gestalten Hierbei handelte es sich um die erste Feedback Schleife in der die Leh renden die Probleme der Studierenden mit dem Stoff erkennen konnten F r die Gestaltung der n chsten Lehreinheit wurden teils Pr sentationsfo lien erstellt die Sachverhalte klar stellen sollten teils aber auch Folien mit anonymen Zitaten der Studierenden die dann in der Vorlesung diskutiert wurden Auch weitere Beispiele wurden hinzuge f gt Zweites Feedback Parallel dazu berlegten sich die Lehrenden Auf gaben f r die Lehrveranstaltung die mit Hilfe eines automatischen Antwortsystems siehe Abb 2 von den Studierenden beantwortet wurden Der Einsatz dieses Mediums hat den Vorteil dass die Studie renden wie oben besprochen individuell die Fra gen beantworten k nnen Au erdem hatten die Studierenden viel Spielfreude dabei was zu einem lockeren Lernklima beitrug Unser Angebot die Fragen anonym zu beantwor ten wurde bei den Masterstudierenden abgelehnt Sie hatten Freude am Wettbewerb Da sich die Studierenden geeinigt hatten dass wir nach jedem Test die Prozentzahl der richtig beantworteten Fra gen gemeinsam anschauen war die Motivation hoch sich bei der Beantwortung der Fragen anzu strengen Die aktive Beteiligung der Studierenden war immens und es bedurfte keiner Ma nahme die Beantwortung der Fragen zu benoten SMART Response XE 9 0 ol P Ve Da Abb 2 Automatisches Antwortsystem SMART In der Leh
231. gineering auf Ba chelor Stufe und haben damit begonnen auch auf dieser Stufe agile Software Entwicklungsmethoden zu vermitteln 81 Agile Software Entwicklung F r ein besseres Verst ndnis der im Folgenden vorgestellten Studienkonzepte und Lehr und Lernmethoden fassen wir hier die aus unserer Sicht wichtigsten Eigenschaften der agilen Software entwicklung zusammen In erster Linie sind dabei nat rlich die Werte und Prinzipien des Agile Manifesto 6 zu nennen die auf der einen Seite zwar noch keine konkreten Praktiken und Techniken vorgeben aber mit Ihren Prinzipien doch klare Anforderungen an eine agile Vorgehensweise definieren Aus diesen Prinzipien hat insbesondere extreme Programming XP eine Anzahl ganz konkreter Programmierpraktiken abgeleitet ohne die aus unserer Sicht eine agile Softwareentwicklung nicht m glich ist Auf Managementsicht geh rt wohl Scrum zu den Vorreitern der agilen Methoden Scrum definiert klare Regeln bzgl Projekt und Teamorganisation sowie dem Requirements Management Neuere Ans tze wie Lean Software Development 9 die sich ebenfalls an den Prinzipien des Agile Manifesto orientieren zeigen weitere interessante Aspekte zur Umsetzung der agilen Software Ent wicklung auf Die folgenden Tabellen fassen die aus unserer Sicht wichtigsten Engineering und Management Practices zusammen Diese Einteilung wurde von uns f r die Studie entwickelt um die Verbreitung der genann ten Praktik
232. gration von Tasks zum Ticket und der Review unbeliebter waren In der Konsequenz wurde lieber ein neues Ticket analysiert als ein fast fertiges Ticket fertigzustellen und dem Kunden zu pr sentieren Anpassungen w hrend des Praktikums W hrend des Praktikums wurden einige Anpassungen an den Arbeitsfluss und die Visualisierung des Prozes ses vorgenommen Im Folgenden m chten wir diese genauer beschreiben und vorstellen Der Hauptgrund f r die Anpassungen war ein verebben des Ticketflus ses innerhalb des Prozesses Ebenso wurden Ver nde 60 m Backlog Items m Input Queue 50 mAnalysis m Development m Review Tickets 40 live Date Abbildung 3 Cumulative Flow Diagramm des Prak tikums A Spillner H Lichter Hrsg SEUH 13 rungen aus didaktischen und allgemeinen praktischen Gr nden vorgenommen Das Verebben des Ticketflusses wurde deutlich an hand der Anzahl der Entwickler die keine Arbeit hat ten Dies wurde teilweise durch blockierende Tickets in sp teren Phasen erzeugt Im Kanban Prozess soll ten idealerweise die freien Ressourcen mithelfen die Engp sse zu beheben Dies war aber bei unseren fein granularen Tasks die schon auf ein Entwickler Paar geplant waren selten m glich Ebenso zeigte sich dass unsere oben beschriebene anf ngliche Priorisierung ung nstig gew hlt war Durch die Engp sse in der Development Phase gab es wenige bis keine Tickets f r den Rev
233. gsheterogenit t haben sich in der Erfah rung des Autors nicht bew hrt da sie das Auftre ten von Trittbrettfahrern zu f rdern scheint Wer zu diesem Zeitpunkt nicht ber minimale Pro grammierkenntnisse verf gt also das Testat nicht bestanden hat muss vom weiteren Verlauf des Projekts ausgeschlossen werden um die brigen Studierenden vor einer berlastung zu sch tzen Dies bringt nat rlich eine gleichzeitige Reduktion der verlangten Features f r den Rest der Gruppe mit sich Eine Wiederholungsm glichkeit f r das Testat w rde den weiteren Ablauf des Projekts A Spillner H Lichter Hrsg SEUH 13 offensichtlich stark beeintr chtigen und ist daher nicht vorgesehen zumal fehlende Programmier kenntnisse ohnehin nicht binnen weniger Tage aufzuholen sind Auf Grund der harten Konse quenzen dieses Kriteriums liegt es aber nahe das Testat bereits zu oder gar vor Beginn des Semesters als Freiversuch anzubieten um den Studierenden ein fr hes Feedback zu geben und ihnen ggf eine mehrw chige Auffrischung ihrer Vorkenntnisse zu erm glichen Nach erfolgter Einteilung der Projektteams sind diese gehalten sich vertieft in die Projektanforde rungen einzuarbeiten und diese entsprechend zu analysieren und zu dokumentieren durch Use Cases System Sequenzdiagramme oder Operation Contracts Um die abschlie ende Benotung zu erleichtern sind alle abzugebenden Artefakte mit dem Namen des Bearbeiters zu versehen und unter
234. h durch die verwendete integrierte Entwicklungsumgebung IDE unterst tzt werden Minimal sollte die IDE auch Unterst tzung f r einfache Refactorings wie Rename Method oder Rename Variable bieten Ebenfalls gute Erfahrungen haben wir mit Werk zeugen wie Checkstyle 16 gemacht welches direkt in der IDE anzeigt falls die Coding Standards ver letzt werden Sehr positive Erfahrungen haben wir mit dem fr hzeitigen Einsatz dieser Konzepte und Werk zeuge z B im 2 Semester im Rahmen des Modul Software Konstruktion zusammen mit Continuous Integration Umgebungen gemacht Durch eine fr he Einf hrung werden die Studierenden animiert diese Praktiken auch in ihren Projekten einzuset 84 zen was auch sehr h ufig auf freiwilliger Basis geschieht da sie die Vorteile solcher Umgebungen schon fr h erkennen Unit Testing Unit Testing wird im ersten Semester eingef hrt Dabei ist besonders wichtig dass diese Praktik nicht nur in speziellen Modulen unterrichtet wird sondern dass auch sonstige programmierlastige Module Unit Tests einfordern oder vorgeben um so z B die erfolgreiche Implementierung einer Pro grammieraufgabe zu berpr fen So k nnen zum Beispiel im ersten Semester w h rend der Einf hrung ins Programmieren Unit Tests bei bungen vorgegeben werden Die Aufgabe gilt als erf llt wenn das zu entwickelnde Programm alle Unit Test besteht Die Studierenden lernen so spielend die N tzlichkeit von automatischen
235. he anstel len zu k nnen ist ein einheitliches Beschreibungs schema erforderlich W hrend zu fachlichen Kompetenzen zahlrei che Vorarbeiten zu finden sind existieren f r ber fachliche Kompetenzen nur sehr allgemeing ltige Einteilungen vgl Kap 3 Daher werden fachliche und berfachliche Kompetenzen separat betrachtet wodurch sich auch das Vorgehen unterscheidet A Spillner H Lichter Hrsg SEUH 13 Vorgehen bei berfachlichen Kompetenzen SWEBOK strukturiert fachliche Inhalte des Soft ware Engineering und bietet somit einen Anhalts punkt welche fachlichen Kompetenzen im Soft ware Engineering relevant sein k nnen Allerdings vernachl ssigt SWEBOK berfachli che Kompetenzen v llig Zudem ist keine mit SWEBOK vergleichbare Landkarte f r berfachli che Kompetenzen im Software Engineering be kannt Auch ist noch unklar wie trennscharf sich berfachliche Kompetenzen unterscheiden lassen L sst sich eine Kompetenz eindeutig beispielsweise den motivationalen oder volitionalen Kompetenzen zuordnen Diese Frage ist erst nach Erhebung ers ter konkreter berfachlicher Kompetenzen zu be antworten Da im Bereich berfachlicher Kompetenzen f r Software Engineering also noch keinerlei Vorerhe bungen oder vorstrukturierende Daten vorhanden sind sind somit die zu erwartenden Inhalte unklar Daher bietet sich ein iteratives Forschungsdesign an das bottom up mit v llig offenem Blick ber fachliche Kompetenz
236. hen Sie k nnen dazu genutzt werden Einsicht in die Notwendig keit von Softwareprozessen zu erzeugen und den Erfahrungshorizont von Studierenden des SE auf virtuelle und effiziente Art und Weise zu erweitern Verschiedene Anstrengungen unterschiedlicher Forschungsgruppen weltweit zeigen ermutigende Ergebnisse Im Forschungsprojekt Sim4SEEd wer den existierende Erfahrungen gesammelt und neue Ideen entwickelt um das Potential digitaler Lern spiele in dieser Dom ne zu erweitern und zu einer weiter verbreiteten Nutzung in der SE Ausbildung anzuregen Die vorgestellten Ideen dienen als Kernelemen te f r die Entwicklung einer neuen Spielumgebung welche das Erlernen von Softwareprozessen effek tiv und effizient unterst tzt Einleitung Die Entwicklung komplexer Softwaresysteme ver langt nach gut ausgebildeten Softwareingenieuren welche in der Lage sind die richtigen Technolo gien Werkzeuge und Prozesse auszuw hlen um dynamischen Anforderungen gerecht zu werden Zu den gro en Herausforderungen heute und in Zukunft geh ren dabei die zunehmende Vielfalt und die Forderung nach k rzeren Entwicklungs zeiten bei gleichzeitiger Sicherstellung vertrauens w rdiger Qualit t Sommerville 2010 Die zu nehmende Vielfalt umfasst neben Technologien Plattformen Werkzeugen und Anwendungsdom A Spillner H Lichter Hrsg SEUH 13 nen auch Methoden und Softwareprozesse Variie rende Szenarien erfordern die Ber cksichtigung
237. hen die einem erz hlt werden und da hei t es dann o k das macht man so und das macht man so aber man wei im Grunde ge nommen ganz oft nicht warum macht man das denn eigentlich so Weil es gibt eigentlich zehn M glichkeiten etwas zu machen Im Studium wer den vielleicht zwei M glichkeiten beleuchtet und dann hat man zwar geh rt Okay das und das sollte man so machen aber man wei gar nicht warum man das so machen muss und wenn jetzt jemand zu uns kommt der sich eben ber das Stu 126 dium hinaus mit den Themen besch ftigt hat dann ist es ganz oft auch der Fall dass der eben ja ver schiedene M glichkeiten schon abgeklopft hat und dann auch ja von sich aus verstehen kann nach vollziehen kann warum manche Sachen notwendig sind Auch ein dritter Befragter verlangt Ver st ndnis daf r vor allem WARUM muss ich das verwenden welchen Nutzen ziehe ich denn dar aus wenn ich das mache Dabei geht es nicht ausschlie lich um das Ver stehen und Einordnen von Fach und Faktenwis sen sondern auch darum die Tragweite und Zu sammenh nge komplexer Probleme bewusst wahr zunehmen Ein Interviewpartner fasst diese Aspek te so zusammen Wenn man dann ins allt gliche Berufsleben hinein geschmissen wird hat man eher das Problem dass man von den ganzen ja Dingen die da existierten erst mal berw ltigt ist Diese Zitate verdeutlichen dass der Theorie Praxis Transfer von Kompetenzen und W
238. hen re schwierig Gefahr unreflek gelm ig tierter Aufz hlungen gro Reflektion Studierende reflektieren Bei korrekter Ausf hrung Weiterer Overhead f r die ber ihre Erfahrungen relativ hoher Lerneffekt Studierenden bei ohnehin schon starker Belastung dedizierte Benotung eben falls schwierig Mitarbeitsnoten Mitarbeit der Studieren Motiviert zu regelm iger Generell nur schwer objek den in ihrer Gruppe wird Mitarbeit geringer Auf tiv einsch tzbar insbeson bewertet wand dere bei Heimarbeit Benotung der Studierende geben sich Geringer Aufwand f r den Validit t amp Legalit t sehr Studierenden un gegenseitig Noten oder Betreuer Studierende re fraglich m gl negative tereinander Peer verteilen eine begrenzte flektieren und lernen durch Auswirkungen auf die Assessment Anzahl von Punkten an Bewertung ihrer Kommili Gruppendynamik Tabelle 1 M gliche Bewertungsverfahren f r ein Softwaretechnik Projekt Alle aufgef hrten Bewertungsans tze sind im Kon text eines Softwareprojekts sicherlich sinnvoll an A Spillner H Lichter Hrsg SEUH 13 wendbar Wie beispielsweise von Hayes et al 2007 vorgeschlagen erscheint in der Praxis aber 107 eine Kombination verschiedener Verfahren erfor derlich um alle zuvor genannten Anforderungen an die Benotung abdecken zu k nnen und dabei m glichst wenig Mehraufwand f r Studierende und Betreuer zu generieren So eignet sich bei sp
239. hen wird if Greenfoot mouseClicked null Die vorherige Fallunterscheidung dient z B dazu festzustellen ob die Maus zum Klicken genutzt wurde Um dann das geklickte Objekt zu finden muss ein Cast Operator und ein Klassen Objekt genutzt werden wie das folgende Code Fragment zeigt Balloon balloon Balloon getOneObjectAtOffset x y Balloon class Verwandt mit Greenfoot sind einige andere Ansat ze wie das Hamster Modell Bol08 Kara Kara Karol Karo oder Scratch Scr mit denen eige ne Umgebungen typischerweise in Java geschaf fen werden um Schiiler an die ersten Schritte des Programmierens also die systematische Hinter einanderausf hrung von Befehlen heranzuf hren Dieser Ansatz mag zu schnellen Erfolgen bei den A Spillner H Lichter Hrsg SEUH 13 Lernenden f hren was die Motivation hochhalten kann ob der bergang dadurch in reale Program miersprachen einfacher oder durch ein dann fun diertes zu einfaches mentales Entwicklungsmodell erschwert wird ist bisher in Studien nicht ernsthaft untersucht worden Interaktionsbrett Die Motivation von Lernenden mit graphischen M glichkeiten hochzuhalten ist in vielen Ans tzen vertreten Aus diesem Grund wurde f r die hier betrachteten Java Veranstaltungen in Osnabr ck motiviert von der kritischen Analyse von Greenfoot eine eigene Klasse Interaktionsbrett zur Visualisie rung erstellt Int Die zentrale Idee ist es konsequent obje
240. hiedenen verwendeten Ope ratoren und Operanden in Betracht Somit kann nicht nur der Umfang des Programms Summe der Anzahl der Operanden und Operatoren sondern auch der Umfang des verwendeten sogenannten Vokabulars Anzahl unterschiedlicher Operanden und Operato ren bestimmt werden Beide Werte k nnen verschie den miteinander in Beziehung gesetzt werden Bei der Analyse von Programmieraufgaben mit die ser Metrik ergibt sich das Problem dass der Umfang des Vokabulars durch die Codevorlage nach unten begrenzt ist auch wenn die Studierenden selber in ihrem Code ein kleineres Vokabular verwenden Bei der Berechnung der Metrik m sste daher sorgf ltig zwischen dem vorgegebenen Code und dem von Stu dierenden erstellten Code getrennt werden was je nach Komplexit t der Codevorlage nicht immer sau ber m glich ist Zudem ist nicht offensichtlich ob der Umfang des Vokabulars in direkten Bezug zu einem m glichen Lernziel gesetzt werden kann Bestenfalls kann noch angenommen werden dass den Studieren den mit fortschreitenden Programmierkenntnissen ein gr eres Vokabular bekannt ist dass bei schwierigen Aufgaben dann auch zum Einsatz kommt Da Aufga ben jedoch oft auch auf ein begrenztes Thema z B Implementierung von Vererbungsstrukturen abzielen kann nicht einmal vorausgesetzt werden dass fort geschrittene Aufgaben tats chlich ein umfangreiches Vokabular erfordern A Spillner H Lichter Hrsg SEUH 13 Zyklomatische Ko
241. hrung mit Ruby sinnvoll f r Erstsemester sein k nnte C Die Programmiersprache C ist in aktuellen Unter suchungen weiterhin eine der zentralen Sprachen bei der Software Entwicklung in Unternehmen Da die Sprache sehr hardware nah ist und gerade der Markt der embedded Systeme kontinuierlich vom Auto bis zum K hlschrank w chst wird die Spra che weiterhin mittelfristig ihre Bedeutung behalten C wurde 2006 in der Programmierausbildung f r Erstsemester in einer Veranstaltung mit f nf Leis tungspunkten an der Fachhochschule Wiesbaden jetzt Hochschule RheinMain genutzt Die Rah menbedingungen waren eine zu dem Zeitpunkt leicht sinkende Anzahl von Erstsemestern wobei es in dieser Veranstaltung eine besonders hohe An zahl von Wiederholern gab C wird als gute Spra che zum Lernen der Programmierung von Bef r wortern angesehen da sie praxisnah ist und mit sehr wenigen Schl sselw rtern auskommt was zur Annahme f hrt dass die Sprache leicht zu erlernen sei In der Durchf hrung zeigte sich deutlich dass die notwendige Zeigerprogrammierung allein schon beim Umgang mit Strings also char Arrays mit besonderem Terminierungssymbol und anderen Arrays ohne M glichkeit deren L nge implizit zu A Spillner H Lichter Hrsg SEUH 13 bestimmen ein gro es Problem darstellt Ein Ver heddern in der Zeigerwelt bei einfach und doppelt verketteten Listen ist f r Anf nger oft unausweich lich Gegen ber Java hat C allerdings
242. hselnden Disziplinen mit Erfolg eingesetzt Bai ley et al 2005 Henderson et al 2006 Nowak et A Spillner H Lichter Hrsg SEUH 13 al 1998 1999 Simkins 2010 Allerdings finden sich die dort ver ffentlichten Eins tze in den Dis ziplinen Physik Biologie und Chemie Im Bereich der Informatik findet sich nur ein Erfahrungsbe richt f r die Grundlagenausbildung Bailey et al 2005 und einer f r Theoretische Informatik Flei scher 2004 jedoch nicht f r Vorlesungen im Be reich Software Engineering Das Just in Time Teaching wird in Prince et al 2007 zu den induk tiven Lehr und Lernmethoden gez hlt Durch die Veranstaltung Forum der Lehre 2012 inspiriert bei dem das Just in Time Teaching JiTT vorgestellt wurde Riegler 2012 haben wir uns vorgenommen diese aktivierende Lehrmetho de auch in unseren Software Engineering Veran staltungen zu erproben Nach einer Einf hrung in die aktivierende Leh re und das Just in Time Teaching allgemein be schreiben wir unsere ersten Erfahrungen mit dieser aktivierenden Lehrmethode Da wir in unseren ersten Versuchen mit dem erhaltenden Feedback noch nicht zufrieden waren erweiterten wir die Methode um einen weiteren Feedback Zyklus Wir beschreiben unsere Erfahrungen mit dem von uns erweiterten Just in Time Teaching durchgef hrt in einer gesamten Lehrveranstaltung Abschlie end wird die andere Herangehensweise an die Vorbe reitung der Veranstaltungen aufg
243. ich mal drei vier f nf Leute dabei sind Wo man sich untereinander ab stimmen muss Wo die Aufgaben auch so abge grenzt sind dass man notgedrungen Schnittstellen zu anderen hat Ein weiterer Befragter w rde es auch gut finden wenn den Studierenden auch Pro jektverantwortung f r ein Studienprojekt berge ben w rde 10 Fazit und Ausblick Insgesamt l sst sich festhalten dass ein Software Ingenieur eine Vielzahl fachlicher und berfachli cher Kompetenzen ben tigt Nun stellt sich die Frage wie man diese ben tigten Kompetenzen in der Hochschulausbildung am besten f rdern kann Auf diesem Weg ist die Beschreibung der Soll Kompetenzen mittels eines Schemas das diese zu verschiedenen Zeitpunkten vergleichbar macht nur ein erster Schritt Die Analyse und Beschreibung der Soll Kompetenzen f r Software Engineering muss noch ausgebaut werden Dies ist f r sowohl f r Kernin formatik als auch f r alle anderen beteiligten Berei che wie Mechatronik oder Studieng nge mit nicht prim rem Informatikbezug notwendig Um die Tragf higkeit der erhobenen Kompetenzprofile weiter zu erh hen werden auch die Ergebnisse anderen beteiligten Verbundhochschulen ber ck sichtigt Neben der Ausweitung der Datenbasis ist es zudem notwendig weitere Blickwinkel neben der unternehmerischen Sicht einzubinden Sinnvoll ist es beispielsweise auch Absolventen Studieren de oder Personalverantwortliche mit einzubezie hen Auch kann es sinnv
244. ichen Ablaufstrukturen werden dann sp ter in den Me thoden eingef hrt Man erh lt so einen recht lan gen Anteil an Vorlesungen die sich ausschlie lich mit Objekten Methoden und sequentiellen Pro grammabl ufen besch ftigen wozu man bemer kenswert viele Beispiele konstruieren kann Dies ist auch ein gutes Beispiel wie man Vorlesungen ver langsamen kann da eine aus C bekannte Anwei sung x xtl f r einen Informatiker intuitiv erscheint f r je mand der noch nicht programmiert hat aber nach A Spillner H Lichter Hrsg SEUH 13 einer nicht erf llbaren Formel aussieht hnliches gilt f r die Frage warum man nicht x 1 x schrei ben darf obwohl wenig sp ter x y l und y 1 x semantisch quivalent sind Dieser konsequente Weg des Starts ausschlie lich mit Objekten wurde an der Hochschule Osnabr ck in zwei einf hrenden Lehrveranstaltungen des Bachelor Studiengangs Informatik Medienin formatik genutzt Der Ansatz wurde im Rahmen einer Reakkreditierung in sehr kontroversen Dis kussionen 2010 ausgew hlt in dem nach einer Ein f hrung in Java in einer Zweitsemesterveranstal tung C und C gelehrt werden Urspr nglich wurde nach einer Einf hrung in C im zweiten Se mester C mit all seinen sprachlichen Besonder heiten auch in Veranstaltungen zu jeweils zehn Leistungspunkten gelehrt Die Java Einf hrung war ein kleiner Block im Rahmen einer Usability Veranstaltung Die Rahmenbedingungen
245. ie Phasen Analyse Development und Review wurden noch weiter unterteilt in die Zust nde In Progress sowie Done Die Arbeitslimits wurden in einer separaten Zeile je Phase dargestellt Ab der zweiten Praktikumswoche wurde ein Zeitraffervideo des Kanban Boards erstellt In diesem sieht man wie einzelne Tickets von links nach rechts durch die ein zelnen Phasen des Prozesses wandern Wie erw hnt unterteilt das Team die anf nglichen Tickets des Kunden die User Stories in kleinere Tasks die von den Studenten jeweils in einem Paar in einer kurzen Zeit bearbeitet werden k nnen In der Ent wicklungsphase wandern daher die Task Karten f r ein Ticket von links nach rechts Ein Ticket ist dann fertig implementiert wenn alle Tasks des Tickets fer tig implementiert wurden Da es aber Tickets geben kann mit wenigen oder auch welche mit vielen Tasks gibt es f r diese Tasks keine Beschr nkung hinsichtlich maximal erlaubter Anzahl an Tasks die zeitgleich be arbeitet werden d rfen Hingegen wurde die Anzahl an Tickets also der User Stories zu den Tasks in der Development Phase beschr nkt W hrend des Praktikums wurde der aktuelle Zu stand zu festen Zeiten von allen Tickets auf dem Kanban Board gemessen und festgehalten Aus die sen Daten wurde anschlie end ein Cumulative Flow Diagramm Anderson 2010 siehe Abbildung 3 ge neriert In dem Diagramm wird ber die Zeit auf getragen wieviele Tickets sich zu einem Zeit
246. iel Wir setzen Blue in SE1 durchg ngig in der Vorle sung und in den bungen ein f r SE2 wechseln wir jedoch in den bungen auf Eclipse als Entwick lungsumgebung Aber auch in SE2 kann Blue bei der Visualisierung objektorientierter Entw rfe eine gute Hilfe sein und wird deshalb punktuell auch in der Vorlesung eingesetzt 3 2 bungen Heimarbeit versus Pr senz bungen sind gerade bei Programmierveranstal tungen wie das Salz in der Suppe letztere w ren ohne erstere fade und langweilig und somit letzt lich nicht effektiv Entsprechend gibt es vermutlich nur sehr wenige Module die ausschlie lich mit Vorlesungen versuchen den Teilnehmern das Pro grammieren beizubringen Allerdings gibt es auch 3 Vom gleichen Entwicklerteam wurde daher Greenfoot entwi ckelt ebenfalls eine Java IDE die diesen Aspekt deutlich besser adressiert aber eher auf die Schulinformatik zielt 41 bei der Gestaltung von Programmier bungen un terschiedliche M glichkeiten der Umsetzung Ein Ansatz Jede Woche gibt es ein Aufgabenblatt das eigenst ndig bearbeitet werden soll dieses Blatt wird in der Ausgabewoche in einem bungstermin vorab besprochen um Fragen zu kl ren und even tuell auch Hinweise auf L sungsm glichkeiten zu geben in der Folgewoche m ssen die Studierenden ihre Bearbeitungen des Aufgabenblattes bei ihrem Tutor abgeben der blicherweise eine weitere Wo che braucht um diese Bearbeitungen zu korrigie ren Di
247. ielsweise die Bewertung der abgegebenen Sys temartefakte allein sehr gut als Feedback ber die im Projekt erbrachte Leistung st t aber an Gren zen sobald diese in Heimarbeit erstellt werden k nnen und sollte daher durch Pr senzverfahren wie Kolloquien o erg nzt werden Bewertungs ans tze mit hoher Eigenverantwortung wie Reflek tionen oder Lerntageb cher erzielen bei entspre chend motivierten Studierenden meist gute Ergeb nisse sind jedoch in einem ohnehin stressigen Pro jekt offensichtlich mit zus tzlichem Mehraufwand verbunden und ferner in Zweifelsf llen nur schwer als nicht ausreichend zu benoten Sie erfordern daher wie die meisten anderen Verfahren ein kla res und idealerweise im Voraus kommuniziertes Bewertungsschema was den Aufwand f r die Be treuenden weiter erh ht insbesondere wenn die Zusammenstellung der Inhalte individuell gestalt bar ist Bewertungsschema Aus den zuvor angestellten berlegungen l sst sich das folgende Bewertungsschema ableiten das sich im Wesentlichen aus f nf einzelnen Bewertungs verfahren zusammensetzt 1 Einfache bungsaufgaben mit direktem Pro jektbezug 2 Ein praktisches Programmiertestat gegen vorgegebene Testf lle am Rechner 3 F hren von Stundenzetteln Timesheets 4 Bewertung der abgegebenen Modellierungs artefakte Quellcodes und Binaries 5 Mehrere Kolloquien Der zeitliche Ablauf einer entsprechenden organi sierten Veranstaltung gestaltet
248. ielte Ver ndern von Einflussvariablen auf den Lernpro zess und die Kompetenzanalysen zu verschiedenen Zeitpunkten Sedelmaier und Landes 2012 beschreiben das Forschungsdesign genauer vgl Abb 4 Structural items Structural items Structural items amp process amp process amp process variables at t variables at t variables at tz Constraints for Constraints for Constraints for Course 1 Course 1 Course 2 att att att Evaluation 4 Evaluation 4 Evaluation 4 Comparison As is As is As is competencies competencies lt competencies at ty Comparison att Comparison at t en ge et To be a Comparison competencies u Time t gt Abb 4 berblick ber das Forschungsdesign 6 2 Erfassen von Einflussvariablen Um die Einflussfaktoren auf Lehr Lern Prozesse systematisch erfassen zu k nnen wurden diese zun chst in Struktur Prozess und Ergebnisvariab len Donabedian 1980 unterteilt Ergebnisvariablen werden mittels der Kompetenzprofile beschrieben Strukturvariablen setzen sich aus den didaktischen Aspekten zusammen die strukturelle Rahmenbe dingungen auf den Lernprozess darstellen wie z B Motivationen Einstellungen didaktische Kenntnis se der Lehrenden R umlichkeiten Prozessvariab len beeinflussen den tats chlichen Lernprozess wie etwa Medien Lehr und Lernmethoden 6 3 Kompetenzanalyse Um Kompetenzen zu verschiedenen Zeitpunkten erfassen und dokumentieren und Vergleic
249. ieng ngen liegt das Verh ltnis von Programmieranf ngern zu Teilnehmern mit Vorer fahrung seit Jahren bei ca 30 702 Wir versuchen diese ungleichen Voraussetzungen mit Zusatzaufga ben zu kompensieren die nicht Teil der Schein bedingungen sind aber interessantere und an Zwischenzeitlich lag es durch die Einf hrung neuer Studien g nge mit teilweise hohem interdisziplin rem Anteil bei 50 50 hat sich aber zuletzt wieder auf den oben genannten Wert ein gependelt A Spillner H Lichter Hrsg SEUH 13 spruchsvollere Inhalte thematisieren Diese M g lichkeit wird dabei nicht nur von Studierenden mit Vorerfahrung genutzt sondern durchaus auch von motivierten Programmieranf ngern Eine weitere M glichkeit die ungleichen Vor kenntnisse von einem Nachteil in einen Vorteil umzuwandeln indem unterschiedlich starke Stu dierende zusammen arbeiten diskutieren wir in Abschnitt 3 2 2 2 Programmiersprache und Programmierung Im Weiteren gehen wir von einer Umgebung mit einem imperativen Einstieg aus dieser wird heut zutage oft mit der Programmiersprache Java Gosling et al 2005 vorgenommen Als n chstes ebenfalls modul bergreifend kann die Frage nach der inhaltlichen Abstimmung zwischen den Pro grammiermodulen gestellt werden Ein Ansatz Im ersten Semester wird eine Kom plett bersicht ber Java gegeben quasi ein Java Crash Kurs Im zweiten Semester folgt ein Modul das klassische Algorithmen und Daten
250. ierende nachvollziehbar sein und sollte unabh ngig von der Person des Bewerters bzw des Bewerteten zum gleichen Ergebnis kommen Auf Grund des relativ gro en Aufwands den Studierende in entsprechende Veranstaltungen investie ren werden idealerweise auch die erstell ten Artefakte ggf in mehreren Teilschrit ten benotet generell erfasst das Bewer tungsschema die in den Lernzielen formu lierten Fertigkeiten 2 Gem der Bologna Kriterien KMK 2010 muss die Benotung f r jeden Studierenden individuell erfolgen es kann daher bei Teamarbeiten nicht automatisch eine ein heitliche Note f r alle Teammitglieder ver geben werden Ein geeignetes Bewertungs verfahren muss die Zuordnung individuel ler Leistungen erlauben dabei aber gleich zeitig Teamarbeit zulassen und f rdern bzw im Idealfall sogar in der Note abbil den Dabei sollte auf Grund entsprechen der Erfahrungen die M glichkeit bestehen Trittbrettfahrer fr hzeitig zu erkennen um die brigen Mitglieder eines Teams vor einer berlastung und deren negativen Folgen f r die eigenen Noten zu sch tzen Softwaretechnik Hintergr nde Zum besseren Verst ndnis des sp ter erkl rten Bewertungsschemas sollen im Folgenden in aller K rze einige Aspekte der Softwaretechnik und daraus abgeleitete Lernziele hervorgehoben wer den Ein zentraler Punkt ist dabei die Definition einer Software selbst Laut Brooks 1995 umfasst Software nicht nur den ablauff
251. iew Nachdem aber auch der Review prio risiert werden sollte wurde eher der Review gemacht bevor ein neues Ticket in die Analyse Phase gezogen wurde Es stellte sich auch heraus dass ein Ticket in der Analyse Phase nicht von mehreren Paaren effektiv be arbeitet werden konnte Daraus resultierte ein Stocken des Entwicklungsprozesses in dem keine Tickets in der Analyse oder fertig f r die Development Phase waren Als L sungsm glichkeiten h tten wir die Ar beitslimits in der Development Phase anpassen k n nen um ein Entwicklerpaar frei zu haben f r Analyse oder Review Wir passten aber unsere ungl cklich ge w hlte Priorisierung an indem wir die Priorisierung Analyse gt Review gt Development vorschlugen Dies stellte sich im Laufe des Praktikums als sinnvolle Ent scheidung heraus da es den Engpass entlastete und die Studenten in der Development Phase Tickets zum Bearbeiten hatten Ein weiterer Engpass in dem Prozess war die Rolle des Kunden Dieser wurde in der Analyse Phase zur Akzeptierung der genaueren Anforderungen und in dem finalen Schritt der Review Phase ben tigt Da es nur einen Kunden gab war dieser eine begrenzte Ressource Ebenso war es aber weder sinnvoll die An zahl an Kunden zu erh hen noch die Einbindung des Kunden in beide Schritte zu vermeiden daher wurde versucht durch den Teamleiter in beiden Schritten einen vorgelagerten Kundenrepr sentanten zu spie len Dies bewirkte dass viele Fragen der St
252. ig von der Pr senzzeit berechnet wird Empirische Studien zu den neu konzipierten Studieng ngen zeigen inzwischen dass Selbststudium allerdings nur dann funktioniert wenn es in ein didaktisches Gesamtkonzept eingebunden und in den Pr senzveranstaltungen wieder aufgenommen wird Metzger 2011 271 f An dieser Stelle setzt JiTT an indem es die Ergebnisse des Selbststudiums zum Ausgangspunkt der Pr senzlehre macht M glich ist es dabei auch das Selbststudium durch die Einbindung in das Pr fungskonzept einer Veranstaltung zus tzlich anzureizen So kann durch JiTT der Forderung nach formati vem d h das Lernen begleitendem Pr fen nach gekommen werden Dubs 2006 2 f Die Bearbei tung der Aufgaben kann anteilig auf die Note an gerechnet werden oder bei Bestehen der Ab schlusspr fung wird ein Bonus f r die Aufgaben bearbeitung gew hrt der die Abschlussnote ver bessert H ufig wird es in diesem Fall von den Lehrenden als ausreichend betrachtet wenn die Aufgaben berhaupt bearbeitet werden unab h ngig davon ob die L sungen richtig sind Luo 2008 167 Slunt Giancarlo 2004 986 Verbreitung und Wirksamkeit von JiTT Just in Time Teaching wurde von Physik Lehrenden der Indiana University Purdue Uni versity at Indianapolis IUPUI der United States Air Force Academy USAFA und des Davidson College entwickelt Novak u a 1999 7 Inzwi schen hat es sich sowohl ber fachliche als auch ber geogr
253. igieren zur Testsuite und das Herausfinden was genau getestet wird wie gro und komplex die C Standardbibliothek ist Die im Durchschnitt zur Beantwortung der Fragen ben tigte Zeit betrug bei diesem Quiz 16 Minuten und 20 Sekunden Der Aufwand zur Vorbereitung kann vom System nicht erfasst wer den wir sch tzen jedoch dass er unter 30 Minu ten lag Am Tag vor der Vorlesung ist das Quiz been det und die Antworten m ssen ausgewertet wer den Durch die Auswahlfrage erh lt man schnell einen berblick wie viele Studierende den neuen Testfall aufnehmen wollen und wie viele nicht In diesem Fall war das Ergebnis unentschieden Zur Auswertung der Begr ndung in der Freitextfrage muss jede Antwort einzeln betrachtet werden Da die Antworten in der Regel recht kurz ausfallen werden hierf r circa ein bis zwei Minuten pro Antwort ben tigt Die meisten Begr ndungen den Testfall aufzunehmen lassen sich in eine Ka tegorie der Testfall testet etwas das bisher noch nicht getestet wurde einteilen und die meisten Begr ndungen ihn abzulehnen in eine Kategorie der Testfall erh ht die Testabdeckung nicht Einige Antworten fallen in die Kategorien jeder A Spillner H Lichter Hrsg SEUH 13 neue Testfall ist gut und der Test wird immer fehlschlagen Bei der Kategorisierung der Ant worten werden auch drei besonders gute oder interessante Antworten ausgew hlt und zusam men mit dem Ergebnis der Auswertung in d
254. im berichtet Einleitung Teambasierte Softwareentwicklungsprojekte sind seit Jahren ein fester Bestandteil des Curriculums von Informatikstudieng ngen an vielen Hoch schulen Der vorliegende Beitrag zielt prim r auf praktische Entwicklungsprojekte im Fach Software technik bzw engl Software Engineering an Hoch schulen und Universit ten kann aber mit entspre chenden Abwandlungen auch f r andere Fachge biete der Informatik von Nutzen sein Aus techni scher Sicht geht es in entsprechenden Lehrveran staltungen haupts chlich um das Erlernen von strukturierten Entwurfs und Modellierungstechni ken f r Software sowie deren Umsetzung in lauff hige und getestete Programme Dazu notwendig ist das Erlernen grundlegender Techniken Methoden und Werkzeuge zur Entwicklung komplexer Soft waresystemen vgl ACM 2004 oder Ludewig 1999 so dass Studierende wichtige Kompetenzen zur konstruktiven Mitarbeit in entsprechenden Industrieprojekten erwerben k nnen Anders aus A Spillner H Lichter Hrsg SEUH 13 gedr ckt sollen Absolventen m glichst direkt in der Industrie beschaftigungsfahig sein vgl KMK 2010 oder auch Coldewey 2009 Prim res Lernziel der in diesem Artikel diskutierten Veran staltungen an der Universit t Mannheim war die Vermittlung eines strukturierten und artefakt getriebenen ingenieurm igen Vorgehens in der Softwareentwicklung und die Ein bung dazu erforderlicher Modellierungs und
255. interessant weil damit konsequent die Schnittstelle zwischen Klient und Dienstleister und das Abstrahieren von Details eines Dienstleisters thematisiert werden kann Vertiefte Kenntnisse in funktionaler oder logischer Programmierung hin gen sind als Erg nzung zwar begr enswert er scheinen jedoch im Notfall am ehesten entbehrlich insbesondere falls Programmiermodule im Curri culum eine knappe Ressource sind Ein Ansatz Es erfolgt ein Einstieg in die funktiona le Programmierung im ersten Semester auf den im zweiten oder dritten Semester Veranstaltungen zur imperativen Programmierung folgen Dies ist ein h ufig praktiziertes Muster an deut schen Hochschulen vor allem an Universit ten A Spillner H Lichter Hrsg SEUH 13 Ein oft genanntes Argument f r diesen deklarativ orientierten Einstieg ist dass alle Studierenden dann vom Kenntnisstand gleich seien da nur die wenigsten Vorerfahrung mit deklarativen Pro grammierstilen mitbringen Dieser Vorteil relati viert sich dann allerdings sp testens beim Einstieg in die imperative Programmierung An der Uni Hamburg wurde bis zum Jahr 2005 innerhalb des ersten Semesters sowohl die funktio nale als auch die logische Programmierung gelehrt im zweiten Semester folgten imperative und ob jektorientierte Grundlagen Eine weitere Veranstal tung im dritten Semester erg nzte Konzepte zu Algorithmen und Datenstrukturen Alternative Imperative Grundlagen werden ein f
256. inzelne Be standteile der Umgebung wieder zu verwenden So k nnen Spiele mit einem anderen Spielfluss oder anderen Benutzeroberfl chen die gleiche Si mulationskomponente nutzen Aktuelle Entwicklungen im Bereich der Web technologien HTML5 CSS3 WebSocket Server Sent Events etc erm glichen attraktive Spielerfahrun gen im Webbrowser ganz ohne die Nutzung pro priet rer Erweiterungen Die Nutzung des Web browsers in welchem sich heutige Studierende daheim f hlen vereinfacht gleichzeitig die nahtlo se Integration von webbasierten Werkzeugen aus der echten Softwareentwicklung und die Einbin dung von Prozessbeschreibungen welche ber das EPF ver ffentlicht wurden 138 Fazit und Ausblick Simulation und Digital Game Based Learning DGBL k nnen bei geeigneter Implementierung den Aufbau einer effizienten konstruktivistischen Lernumgebung unterst tzen Bestehende L sungen f r die Anwendung von Simulation und Digital Game Based Learning in der SE Ausbildung haben Pionierarbeit geleistet und zeigen ermutigende Ergebnisse Sie sch pfen das vorhandene Potential jedoch nicht aus Anfor derungen an die Gestaltung einer konstruktivisti schen Lernumgebung sind in Teilen nicht erf llt Dies betrifft insbesondere die Unterst tzung sozia ler Interaktion fr he Anreize f r Artikulation und Reflexion und die Bereitstellung multipler Perspek tiven auf den jeweiligen Softwareprozess als Lern gegenstand Im Forschungsp
257. issen eine zentrale Herausforderung darstellt die offensicht lich f r viele Absolventen nicht leicht zu meistern ist und auch die Unternehmen vor einige Probleme stellt Umgekehrt ist es f r die Hochschulausbil dung schwierig den komplexen Praxisalltag in der Ausbildung abzubilden so dass die zitierten Aha Erlebnisse f r die Studierenden erfahrbar werden Eine weitere wichtige berfachliche Kompe tenz die von fast allen Befragten genannt wurde ist das Verstehen komplexer Prozesse F r das Ein finden und angemessene Bewegen in diesen kom plexen Abl ufen die dem Software Engineering inh rent sind ist es absolut notwendig dass ein Software Ingenieur diese berblickt und versteht Dies schlie t auch einen Weitblick ber seinen eigenen Tellerrand hinaus mit ein Ein Befragter beschreibt dies so Aber das Prinzip muss er be greifen wie spielt das alles zusammen Ein dritter sehr wichtiger Komplex auf den sich berfachliche Kompetenzen beziehen ist der Bereich der Zusammenarbeit Einer der Befragten bezeichnet das sehr treffend als Teamwork Alltag Ein anderer Befragter gibt hier einen Ein blick in den Arbeitsablauf Dieser kommunikative Austausch ber Themen nicht nur im Daily Scrum mal ein paar Minuten sondern eigentlich fachlich und konkret den ganzen Tag ber im Pairing in immer wiederkehrenden Beratungssituationen Wir haben auch die Teams grunds tzlich immer zu sammensitzen in R umen oder an Tischin
258. ist aus Sicht von Anf ngern nicht sehr intuitiv und f hrt zu Proble men Kritisch aus Anf ngersicht ist auch dass f r die Ausgabe eine Klassenmethode genutzt werden muss A Spillner H Lichter Hrsg SEUH 13 Insgesamt war die Vorlesung erfolgreich da durch eine schnell angebotene Nachpr fungsm glichkeit alle Studierenden letztendlich die Veranstaltung bestanden Weiterhin war der Einstieg in die Ob jektorientierung erfolgreich so dass der bergang zu Java keine besondere Herausforderung darstell te Zusammenfassend kann man den Ansatz Small talk als Anf ngersprache zu nutzen als klaren Er folg ansehen der allerdings ma geblich durch die sehr guten Randbedingungen unterst tzt wird Die M glichkeit mit Smalltalk gerade an anderen Fachhochschulen anzufangen sch tzt der Autor als sehr gering an da neben der mangelnden Akzep tanz unter den Kollegen gerade auch Studierende fr hzeitig praxisrelevante Lehrstoffe vermittelt bekommen wollen Dies ist besonders zu beachten da viele Studierende ihr Studium nebenbei finan zieren m ssen und der fr he Einstieg in einfache Programmierjobs in Unternehmen f r Studierende und Unternehmen sehr vielversprechend sein kann Die Programmiersprache Ruby Fla08 hat viele der zentralen Ideen bernommen und eignet sich sehr gut zur schnellen Prototyp Entwicklung f r Web Systeme mit Ruby on Rails RTH11 Es w re des halb eine berlegung wert ob eine Programmie reinf
259. it in einem E Learning System teil automatisiert zur Bearbeitung vorzuschlagen Im einfachsten Fall k nnten Studierende dabei ein System explizit nach leichteren oder schwierigeren Aufgaben fragen Daraus ergibt sich auch ein unmit telbarer Forschungsansatz indem die Studierenden anschlie end um eine subjektive Einsch tzung der Schwierigkeit gebeten werden Kennzahlen Ergebnis sen und subjektive Bewertungen k nnen dann zur weiteren Validierung der Erkenntnisse dieses Artikels miteinander verglichen werden Auch die oben dis kutierten weiteren Einflussfaktoren sollten in diesen Betrachtungen Ber cksichtigung finden Ferner kann untersucht werden ob aus der Position einer einzelnen L sung in Relation zum Verteilungs diagramm der jeweiligen Aufgabe weitere Erkenntnis se beispielsweise zur Generierung individueller R ck meldungen an die Studierenden gewonnen werden k nnen ber den Einsatz von Softwareproduktme triken hinaus k nnen dabei auch weitere Metriken zum Entwicklungsprozess der L sung zum Einsatz kommen mit denen beispielsweise eine Folge von mehreren Einreichungen mit inkrementellen Verbesse rungen der L sung untersucht wird Dies w rde auch die Bereiche der Analyse abdecken die in diesem Ar tikel nicht besprochen wurden Danksagung Die Autoren danken Alexander Jung f r seine umfangreiche Recherche zu Softwarepro duktmetriken im Rahmen seiner Bachelor Arbeit Literatur e Abreu u Carapuca 1994 ABRE
260. it wird Beschwerden dass Programmieren in Papierklausuren weitaus schwieriger als in einer Entwicklungsumgebung mit Code Completion sei von vorne herein der Wind aus den Segeln genommen Gleichzeitig entf llt das u erst zeit aufw ndige Bewerten von zumeist un bersichtli chem Programmcode f r die Betreuer da nur das automatisierbare Ausf hren der JUnit Tests not wendig wird Idealerweise werden mehrere in etwa gleichschwere Teilaufgaben gestellt so dass die Programme der Studierenden nicht alle Testf lle erf llen m ssen sondern beispielsweise nur drei aus f nf o Auf Grund von in Praxis und Litera tur bekannten extremen Leistungsunterschieden bei Softwareentwicklern vgl Endres amp Rombach 2003 sollte den Studierenden ausreichend Zeit zum L sen dieser Aufgaben gegeben werden In der Mannheimer Praxis hat sich etwa die zehnfache Zeit die wissenschaftliche Mitarbeiter zum Proberechnen ben tigen bew hrt z B ca 18 zu 180 Minuten Die Ergebnisse dieses Testats k nnen im Anschluss zur Einteilung der eigentlichen Projektgruppen genutzt werden Es bietet sich an die Studierenden gem ihrer Leistungen also z B der Zeit die bis zur Erf llung der Testkriterien ben tigt wurde zusammen zu gruppieren um zu gro e Leistungs gef lle innerhalb der Teams und eine daraus resul tierende Demotivation aller Teilnehmer zu vermei den vgl z B Stangl 2002 Gruppen mit einer gro en Leistun
261. ition UK Pearson Education Beck K and C Andres 2004 Extreme Programming Explained Embrace Change 2nd Ed Addison Wesley Bell D and M Parr 2003 Java f r Studenten Grundlagen der Programmierung Prentice Hall BlueJ BlueJ The Interactive Java Environment http www bluej org Gamma E et al 1995 Design Patterns Elements of Reusable Object Oriented Software Reading MA Addison Wesley GI 2000 Standards zur Akkreditierung von Studieng ngen der Informatik und interdiszipli n ren Informatik Studieng ngen an deutschen Hochschulen Gesellschaft f r Informatik e V GI 2005 Bachelor und Masterprogramme im Studienfach Informatik an Hochschulen Neuauflage der Gl Standards zur Akkredi tierung von Informatik Studieng ngen aus dem Jahr 2000 Gesellschaft f r Informatik e V Gosling J et al 2005 The Java Language Specification 3rd Ed Addison Wesley Longman Amsterdam Addison Wesley Koenig A and B Moo 2000 Rethinking How to Teach C Part 1 Goals and Principles Journal of Object oriented Programming 13 7 S 44 47 Kolling M et al 2003 The Blue system and its pedagogy Journal of Computer Science Education Special issue on Learning and Teaching Object Technology 13 4 S 249 268 Ludewig J 2010 Software Ingenieur werden Informatik Spektrum 33 3 S 288 291 McDowell C et al 2006 Pair programming improves student retention confidence and
262. ive Feedback sein Einige der ehemaligen Teilnehmer durfte und darf der Autor weiter begleiten Ein paar Details werden dazu im n chsten Abschnitt vorgestellt Ehemalige Projektteilnehmer Immer wieder haben Studierende aus den Projek ten die M glichkeit in der Firma des Autors oder bei ihren Kunden Praktika abzuleisten ihre Ab schlussarbeiten anzufertigen oder als Angestellte in herausfordernden Kundenprojekten zu arbeiten In der Zusammenarbeit zeigt sich das erlernte Ver st ndnis f r die in der Entwicklung zu erstellenden Arbeitsprodukte Ein Beispiel ist die Entwicklung von kleinen Werkzeugen Zun chst wird am Ver st ndnis der Anforderungen gearbeitet danach werden grunds tzliche Design berlegungen ge macht Erst dann wird mit der Umsetzung begon nen Auch an einer anderen Stelle zeigt sich eine struk turierte Vorgehensweise An vielen Stellen m ssen Entscheidungen getroffen werden Dies kann die Auswahl eines Werkzeuges oder eines Frameworks sein oder auch Designentscheidungen bei der Er stellung von Software Alternativen werden bewer tet und die Entscheidung wird dokumentiert sie entsteht nicht einfach so und ist nachvollziehbar 33 Eine weitere Beobachtung hat der Autor gemacht Auch wenn die Mitarbeiter sehr selbstst ndig ar beiten bitten sie an wichtigen Stellen in den Projek ten von sich aus um Reviews damit sie eine h here Sicherheit erhalten sich auf dem richtigen Weg zu befinden I
263. kam immer seltener nichts je weiter die Lehrveranstaltung fortschritt Die Fragen der Studierenden waren oft sehr detailliert so dass wir erkannten dass sich die Studierenden mit dem Stoff intensiv auseinander gesetzt haben Beim Kapitel ber die Abgrenzung des zu erstellenden Systems kamen z B folgende Fragen 20 e Ich verstehe nicht wie tief man den System kontext spezifizieren muss Was geh rt alles dazu Darauf konnte in der folgenden Lehrveranstaltung eingegangen werden Die dritte Frage ber die Ankn pfungspunkte zeigte ob die Studierenden die Sachverhalte des Textes in ihr bisheriges Studi um oder bisherige Erfahrungen einordnen konn ten Damit hingen die gelernten Themen nicht ein fach in der Luft sondern wurden mit schon Gelern tem verkn pft Zu den jedes Mal vorhandenen oben vorge stellten allgemeinen Fragen kamen spezielle Fra gen in der Lehr und Lernplattform Moodle hinzu die einfache Sachverhalte abfragten um zu erken nen ob die Studierenden den Text berhaupt durchgearbeitet haben Au erdem sollte das Gele sene an Hand eines Beispiels angewendet werden Wir verwendeten ein fiktives Projekt Bewerber managementportal f r Hochschulen f r das Ma nagement von Bewerbern die bei der Hochschule arbeiten wollen Berufungsverfahren f r Professo ren Einstellung von Labor und wissenschaftlichen Mitarbeitern Mitarbeitern in der Verwaltung und Hiwis Bei der Beantwortung der Frag
264. keit von Quellcode wird auf konkrete und projektindividuelle Eigenschaften 142 heruntergebrochen Diese hei en Qualit tsfaktoren des Qualit tsaspektes Ziel ist es f r jeden konkreten Aspekt des Qualit tsaspekts einen beeinflussenden Faktor zu finden sogenannte Einflussfaktoren Beide gefundenen Faktoren sind ber eine Einflusshypothese zu verbinden Nun ergibt sich eine das Messziel cha rakterisierende Frage Question als Zustandsabfrage von Qualit tsfaktoren Die aufgestellte Einflusshypothese wird in Schritt 4 und 5 berpr ft Dabei wird eine Metrik zur Zu standsabfrage des Qualit tsfaktors basierend auf dem Zustand des Einflussfaktoren entwickelt Es werden verschiedene m gliche Auspr gungen f r den Ein flussfaktoren ermittelt und jeweils der Einfluss auf den Qualit tsfaktor gemessen F r diesen Vorgang wird ein eigenes Tabellentemplate verwendet Die einzelnen Prozessschritte samt Formularen skiz ziert Abb 2 Eingehende Betrachtungen der GQM Methode finden sich in Schneider 2007 oder auch Van Solingen u Berghout 1999 Der GQM Editor nimmt ein Facettenziel entgegen und unterst tzt ma geblich die Erstellung eines zu geh rigen Abstraction Sheets und zugeh riger Mess pl ne Schritt 3 und Schritt 4 Die Erstellung und Verfeinerung von Messzielen oder deren Darstellung als Facette werden nicht unterst tzt Schritt 1 und Schritt 2 Beide Schritte lassen sich relativ schnell auf Papier bew ltigen
265. klung sie werden spezifisch ge f rdert Nicht nur das Management des Projektes mit As pekten wie Zeitplanung und Verteilung von Ar beitspaketen liegt komplett in der Hand der Studie renden Auch viele technische Aspekte wie geeig nete Ablage der entstehenden Arbeitsprodukte in einer Versionsverwaltung und verwendete Werk zeuge und Inhalte der einzelnen Arbeitsprodukte werden durch die Studierenden eigenverantwort lich gestaltet Zum Beispiel werden f r die Doku mentation der Architektur keine Sprachen wie UML UML 2012 oder SysML SysML 2012 vor gegeben Und wenn ein Team sich f r eine dieser Modellierungssprachen entscheidet dann muss es au erdem ein geeignetes Werkzeug ausw hlen und entscheiden welche Sichten auf das System vor handen sind und wie sie ausgestaltet werden Z r ner 2012 A Spillner H Lichter Hrsg SEUH 13 Erfahrungsgem f llt es den Studierenden schwer ein Testkonzept zu erstellen Es scheint zun chst schwierig zu sein die Inhalte eines Testkonzeptes zu erfassen Nach Diskussion ber das Thema ver stehen die Studierenden dass es nichts anderes ist als das Vorgehen in den Testphasen zu beschreiben und die Art der Tests samt Hintergr nden zu er l utern Der Weg ist das Ziel Gerade die genaue Ausgestaltung von Arbeitspro dukten ist auch in der Praxis oft ein Problem wie am Anfang des letzten Abschnitts angesprochen Daher wird im Projekt als Aufgabenstellung ein Ziel vor
266. klung wie Lean Development und Kanban Incremental Software Design und Soft ware Evolution Unterrichtsmethoden Neben konventionellen Vorlesungen und Pro grammier bungen verwenden wir als weitere Un terrichtmethoden e Case Studies Fremde Eigene e Gruppenarbeiten e Gastreferate mit Referenten aus der Soft ware Industrie e Simulationen e Medien eBooks Blogs Internet A Spillner H Lichter Hrsg SEUH 13 Wichtig ist die Repetition auf allen Ebenen d h regelm ssiges ben in verschiedenen Kontexten Deshalb kommen die verschiedenen Praktiken und Techniken immer wieder in den verschiedenen Vorlesungen vor Nicht isoliertes Unterrichten der einzelnen Praktiken steht im Vordergrund sondern die Verankerung an mehreren Stellen in der Aus bildung Das unterst tzt insbesondere auch die Werte Ebene in dem die Dozierenden selbst im Rahmen ihrer M glichkeiten diese agilen Werte vorleben Beispiel Bachelor Programm Obwohl an den beiden Fachhochschulen auch was das Themengebiet Software Engineering angeht unterschiedliche Studienpl ne existieren haben sich unterst tzt durch den intensiven Austausch viele Gemeinsamkeiten in der Vermittlung der agilen Methoden ergeben Abbildung 1 zeigt als ein m gliches Beispiel einen 6 aus 8 Modulen 5 aus amp Modulen 6 aus 8 Modulen a Programmierung _ Software ICT Systeme Mathematik Engineering Konzepte von Veneiite Hardwarenahe Indie ee ee Co
267. klus von der Anforderungsanalyse bis zur Lieferung und Demonstration des Systems durchlaufen werden Ein wesentlicher Bestandteil meiner Kurse ist die durchgehende Verwendung von Video beim Anforderungsmanagement szenario basierten Entwurf team aufbauenden Ma nahmen Projektreviews Pr sentationen und bei Demos Anhand von aktuellen Beispielen aus durchgef hrten Projektkursen zeige ich den Einsatz von Video illust riere die Herausforderungen beim Finden von Kunden und Themen und stelle eine Infrastruktur vor welche die Organisation und Durch f hrung solcher Kurse mit akzeptablen Zeit und Kostenaufwand erm glicht A Spillner H Lichter Hrsg SEUH 13 Software Engineering Curriculum Siemens Peter Zimmerer Siemens AG M nchen Corporate Technology peter zimmerer siemens com Zusammenfassung Dieser Vortrag gibt einen Einblick in ein praxisorientiertes Software Engineering Curriculum bei Siemens und schildert die Erfahrungen die wir seit der Einf hrung im Jahre 2006 damit gemacht haben Mit dem Curriculum verfolgt Siemens zwei wesentliche Ziele Zum einen soll die Qualifikation erfahrener Softwarearchitekten ge st rkt und weiter verbessert werden zum anderen soll durch ein Pre Assessment und eine Zertifizierung sichergestellt werden dass diese ber die technischen und sozialen F higkeiten verf gen die Soft warearchitekten ben tigen um gro e komplexe innovative ge sch ftskritische Software intensive
268. ktorientiert eine Klasse nutzbar zu machen mit der die einfa chen graphischen Elemente Punkt Linie Kreis und Rechteck gezeichnet und mit der Maus bewegt werden k nnen Weiterhin wird die Tastatursteue rung unterst tzt Zum Einstieg werden auch hier einfache Befehlsketten genutzt die ein Bild auf der Oberfl che zeichnen Danach werden eigene Klas sen f r graphische Objekte wie Dreiecke angelegt die dann selbst Methoden enthalten um sich auf ein Interaktionsbrett zu zeichnen Das folgende Programm zeigt die M glichkeit einen Kreis mit Hilfe der Pfeil Tasten nach links und rechts zu schieben Etwas negative Magie wird auch im Interaktionsbrett ben tigt da ein Objekt das ber Tastatureingaben informiert wer den m chte eine Methode der Form public void tasteGedrueckt String s realisieren muss Das Inter aktionsbrett nutzt Reflektion um dann diese Me thode aufzurufen public class Steuerung private Interaktionsbrett ib new Interaktionsbrett private int pos 0 public Steuerung ib willTasteninfo this public void tasteGedrueckt String s if s equals Rechts pos pos 5 else if s equals Links pos pos 5 ib abwischen ib neuerKreis pos 5 20 public static void main String s new Steuerung 53 Mit Hilfe des Interaktionsbretts k nnen auch leicht etwas kompliziertere Spiele programmiert werden Abb 1 zeigt ein Beispiel einer
269. kumsaufbau und die His torie unserer Praktika Danach beschreiben wir wie wir unseren Prozess mit Hilfe von Kanban angepasst haben Anschlie end berichten wir was wir w hrend des Praktikums ge ndert haben und am Ende ziehen wir ein Fazit und pr sentieren unsere Empfehlungen f r Lehrende Kanban Kanban ist ein agiler Software Entwicklungsprozess dessen Urspr nge im Toyota Production System liegen Entwickelt wurde das Toyota Production System von Taiichi Ono der es auch in seinem 1988 auf Englisch erschienen Buch beschrieb Ono 1988 Das japani sche Original war bereits 10 Jahre zuvor erschienen kan bedeutet w rtlich aus dem Japanischen tiber setzt visuell und ban Karte Toyota nutzte Kanban um die Lagerbest nde zu reduzieren und einen gleich m igen Fluss Flow in der Automobilfertigung zu realisieren David Anderson hat diesen Prozess auf Softwareentwicklung bertragen Anderson 2010 und durch f nf Kerneigenschaften charakterisiert sie he Tabelle 1 91 F r Kanban ist die sichtbare Tafel oder ein White board mit einer bersicht ber den Entwicklungszu stand ein zentrales und wohl auch das offensichtlichs te Instrument Zur Illustration gehen wir schon hier kurz unser eigenes Kanban Board ein Bereits in der agilen Ent wicklung und in unseren vorherigen Praktika war und ist es blich die sogenannten User Stories auf einem Board zu visualisieren Dieses Board hatte Spalten f r
270. lame bei der Andererwendung der GQM Methode ein um passende Metriken zu finden und Da ten zu sammeln MetriFlame erlaubt die Generierung von GQM B umen auf Basis von bereits gespeicherten Metriken Das Aufstellen von Abstraction Sheets oder Messpl nen wird nicht unterst tzt Das GQM Tool von Lavazza 2000 bietet die M g lichkeit GQM B ume zu erstellen Deren Struktur wird auf Konsistenz berpr ft indem z B kontrolliert wird ob jedes Messziel zu mindestens einer Frage verfei nert wurde und es zu jeder Frage mindestens eine Metrik gibt Messziele Abstraction Sheets Questions und Metriken werden als Produkte der GQM Methode unterst tzt Einzelne Komponenten von GQM Pl nen k nnen wiederverwendet werden Das GQM Tool ist mit einer Datenbank verbunden Auch dieses Tool bietet keine Hilfestellungen an die erkl ren wie ein Abstraction Sheet auszuf llen ist Diskussion Der smarte GQM Editor verwendet Texteingaben des Anwenders um n chst auszuf llende Felder mit kon textualisierten Hilfstexten oder sogar vorgenerierten Antworten zu best cken Die Konstruktion der grau en und schwarzen Hilfstexte basiert auf Textmustern welche wir durch wiederholtes Bearbeiten und Lehren von Abstraction Sheets in der Lehre erkannt haben Grob gesagt hat das begleitete Erkl ren von Abstrac tion Sheets anhand solch gearteter Kommentare den h chsten Lernerfolg bei Studenten erzielt Der smarte GQM Editor setzt eine einfache Texter se
271. llen durchgef hrt werden um verschiedenen Vorschl ge Auspr gungen des Einflussfaktor zu ermitteln 1 Schritt Welcher Schritt soll als erstes den die Aus hgef hrt um verschiedene Auspr gungen f r 2 von Funktionen zu ermitteln 2 Schritt 3 Schritt Weiteres Eingabefeld Linke Seite freigeben Ergebnis mit 2 Auspr gung Ergebnis mit 3 Auspr gung Ergebnisse Welche verschiedenen Auspr gungen haben sie f r den Einflussfaktor ermittelt 1 Auspr gung 2 Auspr gung 3 Auspr gung Abbildung 6 Linke Seite des Messplans wird zu Beginn ausgeblendet mit automatisch generierten Antworten unterst tzen bietet jedoch hier die erste Hilfestufe an grauer Text als Gedankenansto Weiterhin gibt der graue Hin weistext dem unerfahrenen Benutzer die Reihenfolge zum Ausf llen vor Jede Eingetragene Auspr gung f r den Einflussfaktor ist einem Eintragungsfeld f r eine Auspr gung gegen bergestellt Auf diese Weise soll dem Anwender die Gegen berstellung und der Effekt der verschiedenen Faktor Auspr gungen vereinfacht werden Verwandte Arbeiten Zur Unterst tzung der GQM Methode wurden bereits einige Tools entwickelt Jedoch ist keines der unter suchten Tools fokussiert auf unerfahrene Benutzer oder bietet Hilfestellung beim eigentlichen Ausf llen von Abstraction
272. llierte Hinweise wie die Aufga ben abzunehmen sind Kleinschrittige Aufgaben f r Pr senzaufgaben sind aber auch deshalb zu bevorzugen weil die Betreuer dann schneller und h ufiger mit den Studierenden in Interaktion tre ten und so die Gefahr verringert wird dass die Studierenden sich in Fragen zu unwichtigen Rand details verrennen und unn tig Zeit verlieren Das Programmieren im Paar wurde durch agile Me thoden wie das Extreme Programming Beck and Andres 2004 breiter bekannt Der Nutzen in der professionellen Softwareentwicklung ist durchaus umstritten in der Programmierausbildung gibt es jedoch deutliche Hinweise auf seine Wirksamkeit McDowell et al 2006 Wir sehen einen weiteren Vorteil in der M glichkeit Studierende mit Vorer fahrung bewusst mit Anf ngern in den Paaren zu mischen damit das vorhandene Vorwissen zur Unterst tzung von Kommilitonen genutzt werden kann Klassische bung 4 5 Stunden 2 SWS Prasenzzeit es bei beiden Konzepten Labor 8 Studierende betreuung 2 SWS 4 5 Stunden Korrektur von 6 10 Gruppen zeitlich nicht gebunden 15 Studierende 8 Studierende Abb 3 Betreueraufwand pro Woche im Vergleich Fur die Betreuer ergibt sich eine andere Zeiteintei lung fiir zwei SWS Ubung siehe Abbildung 3 statt 90 Minuten klassische Ubung mit einer Gruppe von 15 Teilnehmern die momentane Ubungsgruppen gr e in der Informatik an der Uni Hamburg und der Zeit di
273. log notwen Systems und seine Artefakte bzw ziel und damit direktes dig hoher Zeitaufwand in auch Zwischenabgaben Feedback zum Lernerfolg der Bewertung Zuordnung Meilensteine werden der Leistung nicht immer bewertet einfach M ndliche Pr Pr fungsgespr ch mit Planbarer Zeitaufwand f r Bewertung spiegelt nicht fung en Testate einem oder mehreren den Pr fer etablierte Pr unbedingt den Beitrag zum Studierenden fungsform individuelle Projekt wieder hoher Zeit aufwand verwendete Fra gen verbreiten sich schnell ihre Teamkollegen tonen Schriftliche Pr Die klassische Klausur Bekanntes Verfahren Leis Erfordert mitunter einen fung tung ist klar zuzuordnen hohen Vorbereitungsauf und gut vergleichbar wand kein direkter Bezug zur Leistung im Projekt Programmierpr Programmierklausur Gute berpr fung der Ausreichend gro e Rech fung idealerweise mit einer Lernziele in Bezug auf Pro nerr ume m ssen verf g Entwicklungsumgebung grammierkenntnisse am bar sein bei autom Bewer direkt am Rechner ausge Rechner ber Testf lle au tung kein Bewertungsspiel f hrt tomatisch und damit objek raum minimale Program tiv bewertbar mierfehler k nnen gro e Auswirkungen haben Laborbuch Studierende dokumen Erleichtert Nachvollzieh Overhead f r Studierende tieren Aufgabenvertei barkeit des Vorgehens und Betreuer Benotung lung und Vorge
274. m Projekt an der gleichen Aufgabe die Benotung erfolgt individuell In den Teams ist eine Steuerung von Ampeln an einer Kreuzung oder eine Aufzugsteuerung zu entwickeln A Spillner H Lichter Hrsg SEUH 13 F r das Projekt existieren zwei entsprechende Mo delle au erdem drei unterschiedliche S tze von Evaluationsboards mit automotive Controllern unterschiedlicher Leistungsklassen Bilder der Mo delle sind unter metio Webseite 2012 zu finden Das Projekt deckt die typischen Schritte in der Em bedded Software Entwicklung von der Anforde rungsanalyse mit dem Kunden bis hin zur Imple mentierung in C und zum Test ab Hruschka 2002 Automotive SPICE 2007 Durch Abgaben und Pr sentationen sowie die Ar beit in Entwicklungsteams samt Planung der Ar beitspakete wird die Realit t von Projekten bereits in der Hochschulausbildung vermittelt Insbeson dere die Praxisn he macht das Projekt f r Studie rende interessant Alle Teilnehmer m ssen mindestens zwei Mal die selbst erarbeiteten Abgaben vor der Gruppe pr sentieren Jedes Team ist f r die rechtzeitige Abgabe mindes tens der folgenden Arbeitsprodukte verantwortlich e Planung des Projekts e Anforderungsanalyse e Architektur und Design e Dokumentierte Implementierung e Testkonzept e Testf lle e Lessons Learned Dariiber hinaus gibt es optionale Arbeitspakete mit entsprechenden Abgaben zum Beispiel e die erneute Anforderungsanalyse und die ber
275. m Ressourceneinsatz der Hochschule gerechnet in SWS Lehrkapazit t Diese Vervielfachung der Kontaktzeit muss jedoch begleitet werden von geeigneten Aufgaben Wir haben einige Jahre gebraucht um unsere Aufgaben in dieser Hinsicht zu optimieren Auch das Programmieren Lernen im Paar hat sich als sehr effektive M glichkeit erwiesen die Kom munikation ber kleinste Entwurfsentscheidungen die beim Programmieren getroffen werden m ssen zu erh hen Die Studierenden der bisherigen Jahr g nge haben auch dieses Konzept mit gro er Mehrheit sehr positiv aufgenommen 6 Zusammenfassung In diesem Artikel wurden systematisch einige Al ternativen diskutiert die bei der Gestaltung der einf hrenden Programmierausbildung in Informa tik Studieng ngen auftreten k nnen Dabei wurde ber Fragen der strategischen Ausrichtung ganzer Studieng nge der Bogen geschlagen hin zu inhaltli chen Alternativen bei der einf hrenden Java Ausbildung Wir erhoffen uns dass dieser Artikel einen Bei trag zur Diskussion der hier behandelten Themen auf der SEUH leisten kann A Spillner H Lichter Hrsg SEUH 13 Literatur Altenbernd Giani E et al 2009 Programmierungsveranstaltung unter der Lupe Lernen im digitalen Zeitalter Die 7 eLearning Fachtagung Informatik DeLFI Berlin Lecture Notes in Informatics LNI P 153 S 55 66 Barnes D and M K lling 2008 Objects First with Java A Practical Introduction Using BlueJ 4th Ed
276. ma erarbeiten Feedback Die Beantwortung der Fragen in der Selbststu diums Komponente der Methode gibt den Stu dierenden Feedback in wie weit sie den Lehr stoff verstanden haben Die Antworten auf die online gestellten Fragen und auf die Fragen in der Lehreinheit geben di rektes Feedback ber den Lernfortschritt der Studierenden A Spillner H Lichter Hrsg SEUH 13 Die dritte Feedback Schleife durch die Anwen dung der gelernten Techniken an einem gr e ren realen Beispiel zeigt ob die Studierenden die Techniken auch an einem gr eren Beispiel anwenden k nnen Lehrveranstaltung Die Fragerunden in der Lehreinheit motivieren die Studierenden sich auf den Lehrstoff vorzu bereiten Sie bieten auch die M glichkeit lteres Wissen zu wiederholen Die Studierenden diskutieren Fragestellungen mit da sie sich auf die Lehreinheit vorbereitet haben Die Studierenden werden in den Lehrprozess durch Peer Instruction eingebunden Die Studierenden machen in der Lehrveranstal tung einen motivierten und interessierteren Eindruck Die Studierenden sind gezwungen aus ihrer reinen Konsumentenhaltung in der Lehrveran staltung herauszukommen und aktiv am Ge schehen teilzunehmen Die Atmosph re im H rsaal ist fehlertole rant d h Fragen sind durch die Methode er laubt Sonstige Es werden Fehler oder Unstimmigkeiten im Lehrmaterial aufgedeckt Ad hoc gestellte Fragen di
277. mal pro Woche gemeinsam am Projekt arbeiten k nnen sonst eher getrennt z B Zuhause Ein Daily Standup ist daher in der Regel nicht m g lich Die Studierenden machen daher eher ein Mee ting in dem sie sich gegenseitig auf den neuesten Stand bringen Statt einer Pinnwand als Scrum Board werden h ufig digitale Boards eingesetzt die jedoch nicht so einfach zu bedienen sind wie Pinnw nde und nicht die gleiche Flexibilit t auf weisen Daher werden diese oft nicht mit der not wendigen Sorgfalt verwaltet Erfahrungen Welche Erfahrungen haben wir nun mit dem Un terrichten von agilen Methoden gemacht und wie wird dieses Vorgehen von den Studierenden auf genommen Unsere Erfahrungen sind durchwegs positiv auch wenn noch einige Herausforderungen bestehen Die Studierenden sind sehr offen gegen ber den agilen Methoden da sie den Fokus st rker auf die eigentlichen Interessen der Studierenden die Kon struktion der Software durch Design und Pro grammierung legen Das Feedback der Studieren den ist entsprechend ermutigend Gerade auch der Nutzen von Test getriebener Ent wicklung und der Automatisierung mittels CI Um gebungen wird f r die Studierenden sehr schnell 87 ersichtlich und erfreulicherweise von diesen dann selbst in Projektarbeiten eingesetzt Untersch tzt wird h ufig das disziplinierte Vorge hen welches agile Methoden vom gesamten Pro jektteam z B bei der iterativen Planung und der Software Q
278. mit f r den Interviewleitfaden wurde u a SWEBOK herangezogen Um auch angrenzende Themen komplexe wie beispielsweise Programmiertechni ken und Datenbanken einflie en zu lassen wurden auch entsprechende fachliche Inhalte vorhandener Lehrveranstaltungen ber cksichtigt Es wurden Gespr che mit sieben Vertreten von Wirtschaftsunternehmen verschiedener Branchen vgl Tabelle 1 im Bereich Software Engineering gef hrt aufgezeichnet transkribiert und ausgewer tet Befragt wurden einerseits Personen mit Ent scheidungskompetenz bei der Auswahl neuer Mit arbeiter und N he zu den fachlichen Inhalten also z B Gesch ftsf hrer oder Gruppen Abteilungs leiter andererseits Absolventen der eigenen Hoch schule mit inzwischen mehrj hriger Berufserfah rung Nr Branche Entschei ehem der Absol vent in 1 Marketing Software X entwicklung kein Kerngesch ft 2 Softwareentwicklung X X f r Banken und Versi cherungen 3 Bildbearbeitung Me X dizin Embedded Datenbankl sungen 121 4 Automobilzulieferer X Embedded 5 Softwareentwicklung X und Betrieb einer Marketingplattform 6 Softwareentwicklung X und Betrieb einer Marketingplattform 7 Gro konzern Abtei X lung mit Schwerpunkt Softwareentwicklung Tabelle 1 Zusammensetzung der Stichprobe Zwar gew hrleistet diese Auswahl noch keine re pr sentative Stichprobe aber immerhin eine relativ gute Ab
279. mit den Studierenden f hren sie somit kontinuierlich betreuen und viel Feedback geben bzw bekommen Die Abgabe war fr hzeitig als fixe nicht verhandelbare Deadline definiert worden Ergebnisse und Ausblick Wir haben einen Versuch beschrieben Master Studierende im ersten Semester unter Anleitung eine Forschungsarbeit durchf hren zu lassen Die Ergeb 116 nisse haben unsere Erwartungen bertroffen Aus 16 Arbeiten waren f nf auf sehr gutem Niveau und f r eine Publikation geeignet Alle auf Konferenzen einge reichte Arbeiten wurden vor Einreichung berarbeitet Zwei Arbeiten zu den Themen d und g waren hochwertig jedoch noch nicht ganz vollst ndig Leider entschieden sich die Studierenden die Themen nicht weiter zu verfolgen Eine sehr gute empirische Arbeit zum Thema e stellt einen Versuch mit Bachelor Studierenden im ersten Jahr vor der von zwei Master Studierenden vorbereitet durchgef hrt und analysiert wurde Aktuell warten wir auf die Ergebnisse eines Peer Reviews dieses Artikels Verschiedene Arbeiten zum Thema a haben interessante Zusammenh nge zwischen Architektur und Unternehmensstruktur auf gezeigt sind jedoch nur schwach empirisch belegbar Eine diese Arbeiten wurde bei der VARSA 2012 ein gereicht und vom Peer Review nicht angenommen da der Artikel nicht ganz den Fokus der Konferenz traf Aus den Arbeiten zum Thema c stach eine besonders hervor und wurde nach Anreicherung durch weitere Ideen a
280. mit hohem Infor matik Anteil Typ 1 oder 2 der GI Typisierung in einem solchen Studium sollten sie auch das Pro grammieren erlernen 1 1 Programmierausbildung Dass Programmieren einen hohen Stellenwert in Informatik Studieng ngen haben muss spiegelt sich exemplarisch in der Weiterentwicklung der GI Empfehlungen wider W hrend in den Empfehlun gen zur Akkreditierung von Studieng ngen der Infor matik GI 2000 aus dem Jahr 2000 der Begriff Pro grammieren nur sehr knapp auftaucht werden in den Empfehlungen aus dem Jahre 2005 GI 2005 konkrete Programmierveranstaltungen mit konkre ten Umf ngen vorgeschlagen Eine hnliche Ent wicklung erw hnt Walker f r das Computing Sci ence Curriculum der ACM und IEEE Walker 2010 In diesem Artikel fassen wir alle Bem hungen Lehrender Studierenden die Kunst des Program mierens zu vermitteln unter dem Begriff Program mierausbildung zusammen In jeder Programmier ausbildung sollte die F higkeit trainiert werden l sbare Probleme mit Hilfe der universellen Ma schine Computer l sen zu k nnen problem sol A Spillner H Lichter Hrsg SEUH 13 ving Auf jeden Fall sollte ein Verst ndnis daf r aufgebaut werden welche Probleme mit Compu tern gut gel st werden k nnen und welche eher nicht Dies beinhaltet neben theoretischen Grund lagen auch praktische F higkeiten im Umgang mit Programmiersprachen 1 2 softwaretechnisch konkretisiert Eine fundiert
281. mit ihren Eigen schaften erl utert und Einsatzbereiche diskutiert Meistens besteht bei den Studierenden kein Wissen ber unterschiedliche Klassen von Anforderungen Pohl 2007 Funktionale Anforderungen sind die jenigen die vom System komplett erf llt werden m ssen Qualit tsanforderungen oder oft auch nicht funktionale Anforderungen genannt werden immer zu einem gewissen Grad erf llt Wichtig f r Architektur Entscheidungen sind die Qualit tsan forderungen Bass 2003 Dies kann anhand des folgenden Beispiels veranschaulicht werden Es ist ein System zum Sortieren von Daten zu ent wickeln funktionale Anforderung Dabei ist die mittlere Laufzeit wichtiger als der Speicherplatzbe darf Qualit tsanforderung Die Bewertung sieht wie folgt aus Mittlere Laufzeit Speicher Stack Bubblesort Quicksort _ Tabelle 1 Alternativen und Bewertung Nur mit der Qualit tsanforderung kann eine Ent scheidung f r eine Alternative getroffen werden 31 Quicksort weil die Laufzeit wichtiger als der Spei cherplatzbedarf ist Die bei den meisten eingebetteten Systemen vor handene zeitgesteuerte Ausf hrung Kienzle 2009 ist vielen Studierenden nicht bekannt Es werden in der Praxis bliche L sungen diskutiert die Hinter gr nde der Ans tze beleuchtet und mit anderen Ausf hrungsparadigmen verglichen Alle diese technischen Diskussionen werden gene rell mit allen Studierenden gemei
282. mplerpau IT System 5 der Bes Nan Programmieren Wanrscheinlich in C keitstheonie und Stabstik Al Einfunru 5 Diskrete Projekt 2 a T Mathematik 2 2 systeme Softwa Diskrete emun Effi ana 1 Objektorlentierte Usability und Einf hrung in Lineare E gt 2 Design Opjektorientierte Anfordenu System nee aeus Alison m 1 mind 18 mind 18 Credits mind 18 Crediis Ausschnitt des Informatik Bachelor Programms der Fachhochschule Nordwestschweiz Das fachliche Grundstudium im Bachelorstudien gang ist aufgeteilt in die vier Themenbereiche Mo dulgruppen genannt Programmierung Software Engineering sowie ICT Systeme und Mathematik Jede Modulgruppe besteht aus je 8 Modulen die spezielle Themen aus der jeweiligen Modulgruppe abdecken Jedes Modul hat einen Umfang von 3 ECTS Punkten Begleitet wird die theoretische Ausbildung in den Modulen durch eine vom ersten Semester an be ginnende Projektschiene die sich bis in das 6 Se mester fortsetzt In dieser setzen die Studierenden in grossen Teams 7 bis 8 Studierende und an rea len d h von externen Kunden in Auftrag gegebe nen Projekten die Theorie in die Praxis um Dabei werden in den beiden Jahresprojekten der ersten 4 Semester unterschiedliche Schwerpunkte gesetzt 83 Die explizite Ausbildung in agilen Methoden wird insbesondere in den Modulen Software Konstruk tion im 2 Semester und Software Projekt Manage ment im 3 Semester der Modulgruppe Software
283. mplexen Unterstruktur ist es schwie rig Kompetenzen verschiedener Bereiche des Software Engineering wie etwa Kerninformatik Mechatronik oder Wirtschaftsinformatik mit die sem Modell zu unterscheiden Die Untersuchungen zeigten u a dass die Klassifizierung auf der Ebene der Kompetenzen oftmals widerspr chlich ist Ei nerseits ist dies auf die strikte kumulative Hierar chie der Klassen zur ckzuf hren anderseits sind die Anordnung und Bedeutung der h heren Klas sen f r diesen Einsatzzweck fraglich Claren 2012 Da dieses Modell zur Klassifizierung von Lehrzie len entwickelt wurde eignet es sich nur bedingt f r die Beschreibung von Kompetenzen da diese auf einer abstrakteren Ebene angesiedelt sind Anderson und Krathwohl 2001 ver ffentlich ten eine berarbeitete Fassung der Taxonomie nach Bloom Gegen ber der Ursprungstaxonomie wur den zun chst die Klassen in aktive Verben umbe nannt und die beiden letzten vertauscht da dies nach Meinung der Autoren der steigenden Kom plexit t der kognitiven Prozesse besser entspricht Die wesentliche nderung ist jedoch die Einf h rung einer zweiten Dimension welche die Art des Wissens repr sentiert Damit ergibt sich das in Ab bildung 1 gezeigte zweidimensionale Schema das zwischen einer kognitiven und einer Wissensdi mension unterscheidet A Spillner H Lichter Hrsg SEUH 13 The The Cognitive Dimesnion Knowledge 1 2 3 4 5 6 Dimension Remember Understan
284. mplexit t Die zyklomatische Komplexit t McCabe 1976 ist eine Metrik zur Komplexit t des Kontrollflussgraphen eines Programms Sie basiert auf der Anzahl der Kno ten und Kanten dieses Graphen und damit auf der Entscheidungsstruktur des Programms Das Ergebnis entspricht der maximalen Anzahl linear unabh ngiger Pfade eines Programms und ist damit insbesondere unabh ngig vom Hinzuf gen oder Entfernen von An weisungen die keine Entscheidungsknoten darstellen Sie geh rt damit zu den Metriken die die logische Struktur eines Programms unabh ngig von seinem Umfang beurteilen Wie die oben diskutierte Anzahl der Anweisungen kann auch diese Metrik bei Aufgaben mit vorgege benen Codevorlagen verwendet werden indem die Komplexit t dieser Vorlagen vorab bestimmt wird Da die Vermeidung unn tig komplexer L sungen zu den Lernzielen einer Veranstaltung geh ren kann lassen sich die Ergebnisse der Metrik auch direkt verwenden Die Metrik l sst sich auch ohne Aufbau des komplet ten Kontrollflussgraphen eines Programms berechnen indem alle if Abfragen bedingten Ausdr cke Schlei fen case Anweisungen catch Anweisungen f r Ja va und logische Operatoren gez hlt werden Objektorientierte Metriken Es gibt weitere speziell auf die Messung typischer Eigenschaften objektorientierter Programme ausge richtete Metriken z B zur Kopplung zwischen Klas sen Koh sion innerhalb von Klassen oder Sichtbarkeit von vererbten Methoden e
285. n Form eines Testats gestellt wird Dieses war jeweils innerhalb von 45 Minuten im PC Pool der Universi t t unter Pr fungsbedingungen zu bearbeiten Da der PC Pool nicht ausreichend viele Pl tze bietet um alle Studierenden gleichzeitig zu pr fen mussten die Tes tate in Gruppen abgenommen werden Daher mussten stets mehrere Aufgabenvarianten erstellt werden da mit Teilnehmer der ersten Gruppe nicht Details der Aufgabenstellung an die sp teren Gruppen weiterge ben konnten Aus diesem Szenario ergeben sich zwei Anforderungen die die berpr fung eines relativen Aufgabenniveaus sinnvoll erscheinen lassen Erstens muss sichergestellt sein dass durch die verschiedenen Varianten keine Gruppe benachteiligt wird indem ih re Aufgabe mehr Aufwand erfordert als die Aufgaben anderer Gruppen Zweitens muss sichergestellt sein dass die Testataufgaben insgesamt in einem angemes 64 senen Verh ltnis zum zugeh rigen Miniprojekt stehen und tats chlich einen Ausschnitt aus diesem bilden Um den Studierenden den Einstieg in die Testatauf gaben zu erleichtern und zudem grobe Fehler beim Stellen der Testataufgaben zu vermeiden orientierten sich diese sehr eng an den zugeh rigen Miniprojek ten Es kam stets eine sehr hnliche Codevorlage zum Einsatz und auch der narrative Kontext der Aufgabe war stets identisch mit dem des Miniprojektes Der eigentliche Kern der Aufgabe war den Studierenden jedoch nicht vorab bekannt d h es musste im Tes
286. n Praktikums Dokumenten organisiert werden muss An dere Fragen m gen zun chst banal erscheinen ma chen aber schnell deutlich warum es sich empfiehlt Wissen explizit zu dokumentieren e Ich m chte eine Grillfeier f r 160 Teilnehmer orga nisieren Wieviele Getr nke und Speisen muss ich pro Person ansetzen Woher bekomme ich Grills W rstchen Besteck Salate e Ich m chte eine Messe organisieren auf dem meine Praktikums Teilnehmer ihre Projekte vor stellen k nnen Was brauche ich und woher be komme ich es Wann muss ich wen verst ndigen Um das Wissen ber Softwaretechnik Lehre zu ver walten haben wir ein Wiki eingerichtet um das Wis sen ber Softwaretechnik Lehre zu organisieren und zu dokumentieren und zwar in einer Form die so wohl lokales als auch standort bergreifendes Wissen dokumentieren kann Die Artikel nutzen das Format der Muster analog zu Entwurfsmustern als L sungs schablonen f r immer wiederkehrende Probleme Name Jedes Muster hat einen Namen damit es unter diesem Namen einfach referenziert und nachge schlagen werden kann Ziel Jedes Muster l st ein bestimmtes Problem das hier allgemein charakterisiert werden kann Motivation Das Problem sollte relevant sein also h ufig oder in verschiedenen Auspr gungen im mer und immer wieder auftreten Anwendung Dies ist eine Beschreibung wie das Muster umgesetzt wird sowohl in abstrakter A Spillner H Lichter Hrsg
287. n die mit agilen Methoden einhergehen Um die Relevanz der agilen Methoden f r die Aus bildung zu ermitteln war f r uns unter anderem die Beantwortung folgender Fragen wichtig 1 Wie verbreitet ist agile Softwareentwicklung in der Praxis 2 Haben agile Methoden wirklich Vorteile ge gen ber den traditionellen plan getriebenen Methoden 3 Was sind die entscheidenden Erfolgsfaktoren bei der agilen Softwareentwicklung Im n chsten Abschnitt werden wir die aus unserer Sicht f r die Ausbildung wichtigsten Resultate der Studie vorstellen und danach einige berlegungen und Konsequenzen f r die Ausbildung an Fach Hochschulen n her ausf hren Nach einer bersicht ber die wesentlichen Ele mente der agilen Methoden werden wir im An schluss unsere Konzepte vorstellen Wir zeigen auf wie die erforderlichen Kompetenzen vermittelt bzw von den Studierenden erlernt werden k nnen Anschliessend berichten wir ber den konkreten Umsetzungsstand und unsere Erfahrungen die wir gemacht haben Den Abschluss bildet ein Ausblick ber die Weiter entwicklung der Konzepte und deren Umsetzung Verbreitung und Nutzen von agilen Metho den In der Swiss Agile Study wurden mehr als 1500 IT Firmenmitglieder der teilnehmenden ICT Verb nde SwissICT ICTnet und SWEN befragt die R cklaufquote betrug knapp 10 Dabei wurden sowohl agil als auch nicht agil arbeitende Unter nehmen einbezogen Von den teilnehmenden Un ternehme
288. n Fall durch Zusatz oder Alterna tivaufgaben und die Aufforderung Studierenden mit aktuell weniger Kenntnissen zu unterst tzen f r Lehrveranstaltungen in der Programmierung umgesetzt werden kann Motiviert ist dieser Artikel durch verschiedene Beitr ge zu fr heren SEUH Konferenzen in denen die M glichkeiten zum Einstieg in die Objektorien tierung SZ07 und die Nutzung von Werkzeugen Bol09 diskutiert wurden Generell finden einige Untersuchung zum Lernverhalten von Studieren den statt die h ufiger in Magazinen wie Compu ter Science Education wie z B MFRW11 mit der Untersuchung der Denkmodelle was bei Zuwei sungen passiert und KS12 ber Erfahrungen bei ersten Programmieraufgaben ver ffentlicht und auch in Gl Workshops z B Boe07 behandelt werden Dieser Erfahrungsbericht will diese For schungsinteressen unterst tzen 47 Im folgenden Text werden drei Einf hrungsveran staltungen in die Programmierung die mit unter schiedlichen Programmiersprachen durchgef hrt wurden auf ihren Erfolg im Zusammenhang mit der eingesetzten Programmiersprache analysiert Da der Erfolg ohne den Aufbau eines komplexeren Messsystems nicht vollst ndig objektiv messbar ist basieren Ergebnisse auf pers nlichen Erfahrungen und Gespr chen mit beteiligten Studierenden und Lehrenden in hnlichen Situationen Es wird des halb fast konsequent in diesem Artikel darauf ver zichtet aus Durchfallquoten in Pr fungen direkt
289. n Time darauf eingegangen wer den Der positive Effekt auf das Lernen durch den Einsatz von automatischen Antwortsystemen in den Lehrveranstaltungen kann beispielsweise in Knight et al 2005 nachgelesen werden Erste Erfahrungen mit dem Just in Time Teaching Wie berichtet durch das Forum der Lehre inspi riert und im Rahmen des Projektes EVELIN zur systematischen Verbesserung des Lernens von Software Engineering Abke et al 2012 haben sich die Verantwortlichen f r die Software Engineering Ausbildung der Hochschulen in Kempten und Regensburg zum Ziel gesetzt das Just in Time Teaching in die Lehre einzuf hren Dazu w hlten wir zun chst gew nschte Lernziele aus die die Studierenden im Rahmen der Veranstaltung errei chen sollten Die Studierenden sollen in der Lage sein die Strukturierte Testfallermittlung durch Grenzwert betrachtung zu verstehen und anzuwenden Dazu erhielten die Studierenden zun chst die Aufgabe die entsprechenden Kapitel aus den B chern von Liggesmeyer Liggesmeyer 2002 und Spillner Spillner 2010 zu studieren Au erdem wurden die in Abbildung 1 gezeigten allgemeinen Fragen zum Verst ndnis gestellt Die freiwillige Beantwortung der Fragen ergab erwartungsgem einen R cklauf von weniger als 50 bei den Studierenden Dabei tauchte eine Fra ge h ufig auf e Wie bestimme ich den Repr sentanten kann ich mir den selber ausdenken oder gibt es da irgendwelche Vorschriften wie ich
290. n aus Umfangs und Komplexi t tsbeobachtung Auf die Verwendung von speziellen objektorientierten Metriken wurde verzichtet da al le untersuchten Daten aus einer Anf ngervorlesung stammen Alle Fallbeispiele beziehen sich auf Aufgaben aus der Erstsemestervorlesung Programmierung im Win tersemester 2011 12 Bei allen Aufgaben wurde die Einreichung von L sungen in der Programmiersprache Java erwartet und den Studierenden war es erlaubt beliebig viele L sungen zu einer Aufgabe einzurei chen Bei einzelnen Aufgaben kamen so bis zu 1400 L sungen zusammen wobei im Schnitt 3 6 L sun gen pro Studierendem eingingen F r die Analysen wurden solche L sungen ausgefiltert bei denen die Metriken aufgrund von syntaktischen Fehlern im Pro grammcode nicht bestimmt werden konnten Dupli kate von L sungen wurden nicht ausgefiltert f hren aber zwangsl ufig zu identischen Ergebnissen in den Metriken Die Einreichung der L sungen durch die Studierenden und die Berechnung der Kennzahlen aus den Metriken erfolgte ber das Werkzeug JACK Striewe u a 2009 Die Kennzahlen wurden den Studierenden nicht mitgeteilt sondern nur f r die r ckblickende Analyse nach dem Semester verwen det Freiheitsgrade von Aufgaben Beim Stellen von bungs und Pr fungsaufgaben ist relevant wie viele Freiheitsgrade die Aufgaben den Studierenden beim Erstellen einer L sung lassen Je enger begrenzt die Aufgabenstellungen sind desto leichter sind
291. n gaben 57 an dass sie mit agilen Me thoden entwickeln Auf die Frage wie die agilen Methoden die Ent wicklung beeinflusst hat gaben die Unternehmen 79 zu allen befragten Aspekten an dass sich diese verbessert oder sogar sehr stark verbessert haben siehe Tabelle 1 Dabei sind insbesondere die Aspekte Ability to manage changing Require werden dabei insbesondere Kodierrichtlinien 82 Unit Testing 76 und Continuous Integra tion 70 genannt ments 89 Development Process 80 und Time To Market 76 zu nennen ASP ect 2 Behavior Driven Development i BDD 21 24 17 8 Aspect E z o CH Acceptance Test Driven Devel Time to market 1 2 19 53 23 opment ATDD 18 22 20 17 Ability to manage changing 1 0 9 45 44 Test Driven Development TDD 10 16 29 30 priorities Coding standards 4 9 40 42 Productivity 0 2 33 47 15 Collective code ownership 12 12 33 30 Software quality 0 2 45 35 16 Alignment between IT amp ol sal 235 466 23 Pair programming ZOJ IE AR business objectives Unit testing 2 17 25 51 Project visibility 0 2 25 39 28 Refactoring 3 25 35 28 Risk management er Automated builds s 14 26 40 Development process 2 17 28 2 Continuous integration 4 16 32 38 Software maintainability 0 7 55 23 12 3 iait m Automated acceptance testing 20 26 28 14 extensibility capability
292. n kennzeichnet die Gruppe ein breiter Bildungshin tergrund mit dem Fokus auf Informatik und IT sowie teils mehrj hrige Berufserfahrung Im Rahmen der Veranstaltungen Software Architec ture SWA und Paradigms in Software Development PSD bekamen die Studierenden die Aufgabe aus A Spillner H Lichter Hrsg SEUH 13 einer Zahl von sieben Forschungsthemen eines auszu w hlen und dazu eine Arbeit in Artikelform zu ver fassen sowie eine Pr sentation zu halten Die Veran staltungen haben in Summe f nf ECTS bzw vier SWS und wurden vom verantwortlichen Professor sowie einem Assistenten gemeinsam ber die gesamte Zeit begleitet Die Studierenden hatten die M glichkeit in Gruppen zu arbeiten hiervon machten aber nur wenige Gebrauch Dieser Erfahrungsbericht soll unsere Ideen und Vor gehensweise zusammenfassen und zur Wiederholung animieren Die Ergebnisse sind f r Universit ten und Fachhochschulen gleicherma en interessant Sie zei gen dass bei einem Betreuungsaufwand von vier SWS wissenschaftlich publizierbares Material entste hen kann Doktoranden an Universit ten k nnen so ihre Forschungsarbeiten vorantreiben und in 4 6 Mo naten von Studierenden Forschungsaufgaben effizient erarbeiten lassen An Fachhochschulen wo der wis senschaftliche Mittelbau fehlt kann so Freiraum f r Forschung geschaffen und gef rdert werden Themenauswahl Die Themen orientierten sich am Fokus der Veranstal tungen und waren so gew hlt
293. n sich aus dem entsprechenden Kompetenzmodell ab Das Modell soll die Beschreibung von Soll und Ist Kompetenzen zu verschiedenen Zeitpunkten 122 und deren Vergleich erm glichen Da dieses Be schreibungsmodell ein Werkzeug f r Planung Messung und Analyse sein soll muss es m glichst einfach aber dennoch ausreichend ausdruckskr f tig verst ndlich und handhabbar sein Wichtig ist auch die Kompatibilit t mit anderen Denkans tzen und Beschreibungsmodellen wie z B der Taxonomie von Lernzielen im kognitiven Be reich nach Bloom 1972 Es sollte wenn n tig zu sp teren Zeitpunkten noch erweiterbar sein Auch sollte eine Hierarchie aufeinander auf bauender Kompetenzen zwar abbildbar jedoch nicht zwingend sein Klassifikationsschemata f r Lernaufgaben und Taxonomien f r Software Engineering Inhalte wurden mit diesen Anforderungen abgeglichen 7 3 Taxonomien f r fachliche Kompetenzen Die Taxonomie kognitiver Lernziele von Bloom 1972 ist eines der bedeutendsten Klassifizierungs systeme in diesem Bereich Bloom unterteilt Lern ziele in die Hauptklassen Wissen Verstehen An wendung Analyse Synthese und Bewertung Diese sechs Klassen gliedern sich teilweise wiederum in Unterklassen Insgesamt ergeben sich daraus 24 Klassifikationsm glichkeiten was die Einordnung von Kompetenzen erheblich erschwert F r EVE LIN soll jedoch ein Klassifikationsschema eine schnelle und einfache Zuordnung erm glichen Trotz der ko
294. n un serer eigenen einf hrenden Programmierausbil 1 Unter einfiihrend sei hier zu verstehen dass die entspre chenden Veranstaltungen in den fr hen Semestern eines Ba chelor Studiums stattfinden und zum Pflichtanteil des jeweili gen Studiengangs geh ren 37 dung in den Modulen Softwareentwicklung 1 und 2 SE1 und SE2 an der Uni Hamburg die wir seit einigen Jahren m glichst konsequent an software technischen Anforderungen ausrichten Deren Ge staltungsprinzipien sollen hier zur Diskussion ge stellt werden quasi als eine m gliche Antwort auf die Frage wie eine softwaretechnisch ausgerichtete Programmierausbildung aussehen kann Der Artikel ist folgenderma en strukturiert siehe auch Tabelle 1 In Abschnitt 2 werden Alter nativen auf Studiengangsebene diskutiert die f r die Ausrichtung ganzer Bachelor Studieng nge relevant sind In Abschnitt 3 folgen Alternativen die sich bei der Organisation einzelner Module ergeben Abschnitt 4 diskutiert gezielt einige inhalt liche Alternativen in der Programmierausbildung mit Java In allen drei Abschnitten werden jeweils bestehende und h ufig bliche Ans tze vorge stellt und dann dem von uns gew hlten gegen ber gestellt der eher softwaretechnisch motiviert ist Abschnitt 5 fasst den Artikel zusammen Alternativen 2 auf Studiengangsebene 2 1 Wahl und Reihenfolge der Paradigmen 2 2 Sprache und Programmierung 2 3 Algorithmen vs
295. nd ausgebildete Fach leute jedoch Mangelware In der Praxis sind des halb Software Ingenieure mit Kompetenzen in agi len Methoden sehr gefragt Was bedeutet dies f r die Software Technik Aus bildung an Hochschulen Was sind die speziellen Herausforderungen Wie kann agile Software Ent wicklung die neben konkreten Techniken und Praktiken auf der individuellen Ebene auch auf Team Ebene und Werte Ebene spezielle Anforde rungen stellt berhaupt vermittelt werden Wie kann die Ausbildung von agiler Softwareentwick lung in die Ingenieur Ausbildung integriert wer den In diesem Artikel stellen wir unser Konzept zur Ausbildung von agilen Methoden an Hochschulen vor und berichten ber unsere Erfahrungen als Dozierende Einleitung J ngste Umfragen zeigen dass agile Software Ent wicklungsmethoden in verschiedener Hinsicht zu wesentlichen Verbesserungen in der Durchf hrung von Software Projekten f hrt 1 2 Diese Erfolgs meldungen tragen wesentlich dazu bei dass agile Softwareentwicklungsmethoden in der IT Industrie eine immer gr ssere Akzeptanz finden In der von den Autoren durchgef hrten Studie Swiss Agile Study ber den Einsatz von Software Entwicklungsmethoden in der Schweizer IT Industrie 1 wurden diese Aussagen best tigt Die A Spillner H Lichter Hrsg SEUH 13 Studie liefert auch konkrete Zahlen ber die Ver breitung den Nutzen den Einsatz von konkreten Praktiken aber auch die Herausforderunge
296. nd momentan zu niedrig Mind 20 der Variablennamen werden nicht eindeutig abgek rzt Vorschl ge Weiteres Eingabefeld Weiteres Eingabefeld Hilfestufe Grauer Text Automatischer Text Einflusshypothese Was beeinflusst wie die Qualit tsfaktoren 1 Der Qualit tsfaktor Verzweigungstiefe wird beeinflusst durch Anwendung von Auslagerungsmechanismen Vorschl ge 2 Der Qualit tsfaktor Aussagekraft der Variablennamen wird der Entwickler Vorschl ge Abbildung 3 Ein ausgef lltes Abstraction Sheet im GQM Editor werden dynamisch anhand von vorhergegangenen Eingaben im AS generiert Auf diese Weise lassen sie eine kontextbezogene Unterst tzung zu Dies ist eine der St rken des GQM Editors von denen besonders unerfahrene Anwender profitieren k nnen Beide Un terst tzungstexte werden als vorgeschlagene Antwor teintr ge in den Quadranten eingeblendet die der Anwender nach Belieben ndern und anpassen kann F r erfahrene Benutzer k nnen die beiden Unter st tzungsmechanismen ausgeschaltet werden sodass der GQM Editor als reiner Editor fungiert Alle drei Mechanismen keine Hilfe grauer Hilfstext automa tischer Hilfstext k nnen f r jeden Quadranten indi viduell eingestellt werden siehe Dropboxen in den Quadranten Abb 3 Die Hilfstexte haben eine weitere Funktion Sie er scheinen in der Reihenfolge in der das AS ausgef
297. nd vier 10 min tigen Sprints eine Stadt aus Lego Bausteinen nach vorgegeben User Stories zu realisieren Wir f hren das Scrum Lego City Game in Gruppen von 6 bis 7 Studierenden in leicht abgewandelter Form ber mehrere Wochen durch An Stelle von teuren Lego Baus tzen wird die Stadt aus Karton und Papier mit Farbstiften Scheren und Klebstoff gebaut Das Schreiben der User Stories ist Teil der Auf gabenstellung Um zu verhindern dass die Entwickler ihre eigenen Anforderungen schrei ben bekommt der Product Owner PO eines Teams die Entwickler eines anderen Teams als Benutzer zugewiesen und definiert mit diesen die Anforderungen f r sein Team A Spillner H Lichter Hrsg SEUH 13 Auch die Priorisierung der User Stories durch den PO und das Sch tzen durch das Entwick lerteam geh ren zur Aufgabe Danach werden in insgesamt 3 4 Sprints die Aktivi t ten wie Sprint Planung Task Breakdown Sprint Review Retrospektive Arbeiten am Scrum Board in Mini Sprints von 10 Minuten Dauer durchlaufen Aufgrund der kurzen Sprints entf llt der Daily Scrum Die dabei gemachten Erfahrungen decken sich durchwegs mit jenen des XP Games Ein weiterer wichtiger Aspekt ist die Einpr gsamkeit der ver schiedenen Konzepte durch das konkrete Anwen den in dieser Spielform Entwicklung eines Computerspiels mit Scrum In einem neuen Software Engineering Modul im 5 Semester wird ein anderer Weg beschritten Die Studiere
298. nden findet man in Rieger 2012 Meist kommen Diskussionen ber die Inhalte zustande Dadurch werden die Studierenden aktiv in die Erarbeitung der L sungen eingebunden Die Lehrveranstaltung dient so nicht mehr prim r der bermittlung des Stoffes sondern dazu Stu dierende bei der Bew ltigung ihrer konkreten Schwierigkeiten mit dem Stoff zu unterst tzen Rieger 2012 Zweites Feedback der Studierenden In der Vorbereitung der Lehrveranstaltung bereiten die Lehrenden neben Antworten auf die Fragen der Studierenden zus tzlich Just in Time Aufgaben f r die Lehrveranstaltung vor die dort per Klicker oder automatischen Antwortsystemen von den Studierenden beantwortet werden Hier ist es sinn voll ein automatisches Antwortsystem zu verwen den um allen Studierenden eine individuelle nicht durch andere Studierende beeinflusste Antwort zu erm glichen Dabei k nnen nach einer ersten Ab stimmrunde zun chst mittels Peer Instruction Ma zur 1997 Simon et al 2000 die Studierenden ber ihre abgegebenen Antworten und die Gr nde da f r diskutieren und sind damit in den Lehr Lernprozess eingebunden Nach der Diskussion kann eine erneute Abstimmung stattfinden die meist wesentlich mehr korrekte Antworten auf A Spillner H Lichter Hrsg SEUH 13 weist Durch dieses direkte Feedback erkennen die Lehrenden ob die Studierenden die Konzepte aus reichend verinnerlicht haben Falls nicht kann wiederum Just i
299. nden sollen die Individuelle Team und Werte Ebenen w hrend einem Semester m glichst intensiv erfahren und verinnerlichen Die Vorle sung ist als eigentlicher Crash Kurs f r agile Software Engineering konzipiert In der ersten H lfte des Semesters liegt der Fokus auf der Individuellen Ebene Es gibt eine ausf hrli che Einf hrung in die Engineering Practices von eXtreme Programming Coding Standards Unit Testing Continuous Integration CI etc Die Stu dierenden werden mit dem automatischen Build Process bekannt gemacht und nach der H lfte des Semesters haben sie bereits einen kompletten CI Server in Betrieb genommen In der zweiten H lfte liegt der Fokus auf der Team Ebene Die Studierenden sollen in Gruppen von sechs bis acht Mitgliedern w hrend den restlichen sieben Wochen ein eigenes 2D Computerspiel ent wickeln Dazu bekommen sie eine ausf hrliche Einf hrung in Scrum sowie in agiler Sch tzung und Planung Die Studierenden schreiben die User Stories sch t zen die Tasks und planen die Iterationen Eine Iteration dauert nur eine Woche und der Umfang ist dementsprechend klein L ngere Iterationen sind nicht zweckm ssig da das Projekt mit nur sieben Wochen extrem kurz ist Die Dozierenden nehmen bei jeder Gruppe am w chentlichen Sprint Meeting teil und unterst t zen die einzelnen Teams Es wird grosser Wert auf die Planung und Retrospektive gelegt Die Dozierenden coachen die einzelnen Teams und
300. nehmen M gge u a 2004 Melnik u Maurer 2004 In unseren eigenen Praktika haben wir dabei stets als unerl sslich angesehen weiche Faktoren mit einzubeziehen So unterst tzen wir die Teambildung durch regelm ige Reflexion und aus dr ckliche Retrospektiven um die Studierenden in die Lage zu versetzen Kommunikation Kollaboration und den Prozess als Ganzes zu verbessern Ein aktueller Trend der letzten Jahre in der agilen Softwareentwicklung ist Kanban Anderson 2010 In diesem Beitrag erl utern wir wie wir Kanban in einem universit ren Praktikum zur agilen Softwareentwick A Spillner H Lichter Hrsg SEUH 13 1 Visualize Workflow Visualisiere den Fluss der Arbeit 2 Limit Work in Progress Begrenze die Menge angefangener Arbeit 3 Measure and Manage Flow Miss und steure den Fluss 4 Make Process Policies Explicit Mache die Regeln f r den Prozess explizit 5 Use Models to Recognize Improvement Opportunities Verwende Modelle um Verbesserungsm glichkeiten zu identifizieren Tabelle 1 Die f nf Kanban Kerneigenschaften nach Anderson Anderson 2010 S 15 lung eingesetzt haben Wir berichten von unseren Erfahrungen positiv und negativ und pr sentieren anderen Lehrenden Empfehlungen aufgrund dieser Erfahrungen f r ihre Anwendung von Kanban Wir haben unseren Bericht wie folgt strukturiert Zu erst geben wir eine allgemeine Einf hrung in Kanban und berichten ber den Prakti
301. nen Ticketfluss Wenn man solche M glich keiten vorsieht sollte man diese Aufgaben auch an einem Ort in der N he des Whiteboards visualisieren Der Vorteil davon ist dass sowohl die Lehrenden als auch die Teilnehmer wissen an welchen Aufgaben die Studenten arbeiten T gliche feature celebrations nach der Mittags pause wurden genutzt um im Team kurz vorher fer tiggestellte Tickets in einer Livedemonstration zu fei ern Dies hatte den Zweck den Studenten bewusst 5Die Fragen und die Verteilung der Antworten k nnen online nachgelesen werden http sewiki iai uni bonn de _media teaching labs xp 2011b agile_lab_2011_evaluation pdf A Spillner H Lichter Hrsg SEUH 13 zu machen was sie bereits erreicht haben Nachdem die Studenten h ufig nicht in allen Phasen bei jedem Ticket involviert waren erzeugte dieses Zelebrieren h ufig auch das Gef hl dass jeder seinen Teil dazu beigetragen hat und der Code vom gesamten Team stammt Wir haben diese Treffen auch genutzt um ber die Entwicklung des Tickets selber zu reflektie ren Was lief gut und was h tte im Prozess besser laufen k nnen Das Praktikum hat drei Probleme aufgezeigt denen man sich bewusst sein sollte Erstens sollte vor einem Praktikum genug Zeit investiert werden um den Pro zess und Kanban zu besprechen und zu diskutieren Zus tzlich sollten die Studenten die M glichkeit be kommen den Prozess selber zu erleben zum Beispiel in Form eines Spieles
302. nen und Techniken schneller und deutlicher wahr genommen als beim eher sequenziell orientierten Auf bau fr herer Veranstaltungen Des Weiteren erschei nen durch die relativ kleinen Schritte von Inkrement zu Inkrement die Studierenden weniger berfordert als dies beispielsweise beim in der Vergangenheit an gewendeten Lehransatz mit Gruppenpuzzle und Ler nen durch Lehren der Fall war Dadurch dass beim iterativen Vorgehen bereits be handelte Inhalte und Wissensbereiche immer wieder aufgegriffen und inkrementell weiter ausgebaut wer den werden au erdem die Kerninhalte regelm ig wiederholt und scheinen sich so besser einzupr gen Nachteilig beim iterativ inkrementellen Lehr Lernansatz ist dass bei dieser Vorgehensweise die In formationen zu den einzelnen behandelten Themenbe reichen wie z B einzelne Diagrammtypen der UML quer ber die Lehrmaterialien verteilt sind da jedes 75 Wissens Inkr 1 Inkr 2 Inkr 3 Inkr 4 Inkr 5 Inkr 6 Inkr 7 bereich Use Case Akteur System Diagramm Use Case grenze Assoziati Business on System Use Case Use Case textuelle Normal Alternativer Beschrei Kurzbe ablauf Ablauf bung schrei Fehlerfall bung Vorbe dingung Ergebnis Aktivit ts Start Stop Schwimm Folge von Fallunter Wieder diagramm Aktion bahn Aktionen scheidung holung Kontroll Ereignis fluss Kompo Kompo Schnittstelle nenten nente diagramm Beziehung
303. nformatik Lehre Ein Erfahrungsbericht In Informatik 2004 Beitr ge der 34 Jahrestagung der GI Lecture Notes in Informatics 2004 Ono 1988 ONO T Toyota production system beyond large scale production Productivity Pr 1988 Schwaber u Beedle 2001 SCHWABER K BEEDLE M Agile software development with Scrum Bd 18 Prentice Hall 2001 A Spillner H Lichter Hrsg SEUH 13 n A lg m Session 4 nn ae zZ Zur Diskussion gestellt Muster der Softwaretechnik Lehre Valentin Dallmeier Florian Gross Clemens Hammacher Matthias H schele Konrad Jamrozik Kevin Streit Andreas Zeller Lehrstuhl f r Softwaretechnik Universit t des Saarlandes dallmeier fgross hammacher hoeschele jamrozik streit zeller cs uni saarland de 1 Wissen der Softwaretechnik Lehre organisieren Das Organisieren von Softwaretechnik Projekten ist fiir neue Dozenten stets eine Herausforderung Man muss Kunden finden Projekte definieren Tutoren schulen Anforderungen definieren Terminpl ne ma chen Regeln aufstellen und zum Schluss das Pro jektergebnis bewerten Eine ungen gende Planung und Umsetzung kann schnell das gesamte Projekt ge f hrden Daher empfiehlt es sich f r die h ufigsten Fragen und Probleme L sungen explizit aufzuschrei ben Dies k nnen zun chst immer wiederkehrende Dinge sein wie die Frage wann welche Vorlesungsin halte ben tigt werden oder wie die Begutachtung vo
304. nformatik Studieng ngen Projekte oder Praktika Die im Lau fe des Studiums erlernten Bausteine werden indi viduell bei Bedarf vertieft Insbesondere m ssen sie aber kombiniert werden um die Abh ngigkeiten und den Nutzen besser zu verstehen Dies unter st tzt die Einordnung der sp teren T tigkeit in den gesamten Entwicklungsprozess und damit auch das Verst ndnis f r das Zusammenwirken aller notwendigen Schritte in der Produktentwicklung Neben der fachlichen Weiterentwicklung wird auch im Rahmen der M glichkeiten an geeigneten Stellen an der pers nlichen Weiterentwicklung der Studierenden gearbeitet Vigenschow 2007 Im Projekt treten immer wieder schwierige Situationen wie beispielsweise Konflikte auf Es werden bei Bedarf erste L sungsans tze vermittelt und die Umsetzung in der Praxis diskutiert Au erdem wird den Studierenden das Verst ndnis Ihrer Ei genverantwortung n her gebracht Bei vielen Studierenden konnte eine gro e Weiter entwicklung der praxisrelevanten F higkeiten beo bachtet werden sicherlich unterst tzt durch die gro e Freude an der Projektarbeit Nicht zuletzt wird das zeitaufw ndige Projekt immer wieder durchgef hrt weil die Wissensvermittlung sehr viel Spa macht Konzept und Erfahrungen In diesem Kapitel werden die im Projekt verwende ten didaktischen Konzepte vorgestellt Mehrere Punkte entsprechen den Rahmenbedingungen aus Kleuker 2011 Praxisn he Ein wesentlicher Aspekt
305. nicht einfach in den Unterricht zu integrieren Die meisten Management Practices k nnen nur sinnvoll in einem gr sseren Team im Rahmen eines richtigen Projekts sinn voll ge bt werden Oft ist es aber nicht zweckm s sig oder aus zeitlichen Gr nden unm glich ein solches Projekt durchzuf hren In diesem Fall kann die Situation mit einem der agilen Games wie zum Beispiel dem XP Game 14 oder Scrum City Game 15 simuliert werden Scrum Als agile Projektmethode verwenden wir Scrum Die verschiedenen Studien zeigen dass Scrum am weitesten verbreitet ist Scrum bietet auch den Vor teil dass die Anzahl der roles events und artifacts klein ist Wir haben die Erfahrung gemacht dass die Funkti onsweise von Scrum schnell im Unterricht erkl rt werden kann Der schwierige Teil kommt bei der Einf hrung Wenn die Studierenden Scrum oder eine andere Projektmethode wirklich anwenden sollen Wie kann im Unterricht ein Klima geschaf fen werden so dass die Studierenden sich wie in einem echten Projekt f hlen Wenn sie das Ge f hl haben dass es sich um ein Alibi Projekt handelt setzten sie sich nicht ein und profitieren entsprechend wenig XP Game Das XP Game 14 simuliert ein agiles Projekt In drei bis vier Stunden werden drei Iterationen mit Sch tzen der Tasks Planung der Iterationen Im 86 plementation und Abnahme der Tasks sowie einer Retrospektive nach jeder Iteration durchgespielt Die Planung
306. nig Bezug zur Anwen dungsrealitat Software Engineering ist gekennzeichnet durch ein sehr komplexes Praxisfeld sowie eine Vielzahl zu trainierender Kompetenzen die zudem von der jeweiligen Rolle abh ngen die ein Software Ingeni eur einnimmt Damit ist der Wissenstransfer von der Theorie auf die praktische Anwendung im Software Engineering eine besondere Herausforde rung Lernen von Software Engineering muss also auf den sehr komplexen Anwendungskontext aus gerichtet sein und wird von zahlreichen Faktoren beeinflusst Um Anhaltspunkte f r Ausgangshypo thesen und einen m glichst umfassenden Blick auf diese Einflussfaktoren zu erhalten ist es sinnvoll diese Faktoren auf einer detaillierteren Ebene sys tematisch zu analysieren 6 1 berblick ber das konkrete Vorgehen Wird vor diesem Hintergrund die Grounded Theo ry auf das Lernen von Software Engineering ange wandt ergibt sich folgendes konkretes Vorgehen Die Kompetenzbeschreibungen erm glichen einen Vergleich von tats chlich zu verschiedenen Zeit punkten bei verschiedenen Studierendengruppen erhobenen Ist mit den zu erreichenden Soll Kompetenzen Auf Grundlage dieser Ergebnisse werden Hypothesen zu den Einflussfaktoren auf das Lernen von Software Engineering gebildet und berpr ft Konkret bedeutet dies dass zun chst sowohl die Soll Kompetenzen als auch die Ist Kom petenzen Studierender erhoben werden Dann werden gezielt Einflussvariablen auf den Lernprozess mo
307. ning 66 User stories 65 Daily standup 53 Taskboard 46 Retrospective 41 Burndown charts 40 Story mapping 35 Open work area 27 On site customer 23 Kanban Pull System Limited WIP 11 Tabelle 5 Management Practices in der Praxis Die Werte zeigen deutlich dass auch bei agil ent wickelnden Unternehmen erst relativ wenige der erforderlichen bzw empfohlenen Praktiken eine breite Anwendung finden Studienkonzept fur agile Methoden Die Eigenschaften bzw Anforderungen an eine agile Software Entwicklung lassen sich nicht alle auf die gleiche Art unterrichten da sie unterschied liche Kompetenzen ansprechen Fur die Entwick lung eines geeigneten Studienkonzeptes orientieren wir uns daher an den zuvor eingef hrten drei Kompetenzebenen Den Firmen die agile Methoden anwenden wurde folgende Frage gestellt Which of the following engi neering practices could be observed by someone visiting your company in the next month 5 Den Firmen die agile Methoden anwenden wurde folgende Frage gestellt Which of the following man agement and planning practices could be observed by someone visiting your company in the next month A Spillner H Lichter Hrsg SEUH 13 Die drei Vermittlungsebenen Auf der individuellen Ebene werden insbesondere die handwerklichen Grundlagen vermittelt Ohne das Beherrschen dieser fundamentalen Techniken ist eine agile Entwicklung aus unserer Sicht nicht m glich Aus
308. ninhalte eines Softwareprozesses in die Simulations und Spiel welt zu integrieren So bietet der EPF Composer die M glichkeit den dokumentierten Prozess in ein HTML Format zu exportieren welches dann lokal oder auf einem Webserver ver ffentlicht ohne weitere Werkzeuge mit einem Webbrowser erkun det werden kann A Spillner H Lichter Hrsg SEUH 13 Nach vorheriger Aufbereitung der exportierten Softwareprozessbeschreibung ist es somit m glich diese f r die Erkundung im Stile eines Adventures zu verwenden Adventures sind ein Spiele Genre in welchem Spieler aktiv ihre Spielwelt erkunden und dabei typischerweise Gegenst nde und Informatio nen sammeln welche sie im weiteren Spielverlauf anwenden und kombinieren um gestellte R tsel und Aufgaben zu l sen bertragen auf ein digita les Lernspiel in der SE Ausbildung bedeutet dies dass ein Spieler die Prozessbeschreibung erkundet und dabei Informationen und Werkzeuge sammelt welche anschlie end im Spiel verwendet werden k nnen Eine bestimmte Aufgabe mit einem spezi fischen Werkzeug kann erst dann an eine simulier te Software Entwicklerin bertragen werden wenn zuvor die zugeh rige Dokumentation der Aufgabe in der Prozessbeschreibung besucht und das ent sprechende Werkzeug eingesammelt wurde Da die Spielumgebung die Erkundungsaktivi t ten der Spieler verfolgt erhalten auch Lehrende einen berblick dar ber wie aktiv Einzelspieler Teams und der gesamte
309. nn also gleichzeitig in zwei benachbarte Klassen eingeordnet werden Dadurch fehlt es dem Modell in beiden Dimensionen an der n tigen Trennsch rfe um eine m glichst eindeutige und zielf hrende Klassifizierung durchzuf hren Cla ren 2012 Granzer et al 2008 Fuller et al 2007 untersuchten verschiedene Taxonomien zur Beschreibung von Kompetenzen im Bereich der Informatik darunter auch die Taxo nomien nach Bloom sowie nach Anderson und Krathwohl Ihre Erkenntnisse decken sich weitge hend mit denen der Untersuchung im Rahmen von EVELIN Darunter f llt etwa die problematische Einordnung in h here Klassen die Fragw rdigkeit der hierarchischen Ordnung bei Bloom sowie die zu hohe Komplexit t des zweidimensionalen Mo dells von Anderson Fuller et al 2007 Die Auto ren schlagen die sogenannte Matrix Taxonomie A Spillner H Lichter Hrsg SEUH 13 siehe Abbildung 2 vor die auf der Taxonomie von Anderson basiert PRODUCING INTERPRETING Abb 2 Matrix Taxonomie Fuller et al 2007 Die Dimension INTERPRETING umfasst alle Aus pr gungen einer Kompetenz die sich auf Interpre tieren und Verstehen beziehen Die PRODUCING Ebene dagegen repr sentiert die F higkeiten die n tig sind um neue Produkte zu entwerfen und entwickeln Dadurch lassen sich die theoretischen INTERPRETING und praktischen PRODUCING Aspekte einer Kompetenz beschreiben Zun chst wird ein Zielfeld f r eine Kompetenz festgelegt
310. nsam gef hrt Wenn m glich erkl ren die Studierenden die Sach verhalte oder sie werden zumindest angehalten zur Diskussion beizutragen Am Ende der Diskus sion wird durch R ckfragen gekl rt ob die Inhalte verstanden worden sind Die Dauer der Diskussionen richtet sich nach dem Inhalt von wenigen Minuten bis zu einer Stunde Nat rlich k nnen manche Themen nicht ersch p fend er rtert werden aber das Verst ndnis oder Problembewusstsein kann deutlich erh ht werden Auch nicht technische Aspekte werden bei Bedarf aufgegriffen Wenn beispielsweise bei der Pr senta tion von Ergebnissen Aspekte verbessert werden k nnen werden nach R cksprache mit den Vortra genden diese Themen in den Veranstaltungen an gesprochen Dies k nnen zum Beispiel Hinweise zur Gestaltung der pr sentierten Unterlagen oder verwendeten Tools sein Aber auch Tipps zur Ver besserung der Pr sentationsf higkeiten zum Bei spiel der Rhetorik werden gegeben Oft gehen mehrere Personen eines Teams gemein sam vor die Gruppe um Ihre Ergebnisse vorzustel len Jede Person wei genau welchen Teil sie vor stellen wird jedoch ist nicht klar wer eine kurze Einf hrung gibt oder wer beginnt Das wird vor der Gruppe besprochen Dieses h ufiger beobachte te Ph nomen wird abgestellt nachdem die Studie renden darauf hingewiesen werden Dadurch wer den zuk nftige Vortr ge sei es an der Hochschule oder in Unternehmen professioneller Organisa
311. nstatt lediglich auf die Klausuren zu lernen lesen die Studierenden regelm ig im Lehr buch Aus der Heterogenit t der studentischen Vorer fahrungen wird das im Selbststudium Gelesene unterschiedlich verwertet In der gemeinsamen Er rterung entwickelt sich diese Vielfalt zu ei nem weiteren aktivierenden sowie belebenden Element und unterst tzt die Motivation der Mitarbeit Die individuelle Beantwortung der Fragen der Studierenden durch die Lehrenden kommt ei ner individuellen Betreuung der Studierenden nahe Die Studierenden erhalten jeweils die In formation die sie gerade ben tigen Die Studierenden erkennen dass sie nicht allei ne mit ihren Fragen und Problemen zum Lehr stoff sind Die Studierenden besuchen gerne die Lehrver anstaltung weil sie dort ihre pers nlichen Fra gen beantwortet bekommen Durch die Erstvermittlung des Lehrstoffes durch die Studierenden bereiten diese sich auf den lebenslangen Lernprozess vor Die Studierenden k nnen die Zeit des Selbst studiums auf Zeiten legen an denen sie am aufnahmef higsten sind Die Studierenden ben sich im Schreiben fach licher Texte durch die schriftliche Beantwor tung der Fragen im online Teil Teamarbeit wie in Unternehmen wird in der bung am realen Beispiel situativ ge bt und steigert neben den bereits erw hnten Kompe tenzen auch die Innovationskraft da Menschen miteinander aus unterschiedlichen Perspekti ven ein The
312. nterfaces in Java die blicherweise ebenfalls sp t thematisiert werden Ein weiteres Argument f r eine sp te Be handlung k nnte sein dass das JCF umfangreichen Gebrauch von Generizit t macht die ebenfalls eher sp t thematisiert werden kann Alternative Das JCF wird deutlich vor den Arrays in Java thematisiert Arrays werden prim r als speichernahe Realisierungsunterst tzung f r m chtigere Sammlungskonzepte dargestellt Die Sammlungsarten des JCF u a Set List und Map sind auf einem h heren Abstraktionsniveau angesiedelt als die f r viele Probleme zu spei chernah konzipierten Arrays Somit sind sie f r viele Aufgabenstellungen die deutlich bessere Wahl und erm glichen elegantere L sungen Ent sprechend sollten sie als n tzliche Hilfsmittel so prominent in ihrer typischen Nutzung vermittelt werden dass die Studierenden instinktiv m glichst zuerst zu diesen Sammlungen greifen Diskutiert wird dieser Ansatz unter anderem von Ventura et al in Ventura et al 2004 Koenig und Moo argu mentieren in Koenig and Moo 2000 ganz analog f r eine Behandlung der STL deutlich vor den Ar rays von C Wir haben in einer anderen einf h renden Programmierveranstaltung mit C eben falls gute Erfahrungen mit diesem Ansatz gemacht Konsequenzen Eine m gliche Konsequenz f r eine Java Veranstaltung k nnte sein Generizit t noch vor dem JCF behandeln zu m ssen siehe obige Anmerkung Generizit t ist vereinfacht ge
313. ntwi ckelt wurde Der Artikel ist wie folgt gegliedert Abschnitt 2 f hrt JiTT allgemein ein und erl utert den Hintergrund dieser Lehrmethode Abschnitt 3 beschreibt unsere konkrete Umsetzung im Rah men der Software Engineering Veranstaltung Die dabei gemachten Erfahrungen werden in Ab schnitt 4 besprochen bevor der Artikel mit unse ren Schlussfolgerungen in Abschnitt 5 endet Just in Time Teaching Just in Time Teaching ist eine Lehr Lern Strategie deren Kern eine spezielle Kombination von Pr senzlehre und online gest tztem Selbst studium ist grundlegend zu JiTT Novak u a 1999 Das besondere Merkmal von JiTT ist es dass den Studierenden stets noch vor Beginn einer Lehrveranstaltung Studienmaterial online zur Verf gung gestellt wird Dies k nnen Einstiegs fragen in ein neues Themengebiet sein die bei der Einsch tzung helfen welche Vorstellungen und welches Wissen die Studierenden in diesem Be reich bereits haben Es k nnen aber auch an spruchsvollere Aufgaben sein die bereits ein kor rektes Grundverst ndnis erfordern aber weiter gehende Schwierigkeiten aufzeigen Erg nzend k nnen f r die Studierenden offene Fragen ange f gt werden in denen sie Unklarheiten oder Probleme formulieren die sich bei der Bearbei tung ergeben haben Die Aufgaben deren Umfang gering gehal ten wird bearbeiten die Studierenden vor Be ginn der zugeh rigen Pr senzveranstaltung Ihre Antworten bermitteln si
314. nutzt die Webseite CSS und HTML zur Forma tierung der Inhalte siehe Abbildung 5 Sharelt General Welcome Willkommen bei Sharelt der Plattform f r die gemeinschaftliche Nutzung von Ressourcen Abbildung 5 Startseite mit variablem Titel Ein erster Button ist das zentrale neue Element der n chsten Ausbaustufe Abbildung 6 F r dessen Umsetzung wird die Verwendung eines Formulars und eine Listener Methode eingef hrt sowie auf eine Antwortseite weitergeleitet Abbildung 7 Die Modellebene wird erg nzt um ein einfaches Sequenzdiagramm welches das Zusammenspiel der beteiligten Klassen veranschaulicht Des Wei teren wird das Aktivit tsdiagramm erweitert zu einem noch recht einfachen Ablauf bei dem Be nutzer und System in mehreren Schritten mitein ander interagieren Darauf aufbauend umfasst das n chste Inkrement ein Textfeld in das der Benutzer seinen Namen eingeben kann Abbildung 8 Nach Absenden A Spillner H Lichter Hrsg SEUH 13 Sharelt Who are you Willkommen bei Sharelt der Plattform f r die gemeinschaftliche Nutzung von Ressourcen Weiter Abbildung 6 Startseite mit Button Sharelt Anonymous Welcome Hallo Unbekannte r Abbildung 7 Statische Antwortseite der Anfrage ber den Button erscheint eine per sonalisierte Begr ungsseite Abbildung 9 F r deren Umsetzung wurde der eingegebene Daten wert in der Session abgelegt und zum Generieren der Antwortseite wieder ausgelesen
315. oll sein die entstandenen Kompetenzprofile f r die verschiedenen Bereiche wie Kerninformatik oder Mechatronik miteinander zu vergleichen A Spillner H Lichter Hrsg SEUH 13 Besonders f r berfachliche Kompetenzen gilt es ein Beschreibungsschema zu entwickeln das nahezu die gleichen Anforderungen erf llt wie das f r fachliche Kompetenzen Dieses Modell entsteht parallel zur Analyse der vorhandenen Interviewda ten mit Fokus auf berfachlichen Kompetenzen Dabei sollen berfachliche Kompetenzen sowohl strukturiert als auch definiert werden Es gilt die Frage zu beantworten was im Kontext von Soft ware Engineering etwa unter Team oder Kommu nikationsf higkeit verstanden wird Eine weitere interessante Fragestellung ist ob berhaupt und ggf welche Korrelationen zwischen fachlichen und berfachlichen Kompetenzen auftreten Werden einzelne berfachliche Kompetenzen besonders h ufig im Zusammenhang mit einer oder mehreren bestimmten fachlichen Kompetenzen genannt F r beide Schemata und ihren Inhalt gilt derselbe itera tive Prozess in dem die Daten auch w hrend des gesamten Forschungsprojektes EVELIN immer wieder berpr ft und weiterentwickelt werden Gem Grounded Theory flie en st ndig neue Erkenntnisse und Aspekte ein so dass ein m g lichst umfassendes Bild zum Lehren und Lernen von Software Engineering entstehen kann Parallel dazu findet eine weitere didaktische und inhaltliche Analyse der aktuellen L
316. ollziehbar sind Dies gilt insbe sondere wenn mehrere Pr fer in den Bewertungs prozess involviert sein sollten Basierend auf der recht hohen Zahl von ca 20 Einzelbewertungen hat es sich als ausreichend erwiesen nur die zuvor genannten vier Bewertungsstufen zu verwenden Bei deren Verwendung ergeben sich f r obiges Raster mit seinen 45 Gewichtungsfaktoren maximal 135 erreichbare Punkte die mit Hilfe g ngiger teilweise sogar in Pr fungsordnungen festgeleg ten Prozentskalen problemlos in entsprechende Noten umgerechnet werden k nnen Ein berechtigter Einwand gegen das vorgeschlage ne Bewertungsraster ist sicher sein hoher Detaillie rungsgrad der den Studierenden deutliche Hin weise auf die verlangte L sung liefern kann also z B welche Modelle werden erwartet Sofern die sinnvolle Wahl von Modellen d h das Tailoring der Vorgehensweise und die Auswahl der erstell ten Artefakte ein Lernziel der Veranstaltung dar A Spillner H Lichter Hrsg SEUH 13 stellt ist das Bewertungssystem in seiner vorge stellten Form sicherlich nicht anwendbar Zu die sem Einwand gibt es allerdings zwei wichtige Er widerungen zum einen die Feststellung dass An f nger im Software Engineering die erstmals an einer entsprechenden Veranstaltung teilnehmen h ufig noch genug mit dem Erlernen und Einsetzen der vorgestellten Notationen und Techniken gefor dert sind und entsprechend mit deren Auswahl noch weit berfordert w ren
317. p und Christian Kautz Technische Universit t Hamburg Harburg timo kamph peter salden schupp kautz tuhh de Zusammenfassung Ein verbreitetes Problem beim Unterrichten von Software Engineering ist dass den Studierenden die Erfahrung mit gro en realen Softwaresyste men fehlt Dadurch wird die Sinnhaftigkeit der vorgestellten Methoden nicht ausreichend er kannt Wir versuchen die fehlende Erfahrung zu simulieren und haben dazu die Methode des Just in Time Teaching JiTT in Form von Quiz einge f hrt Die Studierenden die an den Quiz teilge nommen haben konnten die Methoden des Soft ware Engineerings am Ende des Semesters besser einordnen Die Einf hrung dieser JiTT Variante ist mit einem nicht zu untersch tzenden Aufwand verbunden der sich aus unserer und der Sicht der Studierenden aber lohnt Einleitung An der Technischen Universit t Hamburg Harburg TUHH ist die Veranstaltung Software Engineering eine Pflichtvorlesung in zwei Bache lorprogrammen und eine Wahlpflichtveranstal tung in vier weiteren Studienprogrammen Die Vorlesung wird von ca 70 Studierenden im zwei ten oder vierten Semester besucht Die Vorkennt nisse und Erfahrungen der meisten Studierenden beschr nken sich im Bereich Softwareentwicklung auf das Bearbeiten kleiner bungsaufgaben in zwei oder drei einf hrenden Programmierkursen Prozedurale Programmierung Funktionale Pro grammierung Objektorientierte Programmie rung Den Studierend
318. piele zu nennen 2 Team Ebene Die Team Ebene stellt vor al lem Anforderungen im Bereich Manage ment Practices Selbstorganisierende Teams Sch tzen und Planen Continuous Integra tion und Continuous Deployment oder Pair Programming Selbstorganisierende Teams wiederum verlangen eine hohe so ziale Kompetenz der Teammitglieder wie zum Beispiel hohe Kommunikationsf hig keit 3 Werte Ebene Auf dieser Ebene wird implizit das Wertesystem der agilen Softwareent wicklung betrachtet wie die agilen Werte wie Respekt Offenheit Ehrlichkeit etc A Spillner H Lichter Hrsg SEUH 13 vermittelt werden k nnen so dass die Ab solventen in der Wolle gef rbte Software Ingenieure sind Bei der Vermittlung der Anforderungen beziehen wir uns schwerpunktm ssig auf Scrum 7 und eXtreme Programming XP 8 da diese in der Schweiz und auch international 2 die am weites ten verbreiteten agilen Methoden sind Ausserdem erg nzen sich diese Methoden aus unserer Sicht sehr gut da XP eher den Schwerpunkt auf die En gineering Practices legt w hrend Scrum eher auf der Management Ebene anzusiedeln ist Erfahrungen mit agiler Entwicklung im Un terricht Zum Thema der Integration von agilen Methoden in den Unterricht liegen verschiedene Erfahrungs berichte vor 20 21 Die Autoren selbst unterrich ten seit ber f nf Jahren zusammen die Vorlesung Software Engineering and Architecture Diese Vorle sung ist Teil der
319. punkt Shttp www youtube com watch v 0iPalefQbgM A Spillner H Lichter Hrsg SEUH 13 im System befinden und welchen Zustand diese ha ben Dabei z hlen fertig bearbeitete Tickets zu der Live Phase Eine breite Phase in dem Diagramm kann entweder bedeuteten dass ein Ticket lange in dieser Phase bearbeitet wird oder dass die n chste Phase nicht verf gbar ist und die Tickets nicht weiterbear beitet werden k nnen Dieses Diagramm wurde im Praktikumsraum neben dem Board aufgehangen und diente als Visualisierung des Fortschritts in t glichen Stand Up Besprechungen mit dem Team In Kanban Prozessen findet man h ufiger speziali sierte Entwicklerrollen z B Architekten oder Tester die in speziellen Phasen arbeiten In unseren Prak tika legen wir Wert darauf dass die Studenten alle Entwicklungsphasen erfahren so dass wir keine spe zialisierten Rollen genutzt haben Als Konsequenz dar aus waren die Studenten frei in der Wahl in welchem Entwicklungsschritt sie arbeiten m chten solange die Kanban Limits ber cksichtigt wurden Allerdings gab es Priorisierungen von zu bearbeitenden Tickets im System Initial war die einzige Regelung dass Tickets in sp teren Phasen bevorzugt weiterbearbeitet werden sollten damit der Kunde z giger fertige Features be kommt Auch wenn diese Regel bereits dem Toyota Production System entstammt war sie f r uns beson ders plausibel da in fr heren Praktika wie oben erw hnt die Inte
320. r 54 Maus reagieren und mit false antworten da er nicht verschoben aber informiert werden will Generell wurde das Interaktionsbrett von Studie renden in Praktika sehr positiv aufgenommen da man sehr einfach zeichnen kann Das Ein ben der Maussteuerung ist dabei deutlich komplizierter und geh rt in den zweiten Teil der Lehrveranstal tung Aktuell wird diskutiert ob die absichtlich gew hlte minimale Darstellung von ausschlie lich schwarzen Linien und der Verzicht auf einen Hin tergrund durch sinnvolle Erweiterungen erg nzt werden sollen Die Weiterentwicklung findet dabei durch Studierende statt die weitere Beispiele er stellen Processing Processing Pro wurde als Sprache und Entwick lungsumgebung entwickelt um kreativen Leuten einen sehr einfachen Zugang zu den Themen Visu alisierung interaktive Animation und Simulation zu erm glichen Die zugeh rigen Arbeiten wurden am Massachusetts Institute of Technology von Ben Fry und Casey Reas gestartet Mittlerweile gibt es im Internet eine gro e Unterst tzung des Ansatzes mit vielen Tutorials und quelloffenen Beispielen Processing wird in vielen Design Studieng ngen u a auch im Media and Interaction Design Studiengang an der Hochschule Osnabr ck f r kleinere und gr ere Projekte eingesetzt E Zeichnen Processing 2 0b6 File Edit Sketch Tools Help 00 ngng Zeichnen int breite 300 a int hoehe 200 public void setup
321. r Aufwand f r die Lehrveranstaltung f r die Studierenden in einer vergleichbaren Gr enord nung wie bei der klassischen Vorlesung mit Ubun gen Die Kundin hat den Studierenden in typischer Kundenpraxis die Anforderungen f r das Bewer bermanagementsystem vorgetragen Die Lehr Lerngemeinschaft versuchte gemeinsam mit Hilfe der verschiedenen erlernten Requirements Engine ering Techniken die Anforderungen des Kunden systems zu erheben Dabei erkannten die Studie renden von Woche zu Woche wie sie tiefer und tiefer ins Requirements Engineering eintauchten und die gefundenen sowie dokumentierten Anfor derungen immer genauer und aussagekr ftiger wurden F r die Lehrenden ergab sich so sehr sch n eine dritte Feedback Schleife da wir sahen wie die Stu dierenden im Liveprojekt das Gelernte angewendet haben und Dialogf higkeit sowie Kundenorientie rung sichtbar wurde Alle drei Feedback Zyklen gingen in die Vorbe reitung der Lehrveranstaltung der kommenden Woche wieder ein In dieser Reflexion des Kun dentermins fand sowohl der Austausch ber krea tive beobachtende und befragende Techniken des 21 Requirements Engineering Rupp 2009 statt als auch eine f r die Studierenden berraschende und rege Auseinandersetzung ber Kommunikations stil und Konfliktmanagement sowie ber strategi sche Vertragsverhandlung Eine Skizze der Schritte unseres Vorgehens haben wir in Abb 3 dargestellt
322. r Studierenden erhalten bzw die Studierenden eine R ckmeldung zu ih rem Lernstand Auf diesem Weg soll die Stoff vermittlung effizienter werden Interesse und Ak tivit t der Studierenden sollen steigen Didaktischer Hintergrund Betrachtet man JiTT in einem allgemeindidakti schen Kontext so liegt sein Charme jenseits des Beitrags zu einer effizienten Lehrgestaltung zu n chst in der Aktivierung der Studierenden zum selbstst ndigen Lernen denn dass die studenti sche Eigenaktivit t m glichst fr h im Lehr Lernprozess geweckt werden sollte wird inzwi schen gemeinhin als Voraussetzung f r erfolgrei ches Lernen aufgefasst Novak u a 1999 9 Indem JiTT die Studierenden den Einstieg in 10 ein Thema selbst vollziehen l sst nimmt es dabei auch die grundlegende Idee des didaktischen Konstruktivismus auf dass jedes Individuum sei ne Wirklichkeit selbst erzeugt Siebert 1997 17 F r das Lernen bedeutet dies Ein bestimmtes Verst ndnis l sst sich nicht standardisiert vermit teln sondern Lernende m ssen ihren eigenen Zu gang zu einem Thema finden und zus tzliche In formationen in ihr eigenes Wissenskonstrukt wiederum individuell integrieren An den Hochschulen hatte dieser Ansatz die Proklamation eines shift from teaching to lear ning zur Folge Sein Ausdruck ist im Zuge des Bologna Prozesses u a die Berechnung des stu dentischen Arbeitsaufwands workload die f r einzelne Veranstaltungen unabh ng
323. r konkret die Erstel lung des Abstraction Sheets und die Entwicklung von zugeh rigen Metriken unterst tzt Der Anwender wird mit prozess gesteuerten Fragestellungen zum korrek ten Ausf llen beider Formulare angeregt Unerfahrene Anwender k nnen den vollen Unterst tzungsumfang des smarten Editors aussch pfen und so an die GQM Methode herangef hrt werden Erfahrene Benutzer k nnen den Editor verwenden um Abstraction Sheets Questions und Metriken zu erstellen und zu verwal ten Motivation Ein Fallstrick beim Messen von Software Entwicklungs prozessen oder Produkten ist dass man das misst was einfach zu messen ist und nicht das was man mes sen sollte um aussagekr ftige Ergebnisse zu erhalten Basili 1992 Man wendet sich an bereits bekannte oder einfach zu erhebende Metriken Hier verwendet die GQM Methode einen Top Down Ansatz Anstatt mittels vorhandener Werkzeuge z B bekannte Me triken projekt individuelle Ziele zu messen Bottom Up werden diese Ziele konkretisiert und durch ei gens entwickelte Metriken operationalisiert Dies soll gew hrleisten dass tats chlich gemessen wird was auch gemessen werden soll und auch nicht mehr Grundlegende Ideen zu GQM entstanden w hrend einer Untersuchung am Goddard Space Flight Center Basili u Weiss 1984 Sp ter stellt Basili 1992 das GQM Paradigma vor und Van Latum u a 1998 er weitern die GQM Methode um sogenannte Abstraction Sheets Seit seiner Einf hrun
324. rade von ihm verlangt wird Zum anderen muss er die Eintr ge manuell in den n chs ten Schritt bertragen und dort weiterverarbeiten An diesen Stellen setzt unser GQM Editor an Der An wender wird bei einem kreativen Vorgang durch eine gezielte Fragestellung als dezenter Hinweistext un terst tzt Grauer Hilfstext Weiterhin bernimmt der GQM Editor manuelle Schritte bertr gt Zwischen ergebnisse in Folge Quadranten und versucht damit die n chsten Eintr ge teilweise zu generieren Auto matischer Hilfstext Beide Unterst tzungsvarianten 143 Verst ndlichkeit Hilfestufe Grauer Text Qualit tsfaktoren Welche Faktoren definieren den Qualit tsaspekt 1 Verzweigungstiefe Vorschl ge 2 Aussagekraft der Variablennamen f Vorschl ge Weiteres Eingabefeld Einflussfaktoren Hilfestufe Grauer Text Was hat Einfluss auf die Qualit tsfaktoren 1 Auslagerung von Funktionen Vorschl ge 2 Welcher Faktor hat laut der aufgestellten Einflusshypothese Einfluss auf die den Aussagekraft der Variablennamen Vorschl ge Weiteres Eingabefeld Ausgangshypothesen Hilfestufe Grauer Text Automatischer Text Momentane Erwartung ber die Qualit tsfaktoren 1 Verzweigungstiefe is sind momentan zu hoch Momentan betr gt Verzweigungstiefe ber 15 McCabe Wert pro Klasse Vorschl ge 2 Aussagekraft der Variablennamen ist si
325. ren Eigenschaf ten was nat rlich nicht hei t dass man die Hypothesen nicht so gut wie m glich verifizie ren sollte Hypothesen zu generieren hei t sie im empirischen Material zu verankern nicht genug Material anzuh ufen um einen Beweis f hren zu k nnen Grounded Theory fordert eine parallele Daten erhebung und analyse und zwar vom Beginn der Forschung an bis zur ihrem Ende Theoretisches Sampling meint dass die Stich probe sich w hrend des gesamten Forschungs prozesses weiter entwickelt so dass bis zum Ende keine endg ltigen Aussagen ber die er hobenen und einbezogenen Daten getroffen werden k nnen Die entstehende Theorie steu ert wann im Forschungsprozess welche Daten wo erhoben werden Grunds tzlich gilt ein Mix qualitativer und quantitativer Forschungsmethoden als zielf h rend Daraus resultiert permanente Offenheit f r neue Aspekte die jederzeit in den Forschungsprozess aufgenommen werden 6 Methodisches Vorgehen Das Vorgehen der Grounded Theory korrespon diert gut mit dem Anspruch einer angewandten Forschung da hier sowohl die Forschungsmetho dik als auch die Anwendungsorientierung von zu erhebenden Daten ausgehen und diese strukturie ren Zudem soll kein vorgefertigtes Bild verifiziert werden das es f r das Lernen von Software Engi neering ohnehin noch nicht gibt Ein solches Mo dell k nnte nur auf theoretischer Basis entwickelt 119 werden h tte dann aber we
326. ren Rechnerpools zur Verf gung stehen Da es sich bei Kolloquien im Wesentlichen um Pr sentationen und Pr fungsgespr che handelt ist die Bewertung naturgem zu einem gewissen Grad subjektiv s z B M ller amp Bayer 2007 Ferner er fassen Kolloquien nicht notwendigerweise die tat s chliche Leistungsf higkeit eines Pr flings und noch weniger garantieren sie seine F higkeiten in der Softwareentwicklung zu messen da auch Pr sentations und Gespr chskompetenz eine nicht zu untersch tzende Rolle spielen Der praktische Nut zen ist nichtsdestotrotz f r beide Parteien hoch da sich alle Beteiligten einen Eindruck ber den Wis sensstand und das Verst ndnis eines Studierenden machen und im Zweifelsfall direkt nachfragen k nnen F r kleine Gruppen sind solche Gespr che auch ein durchaus konomisches Pr fungsverfah ren sobald allerdings viele Studierende gepr ft werden m ssen steigt die Belastung f r den Pr fer sehr stark an Das vorgestellte Raster zur Systembewertung er m glicht eine hohe Objektivit t zumindest dann wenn wie oben beschrieben nicht die volle No tenskala zur Bewertung der Teilleistungen ver wendet wird Die Unterscheidung zwischen bei spielsweise einer 1 7 und einer 2 0 f r ein Klassen diagramm ist nach Erfahrung des Autors objektiv oft nicht mehr m glich Mit der vereinfachten vier stufigen Benotungsvariante hingegen ist das Ver fahren sehr zuverl ssig und valide da es wie
327. renden zu einer deutlich realistischeren Einsch tzung des eigenen Leistungsstandes gef hrt hat Das war teilweise sehr heilsam hat aber bei einigen auch zu nicht unerheblichem Frust gef hrt Zusammenfassung und Ausblick Der hier vorgestellte iterativ inkrementelle Lehr Lernansatz f r Wissensbereiche und Kompetenzen des Software Engineerings stellt eine M glichkeit dar die umfangreichen und stark miteinander verzahnten Themengebiete so aufzuschl sseln dass die einzelnen Lehr Lerneinheiten einerseits nicht berfrachtet sind und andererseits die Zusammenh nge zwischen den Wissensbereichen fr hzeitig deutlich erkennbar und f r die Studierenden auch selbst praktisch nachvoll ziehbar werden Erste Erfahrungen aus der Umsetzung des Ansatzes verlaufen bisher vielversprechend Aktuell werden der Lehransatz und die ben tigten Materialien kontinu ierlich erweitert und ausgebaut Eine Messung des Lernerfolges ber Pr fungsleistungen steht derzeit noch aus Interessant ist des Weiteren auch die Frage ob der systemimmanente hohe Wiederholunganteil des iterativ inkrementellen Lehr Lernansatzes auch die Nachhaltigkeit des Gelernten positiv beeinflusst Um hier eine Aussage treffen zu k nnen ist jedoch eine Langzeitstudie mit entsprechenden Vergleichsgruppen erforderlich Literatur Abran u a 2005 ABRAN A MOORE J DUPUIS R TRIPP L Guide to the Software Engineering Body of Knowledge 2004 Version SWEBOK IEEE Comp
328. reprojekte vorangetrieben oder gar als Prak tikant Industrieerfahrung gesammelt haben F r diese ist ein solches Projekt nicht selten einer der H hepunkte ihres Studiums den sie mit gro er Motivation und Begeisterung angehen und oft mit beeindruckenden Leistungen abschlie en gerade wenn die Aufgabenstellung eventuell in Koopera tion mit einem Industriepartner erfolgt ist Zum anderen gibt es aber gerade in interdisziplin ren Studieng ngen wie der Wirtschaftsinformatik auch viele Studierende die Softwareentwicklung und insbesondere Programmieren nur als notwen diges bel ansehen und daher entsprechende Pro jekte nur als eine mit einem hohem Zeitaufwand verbundene Pflicht bung betrachten Dies f hrt in der Lehrpraxis h ufig dazu dass stu dentische Teams sehr unterschiedliche Leistungs niveaus aufweisen und schw chere Studierende sich sehr leicht abgeh ngt f hlen w hrend die st rkeren diese vor allem als Belastung wahrneh men vgl auch die Erfahrungen von Lindig amp Zel ler 2005 Somit berrascht es nicht wenn in sol chen Veranstaltungen h ufig auf das Ph nomen von Trittbrettfahrern zu treffen ist die sich ohne nennenswerte eigene Beitr ge von ihren Kommili tonen durch die Veranstaltung schleppen lassen wollen vgl Stoyan amp Glinz 2005 van der Duim et al 2007 oder Stangl 2002 Die Leistungstr ger erdulden das aus falsch verstandener Solidarit t heraus h ufig zumindest so lan
329. rer selten Dann kann der selten genannte Aspekt in der Vorlesung nochmals be sonders betont werden falls er wichtig ist Dar ber hinaus werden aus jeder Kategorie besonders gute oder interessante repr sentative Antworten gezeigt Die Ver ffentlichung erfolgt anonym da das ffentliche Nennen des Namens von den be troffenen Studierenden oftmals als peinlich emp funden wird Die Studierenden erkennen aller dings ihre eigene Antwort und erhalten dadurch eine extra Motivation Online Plattform Zur Durchf hrung der Quiz verwenden wir die E Learning Plattform ILIAS https www ilias de Die Quiz werden dort als Test eingestellt Mit ILIAS ist es m glich die maximale Bearbeitungszeit und den sp testen Abgabetermin automatisch zu setzen Insbeson dere die Bearbeitungszeit l sst sich nur mit einem Online System genau ermitteln Die Fragen in den Quiz sind berwiegend Freitextfragen manchmal kombiniert mit einer Auswahlfrage die das grobe Einteilen der Antworten in Kategorien automati siert hat Bei der oben schon erw hnten Frage nach einem Bug im Firefox Webbrowser muss man sich beispielsweise zun chst in einer Aus wahlfrage f r oder gegen das Verschieben des Ver ffentlichungstermins entscheiden bevor man seine Wahl in einer Freitextfrage begr ndet Da es bei Freitextfragen nicht m glich ist die Antwor ten vom System automatisch bewerten zu lassen muss die Bewertung vom Lehrenden beim Durchsehen der Antworten
330. rgebnisse erzielt haben steht f r den gege benen Fall aus Die Aussagen der Studierenden am Ende des Semesters unsere eigenen Beobach tungen und der Leistungsvergleich mit fr heren Jahrg ngen legen f r uns jedoch nahe dass wir unser Ziel erreicht haben Wir sind berzeugt dass die Quiz das Verst ndnis nachhaltig verbes sert haben und werden JiTT weiterhin in der be schriebenen Weise einsetzen Literatur Dubs R 2006 Besser schriftlich pr fen Pr fun A Spillner H Lichter Hrsg SEUH 13 gen valide und zuverl ssig durchf hren In Neues Handbuch Hochschullehre Einzelbei trag H 5 1 Huber L 2011 Forschen ber eigenes Lehren und studentisches Lernen Scholarship of Teaching and Learning SoTL In Das Hoch schulwesen vol 59 Heft 4 S 118 124 Kautz C 2006 Aktives Lernen in Gro en Vorle sungen Einsatz von internet gest tzten Vortests und interaktiven Vorlesungsfragen In Schlattmann J Hrsg Die Bedeutung der Ingenieurp dagogik Hamburg S 1 8 Luo W 2008 Just in Time Teaching JiTT im proves student s performance in classes ad aptation of JiTT in four geography courses Journal of Geoscience Education v 56 n 2 p 166 171 Metzger C 2011 Studentisches Selbststudium In Schulmeister R Metzger C Hrsg Die Workload im Bachelor Zeitbudget und Stu dierverhalten eine empirische Studie M ns ter u a S 237 276 Novak G Patterson E
331. rhalb der Hochschule gearbeitet zu haben Es stellt sich die Frage wie dieses Potential f r die Forschung an Hochschulen genutzt werden kann Im Folgenden beschreiben wir unsere Erfahrungen mit einer Grupper Master Studierender im ersten Semester denen wir die Aufgabe gestellt haben aus einem Pool von Forschungsthemen eines auszuw hlen und eine Ar beit in Form eines Artikels zu schreiben Das erkl rte Ziel war publizierbare Ergebnisse zu generieren Unsere Erwartungen wurden wesentlich bertroffen Einleitung Die Besch ftigung mit aktueller Forschung ist in vie len Studieng ngen durchaus Gegenstand der Lehre jedoch oft nur abgekoppelt von anderen Veranstaltun gen im Rahmen von Seminararbeiten und Literatur studien Die Einheit von Forschung und Lehre wird vielerorts nicht praktiziert Euler 2005 Software En gineering bietet aber weitreichende Fragestellungen die eine Kombination von Forschung und Lehre inter essant machen Broy u Pree 2003 Wie wir versucht haben das Potential welches Master Studierende mit an die Hochschule bringen f r die Forschung zu nut zen m chten wir im Folgenden anhand unserer Er fahrungen mit einer Gruppe von 19 Studierenden im ersten Semester des Master Studienganges Software Engineering and Management an der Hochschule Heil bronn beschreiben Bei der Gruppe handelt es sich um internationale Studierende entsprechend wurden alle Veranstaltungen auf Englisch durchgef hrt des Weite re
332. rhalten eines Spiegels Bei der Anforderungsanalyse gibt sich der Kunde der Autor zun chst bewusst unkooperativ und dreht den Studierenden das Wort im Mund herum oder ignoriert Ihre Fragen So merken die Studie renden dass die Ermittlung von Anforderungen schwierig ist Nachdem dieses Verhalten des Kun den beleuchtet wurde gibt sich der Kunde koope rativer damit die Studierenden ihrem Ziel nach eindeutigen und vollst ndigen Anforderungen n her kommen k nnen Wie zuvor angesprochen ist ein weiterer wichtiger Aspekt die Vermittlung von Wissen ber den Zu sammenhang der Arbeitsprodukte im Software Engineering Beispielsweise basiert das Design auf Entscheidungen diese wiederum auf Anforderun gen Diese Zusammenh nge verstehen die Studie renden durch ihre Abgaben Meistens wird in das Projekt mindestens eine Anforderungs nderung eingebaut Das Ziel ist es den Studierenden Konse quenzen dieser in der Praxis blichen Situation zu zeigen Es soll das Bewusstsein gesch rft werden dass in solchen Situationen verschiedenste Arbeits produkte zu berarbeiten sind Oft ist bei Studierenden der genaue Anteil der Im plementierung am Gesamtumfang des Projektes nicht bekannt Die Studierenden werden der Reihe nach gefragt wie hoch sie den Anteil sch tzen Am Ende nennt der Autor einen Anteil von 10 15 Nat rlich h ngt dies stark vom Umfang des Pro jekts der Dom ne und der Entwicklungsans tze ab Da meist die Sch tzun
333. rlegt generiert der Editor den grauen Hilfstext Was ist f r einen Entwickler ein Merkmal f r Verst ndlichkeit wenn es um Quellcode geht siehe Abb 4 Sobald der Anwender auf ein Feld mit grauem Hilfs text klickt und einen Eintrag vornehmen will ver schwindet dieser und das Textfeld ist f r den Anwen der freigegeben Die graue Farbe wurde bewusst dem Anschein eines fl chtigen Tooltipps nachempfunden A Spillner H Lichter Hrsg SEUH 13 Ausgangshypothesen Hilfestufe Grauer Text Automatischer Text IMomentane Erwartung ber die Qualit tsfaktoren 1 Verzweigungstiefe ist sind momentan zu hoch Momentan betr gt Verzweigungstiefe ber 15 McCabe Wert pro Klasse Vorschl ge 2 Aussagekraft der Variablennamen ist sind momentan zu niedrig Mind 20 der Variablennamen werden nicht eindeutig abgek rzt Vorschl ge Weiteres Eingabefeld Hilfestufe Grauer Text Automatischer Text Einflusshypothese Was beeinflusst wie die Qualit tsfaktoren 1 Der Qualit tsfaktor Verzweigungstiefe wird beeinflusst durch lt bitte Wert eintragen gt Vorschl ge 2 Welcher Faktor k nnte Einfluss auf die den Aussagekraft der Variablennamen haben und wie sieht dieser Einfluss aus Vorschl ge Weiteres Eingabefeld Abbildung 5 Hilfestellung im Quadranten 2 und 3 Automatischer Hilfstext
334. rnens von Software Engi neering EVELIN F rderkennzeichen 01PL12022 A B C D E F Projekttr ger DLR Das Verbundvorhaben EVELIN ist im Bund L nder Programm f r bessere Studienbedingungen und mehr Qualit t in der Lehre angesiedelt Die Hoch schulen Aschaffenburg Coburg Kempten Lands hut Neu Ulm und Regensburg sind Verbund partner weitere Informationen unter www las3 de und www qualitatspakt lehre de Wir danken auch den Reviewern unseres Artikels f r ihre konstruktiven Anmerkungen Literatur Abke J Brune P Haupt W Hagel G Landes D Mottok J Niemetz M Pfeiffer V Studt R Schroll Decker I Sedlmaier Y 2012 EVELIN ein Forschungsprojekt zur systemati schen Verbesserung des Lernens von Software Engineering Erscheint im Tagungsband des Embedded Software Engineering Kongress 2012 Bailey T Forbes J 2005 Just in Time Teaching for CSO SIGCSE 2005 St Louis USA Faulstich P Zeuner C 2010 Erwachsenenbil dung Beltz Verlag Weinheim Fleischer R 2004 Just in time Better Teaching in Hong Kong Proceedings of the Second Teach ing and Learning Symposium Hafele H Maier H fele K 2010 101 e Le rning Seminarmethoden Methoden und Strategien fiir die Online und Blended Learning Seminar praxis managerSeminare Verlags GmbH Bonn Hagel G Mottok J Utesch M Landes D Studt R 2010 Software Engineering Lernen fiir die berufliche Praxis
335. rojekt Sim4SEEd wurden Ideen entwickelt mit welchen vorhandenes Potential weiter ausgesch pft wird Diese Ideen bilden die Kernelemente einer neuen Spielumgebung welche im Rahmen des Projekts entwickelt wird Sim4SEEd www sim4seed org ist ein laufendes Forschungsprojekt Der derzeitige Fokus der Pro jektaktivitaten liegt auf der Konzeption einer pas senden Gesamtarchitektur und der Modellierung der Simulationskomponente welche die Einbin dung von Softwareprozessen aus dem Eclipse Pro cess Framework EPF unterst tzt Literatur Akilli G 2007 Games and Simulations A New Approach in Education In Games and Simulations in Online Learning Research and Development Frameworks Information Sci ence Pub S 1 20 Barros M O Dantas A R Veronese G O u a 2006 Model driven game development experience and model enhancements in software project management education In Software Process Improvement and Practi ce 11 4 S 411 421 Breuer J 2010 Spielend lernen Eine Bestands aufnahme zum Digital Game Based Lear ning Landesanstalt f r Medien Nordrhein Westfalen LfM Drappa A Ludewig J 2000 Simulation in software engineering training In Proceed ings of the 22nd international conference on Software engineering New York NY USA ACM ICSE 00 S 199 208 DOI 10 1145 337180 337203 A Spillner H Lichter Hrsg SEUH 13 En Ye Chang Liu Polack Wahl J A
336. rten Beno tungsanteile so dass allein die individuelle Leis tung z hlt und nicht die notwendigen Beitr ge f r das Gesamtsystem Ungekl rt bleibt auch die Effek tivit t eines Peer Assessments zur Erkennung bzw Benennung von Trittbrettfahrern Nach dem Kenntnisstand des Autors am n chsten an das in diesem Beitrag vorgestellte Bewertungs raster kommt der Vorschlag von Wikstrand und B rstler 2006 heran In ihrem Bewertungsansatz erwirbt ein Team gem seiner Leistung eine An zahl von Credits f r verschiedenste Aufgaben im Projekt dazu geh ren die Erstellung von Artefak ten und Projektpl nen ebenso wie gehaltene Pr sentationen Am Ende des Projekts sind die Team mitglieder gefordert diese Credits eigenst ndig untereinander zu verteilen so dass sich gegebenen falls individuelle Abstufungen in der Benotung ergeben F r die Betreuer besteht bei offensichtli chen Ungerechtigkeiten eine Eingriffsm glichkeit Eine effektive Erkennung von Studierenden die auf Grund mangelnder Vorkenntnisse nicht hinrei chend zum Fortschritt des Teams beitragen konn ten gibt es bei diesem Vorschlag allerdings wiede rum nicht es wird allein auf gegenseitige soziale Kontrolle durch die Studierenden selbst gesetzt Verschiedene Empfehlungen zur Verminderung dieses Problems wie auch zur organisatorischen Durchf hrung von Softwaretechnik Projekten ins gesamt geben beispielsweise van der Duim et al 2007 Sie schlagen vor Free Ri
337. rung mit Ja va Ihreads in U Jaeger K Schneider Hrsg Software Engineering im Unterricht der Hoch schulen 2009 Seiten 131 144 dpunkt verlag Heidelberg 2009 A Spillner H Lichter Hrsg SEUH 13 Bra08 J Brauer Grundkurs Smalltalk Objektori entierung von Anfang an Eine Einf hrung in die Programmierung 3 Auflage Vie weg Teubner Wiesbaden 2009 Far12 J Farell Java Programming 6 Auflage Course Technology Cengage Learning USA 2012 Fla08 D Flanagan The Ruby Programming Lan guage O Reilly USA 2008 HMG11 C Heinisch F M ller Hofmann J Goll Java als erste Programmiersprache 6 Auflage Vieweg Teubner Wiesbaden 2011 HSRM10 Hochschule RheinMain Modulhand buch Angewandte Informatik 2010 Dad06 M C Jadud An Exploration of Novice Compilation Behaviour in Blue PhD Thesis University of Kent 2006 http kar kent ac uk 14615 1 An Exploration of Novice Compilation Behaviour in Blue p df Kle12 S Kleuker Technischer Bericht http home edvsz hs osnab rueck de skleuker querschnittlich Blue JUserMa nualMID pdf KS12 P Kinnunen B Simon My program is ok am I Computing freshmen s experiences of doing programming assignments Computer Science Education 22 1 Seiten 1 28 2012 MFRW11 L Ma J Ferguson M Roper M Wood Investigating and improving the models of programming concepts held by novice pro grammers Computer Science Education 21 1
338. rveranstaltung die somit Just in Time vorbereitet wurde wurden zun chst die Probleme der Studierenden mit dem Stoff behandelt und danach die erneute Fragerunde mit den Klickern durchgef hrt Hierbei erhielten die Lehrenden das A Spillner H Lichter Hrsg SEUH 13 zweite Feedback ber den Wissensstand der Stu dierenden Danach konnten noch offene Fragen diskutiert oder weitere Beispiele behandelt wer den Mit diesen beiden Feedbacks waren die Feed back Zyklen des reinen Just in Time Teachings ersch pft Drittes Feedback Die Lehrenden wollten dar ber hinaus einen pas senden Umgebungsrahmen zur Verbesserung wei terer Lernprozesse im Bereich der personalen sozi alen Kompetenzen sowie der Aktivit ts und Handlungskompetenz schaffen Heyse 2009 Dazu wurde eine Vertreterin einer realen Unternehmens organisation als Kundin eingeladen Wichtige Pers nlichkeitseigenschaften der Kundin waren selbstbewusstes und sicheres Auftreten Offenheit und Bereitschaft zum Praxisdialog Entscheidungs und Schlagfertigkeit Da in der Zusammenarbeit mit den Studierenden Feedback erwartet wurde waren Kommunikations und Kooperationsf hig keit weitere Rahmenparameter Die gemeinsame Bearbeitung des Projekts Bewerbermanagement portal fand in der bungsstunde statt Die Studie renden mussten also zus tzlich zum Selbststudium und zur Just in Time Teaching Fragerunde keine weiteren bungsaufgaben bearbeiten Damit blieb de
339. rverwendet werden Dieser GQM Baum kann mit fiktiven Messwerten in Simulation ausgewertet werden Damit sollen L cken fehlende Daten im GQM Baum aufgedeckt werden GQM Diva ben tigt ein fertig ausgef lltes Abstraction Sheet als Eingabe Dessen Erstellung wird nicht unter st tzt Auch die Erstellung eines Messplans wird von GQM DIVA nicht abgedeckt Chen u a 2003 stellen mit dem Multi Agent Sys tem ISMS Intelligent Software Measurement System eine Vision eines intelligenten Wizzards zur Durch f hrung der GQM Methode vor Der Anwender gibt ein Unternehmensziel ein und beantwortet interakti ve Fragen Schrittweise werden verfeinerte Messziele individuelle Metriken etc anhand der Anwenderant worten auf intelligente Weise herausgesch lt Dies soll mithilfe von eigenen Agents und einer angeschlos A Spillner H Lichter Hrsg SEUH 13 senen Knowledge Base samt Reasoning Mechanism geschehen Am Ende soll ein fertiger und einsatzbe reiter Messplan ausgegeben werden Der Ansatz ist interessant scheint jedoch noch nicht praktisch umge setzt zu sein Auch werden Abstraction Sheets nicht betrachtet MetriFlame ist von VTT Electronics entwickelt wor den und dient zur Sammlung Analyse und Pr sentati on von Messdaten Die Grundidee ist dass dieses Tool automatisch Daten f r eine anstehende Messung sam melt indem es sich mit verschiedenen Datenbanken anderer Tools verbinden kann Parviainen u a 1997 setzte MetriF
340. s Interesse liegt zu n chst auf einer klaren Strukturierung von For schungsdaten Erst sp ter ist m glicherweise eine weitere Differenzierung sinnvoll und notwendig 4 Wozu sollten Kompetenzen be schrieben werden Die erforderlichen fachlichen und berfachlichen Kompetenzen im Software Engineering sollen er hoben analysiert und beschrieben werden um darauf aufbauend Lehrziele didaktische Methoden und kompetenzorientierte Pr fungen weiter zu entwickeln Die erhobenen Kompetenzen werden in einem Kompetenzprofil zusammengefasst und stellen so ein umfassendes Bild dar was ein Soft ware Ingenieur unmittelbar nach der Hochschul ausbildung kennen und k nnen soll Kompetenz profile sollen sowohl f r den Bereich der Kernin formatik als auch f r Software Engineering im Ne benfach wie etwa Mechatronik erfasst werden Darauf aufbauend soll erforscht werden welche Einflussfaktoren die Kompetenzf rderung im Software Engineering beg nstigen so dass in der Hochschulausbildung gezielt kompetenzf rdernde Rahmenbedingungen geschaffen werden k nnen Die Kompetenzbeschreibung ist somit eine we sentliche Grundlage f r die weitere empirisch experimentelle Didaktikforschung Kompetenzbe schreibungen werden ben tigt um die Ziele der akademischen Ausbildung klar beschreiben zu k nnen und eine Vergleichsm glichkeit zu schaf fen inwieweit diese Ziele dann tats chlich erreicht wurden Dazu ist eine systematische vergleichbare
341. s Interfaces List gibt Konsequenzen Da Interfaces in Java ein recht abs traktes Konzept sind sollten m glichst viele Auf gaben nach der Einf hrung von Interfaces gezielt ihre Vorteile demonstrieren Dabei muss darauf geachtet werden dass es sich nicht um Aufgaben handelt die eher den Einsatz von Implementations vererbung nahe legen 5 Diskussion Eine Motivation f r diesen Artikel entstand aus dem Umstand dass wir unsere eigene Program mierausbildung an verschiedenen Stellen zum Ge genstand von Untersuchungen gemacht haben und immer wieder feststellen mussten dass wir in etli chen Punkten vom Mainstream abweichen Ein zelheiten dieser Abweichungen haben wir an ver schiedenen Stellen ver ffentlicht aber das Gesamt bild bisher nicht Die beiden Veranstaltungen SE1 und SE2 haben wir nach den hier beschriebenen Konzepten ent worfen und f hren sie seit dem Wintersemester 2005 06 jedes Jahr durch In den bisherigen sieben Durchl ufen haben wir sehr viel ber einf hrende Programmierveranstaltungen gelernt und diese Erfahrungen auch in ihre berarbeitung einflie en lassen Beide Module werden in der studentischen Lehreevaluation regelm ig sehr positiv bewertet obwohl sie Pflichtmodule sind Das Gesamtkonzept von SE1 mitsamt dem hier nicht diskutierten Ob jects First Vorgehen Barnes and K lling 2008 wurde von den Studierenden des Jahrganges 2007 08 f r den Hamburger Lehrpreis vorgeschla gen und
342. s die Programmier ausbildung in den Schulen ein extremst unter schiedliches Niveau hat H ufiger sind F lle zu 56 beobachten dass Lehrer die nat rlich ebenfalls auf der Suche nach dem richtigen Ansatz zur Pro grammierausbildung sind zu sehr merkw rdigen Programmierrichtlinien und Programmierstilen f hren Nat rlich ist auch das andere Extrem ver treten bei denen wesentliche Teile von Program mierveranstaltungen an der Hochschule f r Studie rende dank ihrer Schul oder evtl betrieblichen Ausbildung trivial werden Die Frage ob ein In formatik Unterricht mit Inhalten der Studiensemes ter in der Schule berhaupt sinnvoll ist sei dabei am Rande gestellt Eine Analyse des Erfolgs eines Ansatzes ist noch schwieriger da er eigentlich nur durch die intensi ve Analyse der F higkeiten von Studierenden er m glicht wird Da aber die damit verbundene in tensivere Betreuung bereits wesentlichen Einfluss auf den Lernerfolg haben kann wird eine Beurtei lung oder gar ein Vergleich von Ergebnissen sehr schwierig Es stellt sich so die Frage ob statt einer direkten Beobachtung Indikatoren gefunden werden k n nen die auf den Programmiererfolg schlie en las sen Dies k nnte durch die Verbindung von Ent wicklungswerkzeugen mit statischen Analysewerk zeugen geschehen die z B messen wie oft ein Compiler aufgerufen wird und wie oft Fehler z B in gleichen Zeilen dabei gefunden werden Diese Analysewerkzeuge d rfen d
343. s eine Schnittstelle auf verschiedene Weisen implemen tiert werden kann 4 Im Deutschen k nnen wir das Konzept einer Schnittstelle gut von dem Sprachmechanismus unterscheiden indem wir den Mechanismus mit dem englischen Begriff benennen der auch namengebend f r das entsprechende Java Schl sselwort ist 5 Eine Spezifikation die so vollst ndig ist dass eine Implemen tation maschinell abgeleitet werden kann verdient ihren Namen nicht 44 In unserer Programmierausbildung stellen wir Interfaces bereits in der Mitte des ersten Semesters vor Vererbung unterschieden in Typ und Imple mentationsvererbung siehe Schmolitzky 2006 hingegen erst im zweiten Semester In der zweiten H lfte des ersten Semesters wird unter anderem ein nicht generisches Interface f r eine fachliche Liste vorgestellt das die Studierenden in den bungen auf zwei verschiedene Arten implementieren als verkettete Liste und als Array Liste Auf diese Wei se kann diskutiert werden dass Klienten Code vollst ndig von der implementierenden Struktur entkoppelt werden kann und beide Implementati onsformen das Interface korrekt implementieren k nnen Ihre Unterschiede wirken sich lediglich bei der Effizienz bestimmter Benutzungsprofile aus wie h ufiges Einf gen am Anfang der Liste etc ein Aspekt der aus Sicht der Korrektheit nachran gig ist Auf diese Weise kann u a verdeutlicht wer den warum es im JCF verschiedene Implementati onen de
344. samten Kurses vermitteln An schlie end werden Woche f r Woche die zu behan delnden Themen abgearbeitet in der Regel streng sequenziell hintereinander Jedes Thema wird dabei umfassend und ersch pfend behandelt bevor zum n chsten Thema vorangeschritten wird Beispielsweise lernen Studierende im Software En gineering auf diese Weise also zun chst alle Facet ten der Use Case Modellierung kennen Wenn diese abgeschlossen sind folgen Ablaufbeschreibungen mit tels Aktivit tsdiagrammen Danach werden Klassen diagramme durchgenommen gefolgt von Sequenz diagrammen und so weiter Abbildung 1 Wenn die ganzen Modellierungsthemen abgehandelt sind folgt im n chsten gro en Themenblock dann die Softwa rearchitektur Use Cases Hali mi zer trat Klassen Quelltext Abbildung 1 Lehre nach dem Wasserfallmodell Der Vorteil dieses Ansatzes liegt darin dass die Ver anstaltung klar gegliedert ist Insbesondere wird je des Thema umfassend und abschlie end behandelt Des Weiteren sind die Themen klar voneinander ab A Spillner H Lichter Hrsg SEUH 13 gegrenzt Sorgf ltige Mitschriften aus so aufgebauten Veranstaltungen k nnen sich gut als Refernz f r die Pr fungsvorbereitung bzw als Nachschlagewerk eig nen weil alle Informationen die zu einem Themen bereich geh ren im zugeh
345. sch aus dem Abstraction Sheet bernommen und bleiben an der selben Stelle stehen Dies soll Verwirrungen beim un erfahrenen Anwender vermeiden Bedingt durch die Idee der experimentellen berpr fung muss der An wender mit der rechten Seite des Messplans beginnen und zuerst den Einflussfaktor betrachten Da dies et was unintuitiv erscheinen mag wird standardm ig die linke Seite mit einem Hinweis ausgeblendet siehe Abb 6 Pers nliche Workflows k nnen auch realisiert werden der Hinweis l sst sich ausschalten Jede Seite des Messplans gliedert sich in drei Teile die nacheinander ausgef llt werden 1 Frage nach den m glichen Auspr gungen des Fak tors 2 Handlungsanweisungen diese Auspr gungen zu ermitteln 3 Auspr gungen ermitteln und eintragen Die Formulierung der einleitenden Frage nach den Auspr gungen wird mit grauem Hilfstext bzw schwar zem L ckentext unterst tzt siehe Abb 6 beide Texte in den Feldern Frage sind generiert Jedoch sind Schritt 2 und 3 stark projektabh ngig und individuell Dementsprechend kann der GQM Editor diese nicht 145 Hilfestufe Grauer Text Automatischer Text Verzweigungstiefe Auslagerung von Funktionen Frage Welche Frage in Bezug zum Qualit tsf mit dem Mess Frage Welche verschiedenen Auspr gungen kann der Einflussfaktor Auslagerung von Funktionen annehmen Messplan Metrik Welche Schritte so
346. se Nachweise der Effektivit t von JiTT sind nicht durchg ngig auf Zustimmung getrof fen So zweifelt etwa Poth 2009 2 an der statisti schen Belastbarkeit vieler der vorliegenden Studi en und kommt in seiner eigenen Analyse von JiTT zu durchaus skeptischen Einsch tzungen Auch er verwirft die Methode aber nicht sondern for dert genauere Studien unter welchen Bedingun gen sie funktionieren kann Poth 2009 230 vgl Kautz 2006 Dies scheint auch insofern w n schenswert als dass JiTT bei Evaluationen von den Studierenden regelm ig als sehr gut und hilfreich bewertet wird Im Folgenden soll nun erl utert werden wel che Erfahrungen bei der Anwendung von JiTT im Rahmen der Veranstaltung Software Engineering an der Technischen Universit t Hamburg Harburg gemacht worden sind JiTT f r Software Engineering Bei den bisherigen Umsetzungen von JiTT in un terschiedlichen F chern ging es vorrangig darum den Studierenden Grundwissen vor Beginn der Lehrveranstaltung zu vermitteln und den Leh renden einen berblick ber den Wissenstand der Studierenden zu verschaffen Bei unserem Einsatz von JiTT geht es hingegen in erster Linie darum die Studierenden Erfahrungen mit der Komplexi t t von realen Softwareprojekten machen zu las sen Diese Erfahrungen k nnen nur gemacht werden wenn die Studierenden auch an realen Softwaresystemen arbeiten Wir haben uns daher entschieden den Studierenden im Rahmen eines Online
347. seln von Leuten die im Team gemeinsam miteinander arbei ten Dass also auch ein Austausch stattfindet dass sie nicht nur sich von einem Zimmer ins andere eine E Mail schreiben sondern dass sie auch immer diesen m ndlichen Kommunikationsweg und dass viele dar ber sprechen das versuchen wir eigent lich in jeder Weise zu bef rdern Insgesamt scheint der Faktor Zusammenarbeit zunehmend an Bedeu A Spillner H Lichter Hrsg SEUH 13 tung zu gewinnen allerdings ver ndert sich die Arbeitsrealit t in gleichem Ma e Ein Befragter fasst es zusammen Teamf higkeit ist allerdings immer besser ausgepr gt heute weil eben immer mehr in der Ausbildung Arbeiten im Team erle digt werden oder erledigt werden m ssen Das hat sich deutlich verbessert im Lauf der 25 oder 30 Jahre die ich das jetzt betrachte Am Anfang waren viele viele viele Einzelk mpfer da das hat sich deutlich verbessert und das ist auch gut die Ent wicklung ist gut Auf der anderen Seite erkennen die Befragten noch immer Handlungsbedarf Ich sage mal so die Leute haben scheinbar eine gewis se technische Kompetenz aber wie man eine ver n nftige Pr sentation macht wie man einen ver n nftigen Text schreibt wie man in einem Team umgeht wie man Konflikte l st das sind alles Themen die hat der gew hnliche Hochschulab g nger nicht gelernt Ein weiterer sieht darin einen Ausweg f r die Hochschulausbildung dass man Projekte definiert wo wirkl
348. sgabe gezogene Visua lisierung ist auch eine Motivation f r eine Alterna tive zu Blue namens Greenfoot Gre ebenfalls einer Entwicklungsumgebung f r Anf nger die allerdings auf Blue basiert Typischerweise werden mit Greenfoot sogenannte Objektwelten definiert deren Objekte auf einem zweidimensionalen Feld als Objekte platziert werden k nnen Wie in Blue sind dann direkt alle Methoden des Objekts und das Objekt selbst zur Analyse zugreifbar und Me thoden k nnen ausgef hrt werden Das typische Einf hrungsbeispiel sind Wombat Objekte die ber das Feld mit Hilfe der Methoden gesteuert werden k nnen und z B Bl tter suchen und fressen Generell vermittelt Greenfoot so sehr sch n den Objektbegriff man kann sogar einfache Vererbungen verfolgen allerdings wird im Bei spiel Code wieder sehr schnell auf Klassenvariab len und Klassenmethoden zugegriffen Greenfoot nutzt im Wesentlichen dabei eine Objektwelt um zentral die Nutzung von if und while zu trainieren Man muss dabei klar zwischen der reinen Nutzung der Objektwelt bei der die Objekte nur ber Me thoden gesteuert werden k nnen und der Erstel lung neuer Welten Szenarien genannt die von erfahreneren Entwicklern angelegt werden sollten trennen Von Programmieranf ngern wird nur die Erweiterung existierender Szenarien erwartet Greenfoot eignet sich auch um einfache interaktive Spiele zu erstellen wobei hier von der konsequen ten Objektorientierung abgewic
349. sich folgenderma en zeitnah zu Semesterbeginn werden den Stu dierenden grobe Anforderungen an das zu erstel lende System mitgeteilt und sie erhalten erste Auf gaben bzgl der Erfassung und Modellierung der Anforderungen mit direktem Projektbezug Diese sind einzeln oder in Zweiergruppen zu bearbeiten und abzugeben Somit ist gew hrleistet dass jeder Teilnehmer sich individuell einen grundlegenden berblick ber die Anforderungen an das zu erstel lende System erarbeiten muss Idealerweise werden die L sungen der Studierenden kontrolliert oder zumindest in einem Tutorium besprochen aber nicht benotet Gleichzeitig werden erste einfache Programmieraufgaben gestellt die auch dazu die nen die Studierenden mit der verwendeten Ent wicklungsumgebung also z B Eclipse s z B Bur 108 nette amp Staudemeyer 2009 vertraut zu machen falls dies nicht bereits in fr heren Veranstaltungen geschehen ist Programmiertestat amp Kolloquien Nach etwa drei bis vier Wochen wird ein ebenfalls einfaches Programmiertestat mit gro z gig be messener Bearbeitungszeit als erster harter Leis tungsnachweis zum Einstieg in das Projekt ver langt Es bietet sich an dieses als Programmie r bung direkt am Rechner mit Eclipse und den Javadocs aber ohne Internet Zugang durchzuf h ren und den Studierenden Interfaces und JUnit Tests vorzugeben gegen die sie entwickeln m ssen vgl testgetriebene Entwicklung nach Beck 1999 Som
350. sie in der Regel zu korrigieren da sich die Lehrenden in weniger verschiedene L sungsan s tze hineindenken m ssen Welche didaktischen Vor und Nachteile sich aus eng begrenzten oder freieren Aufgaben ergeben und in welcher Phase des Lern prozesses welche Aufgaben am besten geeignet sind soll hier nicht weiter diskutiert werden Stattdessen soll beleuchtet werden wie durch die Anwendung von Softwareproduktmetriken f r Umfang und Kom plexit t berhaupt gemessen werden kann welchen Freiheitsgrad eine Aufgabe hat Die Abbildungen 1 bis 3 zeigen drei Verteilungsdia gramme f r L sungen zu drei bungsaufgaben die in der zweiten H lfte des Wintersemesters 2011 12 gestellt wurden und die durch die Studierenden als Hausaufgaben bearbeitet wurden Aufgetragen sind jeweils Kreise deren Position sich aus der Anzahl der Anweisungen und der zyklomatischen Komplexit t er gibt Je mehr L sungen auf dieselbe Position fallen umso gr er ist der dort dargestellte Kreis Dabei wird unterschieden ob die L sung als bestanden gewertet wurde oder nicht Insbesondere ist zu beachten dass 62 unterschiedliche L sungen dieselben Kennzahlen auf weisen k nnen und an derselben Position sowohl be standene als auch nicht bestandene L sungen liegen k nnen Es ist zu erkennen dass die erste bungsaufgabe Abbildung 1 im Folgenden entsprechend der Benen nung in der Lehrveranstaltung als Miniprojekt 4 be zeichnet im Vergleich zu
351. sitive Lernerfahrung der Studierenden und einen positiven Projektab schluss zu erm glichen wird durch Lehrende h u fig eine Vorauswahl von geeigneter Technologie Werkzeugen Methoden und Prozessen getroffen der die Studierenden dann folgen sollen Die Erh 131 hung des Projektumfangs und der Anzahl der Pro jektmitglieder die Anhebung des Kommunikati onsbedarfs eine st rkere Teilung von Aufgaben und Verantwortlichkeiten sowie das Beharren auf einem definierten Projektergebnis erh hen die Realit tsn he und vermitteln Studierenden ideal erweise einen Eindruck von echter Projektarbeit nach dem Studium Der Blick auf den Softwareprozess als Ganzes geht in solchen Projekten jedoch allzu schnell ver loren wenn Projektmitglieder unter Zeitdruck da mit besch ftigt sind Projektartefakte zu liefern Studierende erhalten nicht die M glichkeit in ver schiedene Rollen zu schl pfen um bspw in der Rolle eines Projektmanagers Zielkonflikte zu sp ren und richtungweisende Entscheidungen treffen zu m ssen Die begrenzte zur Verf gung stehende Zeit erm glicht es nicht alternative Strategien zu verfolgen oder gar andere Softwareprozesse aus zuprobieren Sommerville betont engineering is all about selecting the most appropriate method for a set of circumstances Sommerville 2010 S 7 Um dies zu erm glichen m ssen zuk nftige Softwareinge nieure ihre Optionen kennen Sie m ssen in der Lage sein vielf ltige Asp
352. ss die abgelie ferten und benoteten Artefakte auch von den ent sprechenden Studierenden erstellt worden sind Nat rlich sollte auch die Bewertung Kolloquien auf bekannten Richtlinien und Bewertungskriterien wie z B aus Schubert Henning 2004 aufbauen Ein fr heres Feedback ber die Leistungen der Teilnehmer sollte zur Vervollst ndigung des Ein drucks ohnehin ber regelm ige Gespr che mit den Tutoren erhoben werden so dass bei Verdacht auf mangelhafte Leistungen bereits im Projektver lauf eingegriffen werden kann Auch eine Bewer tung einzelner Artefakte aus f r den Projektverlauf definierten Meilensteinen ist m glich und gibt den Teilnehmern eine fr he R ckmeldung ber ihren Leistungsstand Erfahrungsbericht amp Diskussion Unter der Verantwortung des Autors wurde das vorgestellte kombinierte Bewertungssystem in drei Softwaretechnik Lehrveranstaltungen zwei Mal in einer einsemestrigen Bachelorveranstaltung mit je ca 50 Teilnehmern in Vierergruppen und einmal in einem zweisemestrigen Masterprojekt mit vier Teilnehmern erfolgreich eingesetzt und aufbauend auf vorherigen Erfahrungen immer wieder leicht ver ndert Insbesondere hat sich gezeigt dass die Verwendung der vollen Notenskala also 1 0 1 3 4 0 bzw 5 0 f r die Systembewertung nicht zielf hrend ist da die entsprechend feinen Unter schiede zwischen den Notenstufen zu zeitaufw n dig in der Ermittlung und im Nachhinein praktisch nicht mehr nachv
353. strukturen mit Java thematisiert Das Problem mit diesem Vorgehen ist dass Java trotz ihres vergleichsweise einfachen Sprachmo dells keine leicht zu erlernende Sprache ist F r Programmieranf nger ist der Bogen von imperati ven Ausdr cken und sequentiellen Anweisungen mit typisierten Variablen hin zu Vererbung Poly morphie Generizit t oder gar Nebenlaufigkeit nicht leicht zu schlagen Die Erwartung dass die Teilnehmer nach nur einem Semester Java komplett k nnen kann blicherweise kaum erf llt wer den Alternative Im ersten Semester werden die Me chanismen von Java nicht vollst ndig behandelt sondern nur eine Teilmenge Fortgeschrittene Me chanismen werden erst im zweiten Semester the matisiert Daf r werden schon im ersten Semester elementare Konzepte von Algorithmen und Daten strukturen eingef hrt In unseren einf hrenden Modulen SE1 und SE2 behandeln wir im ersten Semester neben den impe rativen Grundlagen Ausdr cke Anweisungen Kontrollstrukturen Rekursion nur diejenigen ob jektorientierten Mechanismen die objektbasierte Programmierung im Sinne von Wegner Wegner 1987 erm glichen Klassen Objekte Typen Java Referenzen Schnittstellen Vererbungskonzepte werden erst im zweiten Semester behandelt ebenso wie die Mechanismen zur Ausnahmebehandlung Den im ersten Semester entstehenden Freiraum nutzen wir in dessen zweiter H lfte f r einen fr hen Einstieg in die Grundlagen von Algorithm
354. t A Spillner H Lichter Hrsg SEUH 13 Sharelt Who are you Willkommen bei Sharelt der Plattform f r die gemeinschaftliche Nutzung von Ressourcen Who are you Please enter your name Absenden Abbildung 8 Startseite mit Texteingabefeld Sharelt Welcome Hallo Emmi sch n dass du da bist Abbildung 9 Personalisierte Begr ungsseite dessen m glichst simpel anzufangen und die nachfol genden einzelnen Inkremente angemessen klein zu halten Dazu wurde das urspr ngliche Beispiel Thur ner u B ttcher 2010 solange sukzessive immer wei ter abgespeckt und vereinfacht bis es nur noch die wesentlichen zu zeigenden Inhalte Techniken und Zusammenh nge umfasst Die daraus resultierende minimalisierte Version von Spezifikation und System war f r den Einstieg jedoch immer noch viel zu komplex Daher wurde in einem zweiten Schritt noch einmal ganz von vorne mit ei nem leeren Projekt anfangend eine Folge von Spezifi kationen und Systemen erstellt die von der Komple xit t und vom Funktionsumfang her bei null anf ngt und in winzigen Einzelschritten sukzessive aufgebaut wird Am Ende dieser Folge steht die minimalisierte Version auf die das ursp ngliche umfangreiche Bei spiel zuvor eingedampft worden war Nach den bisher gewonnenen ersten Erfahrun gen kommen die Studierenden gut mit dem iterativ inkrementellen Lernansatz zurecht Insbesondere wer den die Zusammenh nge zwischen den einzelnen Dis zipli
355. t um ein m glichst umfassendes Bild zu bekommen Es geht auch darum zu verste hen was z B kommunikative Kompetenz im Kontext von Software Engineering bedeutet Die systematische Erfassung der Soll Kompe tenzen ist Voraussetzung daf r Lernprozesse bes ser analysieren und verstehen zu k nnen Zentrale Fragen sind dann Welche Faktoren wirken ber haupt auf das Lernen Und wie k nnen diese Ein flussfaktoren systematisch erfasst werden so dass dann zielgerichtet diejenigen angepasst und ver n dert werden k nnen die Lernprozesse unterst tzen und so die Soll Kompetenzen gezielt f rdern Hin zu kommt die Schwierigkeit dass Wechselwirkun gen zwischen den Einflussfaktoren bestehen die nderung einzelner Faktoren hat immer Auswir kungen auf andere Es gilt diese Einflussfaktoren auf Lernprozesse im Software Engineering und ihre Wechselwirkungen untereinander mittels Groun ded Theory besser zu verstehen zumal es speziell f r den Bereich Software Engineering noch keine etablierte Theorie gibt 5 Grounded Theory als For schungsstrategie Den methodischen Rahmen f r das gesamte Vor haben bildet die Forschungsstrategie Grounded Theory Glaser et al 1998 die h ufig verwendet wird wenn eine auf Daten gest tzte Theorie zu einem Thema entwickelt werden soll Sie zielt da rauf ab Sachverhalte besser zu verstehen und wird in diesem Forschungsprojekt angewandt um Pro zesse umfassend zu verstehen die dem Lernen von
356. t ein durchg ngiges Beispiel das in Grundz gen vorentwickelt ist und von den Studierenden im Rahmen des Praktikums sukzessive erweitert wird Eine Urversion davon wurde bereits in Thurner u B ttcher 2010 vorgestellt Die folgende Aufz hlung skizziert knapp die Funk tionalit t die sukzessive in den einzelnen Inkremen ten umgesetzt wird Darauf aufbauend verdeutlicht Tabelle 1 welche Techniken und Wissensbereiche in den einzelnen Inkrementen jeweils zum Einsatz kom men 1 Der Administrator startet einen Jetty Server als leichtgewichtigen Application Server Anschlie end greift der Normalbenutzer ber den Brow ser auf den lokalen Port zu unter dem der Jetty Server bereit steht Anhand der angezeig ten Standard Fehlerseite ist erkennbar dass der Application Server im Hintergrund l uft siehe Abbildung 4 2 In der zweiten Aufbaustufe wird die Anfrage an einen Handler weitergeleitet die als Antwort den minimalistisch formatierten statischen Text Hello World erzeugt 3 Das n chste Inkrement f hrt das Zusammenspiel von Java Klasse und parametrisierter Webseite ein Dabei ist das titel Attribut der Java Klasse an die titel Variable der Webseite gebunden Des Weite 74 Use Case 2 Abl ufe 2 Quelltext 2 Abbildung 3 Komplexeres Inkrement 2 HTTP ERROR 404 Problem accessing Sharelt home htm Reason Not Found Powered by Jetty Abbildung 4 JettyServer mit Standardfehlerseite ren
357. t getroffen werden und motivie renden sozialen Elementen ist w nschenswert Das Hinzuf gen eines Teams zum individuellen Spiel jedes Einzelnen erscheint hier erfolgsversprechend Dabei erkunden und bearbeiten alle Spieler indivi duell einen gesamten Softwareprozess Gleichzeitig jedoch agiert jeder Spieler auch in einem Team und sammelt f r dieses Punkte Indem die Performance des Teams die Kumulation der Einzelspielerer gebnisse als prim rer Erfolgsfaktor herangezogen wird werden Zusammenarbeit und Diskussion innerhalb der Teams gef rdert Dashboards welche einerseits Teamrankings und andererseits Rankings einzelner Spieler inner halb dieser Teams zur Verf gung stellen bieten dabei Orientierung Sie zeigen an wie gut bisher getroffene Entscheidungen in Relation zu anderen Spielern waren Diese Orientierung dient als Aus gangspunkt f r Interaktionen innerhalb der Teams und als Anlass f r den st ndigen Versuch Ent scheidungen zu optimieren nicht geboten werden kann Lernende erhalten Feedback zu einem viel fr heren Zeitpunkt als dies in einem realen Kurs Projekt der Fall w re Mehr noch durch die vorgeschlagene Kombi nation aus Einzelspiel und Zusammenarbeit im Team kann parallel auch aus Erfahrungen anderer Spieler gelernt und profitiert werden Das Spiel bietet damit die Basis f r einen probe hypothesize reprobe rethink cycle Gee 2007 S 87 ff der zu einer tieferen Auseinandersetzung mit
358. ta tion mit den erarbeiteten Ergebnissen zu planen und durchzuf hren in den Studierende als kon kurrierende Unternehmensberatungen ihr Ergeb niss des Requirements Engineerings darstellen Eine solche Erweiterung sorgt bei den Stakeholdern einer Hochschule f r angewandte Wissenschaften die sich auch als Hochschule der Region versteht f r besondere Profilierung Fazit Die Methode des Just in Time Teachings hat uns aus einer Vielzahl von Gr nden motiviert Unsere Erfahrungen damit sind durchg ngig als positiv zu bewerten Erste Versuche mit einzelnen Lehreinhei ten waren f r die Einstimmung der Lehrenden auf diese Methode gut geeignet Allerdings bemerkten wir dass die Studierenden viel mehr bei der Sache sind wenn die ganze Lehrveranstaltung nach die sem Prinzip abgehalten wird Die Vorteile der Me thode unter Ber cksichtigung der dritten Feedback Schleife haben wir nach unterschiedlichen Schwer punkten angeordnet teils bereinstimmend mit Fleischer 2004 Unter dem Punkt Studierende haben wir alle Vorteile f r die Studierenden aufge A Spillner H Lichter Hrsg SEUH 13 f hrt unter Feedback alle Vorteile das Feedback betreffend unter Lehrveranstaltung die Vorteile f r unsere Veranstaltungen wenn wir diese Me thode anwenden und unter Sonstige all diejeni gen Punkte die nicht in die anderen Kategorien passen Dabei sind die Grenzen zwischen den Punkten flie end Studierende e A
359. tat immer Funktionalit t implementiert werden die im Miniprojekt nicht diskutiert wurde Daraus ergeben sich auch die Risiken bei der Aufgabenstellung die es durch den Einsatz von Metriken abzusch tzen gilt Zum einen k nnen unterschiedliche Funktionalit ten mehr oder weniger Aufwand erfordern was einzelnen Gruppen Vor bzw Nachteile bringt und zum anderen kann die Funktionalit t in Relation zum Miniprojekt eher aufwendig oder eher einfach zu implementieren sein Die konzeptionelle Arbeit die von den Studieren den beim Entwurf ihrer L sung erbracht werden muss l sst sich freilich ber die Metriken des Ergebnisses nicht bestimmen und folglich in den Betrachtungen auch nicht ber cksichtigt werden Die Abbildungen 4 und 5 zeigen die Verteilungsdia gramme zu zwei Varianten von Testat 4 Die Verteilung der dritten Variante an der deutlich weniger Studie rende teilnahmen sieht vergleichbar aus und wir aus A Spillner H Lichter Hrsg SEUH 13 Anweisungen Abbildung 800 700 600 500 400 300 200 50 70 90 110 130 150 170 190 210 230 250 Komplexit t Bestanden Nicht bestanden 4 Verteilungsdiagramm f r 378 L sungen zu einer Pr fungsaufgabe Testat 4 Variante 1 Die Aufgabe griff die Aufgabenstellung aus Miniprojekt 4 siehe Abbildung 1 auf Zur Verteilung einer zweiten Aufgabenvariante vgl Abbildung 5 Anweisungen Abbildung 800 700 600
360. tio de berblick In vielen Studieng ngen wurden gegen Ende des Studiums Entwicklungs Projekte in den Studien plan aufgenommen Der Autor beobachtete vor mehreren Jahren zwei Dinge F r viele Absolvierende von Ingenieur und Informatik Studieng ngen sind wesentliche Schrit te im Entwicklungsprozess und deren Zusammen h nge nicht klar Trotz oft detaillierter Vorgaben in den Firmen m ssen noch immer viele Aspekte der Software Entwicklung ausgestaltet werden Basierend darauf wurde ein Projekt mit starkem Praxisbezug konzipiert und seit 2007 sieben Mal an der FH Frankfurt und der TH Mittelhessen durch gef hrt und kontinuierlich verbessert Die Studie renden sollen die M glichkeit haben in einem ge sch tzten Raum eigene Erfahrungen zu machen da Erfahrung im Rahmen einer Vorlesung schwer weitergegeben werden kann Das Ziel des Papers ist eine ausf hrliche Beschrei bung der einzelnen Aspekte des Konzepts und eine Diskussion der Erfahrungen Des Weiteren wird ein kurzer Ausblick zu angedachten Erweite rungsm glichkeiten gegeben und am Ende werden die wesentlichen Punkte zusammengefasst Beschreibung des Projekts Das Projekt Objektorientierte Softwareentwicklung f r Steuerger te wurde f r Studierende in Informatik Studieng ngen am Ende ihrer Hochschulausbil dung konzipiert Eines der wichtigsten Kriterien bei der Konzeption war die Praxisn he Drei Entwicklungsteams mit jeweils vier Personen arbeiten i
361. torisches Am Anfang der Lehrveranstaltung ist es notwen dig den Studierenden das Handwerkszeug aus verschiedenen Themengebieten mitzugeben um die Aufgaben im Projekt meistern zu k nnen Dazu findet ein ganzt giger Pr senztermin vor dem Be ginn der Vorlesungszeit statt Jedoch werden schon ab dem zweiten Pr senztermin die Studierenden immer mehr der zur Verf gung stehenden Zeit mit 32 Pr sentationen ausf llen und sp testens ab dem vierten Pr senztermin reagiert der Dozent nur noch bringt aber von sich aus keine weiteren The men ein Wie eingangs beschrieben m ssen die Teams re gelm ig Arbeitspakete abgeben Diese werden nach der Abgabe bewertet und m ssen zu einem Pr senztermin der wenige Tage nach der Abgabe stattfindet vorgestellt werden Abgaben und Pr senztermine finden in Abh ngigkeit des Aufga benumfangs alle zwei bis vier Wochen im Umfang von vier Vorlesungsstunden statt Als Teamgr e wird vier festgesetzt Drei Personen pro Team w re auch m glich Bei weniger Perso nen ist der Arbeitsaufwand der Einzelnen zu hoch bei mehr Personen wird die Aufteilung der Ar beitspakete schwierig Eine durchg ngige Mitarbeit jedes Teammitglieds k nnte nicht sichergestellt werden Ein weiterer wichtiger Aspekt ist die individuelle Benotung jedes Teilnehmers Nat rlich geht in die Benotung zum kleinen Teil das Teamergebnis mit ein aber wesentlich sind die Beteiligung und die erstellten Arbeitsergebniss
362. tritten Gerade Paradigmen Wechsel haben diese Diskus sion befruchtet In diesem Artikel werden drei Er fahrungen in der Programmierausbildung in unter schiedlichen Programmiersprachen an verschiede nen Fachhochschulen zusammengefasst und mit einigen Hintergr nden verkn pft F r die Pro grammiersprache Java werden zus tzlich noch Varianten der didaktischen Herangehensweise diskutiert Einleitung Da fast alle Bachelor Abschlussarbeiten von Fach hochschulen in Unternehmen stattfinden und sich dabei fast immer ein Programmieranteil in dieser Arbeit befindet ist fachliche Programmierausbil dung ein elementares Ziel von Informatik Studieng ngen Dabei soll es f r angehende Absol venten keine Einschr nkungen in der Wahl des Themas durch die am Anfang im Studium gew hl te Programmiersprache geben Es wird davon aus gegangen dass innerhalb des Studiums die F hig keit erlangt wird sich schnell in die Prinzipien einer vorher nicht benutzten Programmiersprache einzuarbeiten Die eigentliche Nutzung der Sprache ist die Basis f r die durchzuf hrenden Arbeiten und wird nebenbei erlernt In der Grundlagenausbildung soll dabei grunds tz lich eine Einf hrung in die Programmierung und nicht in eine bestimmte Programmiersprache statt finden Dies bedeutet dass man aus didaktischen Gr nden lieber auf Sprach Features verzichtet um elementare Konzepte wiederholt intensiver ein ben zu k nnen Studierende sollten sp testens
363. tschieden sie wissen dass ihre Leistungen in der Hochschule auch von ihrem Unternehmen verfolgt werden und oftmals wird die sp tere Weiterarbeit im jeweiligen Unternehmen angestrebt Fachlich bedeutet dies nach den Beobachtungen des Autors dass das zumindest anf nglich leis tungsschw chere Drittel von Studierenden das an ffentlichen Hochschulen anf ngt an der Nord akademie kaum vertreten ist Im oberen Bereich fehlen daf r vereinzelt sehr kreative K pfe die ein stark verschultes Ausbildungssystem bewusst um gehen wollen um experimentelle Freiheiten im Studium zu schaffen Die eigentliche Vorlesung wurde mit dem Objects First Ansatz gehalten der bereits am Anfang auf die Strukturbegriffe Objekt und Klasse setzt Gene rell wurden bei dieser Veranstaltung sehr positive Erfahrungen gemacht die sich in der auf zwei Se mester aufgespaltenen Veranstaltung in gro en Lernfortschritten der Studierenden zeigten Nachdem anf ngliche Schwierigkeiten mit der Syn tax und der zun chst kompliziert dann aber intui tiv nutzbaren Entwicklungsumgebung Visu alWorks ausger umt waren fand eine Konzentrati on auf die eigentliche Programmentwicklung statt Smalltalk nutzt den Begriff der Literale um unver nderliche Objekte immutable Objects zu definie ren so kann ein String Objekt in den meisten Smalltalk Varianten nicht ver ndert werden etwa ige Methoden liefern ein neues String Objekt als Ergebnis Diese Unterscheidung
364. twareprozessen wird durch deren verschiedene Darstellungsfor men erschwert Die Softwareindustrie hat einigen Aufwand in die vereinheitlichte Dokumentation und Kommunikation von Softwareprozessen inves tiert Basierend auf der Software and Systems Process Engineering Metamodel Specification SPEM Version 2 0 Object Management Group 2008 und ihrer Vorg ngerin Unified Method Architecture UMA stehen mit dem Eclipse Process Framework EPF The Eclipse Foundation 2012 Werkzeuge bereit um Softwareprozesse und Methoden zu dokumen tieren zu konfigurieren und zu ver ffentlichen Inhalte werden mit den EPF Werkzeugen standar disiert und relativ komfortabel erstellt Dabei kommt ein gemeinsames einheitliches Vokabular mit definierter Semantik zum Einsatz Der in der Abbildung 4 dargestellte EPF Composer verwendet die vertraute Unified Modeling Language UML um grafische Visualisierungen der modellierten Soft wareprozesse zu erzeugen Diese Visualisierungen unterst tzen die komfortable Erkundung der er zeugten Prozessmodelle Der hierbei erbrachte Einarbeitungsaufwand der Lehrenden und Lernenden ist ber eine spezifi sche Simulations und Spielwelt hinaus von Wert und Nutzen Unterst tzung der Erkundung neuer Soft wareprozesse Die Evaluation bestehender Ans tze digitaler SE Lernspiele hat ergeben dass diese weniger geeignet waren neue Lerninhalte zu vermitteln Wangen heim Shull 2009 Ein Grund daf r d rfte sein
365. twicklung ist die Auspr gung An wendung st rker vertreten 8 2 Requirements Engineering Beim Thema Requirements Engineering erwarten die Befragten ein Verst ndnis daf r welche Rollen Lasten bzw Pflichtenhefte im Anforderungspro zess einnehmen Auch wenn die Mehrheit der Be fragten keine spezielle Technik zur Formulierung von Anforderungen nutzt erwartet sie dennoch grundlegendes Verst ndnis daf r wie sich gute von schlechten Anforderungen unterscheiden Ab solventen sollten Techniken zur Anforderungser hebung sicher und gezielt anwenden k nnen 8 3 Modellierung Im Gebiet der Modellierung werden deutlich an wendungsorientierte Kompetenzen erwartet Ab solventen sollten sowohl im Bereich der System modellierung z B mit der UML als auch der Da tenmodellierung z B ER Modelle ausgepr gte praktische Erfahrungen im Studium sammeln Im Gegensatz dazu spielt das Thema Prozessmodellie rung bei den Befragten eine eher untergeordnete Rolle A Spillner H Lichter Hrsg SEUH 13 8 4 Datenbanken Auch im Themenkomplex Datenbanken dominie ren praktisch ausgerichtete Kompetenzen Vor al lem bei Datenbankentwurf und Datenabfrage er warten die meisten Befragten Kompetenzen auf dem Niveau Anwenden Auch bei der Daten bankprogrammierung wie z B dem Erstellen von Triggern und Funktionen gibt es eine leichte Ten denz in diese Richtung wobei es manchen Inter viewten hier auch gen gt wenn Absolventen ver
366. twortet und f r das gesamte Team ein heitlich benotet f r kursiv gedruckte ist jeder Teil nehmer individuell verantwortlich und bekommt eine eigene Bewertung Eine entsprechende Kenn zeichnung der Dokumente ist daf r wie bereits beschrieben obligatorisch A Spillner H Lichter Hrsg SEUH 13 Im Sinne der agilen Softwareentwicklung Pichler 2007 oder Beck 1999 sollen alle Teilnehmer indvi duell Verantwortung f r vollst ndige Features also meist komplette Use Cases vgl Larman 2004 bernehmen so dass die Anforderungen ver gleichbar bleiben und eine technologieorientierte Aufteilung z B ein Teammitglied programmiert eines entwickelt die UL eines testet und eines er stellt nur Diagramme oder Anforderungen ver mieden wird Details zu den im Folgenden ver wendeten Modellen finden sich bei Bedarf bei Larman 2004 Je nach genauer Ausrichtung der Veranstaltung ist nat rlich auch eine ge nderte Zusammenstellung mit anderen Artefakten wie z B Projektpl nen o oder ver nderten Gewich tungen denkbar Kontextmodellierung 1 Dom nenmodell 2 2 Gesch ftsprozessmodelle 1 bei Wirtschaftsinformatik Bezug Anforderungsmodellierung 3 Use Cases 5 4 Use Case Diagram 1 Analysemodelle 5 System Sequenzdiagramme 3 6 Contracts der Systemoperationen 3 Entwurfsmodelle 7 Schichtenarchitektur und Architekturdia gramm 2 8 Interaktionsdiagramme GRASP und De sign Patterns 5 9 Klassendiagramme 3 10
367. tzung nach diesen Regeln ein Dieser Mechanismus ist zuverl ssiger je eindeutiger die Eingabetexte sind Z B l sst sich anhand der starren Form der Messziel Facette des Abstraction Sheets vier Eingabefelder jeweils meist nur ein Wort ein relativ passender und hilfreicher grauer Hinweistext im ersten Quadranten erzeugen siehe Abb 4 Je variabler die Eingabetexte werden desto unzuverl ssiger kann der generierte Text im n chsten Feld ausfallen Dies kann dazu f h ren dass der generierte Text unbrauchbar wird Graue Hilfstexte verschwinden jedoch auch beim Anklicken und vorgenerierte Antworten schwarzer Text k n nen einfach anwenderseitig bearbeitet oder gel scht werden Werden diese Textst cke generell zu verwir A Spillner H Lichter Hrsg SEUH 13 rend kann der Anwender diese Unterst tzung auch insgesamt ausschalten Die Feinheiten der deutschen Grammatik m nnli che weibliche Artikel Plural Singular werden nicht gesondert behandelt Die generierten Texte sind in dieser Hinsicht m glichst allgemein ausgelegt und verwenden mitunter unsch ne Doppelbelegungen wie z B die den Ein Plugin zur korrekten L sung sol cher F lle l sst sich jedoch nachtr glich einf gen Ge nerell priorisieren wir den Lerneffekt beim unerfah renen Anwender gegen ber vollkommen korrekter Sprachkonstrukte M gliche sprachliche Fehler oder Ungenauigkeiten werden hingenommen solange der Anwender versteht was gemeint ist bzw
368. tzung von Werkzeugen aus dem echten Softwareentwicklerleben Aktuelle kommerzielle Spieletitel begeistern Spieler mit fotorealistischen Darstellungen virtueller Wel ten Einen Wettbewerb um Realit tsn he auf dieser Ebene kann ein digitales Lernspiel mit viel geringe rem Budget und Ressourceneinsatz nur verlieren Wie kann ein Lernspiel jenseits solcher Dimensio nen dennoch relevant und realistisch wirken Die Integration von Werkzeugen aus dem ech ten Softwareentwicklerleben in das Spielerlebnis tr gt an dieser Stelle dazu bei den realistischen Charakter des Lernspiels zu unterstreichen Diese Werkzeuge werden durch simulierte Softwareent wickler getrieben Hierzu ein kleines Beispiel der simulierte Softwareentwickler Bob hat gerade seine Arbeit am Anforderungsdokument beendet Er st t ein Commit in der verwendeten Versions verwaltung an und schlie t anschlie end das Ti cket im Ticket Verwaltungssystem so wie in ei nem echten Softwareprojekt Der Spieler sieht diese Aktivit ten anschlie end in den Aktivit ten und Repository Sichten der jeweiligen Werkzeuge und kann sie nachvollziehen Aktuelle Werkzeuge wie bspw das an der FH Stralsund eingesetzte Redmine Lang 2012 sind quelloffene Webanwendungen und verf gen ber Schnittstellen f r die Integrati 137 on so dass sie auch von simulierten Softwarepro jekten verwendet werden k nnen Studierende welche bereits mit derartigen Werkzeugen gearbeitet haben
369. u dem Schluss dass Kompetenzen mehr sind als reines Wissen oder Fertigkeiten Kompetenzen schlie en Fertig keiten Wissen und Qualifikationen ein lassen sich aber nicht darauf reduzieren Weinert 2001 S 27f gibt eine allgemeinere De finition Kompetenzen sind die bei Individuen verf gbaren oder von ihnen erlernbaren kognitiven F higkeiten und Fertigkeiten bestimmte Probleme zu l sen sowie die damit verbundenen motivatio nalen das Motiv betreffend volitionalen durch den Willen bestimmt und sozialen Bereitschaften und F higkeiten die Probleml sungen in variablen Situationen erfolgreich und verantwortungsvoll nutzen zu k nnen Angelehnt an Weinert unter scheiden wir im vorliegenden Artikel zwei Kompe tenzarten Fachkompetenzen entsprechen den kognitiven F higkeiten und Fertigkeiten e Uberfachliche Kompetenzen beinhalten die motivationalen volitionalen und sozialen Be reitschaften und F higkeiten 118 Somit beschreiben berfachliche Kompetenzen hier diejenigen Kompetenzen die gemeinhin nicht di rekt als Fachwissen bezeichnet werden sondern vielmehr alle F higkeiten die n tig sind um Fachwissen situationsbezogen und zielgerichtet in komplexen Situationen anwenden zu k nnen Die derzeitige Unterscheidung von lediglich zwei Kompetenzarten ohne weitere Unterteilungen liegt darin begr ndet dass aktuell noch keine Aus sagen ber feinere sinnvolle Differenzierungen getroffen werden k nnen Da
370. u entdecken und damit einander hnliche L sungen zu finden Handelt es sich dabei um Fehlerschwerpunkte k nnen diese in Lehrveranstaltungen gezielt auf gegriffen werden Handelt es sich dagegen um gute L sungen die jedoch von der Musterl sung messbar abweichen kann dies Hinweise auf einen alternativen L sungsweg geben der in einer zwei ten Musterl sung ber cksichtigt werden k nnte e Ebenfalls durch die Analyse aller L sungen und den Vergleich dieser Mengen ber verschiedene Aufgaben hinweg k nnen Aussagen ber generel le Merkmale der jeweiligen Aufgaben getroffen werden Zum Beispiel l sst sich so der minimale Umfang einer korrekten L sung ableiten oder Auf gaben k nnen anhand des Mittelwertes verschie dener Kennzahlen miteinander verglichen werden Letzteres ist insbesondere auch in vollautomati sierten Systemen nutzbar die auf diese Weise rele vante Eigenschaften von Aufgaben lernen k nnen Die letzte Kategorie steht im Fokus des vorliegen den Beitrags Dabei wird davon ausgegangen dass der Einsatz von Metriken in diesem Fall nur dann zu aussagekr ftigen Ergebnissen kommt wenn eine gr ere Menge von Aufgabenl sungen analysiert wer den kann Erst dann erscheint eine Verallgemeinerung der durch Kennzahlen gewonnen Aussagen auf die Aufgabe insgesamt sinnvoll da in einer freien Auf gabenform wie Programmieraufgaben eine zu kleine Stichprobe kaum als repr sentativ angesehen werden kann Aus der Gesamtheit
371. ualit t einfordern Hier gilt es sicherlich von der Ausbildungsseite her ein Augenmerk da rauf zu haben Die Simulationen von agilem Vorgehen mittels Games XP Scrum hat sich sehr bew hrt In den Games erfahren die Studierenden wichtige agile Konzepte wie selbst organisierte Teams und h ufi ge Auslieferungen in sehr intensiven Mini Projekten die sich entsprechend einpr gen Im Hinblick darauf dass vor allem die agilen Wer te aber auch deren Praktiken nicht durch einmali ges Vermitteln sondern durch Vorleben und st n dige Anwendung erlernt werden m ssen ist es wichtig dass diese Praktiken auch in den sonstigen Programmiermodulen zum Einsatz kommen Die neuen zus tzlichen Anforderungen an die Do zierenden sind dabei nicht zu untersch tzen Die Dozierenden der entsprechenden Module m ssen sich die notwendigen Grundlagen aneignen Die Vorlesungen m ssen entsprechend angepasst und die agilen Praktiken in die eigenen Module inter giert werden Der h here Aufwand der Dozieren den ist sicher eine Herausforderung welcher aber aus unserer Sicht durch das gute Resultat mehr als gerechtfertigt ist Ein weiterer wichtiger Vorteil der Vermittlung der agilen Methoden ist dass die vor allem von XP propagierten allgemeinen Best Practices viel st rker ins Bewusstsein der Studierenden r cken und auch eine st rkere Akzeptanz erfahren da mit jeder Ite ration eine Qualit tskontrolle stattfindet Zusammenfassung un
372. udenten in diesen Schritten von dem Teamleiter beantworten wer den konnten und der Kunde trotz alledem die fertigen Dokumente pr sentiert bekam und selber entscheiden konnte ob sie fertig sind F r die meisten Studenten war es das erste Mal dass sie in einem gr eren Entwicklerteam an einem gemeinsamen Projekt arbeiten mussten Der Kanban Prozess war keinem der Studenten vor dem Prakti kum bekannt Eine Einf hrung in den Kanban Prozess und das Kanban Board war zwar durch in den Work shop gegeben aber diese war nach unserer jetzigen Erfahrung zu kurz Aus diesen beiden Tatsachen resul tierten w hrend des Praktikums Unsicherheiten der Studenten was zu tun ist oder wo sie helfen konnten Nachdem die Erfahrung mit dem Prozess und dem 95 Board merklich zunahm wurden die Zeiten in denen die Studenten aufgrund der Limits keine Arbeit am Projekt leisten konnten f r die Studenten demotivie rend In der Kanban Literatur Anderson 2010 wird die ser n tzliche Spielraum Slack genutzt um einer seits den Prozess zu optimieren und andererseits den Entwicklern die M glichkeit zu bieten sich selbstst n dig fortzubilden Als Fortbildungsm glichkeit definier ten wir einige M glichkeiten in Form von Tutorials und Literatur die sich um die benutzte Technologie oder solche die sp ter noch genutzt werden sollte drehten Diese hatten damit den zus tzlichen Nutzen f r den Kunden dass das Wissen ber die Technologi
373. uf der SC 2012 durch die Reviewer angenom men und im Juni 2012 unter Hesenius u a 2012 ver ffentlicht Die Nichtbestehensquote lag bei ca 36 Eine auf f llige Korrelation mit dem Einf hrungstest besteht aus guten Ergebnissen folgten auch gute Arbeiten Nat rlich gibt es erfreuliche wie unerfreuliche sta tistische Ausrei er So verhoben sich zwei durchaus begabte Studierende mit guten Ergebnissen im Ein f hrungstest an der Programmieraufgabe b F r die Zukunft ist zu pr fen wie mehr Lehrinhalte eingewoben werden k nnen etwa durch Kombination mit dedizierten Veranstaltungen zum wissenschaftli chem Schreiben Literatur Broy u Pree 2003 BRoy Manfred PREE Wolf gang Ein Wegweiser f r Forschung und Lehre im Software Engineering eingebetteter Systeme In Informatik Spektrum 26 2003 Januar Nr 1 S 3 7 ISSN 0170 6012 1432 122X Euler 2005 EULER Dieter Forschendes Lernen In W Wunderlich amp S Spoun Hrsg Universit t und Pers nlichkeitsentwicklung Frankfurt New York Campus 2005 Hesenius u a 2012 HESENIUS Marc OROZCO ME DINA Carlos D HERZBERG Dominikus Touching factor software development on tablets In Procee dings of the 11th international conference on Softwa re Composition Berlin Heidelberg Springer Verlag 2012 ISBN 978 3 642 30563 4 S 148 161 lhttp sites google com site varsa2012 http we24 ifip org SC2012 A Spillner H Lichter Hrsg
374. ule UpdateNumActsProgra Effect Rule Trigger UpdateNumActsProgra Effect Rule Destroyer Remove Rule SetNotidleProgramT Effect Rule Trigger SetNotidleProgramC Effect Rule Continuous SetldieProgram Effect Rule Destroyer v u Add New Effect Rule Add New Create Objects Rule Add New Destroy Objects Rule CreateAcceptanceTests aj Design CreateUnitTests Actions LearnCodingStandard Program PairProgramRobertJoyce PairProgramTimothyReda X Abb 2 Ausschnitt aus SimSE s Regeleditor Abbildung 1 zeigt einen Screenshot von SimSE Navarro 2006 einer an der University of California Irvine entwickelten Spielumgebung welche aktuell die Erkundung der zahlreichsten Softwareprozesse erlaubt Die simulierten Soft 133 wareentwickler mit ihren verschiedenen Eigen schaften welche durch das simulierte Softwarepro jekt gesteuert werden sind neben bereits erstellten Artefakten zu erkennen Abbildung 2 stellt den grafischen Regeleditor von SimSE dar ber wel chen sowohl der Softwareprozess als auch das spe zifische Anwendungsszenario modelliert werden Sichtbar ist hier nur ein kleiner Ausschnitt der mo dellierten Regeln des Simulationsmodells welches die Basis des Spiels darstellt Ergebnisse bisheriger Forschungsprojekte Die Auswertung bisheriger Forschungsprojekte zeigt gro es Potential aber auch einige Ambivalen zen Bisherige Ans tze scheinen besser geeignet bereits erworbenes
375. und Retrospektiven werden richtig gemacht die Implementationen dauern jeweils nur zwei Minuten In diesen zwei Minuten kann nat r lich kein Code entwickelt werden Anstelle werden kurze einfache Tasks wie zum Beispiel ein Kar tenhaus bauen oder etwas im Kopf ausrechnen durchgef hrt Das XP Game wurde bis jetzt vier Mal mit je ca 25 Studierende im Master Studiengang im Rahmen des Moduls Software Engineering and Architec ture 3 ECTS 19 durchgef hrt Interessant sind dabei folgende Beobachtungen Die erste Iteration ist typischerweise sehr chao tisch Die Sch tzungen sind schlecht und die Selbstorganisation der Teams funktioniert nicht Nach der Retrospektive am Anschluss an die erste Iteration nimmt die Selbstorganisation der Teams merklich zu Ab der zweiten Iteration funktionieren die Teams die Sch tzungen werden viel besser Die Velocity wird erstaunlich konstant Der Lerneffekt in dieser kurzen Zeit ist sehr gross Die Studierenden sind aktiv am arbeiten Das XP Game macht grossen Spass Das Feedback der Studierenden ist durchwegs po sitiv Die Studierenden sch tzen es insbesondere auf eine spielerische Art einen grossen Lerneffekt zu erzielen Scrum City Game Ein alternativer Ansatz um agile Management Praktiken zu vermitteln und insbesondere zu er fahren ist das Scrum Lego City Game 15 Hier bekommen die einzelnen Teams die Aufgabe ge stellt in einem Mini Projekt w hre
376. und definieren sechs Schritte 1 Ziele erheben und verfeinern Goal 2 Facettenbeschreibung der Ziele Goal 3 Ableitung von charakterisierenden Fragen Ques tion zu den Zielen 4 Ableitung von zugeh rigen Metriken Metric 5 Messplan f r eigentliche Datenerhebung erstellen Metric 6 Datenerhebung und Auswertung Collection In terpretation Die Einordnung dieser Schritte in das umfangreiche Prozessmodell der GQM Methode nach Van Solingen u Berghout 1999 ist in Abb 1 eingezeichnet Schritt 1 produziert einen sogenannten Zielbaum welcher ein high level Messziel auf konkretere Sub ziele verfeinert und in Beziehung miteinander setzt Aus diesem Zielbaum werden Subziele zur weiteren Bearbeitung ausgew hlt Die Facettendarstellung des Messziels Schritt 2 forciert die Auseinandersetzung mit verschiedenen Aspekten eines Ziels und regt zur abgewandelten Betrachtung an F r die Ableitung von charakterisierenden Fragen zu einem Messziel nun vorliegend als Zielfacette Schritt 3 wird ein spezielles Formular eingesetzt das sogenannte Abstraction Sheets Van Latum u a 1998 Van Solingen u Berghout 1999 Gantner u Schnei der 2003 Es bietet eine festgelegte Struktur Mittels vier vordefinierten Fragestellungen baut der Anwen der systematisch ein Modell des zu untersuchenden Messziels auf und gelangt zu tiefergreifendem Ver st ndnis Der Qualit tsaspekt des Betrachtungsgegen standes z B Verst ndlich
377. und so das Wissen ber erfolgreiche L sungen der Softwaretechnik Lehre lebendig halten k nnen In diesem Sinne rufen wir alle auf die sich mit der Lehre der Softwaretechnik besch ftigen ihre eigenen Erfolgsrezepte beizusteuern unter http www sewiki de Danksagung Die Idee ein Wiki zu nutzen um Kon zepte der Softwaretechnik Lehre auszutauschen ent stand 2008 in Diskussionen mit Kurt Schneider Han nover dem wir zu tiefem Dank verpflichtet sind Die Muster der Saarbr cker Veranstaltungen gehen auf jahrelange Feinarbeit mit zahlreichen Tutoren zur ck f r deren Anregungen wir ebenfalls sehr dankbar sind 101 Muster Spiel als Aufgabenstellung Ziel Ziel ist es zum einen die Zeit zu minimieren die ben tigt wird um sich dom nenspezifisches Wissen bez glich der Aufgabe anzueignen Zum anderen jedoch und viel wichtiger zeigen sich die Studierenden bei Verwendung eines Spiels als Implementierungsziel besonders motiviert Der Sinn der Aufgabenstellung wird kaum kritisiert Motivation Insbesondere in einem Vollzeit Praktikum das innerhalb recht kurzer Zeit stattfindet ist es wichtig dass nicht zu viel Zeit aufgewendet werden muss um die Aufgabenstellung und die sich daraus ergebenden Konsequenzen zu verstehen Mit der Verwendung von Spielen insbesondere von Brettspielen als Implementierungsziel wurde die Erfahrung gemacht dass die Studierenden innerhalb von einem bis maximal zwei Tagen die Aufgabe klar
378. ungen mit denselben Kennzahlen eingereicht Anweisungen 110 130 150 170 190 210 230 250 Komplexit t Bestanden Nicht bestanden Abbildung 2 Verteilungsdiagramm f r 815 L sungen zu einer bungsaufgabe Miniprojekt 5 Gr ere Kreise bedeuten mehr L sungen mit denselben metrischen Kennzahlen Es wurden maximal 155 L sungen mit denselben Kennzahlen eingereicht A Spillner H Lichter Hrsg SEUH 13 63 800 700 600 u e oO D Q oO Anweisungen 300 200 100 T T T T Bestanden 150 170 190 210 230 250 Komplexit t Nicht bestanden Abbildung 3 Verteilungsdiagramm f r 600 L sungen zu einer bungsaufgabe Miniprojekt 6 Gr ere Kreise bedeuten mehr L sungen mit denselben metrischen Kennzahlen Es wurden maximal 85 L sungen mit denselben Kennzahlen eingereicht wiederfinden Zum anderen kursierten in den studenti schen Internetforen inoffizielle Musterl sungen an de nen sich ebenfalls Studierende orientiert haben Wie oben beschrieben wurden die Daten nicht um Plagia te bereinigt Stichproben zeigten jedoch dass es sich bei den Anh ufungen nicht ausschlie lich um Plagiate einer einzelnen L sung handelt Relatives Aufgabenniveau Das didaktische Konzept der untersuchten Lehrver anstaltung sah vor dass zu jedem der oben disku tierten Miniprojekte eine kleinere Pr fungsaufgabe i
379. unktionalit t angesehen werden Weiterhin setzt sich bei durchschnittlich begabten Studieren den bei frei gestaltbaren Programmieraufgaben in h heren Semestern eher der Ansatz durch alles m glichst mit Klassenmethoden l sen zu wollen Einen ersten Bruch mit der imperativen Herange hensweise gibt es sp testens wenn Strings oder Arrays genutzt werden sollen da es sich hier um Objekte handelt auf denen Methoden genutzt werden k nnen Arrays deren Umsetzung in Java aus didaktischer Sicht sicherlich diskutabel ist 50 werden dann zum Problem wenn sie an Funktio nen automatisch per Referenz bergeben werden Unabh ngig vom didaktischen Ansatz bietet Java als hybride Sprache eine weitere Falle f r Anf nger mit dem bergang vom elementaren Datentypen zu seiner kapselnden Klasse z B von int zur Klas se java lang Integer die z B bei der Nutzung von Listen ben tigt wird Zwar findet im Wesentlichen die Umwandlung durch Autoboxing automatisch statt wird aber durch null Werte und die Festle gung dass die Integer Werte von 128 bis 127 iden tisch genauer Singletons sind die anderen nicht bemerkenswert kompliziert Das folgende Pro gramm zeigt diese Probleme public static void main StringL s ArrayList lt Integer gt 1 new ArrayList lt gt 1 add 10 1 add 1000 Integer vgll 10 Integer vgl2 1000 for Integer val 1 if val vgl1 System out printIn val ist 10 if val vgl2
380. unsichere Anwender wird mit gezielten Fragestellungen durch den Ausf ll prozess gef hrt Studierenden soll so eine m gliche Ablehnung gegen ber der komplex anmutenden GQM Methode genommen werden Studierende sollen mit diesem Werkzeug Gelegenheit erhalten das korrekte Ausf llen von Abstraction Sheets zu ben Werner 2012 hat die in dieser Arbeit vorgestellten Konzepte in einem lauff higen Webtool realisiert Die GQM Methode Die GQM Methode wurde bereits in zahlreichen Ver f fentlichungen behandelt Im folgenden wird ein kur zer berblick ber die GQM Methode gegeben in der Form in welcher diese an der Leibniz Universit t Hannover gelehrt wird Schneider 2007 um den Wirkungsbereich unseres GQM Editors aufzuzeigen Der grundlegende Ablauf der GQM Methode sieht die schrittweise Erstellung eines GQM Modells auch GQM Baum genannt vor Abstraktere Ziele werden 141 Abbildung 1 GQM Methode an der Leibniz Universit t Hannover basierend auf Van Solingen u Berghout 1999 in konkrete Subziele Goal aufgeteilt Subziele wer den durch beschreibende Fragen Question scharf und zweckm ig umrissen Zur Beantwortung der charakterisierenden Fragen werden Metriken Metric erstellt die den Erf llungsgrad der Fragen und somit den Erreichungsgrad des Ziels angeben Abb 2 zeigt einen solches GOM Modell Zu Lehrzwecken spalten wir Teile der GQM Metho de auf
381. ur Erzeugung und Verarbeitung graphischer Elemente bereits zur einfachen Nutzung vorliegen wodurch die eigent liche Processing Sprache definiert wird Dazu ge h ren auch viele Varianten Farbt ne anzugeben und detailliert Fonts auszuw hlen Im obigen Bei spiel sieht man wie die Hintergrundfarbe als eine M glichkeit mit einem int Wert festgelegt wird Mit stroke wird die Farbe f r die n chsten gemal ten Objekte festgelegt Dabei ist die Grundidee hnlich wie beim Malen selbst dass man durch Funktionen festlegt wie gemalt wird und dies dann f r alle folgenden Malaktionen gilt Das Beispiel zeigt auch dass in Processing einfach einige negative Magie genutzt wird um das Pro grammieren zu erleichtern Es gibt eine Boolesche A Spillner H Lichter Hrsg SEUH 13 Variable mousePressed mit der der Zustand der Maus abgepr ft werden kann Weiterhin befindet sich die aktuelle Mausposition in den Variablen mousex und mouseY sowie die unmittelbar vorherige Position in den Variablen pmouseX und pmouseY Processing ist keine prozedurale Sprache wie C da die Klassen der Java Klassenbibliothek genutzt werden und auf deren Objekte mit Methoden zu gegriffen wird Es entsteht so eine Mischung aus Funktionen und Methodenaufrufen Die Entwick lungsumgebung enth lt keinen Debugger Seman tisch programmiert man in Processing eine Erwei terung einer Klasse processing core PApplet in die der Code aus dem Editor eingebaut wird
382. uter Society Press 2005 IEEE 2012 IEEE Computer Society Software En gineering Body of Knowledge vorldufiger Stand der Version 3 www computer org portal web swebok abgerufen am 28 10 2012 2012 77 Lehner 2009 LEHNER M Viel Stoff wenig Zeit Haupt Verlag Stuttgart 2009 Rupp u Joppich 2009 Rupp C JOPPICH R Dokumentenberge oder Bierdeckel Requirements Engineering in Zeiten der Agilit t heise Developer http www heise de developer artikel Requirements Engineering in Zeiten der Agilitaet 804971 html abgerufen am 28 10 2012 2009 Thurner u B ttcher 2010 THURNER V B TTCHER A Beispielorientiertes Lernen und Lehren im Soft ware Engineering In ESE 2010 Embedded Software Engineering Kongress 2010 S 591 595 78 A Spillner H Lichter Hrsg SEUH 13 Vermittlung von agiler Software entwicklung im Unterricht Martin Kropp FHNW martin kropp fhnw ch Andreas Meier ZHAW meea zhaw ch Zusammenfassung ber den Hype hinaus der um agile Softwareent wicklung entstanden ist zeigen verschiedene Um fragen dass dieses Vorgehen in der Praxis in ver schiedener Hinsicht tats chlich zu Verbesserungen in der Durchf hrung von Software Projekten f hrt Firmen die agile Methoden einsetzen geben an dass sie seither zufriedener mit ihrem Entwick lungsprozess sind und insbesondere der Umgang mit Anforderungs nderungen sich wesentlich ver bessert hat Andererseits sind entspreche
383. utzutage in Kontakt kom men sind interaktive Systeme Egal ob Rich Client auf dem Desktop Thin Client f r das Web oder mobile Anwendung f r ein Smartphone die Prin zipien reaktiver Systeme sind bei allen grundle gend relevant Gut entworfene interaktive Systeme haben spezifische Eigenschaften u a Unterschei dung von Model View und Controller saubere Tren nung fachlicher und technischer Klassen gute Mo dularisierung die eine fr he Thematisierung von Schnittstellen in der Programmierausbildung nahe legen Wir adressieren in der Pflichtveranstaltung SE2 explizit die Konstruktion interaktiver Anwendun gen w hrend die Studierenden ihre in SE1 erwor benen Kenntnisse zu Algorithmen und Datenstruk turen bei entsprechendem Interesse in einem Wahlpflichtmodul vertiefen k nnen Konsequenzen Ein fr her Fokus auf die Pro grammierung reaktiver Systeme erfordert dass Entwurfsmuster fr h in die Ausbildung einbezo gen werden In SE2 thematisieren wir explizit auch die Prinzi pien von grafischen Benutzungsoberfl chen am Beispiel von Swing Dazu f hren wir auch die Konzepte von Entwurfsmustern ein indem wir exemplarisch zentrale Muster wie das Beobachter muster thematisieren und implementieren lassen Wir haben dabei explizit nicht den Anspruch den Katalog der Gang of Four Gamma et al 1995 voll st ndig abzudecken Ein schrittweises Einf hren einzelner Muster an geeigneten Stellen innerhalb der Programmierausbil
384. verschiedener Aspekte und das Setzen unterschied licher Priorit ten Die Ausbildung im Software Engineering SE muss dieser Vielfalt Rechnung tragen um die Softwareingenieure von morgen zu bef higen Aus Zeitgr nden k nnen die Lerninhalte stets nur eine Auswahl aus einem breiten Spektrum sein W h rend die Auswahl der Inhalte im Detail variieren wird ist es breiter Konsens dass neben allen tech nologischen Aspekten und Werkzeugen ein fun diertes Wissen ber Softwareprozesse essentiell f r die erfolgreiche Gestaltung von Softwareprojekten ist Motivation Aufkommende und sich in den Vordergrund dr n gende agile Prozesse propagieren den Verzicht auf Ballast die Nicht Nutzung von Methoden und Werkzeugen welche wichtige Bausteine traditio nellerer Entwicklungsprozesse bilden Ohne Erfah rung in der Entwicklung komplexerer Softwaresys teme k nnen die Konsequenzen der Nicht Nutzung von Methoden und Werkzeugen jedoch nur schwerlich qualifiziert eingesch tzt werden Das Kennenlernen verschiedener Softwareprozesse kann an dieser Stelle helfen Methoden und Werk zeuge sowie deren Wirkung besser einsch tzen zu k nnen Durch Lehrende gesteuerte Kursprojekte er g nzen heute gew hnlich klassische Vorlesungen im Bereich des SE Akademische Rahmenbedin gungen wie begrenzte Zeit und die Notwendig keit individuelle Leistungen der Studierenden zu bewerten begrenzen Gr e Umfang und Typen solcher Projekte Um eine po
385. vierende Charakter von Spielen f rdert die intrinsische Motivation der Lernenden indem er sie dazu motiviert die Verantwortung f r den ei genen Lernfortschritt zu bernehmen Akilli 2007 Jede Verbindung von Ausbildungsinhalt educatio nal content und digitalen Spielen wird dabei als Digital Game Based Learning DGBL bezeichnet Prensky 2007 DGBL f rdert den Lernprozess indem durch die Integration attraktiver Spielele mente wie Interaktivit t Herausforderungen kontinuierlichem Feedback Multimedialit t dem Geftthl der Selbstwirksamkeit Wettbewerb und Belohnungen eine motivierende und fesselnde Lernumgebung bereitgestellt wird Digitale Spiele k nnen demnach ein selbstgeleitetes Lernen durch Exploration erm glichen und bef rdern Breuer 2010 S 12 Bisherige Ans tze Wir finden heute bereits eine Reihe von verf gba ren Anwendungen von Simulation und DGBL f r den Bereich des SE Tabelle 1 fasst Charakteristik und F higkeiten verschiedener Ans tze zusammen in welchen es explizit um SE Inhalte Softwarepro A Spillner H Lichter Hrsg SEUH 13 zesse und deren Elemente geht Nicht alle in der Tabelle aufgef hrten Projekte sind f r den direkten Einsatz in der SE Ausbildung verf gbar Einige Ans tze werden nicht mehr aktiv entwickelt Die in den jeweiligen Projekten gewonnenen Erkenntnisse sind jedoch auch in diesen F llen in Publikationen dokumentiert In der letzten Spalte der Tabell
386. was gerade von ihm verlangt wird Der smarte GQM Editor stellt keine Silver Bullet f r die GQM Methode oder das Erstellen von Abstracti on Sheets dar Der Anwender soll jedoch verstehen was von ihm verlangt wird und wie solche Formulare gehandhabt werden Der smarte GQM Editor hilft dabei auf die Spr nge kreative und korrektive Arbeitsschritte seitens des Anwenders werden dabei aber nicht ausgeschlossen Die praktische N tzlichkeit der hier vorgestellten Konzepte konnte nicht im universit ren Umfeld evalu iert und validiert werden Eine umfangreiche Evalua tion ist bereits in Planung Da diese Konzepte aber auf praktischer Lehrerfahrung basieren sind wir zuver sichtlich dass Studierende davon profitieren werden Zusammenfassung und Ausblick Die GQM Methode wurde seit seiner Vorstellung durch Basili 1992 erfolgreich in Industrieprojekten eingesetzt und hat die Entwicklung von verschiede nen Werkzeugen angetrieben Lehrerfahrung an der Leibniz Universit t Hannover zeigt jedoch dass die GQM Methode bei Studierenden nur Akzeptanz findet wenn sie praktisch ausprobiert und eingesetzt wird Jedoch schrecken die komplex anmutenden Formulare wie Abstraction Sheet oder Messplan Studierende ab In dieser Arbeit wird ein lauff higer smarter GQM Editor vorgestellt Er bietet eine webbasiert Editor Oberfl che f r die beiden Formulare Abstraction Sheet und Messplan und richtet sich in erster Linie an uner fahrene GQM Anw
387. werden diese Vorschl ge vorgestellt und er rtert F r die SEUH konnten wir mit Bernd Br gge und Peter Zimmerer zwei sehr interessante Pers n lichkeiten als eingeladene Vortragende gewinnen Bernd Br gge TU M nchen berichtet ber seine Erfahrungen beim Multimedia Einsatz in Software Engineering Projektkursen Peter Zimmerer von der Siemens AG pr sentiert das Software Enginee ring Curriculum in der betrieblichen Weiterbildung bei der Siemens AG und berichtet ber die gemach ten Erfahrungen sowie ber kritische Erfolgsfakto ren Organisatorisch gibt es 2013 eine Neuerung Die SEUH wird als Teil der Multikonferenz Soft ware Engineering durchgef hrt Diese b ndelt die deutschsprachigen Tagungen im Bereich Software Engineering SEUH SE 2013 Motto Software Innovator f r Wirtschaft und Gesellschaft und SEE Software amp Systems Engineering Essentials Dadurch wird die RWTH Aachen Ende Februar 2013 zum Treffpunkt der deutschsprachigen Soft ware Engineering Community Unser besonderer Dank gilt den Autoren die eine Vielzahl von Beitr gen eingereicht und somit erst eine Auswahl erm glicht haben Die Auswahl der Beitr ge und die thematische Struktur der dies j hrigen SEUH wurden wie immer von einem Pro grammkomitee vorgenommen Folgende Hoch schullehrerinnen und Hochschullehrer haben daran mitgearbeitet Axel B ttcher Hochschule M nchen Marcus Deininger Hochschule f r Technik Stuttgart Ulrike
388. werden diese wie dererkennen und Parallelen herstellen k nnen Anderen Studierenden werden sie im Laufe ihres Studiums noch begegnen und dann schon etwas vertrauter vorkommen F rderung von Analyse und Reflexion Neben der aktiven Probleml sung kontinuierli chem Feedback und sozialer Interaktion in Teams tragen verschiedene Perspektiven zu einer konstruktivistischen Lernumgebung bei Das aktive Steuern der simulierten Charaktere in der Spielumgebung stellt eine erste Perspektive dar Die gesammelten Statistiken w hrend des Spiels liefern eine aggregierte zweite Sicht Inte grierte Werkzeuge aus dem echten Softwareent wicklerleben liefern eine dritte realit tsnahe Per spektive Die verf gbare Beschreibung des Soft wareprozesses welche w hrend des Spiels erkun det wird stellt eine weitere Perspektive dar die gleichzeitig vom gespielten Anwendungsszenario abstrahiert Da die Spielumgebung mit dem Eclipse Process Framework EPF auf einem frei verf gbaren Indust riestandard basiert ist es ohne weiteres m glich Studierende im Anschluss an ein Spiel in dieses einzuf hren Mit dem EPF Composer k nnen bspw eigene Prozesse modelliert analysiert und diskutiert werden was die Reflexion und die ber tragung des erworbenen Wissens auf andere Szena rien und Kontexte f rdert Bessere Wiederverwendbarkeit und web basierte Architektur Die Trennung von Spiel und Simulationskompo nente er ffnet die M glichkeit nur e
389. zu expressions stellt A Spillner H Lichter Hrsg SEUH 13 eine sehr einfache Umfangsmetrik dar Im Gegensatz zur Z hlung von Codezeilen lines of code hat sie den Vorteil dass sie resistent gegen ber Formatie rungs nderungen am Programmcode ist und die L n ge eventueller Code Kommentare nicht ber cksichtigt Das Ergebnis dieser Metrik wird daher nur durch tat s chliche inhaltliche nderungen am Programmcode beeinflusst Allerdings haben nicht alle nderungen am Programmcode Einfluss auf die Metrik da Erwei terungen oder Vereinfachungen an Ausdr cken ex pressions nicht ber cksichtigt werden Die Metrik kann auch bei Aufgaben mit vorgegebe nen Codevorlagen verwendet werden da die Anzahl der dort vorgegebenen Anweisungen ebenfalls gemes sen und gegebenenfalls vom Ergebnis f r studentische L sungen abgezogen werden kann Ferner k nnen die Kennzahlen didaktisch verwendet werden da die Vermeidung unn tig aufw ndiger und umfangreicher L sungen zu den Lernzielen einer Veranstaltung ge h ren kann Zudem hilft die Metrik zum Beispiel bei der Bestimmung der Schwierigkeit einer Aufgabe da mehr Anweisungen im Programmcode in der Regel einen erh hten Zeitaufwand bei der Erstellung der L sung bedeuten Halstead Metriken Die nach ihrem Autor benannten Halstead Metriken Halstead 1977 basieren ebenfalls auf der Messung der L nge eines Programms ziehen aber zus tzlich noch die Menge der versc
390. zung ein gef hrt Komplexere Design Refactorings werden in den folgenden Semestern eingef hrt Dazu wird ein Katalog der verschiedenen Refactorings abge geben und mit den Studierenden durchgearbeitet A Spillner H Lichter Hrsg SEUH 13 Erg nzt wird dieses Thema durch die Anwendung von komplexeren Refactorings wie Extract Class Extract Method Move Method anhand von Case Studies z B bei berschreitungen von Schwellwer ten bei Qualit tsmetriken Test Driven Development TDD und Refac toring TDD ist eine anspruchsvolle Engineering Practice Um TDD wirklich zu beherrschen w re es am Bes ten wenn die Studierenden einen erfahrenen Soft ware Entwickler als Coach zur Seite h tten Da dies im Rahmen einer Vorlesung oder bungsstunde nicht wirklich realisierbar ist sind alternative Vor gehensweisen n tig Bew hrt haben sich folgende Alternativen e Case Studies e Programming Katas e Experten Videos e B cher und Fachartikel W hrend den Studierenden mittels Experten Vi deos und Fachliteratur die konzeptionellen Aspek te des TDD vermittelt werden k nnen sollen Case Studies und Programming Katas den Studierenden dazu dienen den TDD Ansatz praktisch zu ben und insbesondere dessen Einfluss auf Testbarkeit und Software Design selbst zu erfahren Automated Builds Automated Builds werden mit Hilfe von Ant Skripts und einem Code Versioning System CVS wie zum Beispiel SVN oder GIT eingef hrt Um den voll
391. zur technischen Umsetzung erst ein Semester sp ter stattfindet Selbst wenn die Software Engineering Lehrveran staltungen durchg ngig ber zwei Semester hinweg konzipiert und durchgef hrt werden bleibt der gro e zeitliche Abstand zwischen Modellierung und Imple mentierung problematisch Letztlich dauert es insge samt zu lange bis in den K pfen der Studierenden ein rundes Bild der gesamten Disziplinen im Software Life Cycle entsteht sodass Zusammenh nge und Ab h ngigkeiten zwischen den einzelnen Techniken und Disziplinen oft erst sehr sp t erkannt werden Dadurch sinkt nicht nur die Lernintensit t sondern auch der Spa faktor da der Nutzen vieler Inhalte erst gegen Ende des Entwicklungszyklus deutlich wird Falls zwischen dem dritten und vierten Semester dann auch noch der die Dozierende wechselt und im Praktikum ein anderes Anwendungsbeispiel ver wendet kommt der die Studierende unter Umst nden berhaupt nicht an den Punkt an dem selbsterstellte Spezifikationen zu einem laufenden System umgesetzt werden m ssen Dadurch fehlt ein sehr wesentlicher Erkenntnisschritt im gesamten Lernprozess da die Studierenden nicht unmittelbar an der eigenen Arbeit erfahren wie sich ihre bei der Modellierung gef llten Entscheidungen bei der Implementierung auswirken und wieviel Mehraufwand ggf erforderlich ist um Modellierungsfehler auszub geln die ihren Ursprung in Anforderungsanalyse und Entwurf haben aber erst bei der Implementi

Volltext - SE 2013

Contents

Download Pdf Manuals

Related Search

Related Contents